Fork me on GitHub

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?


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

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


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


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

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

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


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


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


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

 (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)))


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


You actually can!


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


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


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


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


I guess it's fine, but seems unusual


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


Does it modify the actual functions?


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


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?


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})
((:a n) 1)
I still don't get any errors. I guess I'll have to be very wary when instrumenting stuff