Fork me on GitHub

handlers should not be accessing subscriptions correct?


I have a list of things with the typical checkboxes, and a check all at the top. but the list also has a filter form, so sometimes not everything is showing. when I click check all box, i only want to check the visible items. But which items are visible are filtered through a subscription. So my handler which does the marking of times as checked I guess would have to redo the filter on the appdb so it knows what items to deal with i guess. Alternatively, i can pass the checked visible items through the event to the handler. Any more elegant solutions would be welcomed


thanks @lovuikeng @mikethompson Sorry I missed that in the FAQ


The first thing that occurred to me when trying to migrate a reagent only app to re-frame was that I seemed to want to share “subscription” path information with the event handling.


So immediately I felt the need to “access subscriptions” within an event handler to make changes to specific areas without repeating lots of app db path details all over the place


So I’m glad there is a 3rd party lib for this, but I wonder what if I’m doing something wrong? Doesn’t this come up for most applications? I’d think it’d just be some built in concept of re-frame


Building subscriptions tiers seemed to sort of work as a “cursor” on the app state and allowed for changes to be made in more localized places of the overall state. But on the event handling side, it seems there is nothing similar to that?


I may be wrong on this too, but I was under the impression that changing a reagent cursor may be a bit more performant than making the change at the top-level ratom level


What I’m getting at is that the only reason for me to want to access a subscription in an event handler isn’t just to use the value for some calculation, it is to make a change to the app state location represented by that subscription.


@mikerod I wouldn't be accessing the value of a subscription in an event handler UNLESS that subscription provided a materialised view involving quite a bit of computation. If all you want is to factor out path information, then I'd just factor out the path information:

(def  path-to-X  [:some :thing :over :here])
Put that definition in your db.cljs along with your specs perhaps. Then use that definition in both your subscription and in your event handler. As far as the event handler side of things is concerned, the path interceptor may be of interest to you. See here: and use here:


Now, that was all mechanics. Let's talk philosophy. See the Finally point here:


So, I believe you get a better architecture when you separate out Commands (events in re-frame) from queries (subscriptions in re-frame). Commands/events are about modelling "intent" (often the user's). And queries are about reactively assembling values (a materialised view of app state) for rendering. In the trivial case, this can collapse to get-in and update-in semantics (aka path-oriented cursors), but as your application gets more complex, you'll be glad you teased these two important concepts apart.


@mikethompson thanks for all the info! I will look it over. I’ve read some of it before but could use a re-read when thinking about this again.