Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Simplify FlagsmithCache interface #165

Merged
merged 4 commits into from
Nov 28, 2024
Merged

Conversation

rolodato
Copy link
Member

@rolodato rolodato commented Nov 7, 2024

The FlagsmithCache interface is unnecessarily complicated:

  • has is never used by the SDK, it is only used in tests. This change removes it.
  • The return value of set is never used by the SDK, and serves no purpose. This changes set to be of type Promise<void>.
  • set accepts a ttl parameter but the SDK never actually uses it. This change removes it.
  • The return type of get used to be Promise<Flags | undefined> | undefined. In practice, the SDK always awaits this value so it should be Promise<Flags | undefined>, which is what this change uses.

The Flagsmith constructor also checks that the supplied cache has the same methods as the ones required by FlagsmithCache. This check is not thorough enough to be useful and should be done by typechecking. Also, this checking requires FlagsmithCache to be indexable by a string, which customers will never need to do and just adds boilerplate. This change removes this check and should be enforced by typechecking.

This change also adds JSDoc to FlagsmithCache, so we can link to it directly from docs and avoid duplicating code snippets or explanations.

These are technically breaking changes, but only for TypeScript users and has no effect at runtime. Prior to 4.0.0 it was impossible to actually refer to the FlagsmithCache in TypeScript code because we were not exporting any types. I'd be okay with releasing it as 4.1.0.

Copy link
Contributor

@matthewelwell matthewelwell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine, but I'd rather release a major version here. I don't see any reason not to?

@rolodato
Copy link
Member Author

Sure, we can release it as new major version.

@matthewelwell
Copy link
Contributor

@rolodato ok, can you merge and handle the release?

@rolodato rolodato merged commit 3d04ec7 into main Nov 28, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants