chore: move initialization into class methods, limit singleton use #170
Conversation
| @@ -287,308 +584,42 @@ export function buildStorageKeySuffix(apiKey: string): string { | |||
| * @public | |||
| */ | |||
| export function offlineInit(config: IClientConfigSync): EppoClient { | |||
| const isObfuscated = config.isObfuscated ?? false; | |||
| return client; | ||
| } | ||
|
|
||
| async function explicitInit(config: IClientConfig): Promise<EppoClient> { |
There was a problem hiding this comment.
moved to EppoJSClient.init
typotter
changed the title
src/index.ts
Outdated
| * @internal | ||
| * @param config | ||
| */ | ||
| async init(config: IClientConfig): Promise<EppoJSClient> { |
There was a problem hiding this comment.
no changes here from explicitInit
| * @internal | ||
| * @param config | ||
| */ | ||
| offlineInit(config: IClientConfigSync) { |
There was a problem hiding this comment.
no changes from offline init
| : initFromConfigStoreError | ||
| ? initFromConfigStoreError | ||
| : new Error('Eppo SDK: No configuration source produced a valid configuration'); | ||
| applicationLogger.warn( |
There was a problem hiding this comment.
The diff makes it hard to see what's left in this method;
- We keep the
forceReinitializecheck here to keep it out of the EppoJSClient.init method - Warn if an initialization is currently in progress
|
Just a thought here, since this will require a major version bump, does it even make sense to deprecate the old APIs? Since we're doing a major departure in terms of API design, it might not make sense to keep deprecated APIs around, as that will make the internal design a lot more complicated. Since upgrading will require code changes anyways (assuming it will be a major bump), then we might as well just redesign it as a blank slate, not worrying about deprecations. WDYT? |
labels: mergeable
Eppo Internal
🎟️ towards FF-3888
📜 Multiple Eppo Clients
Configuration Side-loading
Motivation and Context
This PR is carved from #166 in an attempt to make #166 focused on the the "new" API. This PR adds no net new functionality, however, the new
EppoJSClient.initmethod, marked @internal does allow for unbuffered initialization calls just as the globalinitmethod previously allowed. This internal method can be made private once we remove the globalinitmethod in the next major release.The
initandgetInstance()methods work on a singleton instance of theEppoJSClientwhich makes for a generally smooth developer experience given that the Eppo SDK essentially handles dependency management for the dev. This does have its own drawbacks, but those are not particularly relevant here.There are use cases, however, when a non-singleton instance of the
EppoJSClientis required. One such use case is embedding the Eppo SDK into a library which itself can be included in other applications. If that 3p library shipped with Eppo is integrated into another application that has the Eppo SDK running, there would be undefined behaviour as the SDK cannot handle this use case.TL;DR: We want to move away from singleton access and allow for multiple instance of the EppoJSClient while maintaining the current API
Description
instancethroughgetInstance()EppoJSClient.instanceinitializedandensureInitializedclass members; still setEppoJSClient.initializedas before to ensure backward compatibility with the current APIHow has this been documented?
How has this been tested?