Clojurians Log v2
re-frame
Are flows hard wired to app-db? Subscriptions can use alternative inputs (iirc there was one that used datascript as backend), and it feels weird that flows apparently can't (looking at resolve-inputs and run in flows.alpha)
I'd say it's the other way around - it feels weird putting anything that doesn't originate from app-db as a subscription signal. It makes the state of the app fractured and negates all the advantages of having all the state at one place.
In my case I'd want to use a reactive database (something that can notify changes) to store user data and the app-db to store ephemeral application state
I understand the need, my point is that it doesn't sit well with the overall re-frame design and its justifications. Local Storage is somewhat similar to a reactive database. When using it, I basically copy the values that I need into app-db when they change and then use them from there. Perhaps it's something you can employ as well.
> Are flows hard wired to app-db? Yes :)
is that an intentional choice, and if so what's the reasoning?
Somewhat explained it here - https://clojurians.slack.com/archives/C073DKH9P/p1699779468706539?thread_ts=1698792674.379499&cid=C073DKH9P
š , Iāve looked into flow and I think it may solve some problems that Iāve been struggling with. I have a couple of thoughts, questions.
1. The :live? seems to couple presentation with the flow, since the flow needs to know what tab is showing. Would it not be possible to track references to the flow?
2. I have thought a lot about a machinery to handle time consuming and cascading recalculations of data as result of changes in app-db. Iāve followed the example in the re-frame docs of an event that runs and then triggers a new event to continue the calculation, handing back control to the browser. Would it be possible to implement something similar i flows?
what is presentation?
Maybe not a good termā¦ in contrast to regular subscription, that are automatically āfreedā when no one is subscribing to them, the flows need to know what components that depend on the so they can be cleaned up when the component (the tab in the example) is no longer showing. Of course the current tab is also stored in app-db, but it seems to me to be another concern.
I wouldn't say a flow needs to know about any components. What we're imagining is a system where a dataflow lives or dies based on explicit predicates. You can ideally do all your essential calculations with flows. Then, your view logic might use those predicates to mount or unmount, but that's more incidental. It's your decision to couple views and flows, whereas with subscriptions, they were always coupled, and you didn't really have a choice.
It does make me wonder what a reference-counted flow might look like.
You might be interested in the subscription alpha, too - it offers another approach to lifecycle definition. We don't have an official doc, but I wrote up some https://github.com/day8/re-frame/issues/680#issuecomment-1676487563 and some https://github.com/day8/re-frame/blob/master/test/re_frame/subs/alpha_test.cljc
On second thought, I think that this ācouplingā may be unavoidable. If I have a regular subscription to the value in :path, itās not simple for the flow mechanism to understand that the flow should be cleaned up when that component unmounts.
> Would it be possible to implement something similar i flows? As for this, not sure. Do you have a link to the specific tutorial?
Iāve made a very bespoke solution that runs takes a vector of values, a reducing function, and a path for the final storage. The machinery feeds reducer each element in the vector for about 6 ms, yields back to the browser, and the runs it again, etc., until the vector is empty, and then the value is stored in the path.
interesting, I haven't tried that pattern before
I guess we both see how you can set up a flow to do a certain calculation. And technically it could stop after some time. I think a flow could have an input path that's the same as its output path - maybe that would come in handy for iterative calculations. A flow can't declare effects, the way an event handler can, which might make it hard to keep the iteration going.
no :dispatch effect after the flow runs
so far I see how a flow might add complication to solve the problem, but I don't see a clear way for a flow to simplify things
Makes sense. I just wanted to check if this triggered any ideas š
might be worth looking at https://github.com/day8/re-frame-async-flow-fx, too
That solves another problem that Iāve another bespoke solution for š