User model/core v2

[rgomezp]

Description

1 Line Summary

Version 2 of the Core Module.

Details

This PR is an overhaul of the v1 version of the core module.

Overview

We drop the previous dependence on the ObservableSlim proxy observer in this PR to trigger changes. We also introduce the concept of executors to handle model-specific logic.

Core v1 problem: while making model changes was very easy, it was difficult to map the model change to an eventual REST call.

Core v2 solution: we expose a new way to trigger model changes that will know exactly what change type we want end-to-end.

Change types

There are three main change types:

1. Add
2. Remove
3. Update

Add and remove change types describe model-level changes. For example, if we call "add," we are adding an entire model (e.g: subscription model object) to a user—same thing with remove. If we call "update," we update a specific property in a specified model.

Update is not called directly (like add & remove) but rather triggered via calling set on an OSModel instance.

Model-agnostic nature

This core module version was designed to be as model-agnostic as possible. Model-specific logic exists only in the executors and the core director class.

Key Components

Model Repo

Contains a model store for each model name (e.g: "IdentityModel"). Also contains top-level change-processing logic. The model repo listens to changes, then processes them based on the change type (add, remove, update).

Model Cache

Used by the model repo to synchronize models in memory with disk.

Operation Repo

In this much-simplified version, the operation repo will be used to tell executors what to do. Operations contain a unique id to find it after the executor completes, the payload, a reference to the relevant model, and a timestamp used for sorting.

Operation Cache

Used by the operation repo to back-up any operations in case they fail or device is disconnected.

Executor

An executor contains the delta and operation queues and the processing logic for deltas and operations. The OSExecutorBase class is the parent class to model-specific executor types. Model-specific logic mainly resides in the processDeltaQueue function for each executor.

Core Module Director

The core module director provides user-model-aware interface through which we can operate on the core module from outside while avoiding heavily nested calls.

More details in individual commits.

Systems Affected

• [x] WebSDK
• [ ] Backend
• [ ] Dashboard

Validation

Tests

Info

Checklist

• [x] All the automated tests pass or I explained why that is not possible
• [x] I have personally tested this on my machine or explained why that is not possible
• [x] I have included test coverage for these changes or explained why they are not needed

Programming Checklist Interfaces:

• [x] Don't use default export
• [x] New interfaces are in model files

Functions:

• [x] Don't use default export
• [x] All function signatures have return types
• [x] Helpers should not access any data but rather be given the data to operate on.

Typescript:

• [x] No Typescript warnings
• [x] Avoid silencing null/undefined warnings with the exclamation point

Other:

• [x] Iteration: refrain from using elem of array syntax. Prefer forEach or use map
• [x] Avoid using global OneSignal accessor for context if possible. Instead, we can pass it to function/constructor so that we don't call OneSignal.context

Screenshots

Info

Checklist

• [ ] I have included screenshots/recordings of the intended results or explained why they are not needed

---

Related Tickets

---

---

This change is 

[rgomezp]

prefer unknown over any, or if you know it'll be non-null use object

[rgomezp]

drop OS prefix from classes/files

[rgomezp]

make unit test for add, remove model