Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2019-04-15

Channels

#re-frame
<
2019-04-15
>
henrik06:04:53

Subscriptions are nice, because they (kind of) let me reason about what something is rather than where it is. However, in events, if I need a piece of data, I still have to know where it is. Is it possible to ask a subscription where a value is inside an event?

henrik06:04:49

I've refactored my backend a bit, so that a query that previously returned a compound answer is now split into several queries, each returning parts of what the previous query returned. The result of the query was previously stored in a single location in the DB. Subscriptions took care of returning the different parts separately to the app, picking apart the compound thing. Now the subscriptions need to go look in other locations, but other than that the app logic hasn't changed one bit. This is easily refactored. What's less straightforward is that my events have made assumptions about where stuff is stored, and I need to go update their assumption of the world as well. It occurs to me that if they just asked subscriptions to tell them the proper location, the events would require zero refactoring as well.

Lu06:04:31

@henrik If you used pure functions to get the values in each subscription, you could have easily called the same functions in your events. What I mean by pure function is a helper that takes the dB and returns the value you’re supposed to be getting. In this way, you only needed to update the logic in your pure functions and all the rest would have been automatically up to date.

henrik06:04:07

I put literally no logic in the subscriptions or templates, and lean heavily on events and interceptors for logic and side-effects. They all look something like this: 

(rf/reg-sub :publisher-suggestions
  (fn [db _] (-> db :search-results :data :metadata :suggestion/publishers)))

(rf/reg-sub :category-suggestions
  (fn [db _] (-> db :search-results :data :metadata :suggestion/categories)))

(rf/reg-sub :type-suggestions
  (fn [db _] (-> db :search-results :data :metadata :suggestion/types)))

henrik06:04:23

But is it OK to call a subscription from an event? I thought that was discouraged.

Lu06:04:08

It is not correct, you’re right! I know this is a bit more verbose by I meant the following:

henrik06:04:02

Ah, you're suggesting I create a set of functions that do the same, then call the functions from both subs and events?

Lu06:04:37

(rf/reg-sub
 :publisher-suggestions
 (fn [db _]
     (helpers/publisher-suggestions db)))

(rf/reg-event-db
 :some-event
 (fn [db _]
     (let [publisher-suggestions
	   (helpers/publisher-suggestions db)]
       ;; all your other stuff
       )))

;; and in your helpers namespace

(defn publisher-suggestions
  [db]
  (-> db :search-results :data :metadata :suggestion/publishers))

Lu06:04:28

So in this case you will only need to update the path in publisher-suggestions and all the rest will work accordingly

Lu06:04:12

@henrik yup! that's exactly what I meant.

henrik06:04:17

Perfect! Thank you. My brain was stuck in re-frame API mode, and didn't realize that the tools are already there.

😄 4
Lu06:04:19

Yeah! It took me a bit to realize this as well 😅

ghadi15:04:22

is it possible to have built-in correlation IDs so that when an event dispatches another event, there is a trail?

💯 4
ghadi15:04:43

or is that something you'd build into the events themselves?

danielglauser19:04:40

One of the apps I’ve been working on has more and more cascading events. Ghadi’s suggestion (in addition to filtering withing re-frame-10x) would be super helpful.

ag21:04:00

does anyone know a quick way of converting string->hiccup without any third-party lib using reagent/re-frame? e.g. if I have string like "[:<> [:span \"lorem\"] [:span \"ipsum\"]], how do I quickly convert it into a hiccup vector?

ag21:04:49

ah… I’m an idiot… clojure.edn/read-string does that