[Feat] Add User change event listener and getters for OneSignal Id and external Id

[shepherd-l]

Description

1 Line Summary

Adds change event listener, onesignalId and externalId properties to OneSignal.User.

Details

The User change event listener has the same name as the PushSubscription change event listener and should not be added to the same emitter because it will lead to both events being fired twice. Another emitter was added in the UserNamespace. All other namespaces still use the same static emitter from the OneSignal class.

The User emitter is static because there are two instances of UserNamespace where one is created on the property and again later when OneSignal initializes. When addEventListener is called by the dev, the event is being added before OneSignal initializes and to the property instance (new UserNamespace(false)). To keep the event on the new instance after initialization, the emitter is static.

OneSignal.ts
_initializeCoreModuleAndOSNamespace() {
  …
  OneSignal.User = new UserNamespace(true, subscription, permission); // initialize: boolean
}

static User = new UserNamespace(false); // initialize: boolean

Future considerations:

• Change externalId to be a property on User
• Add unit/integration tests
• Add an emitter for each namespace

Systems Affected

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

Validation

Tests

Manually tested OneSignal.User.onesignalId, OneSignal.User.externalId, and User change event firing when calling login and logout on the OneSignal WebSDK Sandbox.

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

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

---

Related Tickets

---

---

This change is