Fork me on GitHub
#re-frame
<
2019-02-07
>
orestis14:02:26

If your UI is made by pretty much “separate” views, how would the single app-db approach of re-frame work? Would you use namespaced keys to segregate the state of different views, or wipe the state entirely when you transition to a completely separate view?

dtsiedel14:02:06

You could always just use nested keys. Like all state related to page X would be under a :page-x key within the db, and top-level state is in the top-level of the db or under a :global key

👍 5
restenb14:02:04

yes, nest your keys in a way that is logical for your app data

restenb14:02:57

you could still want to use namespaced keys occasionally, but mostly if you've actually ran out of available key names, which in my experience isn't a big problem if you nest

orestis15:02:59

Right, using nested keys was my first thought too. If that’s a common pattern, I will explore further.

Jacob Haag14:02:11

Is there a way to pass a parameter to a subscription that does a computation? The subscription that is used for the computation takes a parameter. See example below

(register-sub
 :cart-items
 (fn [db [_ category]]
   (get-in db [:cart category :item])))

(rf/reg-sub
 :cart-count
 (fn [_] ; <--- this is where the param would theoretically go
   (rf/subscribe [:cart-items]))
 (fn [items]
   (count items)))

restenb14:02:49

if you want to use already registered subs as parameters to a new sub there's syntax sugar for that

restenb14:02:20

I think that would accomplish what you're trying to do with the :cart-count sub

restenb14:02:52

you can include as many subs with :<- as you want, but note that multiple will be sent back in as a vector

Jacob Haag14:02:51

My question is more so how can I pass a parameter to a registered sub used in the computation

(register-sub
 :cart-items
 (fn [db [_ *category*]] ; <-- parameter passed to subscription
   (get-in db [:cart category :item])))

(reg-sub :cart-count
         :<- [:cart-items *category*] <-- same parameter
         (fn [items]
           (count items)))

restenb14:02:53

oh. yeah you can't quite combine things like that, at least to my knowledge

Lu00:02:08

You actually can!

restenb14:02:36

if category is something that's selectable from the UI i'd just store it as a key and use that so it's available when :cart-count gets called

restenb14:02:51

same as your :cart-items but the category is stored separately in :selected-category

restenb14:02:21

now there'd be no need to pass category on to :cart-count, it can just take in :cart-items whenever it's called and not have to worry about it

frankitox22:02:16

Hi, I'm struggling to understand why this don't triggers instrumentation.

(defn coco [_])
(cljs.spec.alpha/fdef coco :args
                      (cljs.spec.alpha/cat :str string?))
(re-frame.core/reg-event-fx :coco coco)
(cljs.spec.test.alpha/instrument `coco)
(dispatch [:coco])
BUT, it works if I put the instrument line before registering the event. :thinking_face:It seems related to re-frame, but I'm not 100% sure

danielcompton23:02:42

I guess it's fine, but seems unusual

danielcompton23:02:55

I'm not actually sure how instrument works under the covers

danielcompton23:02:00

Does it modify the actual functions?

danielcompton23:02:17

If so, then re-frame already has a reference to the unstrumented function

frankitox23:02:53

Well, maybe that's the issue, I'll have to read the code of instrument. But also understand better about functions and namespaces, I suppose that when you call reg-event-fx as the second argument re-frame gets a copy of the function?

frankitox23:02:18

Yes! You're right! If I do

(defn coco [_])
(cljs.spec.alpha/fdef coco :args
                      (cljs.spec.alpha/cat :str string? :n string?))
(def n {:a coco})
(stest/instrument)
((:a n) 1)
I still don't get any errors. I guess I'll have to be very wary when instrumenting stuff