search

JAForbes / S

MIT License
6 stars 0 forks source link

Store Caching within computations #20

Open JAForbes opened 1 year ago

JAForbes commented 1 year ago

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 commented 1 year ago

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.