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

Fast init with localStorage cache age config #311

Open
romulof opened this issue Nov 15, 2024 · 1 comment
Open

Fast init with localStorage cache age config #311

romulof opened this issue Nov 15, 2024 · 1 comment

Comments

@romulof
Copy link

romulof commented Nov 15, 2024

Is your feature request related to a problem? Please describe.

When my app initializes using it has to wait for LD to connect before I start rendering content.

If I don't wait, it uses localStorage cache, which might be inexistent or old.

Describe the solution you'd like

To have a configuration that says how old localStorage cache can be to make init go faster by not waiting for LD to connect.

Describe alternatives you've considered

Manually checking if there are LD entries in localStorage to decide if I should wait or not for LD init before it starts rendering.

Additional context

N/A

@kinyoklion
Copy link
Member

kinyoklion commented Nov 15, 2024

Hello @romulof,

I want to clarify some behavior and then determine if I understand the remaining request.

If I don't wait, it uses localStorage cache, which might be inexistent or old.

In the case where the cache doesn't exist, then the SDK uses a poll to complete initialization.

When it does exist, then it finished initialization and immediately makes a poll to update the cache. If you are not using change listeners, then I see how this wouldn't be useful, you would just have a stale set of flags until the next page load. (Or if the flags have diverge substantially, then there could be some "flash").

So if we have cache age, it would affect old cached, but the non-existent cache case will be the same. I think that sounds reasonable.

So if we had some cached entry that was 10 days old, and we have a maxCacheAge of 1, then we would not use that cache and instead attempt to do a poll. If the poll failed, would you still want the cache, versus having default values?

Based on the other issue I am interested in how you are using contexts which accumulates many caches. The caching behavior in our new SDK is going to be different, as it uses our now more standard approach of caching based on the keys of the context. Versus a somewhat unstable hash of a serialized context, which is what this SDK currently does.

Thank you,
Ryan

Filed internally as SDK-910

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

No branches or pull requests

2 participants