re-frame 2023-11-29

I note that in the new “flows” docs, https://day8.github.io/re-frame/Flows/#subscribing-to-flows - it mentions that there is no caching behavior for flows. What are the implications for this when using a flow as a subscription? I’ve had situations before where the caching behavior in subs was important for perf reasons. I’m trying to comprehend what this means for performance here.

👀 1

Basically, we had utility in subscriptions that take query-vec’s and having multiple subscribe calls to the same subscription reuse a cache when they had the same query-vec.

For flows, the inputs are not parameterizable like a query-vec I guess, so perhaps this just doesn’t apply? That seems to me to mean that we’d still have to use subscriptions though for parameterized query, rather than flows.

yeah, flows don't have an implicit factory like subscriptions do. for the parameterized behavior you're describing, we hope you can just do your own factory. https://day8.github.io/re-frame/Flows/#redefining-and-undefining demonstrates this.

Interesting. I read that part but didn’t put the pieces together. I’ll think about it some more.

as for caching, there are sort of two layers to it. Reagent caches reactions, so you don't have to worry about creating multiple copies of the same reaction. Re-frame subscriptions are sort of like double-layered reactions, and re-frame has its own cache for these. That's what we bypass. When you call (subscribe :flow {...}), you're just getting a reaction that we stored in an atom. So it has the lifecycle of a normal reaction, but not a subscription.

hard to explain, but it should kind of just work. you use the flow DSL itself to control how the output value gets stored or deleted.