how to handle optional properties correctly?

[eliprand]

I am storing an object I receive from another API/Library. One of the properties is optional. When passed to StorageMap.set() it stores it with an undefined value. I currently do not enforce the schema on .set(). But when reading it back, i keeps complaining about invalid schema.

Here is my schema:

export const DISPLAY_USER_INFO_JSON_SCHEMA: JSONSchema = {
    type: 'object',
    properties: {
        firstName: { type: 'string' },
        lastName: { type: 'string' },
        name: { type: 'string' },
        partner: { type: 'string' },
        passwordExpiration: { type: 'string' },
        username: { type: 'string' },
    },
    required: ['name', 'partner', 'username'], // i originally did not have that, but that did not help
};

and here is my data from IndexDB:

firstName: "Eric"
lastName: "Liprandi"
name: "Eric Liprandi"
partner: "snapfish"
passwordExpiration: undefined
username: "ericl"

I tried returning null from the API/library, but same result.
The only fix I have right now is to pass '' (the empty string). It's not ideal, but I can live with i.

How can I handle this situation directly with the library?

[cyrilletuzi]

Hi,

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

const user = {
  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:

const user = {
  firstName: "Eric",
  lastName: "Liprandi",
  name: "Eric Liprandi",
  partner: "snapfish",
  passwordExpiration: undefined,
  username: "ericl"
};

if (user.passwordExpiration === undefined) {
  delete user.passwordExpiration;
}

Given that in TypeScript passwordExpiration?: string is equivalent to passwordExpiration: string | undefined, it would make sense to allow explicit undefined 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 to localStorage, which needs data serialization with JSON.stringify(), which will remove undefineds (as it doesn't exist in JSON).

So it means you would not get the exact same value when reading back (as undefined properties would have been stripped by serialization), which would be an issue in some scenarios (for example in Jasmine toEqual() 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 doing this.storage.set('key', undefined) the lib will delete the key instead of trying to store undefined.

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

[eliprand]

Merci pour la réponse et pour pour le package ;)