feat: allow for new flag source #17806
Conversation
|
|
||
| export type Actions = SetMe | ||
| export type Actions = ReturnType<typeof setMe> |
There was a problem hiding this comment.
migrated to new reducer coding standard while i was in here
| const seedStore = configureStore(localState, history) | ||
| const seedState = seedStore.getState() | ||
| clearStore() |
There was a problem hiding this comment.
this whole process seems a bit circuitous. Is this all being done to simply ensure that the initialState is set correctly?
There was a problem hiding this comment.
to share the store around the app without recreating stores, i had to make it a singleton, which makes sense for a single page app. maybe a slight interface change to allow for multiple stores to be created will be required in the future, but the desired outcome is to provide the developer the ability to say "give me the store" without explicitly plumbing it everywhere. There be some abstraction dragons here, but i like to think we're using the store as a singleton anyways, just allowing connect to be that interface that obfuscates the plumbing for us, so it's not THAT bad. the clearStore works like how we use the /debug/flush endpoint for e2e tests, so that we can inject fresh data into the singleton on every test. This specific stuff looks weird because we're using a store to load a store, but overwrite specific things, instead of injecting a default store with overrides, which i can imagine is to allow for greater flexibility in how that default store gets defined / created and more easily mirror actual application state than keeping a derived state in sync with an explicit one.
some ground work for: https://github.com/influxdata/idpe/issues/6654
related to: #17851
the intended behavior is that a user gets their feature flags assigned to them on the server, whos state is sent to the client on a
/api/v2/flagsrequest. If a developer wants to override the feature flag on the client, or add a feature flag that is only used on the client, they can do so using an interface much like the current one.the api work isn't merged yet, so this just moves the feature into redux, and allows the existing functionality to operate until we start fleshing out the contract