Clojurians Log v2
re-frame
I want to update the url based on a subscription (or flow). The very straightforward way I thought about doing it would be to create an invisible component and update the url in there while I subscribe for the piece of data I need. But this is an antipattern, right? That would make my component not pure. Would be using effects (`reg-fx`)? If so, I would need to apply it to multiple events that might change the data I'm interested. I couldn't find the docs explaining it. I believe it's similar to cases where you want to log or send data do DataDog based on a subscription. What's the recommended way?
It turns out an interceptor can't see a difference in app-db generated from a flow. The value I'm interested (that is generated by a flow) is always identical in coeffects' and effects' db. As far as I understood, this is happening because flow is a global interceptor that is calculated after the one I created. I'm trying to change the order my interceptor runs. Any suggestion?
We do handle the flow's db effect in a unique way, which is unfortunate. This issue seems like a consequence of that. It does seem like a problem we should solve at the framework level, not work around.
Let me think on it for a few days
@jpsoares106 I released https://clojars.org/re-frame/versions/1.4.4-SNAPSHOT. Haven't tested it much. I wrote down some implications that came to mind - there may be more that I haven't thought of, of course...
- Changed flows to calculate the new app-db earlier in the chain.
- Benefit: user-defined interceptors are aware of the post-flow app-db value.
- Drawback: they can't access the value of app-db directly resulting from the event handler.
- Drawback: they can't access flow-related effects like `:reg-flow`.
- Added a :re-frame/pre-flow-db key to the context
- This way, user-defined interceptors can still access the app-db value resulting directly from the event handler.> I want to update the url based on a subscription Don't do it. > (or flow) IIRC flows can side-effect. If so, that would be reasonable. > But this is an antipattern, right? Indeed. I haven't really studied flows beyond the initial implementation so my memory might bu fuzzy but I think you can register a flow that runs and side-effects by itself, without you having to use it in a view.
Just skimmed through the docs - seems I'm wrong about side-effects in flows, so disregard that.
One approach would be to have an effect, and event, and a global interceptor.
The effect does the actual work of updating the URL.
The event simply schedules that effect.
The global interceptor monitors the desired values in the app-db and dispatches the event when needed.
Alternatively, you can reverse the roles - change the URL and have some values in the app-db be determined by the URL.
Hum.. I'm reviewing Flow docs now and I don't think I can have an effect based on it. 🤔
Yeah, that's what my second comment is about. :) So disregard subs and flows for this goal.
Sorry, I missed your second message when I wrote mine 😅 I never used a global interceptor, I'll check that, thanks.
> The global interceptor monitors the desired values in the app-db and dispatches the event when needed.
Do you mean comparing :before app-db and :after and dispatching the :set-url-state if they are different?
Yep! Although probably not the whole app-db but rather some subset of values that should dictate the URL. But I myself definitely prefer to work with it the other way around, when the URL dictates the state. Makes navigating to e.g. a bookmark work by default.
If you're curious about that approach, you can check out kee-frame.