#3 Implement in memory feature store and async wrapper. #8
Conversation
…thodology for logs.
…ttributes-and-context
Co-authored-by: Alex Engelberg <alex.benjamin.engelberg@gmail.com>
|
This pull request has been linked to Shortcut Story #155108: Implement memory data store.. |
kinyoklion
changed the title
kinyoklion
changed the base branch from
main
to
rlamb/sc-154353/implement-basic-loggers
| /** | ||
| * Represents an item which can be stored in the feature store. | ||
| */ | ||
| export interface LDFeatureStoreItem { |
There was a problem hiding this comment.
These interfaces should all be compatible with the data as it already exists. They were just untyped before.
For TS, if people had been using these wrong, and they had implemented their own stores, then they would have to update the types.
There was a problem hiding this comment.
If they used it correctly, then no changes.
| @@ -0,0 +1,75 @@ | |||
| import { DataKind } from '../api/interfaces'; | |||
There was a problem hiding this comment.
Our existing interface uses callbacks. We will still want to be able to use stores written against them. But we will not want to use callbacks because they make the code an unmaintainable hellscape. So, I am providing this adapter so the code can be written sanely.
| import { DataKind } from '../api/interfaces'; | ||
|
|
||
| export interface VersionedDataKind extends DataKind { | ||
| namespace: string, |
There was a problem hiding this comment.
Most of these fields are not used for now, but they will be once a data source is implemented. For now just the namespace is used and only in tests.
These are basically static definitions of the type of data we expect.
Co-authored-by: Matthew M. Keeler <keelerm84@gmail.com>
Co-authored-by: Matthew M. Keeler <keelerm84@gmail.com>
No description provided.