Fork me on GitHub
Slack Archive

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

2021-03-23

Channels

#re-frame
<
2021-03-23
>
zendevil.eth14:03:41

What’s the advantage of using: 

(reg-sub
 :root-comp-initial-tab
 :<- [:_id]
 (fn [id _]
   (if id "Tabs" "Sign In")
   ))
over 
(reg-sub
 :root-comp-initial-tab
 (fn [db _]
   (if (:_id db) "Tabs" "Sign In")
   ))
?

p-himik14:03:36

In this particular case - none.

zendevil.eth14:03:34

can you describe a case where the former pattern would be better than the latter?

p-himik15:03:58

As is almost always the case, it's described rather well in the excellent re-frame documentation, which IMO everybody working with re-frame should read in full at least once. https://day8.github.io/re-frame/subscriptions/#the-four-layers

zendevil.eth16:03:50

Yes I’ve read this. But it doesn’t tell why pass in signals instead of accessing the dB directly even in layer 3

zendevil.eth16:03:58

Is it more efficient?

achikin11:03:17

It helps a lot if [:_id] is not just a path in the db, but a rather complicated subscription which is not easy to replicate as a function from db

kennytilton16:03:55

@U2FRKM4TW "In this particular case - none." Is that strictly correct? I thought RF, given the explicit :id subscription, would avoid propagating to :root-comp-initial-tab if sth other than :id changed in db.

p-himik16:03:30

That's true. But in this particular case, the :root-comp-initial-tab subscription is as simple as it can get - it won't matter at all.

p-himik16:03:13

In fact, if :_id is only used by :root-comp-initial-tab, then that might be a disadvantage even. At the very least, just because of the extra code involved.

kennytilton17:03:05

I was thinking it important for a noob to RF to grok the short-circuiting of state propagation by RF, regardless of the de facto insignificance in the given use case. No? Still not sure if @U01F1TM2FD5 picked that up, though the doc is indeed extensive.

👍 3
zendevil.eth23:03:26

I have an issue with my react component not correctly subscribing to a value. This is my view: 

(let [Stack (createStackNavigator)]
      [:> (.-Navigator Stack) {:initialRouteName @(subscribe [:root-comp-initial-tab])}
       [:> (.-Screen Stack) {:name "Sign In" :options {:headerShown false}
                             :component (reactify-component google-signin-comp)}]
       [:> (.-Screen Stack) {:name "Tabs" :options {:headerShown false}
                             :component (reactify-component tabs)}]])
Notice the @(subscribe [:root-comp-initial-tab]. This is the registration: 
(reg-sub
 :root-comp-initial-tab
 :<- [:signed-in-status]
 (fn [signed-in? _]
   (let [returning (if signed-in? "Tabs" "Sign In")]
     (prn "returning " returning)
     returning)
   ))
When this component loads, I see “returning Tabs” (from the prn statement in the subscription) in the logs, suggesting that that’s what the value of the subscription would be. However, the actual behavior is not that. The value is not “Tabs” in the actual component. When I replace the subscription with “Tabs”, I’m seeing a different behavior. How to explain this? I am seeing “retuning Sign In” before that too, but wouldn’t the change in the return value of the subscription also automatically change the view? TLDR in my view, the value of the subscription changes but the view doesn’t change. How to fix this?

achikin11:03:40

It looks like you’re using some js components and it’s hard to tell how exactly they treat the values you pass inside them.

achikin12:03:02

From what you saying, it looks like the subscriptions are working fine.