This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (4)
- # boot (2)
- # cider (17)
- # clara (8)
- # cljs-dev (5)
- # clojure (16)
- # clojure-italy (14)
- # clojure-nl (1)
- # clojure-norway (1)
- # clojure-russia (1)
- # clojure-uk (4)
- # clojurescript (8)
- # data-science (19)
- # datomic (4)
- # ethereum (1)
- # events (1)
- # fulcro (15)
- # graphql (4)
- # hoplon (10)
- # jobs (1)
- # mount (1)
- # off-topic (15)
- # parinfer (4)
- # perun (1)
- # portkey (6)
- # re-frame (15)
- # reagent (10)
- # schema (1)
- # shadow-cljs (80)
- # specter (4)
- # test-check (35)
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
you might need that
inject util, @stvnmllr2 https://github.com/vimsical/re-frame-utils shared by @danieleneal
@stvnmllr2 see this FAQ answer: https://github.com/Day8/re-frame/blob/master/docs/FAQs/UseASubscriptionInAnEventHandler.md
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
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:
Put that definition in your
(def path-to-X [:some :thing :over :here])
db.cljsalong 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
pathinterceptor 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
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
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
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.