Hi,

Currently, the JSON validator in the lib expects optional object properties to be inexistant:

constuser={firstName:"Eric",lastName:"Liprandi",name:"Eric Liprandi",partner:"snapfish",username:"ericl"};

If it's not possible to directly get that from your other API, you can do:

constuser={firstName:"Eric",lastName:"Liprandi",name:"Eric Liprandi",partner:"snapfish",passwordExpiration:undefined,username:"ericl"};if(user.passwordExpiration===undefined){deleteuser.passwordExpiration;}

Given that in TypeScriptpasswordExpiration?: string is equivalent topasswordExpiration: string | undefined, it would make sense to allow explicitundefined too.

But while testing this solution, it appeared that the current lib behavior is preventing another issue: in some scenarios, the lib is forced to fallback tolocalStorage, which needs data serialization withJSON.stringify(), which will removeundefineds (as it doesn't exist in JSON).

So it means you would not get the exact same value when reading back (asundefined properties would have been stripped by serialization), which would be an issue in some scenarios (for example in JasminetoEqual() tests, which would fail).

Also, more generally,undefined /null can cause a lot of issues in client-side storage APIs. That's why for example when doingthis.storage.set('key', undefined) the lib will delete the key instead of trying to storeundefined.

So I'm not sure yet how and even if we should fix/add this feature. It needs further thinking.