Fork me on GitHub
#re-frame
<
2017-10-14
>
stvnmllr201:10:46

handlers should not be accessing subscriptions correct?

stvnmllr201:10:55

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

stvnmllr211:10:26

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

mikerod18:10:37

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.

mikerod18:10:14

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

mikerod18:10:48

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

mikerod18:10:59

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?

mikerod18:10:30

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

mikerod18:10:36

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.

mikethompson22:10:52

@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: https://github.com/Day8/re-frame/blob/master/src/re_frame/std_interceptors.cljc#L152-L177 and use here: https://github.com/Day8/re-frame/blob/master/examples/todomvc/src/todomvc/events.cljs#L59

mikethompson22:10:13

Now, that was all mechanics. Let's talk philosophy. See the Finally point here: https://github.com/Day8/re-frame/blob/master/docs/MentalModelOmnibus.md#guiding-philosophy

mikethompson22:10:37

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.

mikerod22:10:49

@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.