Subscription Cache, Memoization

[scott-kl]

What is the rationale behind re-frame wiping the reaction from the subscription cache on dispose?

So, for example, I have a list that is expensive to compute, and when I navigate back to the home launcher, and then back to the list, the subscription is destroyed and recreated and hence re-run, without benefiting from the cache.

Now, I could register all those subs in the main launcher to prevent them being destroyed, but I don't want them to recompute if they're not contextually relevant.

So my solution has been to memoize my subscription handler, which seems to work great. Now, when I navigate to the launcher and back, the sub is recreated and re-run, but the handler returns the memoized data and runs fast.

But should there maybe be an option to keep the sub data in the cache, even after the subscription is disposed? Because it seems strange to me to have to memoize something that is already being cached.

Is it just a default you've chosen to ensure you don't use too much memory? My tests show that memoization of the db doesn't increase it that much.

[kimo-k]

Hey @scott-kl, I agree with your points overall. Subscriptions treat this as the only behavior, not a default. It's not straightforward to do anything else. We have a few projects in alpha which should address this - flows and polymorphic subscriptions. I'd love to hear if you have any feedback, or if you had a different idea to solve this problem at the framework level.

[scott-kl]

Just bumping this as a good idea to which I could contribute.

Is the slack channel private? I can't get on there to see the discussion.

[kimo-k]

Hey there. Clojurians slack should be open to anyone willing to sign up with an email address. If the permalink doesn't work for you, then you can also just go to the #re-frame channel and check the pinned threads. Or just search for flow alpha.