feat: support multiple environment caching #252
Conversation
…heOptions to customize the key
#201 (feat): added envId to the storage key and added property to cacheOptions to customize the key
|
@oluizcarvalho This is published under [email protected]! |
Excellent, I'm going to test it in my projects. |
…-caching # Conflicts: # lib/flagsmith-es/package.json # lib/flagsmith/package.json # lib/react-native-flagsmith/package.json # types.d.ts
# Conflicts: # lib/flagsmith-es/package.json # lib/flagsmith/package.json # lib/react-native-flagsmith/package.json # test/cache.test.ts
@oluizcarvalho Could I confirm everything's going well with this ? I'd like to publish a release with this soon 🚀 |
Yes, I finished the tests. I noticed that in this documentation we mention the old key that will be replaced, it would be interesting to change. All tests were successful with two different keys being used in the same browser. I haven't tested the scenario of having two identical keys with different instances in the same browser, but I don't think it would be a problem either. |
Yep we can do that our end!
Amazing work!
Actually I can maybe think of 1 case, if one instance was identifying and the other wasn't, the api responses would combat cache. |
|
I've been thinking about this more and I think the cache key should have the identity in it, it makes sense we do this as part of the same release |
Since it is a major version, I think it makes sense to include this other solution together. I still can't understand how it would work, but I imagine that you wanted to make the cache key as I believe that it wouldn't be that complex to adapt, but if a lot of restructuring is needed, you could separate it into a new issue, since today customizing the cache key (cacheOptions.storageKey) seems to be a way to solve the scenario |
See #246