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

Store Caching within computations #20

Open
JAForbes opened this issue Nov 14, 2022 · 1 comment
Open

Store Caching within computations #20

JAForbes opened this issue Nov 14, 2022 · 1 comment
Labels
bug Something isn't working

Comments

@JAForbes
Copy link
Owner

If you define a store query within a computation, the reactive queries end up being cleaned up which leads to the query becoming non-reactive.

This is just how S works, but I really would like to cache queries. I might disable caching queries for now and think about this as I want to work with the grain of S while also supporting caching queries.

Maybe queries are defined in a separate S.root and have the same lifecycle as the context which created the store. But that may encourage having multiple stores which I don't think is a good approach by default.

Or... we use cleanup hooks in the read stream to deregister/register the store instance. Needs some dogfooding to find the right approach.

@JAForbes JAForbes added the bug Something isn't working label Nov 14, 2022
@JAForbes
Copy link
Owner Author

Had an idea re: this today. What if the cache key wasn't just the path, but the immediate parent computation.

So if you define the same query in the same scope its cached, but if you define the same query in a different computation it gets recreated.

That should cover off the lifecycle edge case just fine while also allowing you to use queries without having to always define them ahead of time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant