Consent & local storage config flag

[shandilya3]

Description

• personalizationStorageEnabled is set to true by default. Local storage is only created when the flag is enabled.
• If a customer sets personalizationStorageEnabled to false at some point, local storage is cleared.
• consent can have three states: in, out, pending
• when personalizationStorageEnabled is true and consent is in, in that case local storage is setup once the consent is resolved.
• in the case of defaultConsent set to out, await consent promise is not resolved & the promise falls into catch block, where we clear the local storage if it existed before.
• in the case of defaultConsent set to pending, sendEvents calls are queued up and processed only when opted-in

Future work :

• will add additional test with functional tests in the same PR

Related Issue

Motivation and Context

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (non-breaking change which does not add functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA or I'm an Adobe employee.
• I have made any necessary test changes and all tests pass.
• I have run the Sandbox successfully.

[jasonwaters]

I'm not sure we need the eventContext object. I see what you are trying to accomplish here, but i'd like to encapsulate the logic for event persistence within the eventRegistry as much as possible. It can manage event persistence without introducing another layer of abstraction above it.

The createEventRegistry method takes a storage parameter, this parameter specifies what to use for storage. What if we create a new function createInMemoryStorage() that provides a lean implementation of getItem and setItem where events are only stored in memory. This would be better than nothing, if the user opts out of consent or the customer disabled personalizationStorage.

// on initialization
const eventRegistry = createEventRegistry({ storage: createInMemoryStorage() })

Once the consent promise resolves, if the user opted in, you can set a new storage on the event registry.

eventRegistry.setStorage(storage.persistent); // this method doesn't exist yet, you'd need to add it. 

☝️ this would effectively tell eventRegistry to switch from in memory storage to local storage.

[jasonwaters]

If a customer sets personalizationStorageEnabled to false at some point, local storage should also be cleared. That way customer's won't disable it and wonder why they still see an entry in local storage.

[jasonwaters]

I think it's fine to have .awaitConsent() here in the index.js file. But I wonder if it makes sense to move the listener within eventRegistry instead? 🤔 There are pros/cons.

[carterworks]

If a new event registry is set, should it copy over the event history from the previous registry?

[jasonwaters]

looks great @shandilya3 ! Just one suggestion.

[jasonwaters]

I think it's redundant to have both updateStorage and setStorage functions.

I recommend removing this version of setStorage and renaming the updateStorage method above to setStorage. Implementation of setStorage can be modified to accept newStorage for example...

  let currentStorage;
  let restore;
  let save;
  let events;

  const setStorage = newStorage => {
    currentStorage = newStorage;

    restore = createRestoreStorage(currentStorage, STORAGE_KEY);
    save = createSaveStorage(
      currentStorage,
      STORAGE_KEY,
      createEventPruner(MAX_EVENT_RECORDS, RETENTION_PERIOD)
    );
    events = restore({});
  };

  setStorage(storage);