feat: add local override functionality #184
Conversation
yfrancis
changed the title
There was a problem hiding this comment.
Looks like a good foundation for overrides, and I think getAssignmentDetail() is the right place to check for an override.
We will need to be sure to check in the right place for the precomputed client as well.
I think overrides like this could be useful for testing and simple, client-only deployments. For customers using server flags as well, I think we'll need to on-the-fly adjust targeting rules or something to that effect. A mini design review could be helpful in laying out the various use cases.
Note that if we do release this, we'll want to bump the version in package.json before releasing. This should be developed concurrently with the upstream SDK(s) as well.
| }); | ||
|
|
||
| it('returns override values for all supported types', () => { | ||
| overrideStore.setEntries({ |
There was a problem hiding this comment.
Upstream overrideStore is not exposed, so I imagine we need a setOverride() method on the client to add an entry to this store, if present.
yfrancis
force-pushed
the
yf-overrides
branch
2 times, most recently
from
7d01d0f to
0fee52a
Compare
This reverts commit 8cdd8ec.
yfrancis
force-pushed
the
yf-overrides
branch
from
b5e41cf to
d64a2d1
Compare
If overrides have been supplied, use those instead of evaluating rules. Leverages a user-supplied configuration store if present, which may be backed by memory or local storage.