Fork me on GitHub
Slack Archive

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

2017-12-16

Channels

#re-frame
<
2017-12-16
>
mikerod15:12:25

@jonr it is mostly described in that link

mikerod15:12:41

However, I think the general idea is that the need for them went away with a few revisions on subscriptions. 1) Subscriptions are cached and de-duplicated - so multiple places referring to (rf/subscribe [:sub1 <etc>]) get the same value from a single reaction when <etc> is the same. 2) Subscriptions handle their own clean-up when they no longer are referenced. Sort of like a garbage collection of subscriptions. So now it is safe to call subscriptions with query vec arguments that are directly values of the render body.

mikerod15:12:47

I’ve found in my case, I often need to get a bit fancier with subscriptions on the rf/reg-sub side of things to get reuse out of more complicated “materialized views” (layer 3 of the signal graph from https://github.com/Day8/re-frame/blob/master/docs/SubscriptionInfographic.md) and build views on top of those. Something like: 

(rf/reg-sub
 :layer-3-computation-1
 (fn [db [q x y]]
   (do-something-fancy-with db x y)))

(rf/reg-sub
 :layer-3-computation-2
 (fn [[q x y]]
   (rf/subscribe [:layer-3-computation-1 x y]))
 (fn [c1 [q x y]]
   (do-something-fancier-with c1 x y)))

jonr16:12:11

Hey @U0LK1552A I just saw this thorough response. Much appreciated! My use case is that I have a "workspace" data structure of views in containers. I'm hoping to produce reaction type values which can be derefed for each view leading to only rerendering subviews when their data changes. From what you have posted I'm gathering I can just pass the path into a generic workspace-view sub and get the result I am after. Does that seem right? Thanks again, super helpful

mikerod17:12:59

@jonr I think that seems ok more or less. I don’t know that I know enough to definitely say yes. One thing to avoid I know is to have your “path” information tightly coupled to your underlying app db structure. That is something that is recommended against in the re-frame docs and by the authors.

mikerod17:12:28

However, I don’t think it is a bad thing to have query params in that influence the results of a subscription that you are using for different purposes (perhaps dynamically)

mikerod17:12:05

I know in the app’s I’ve used re-frame with so far, I’ve reused subscriptions for different components by passing in some sort of indexing/identifying info

jonr23:12:29

Ok, this is super helpful, thanks. I’m also assuming that subs which take an index/id will work like reactions (cause they are) where the subscriber will only be recalled when the resulting value of the sub changes not the structure that is pulled in from layer 2. Does that seem correct?

mikerod00:12:13

Yes, that sounds correct

mikerod00:12:17

It is a reagent thing with reactions, but I believe if a reaction depends on other reactions the computation is reran if any of those dependencies change in value according to =

mikerod00:12:53

and then the component render only changes if the subscriptions/reactions it depends on have their value change according to =

mikerod00:12:29

so if an upstream “layer 2” (or possibly just deeper nested “layer 3"s) change, but doesn’t affect the “leaf subscription” then the dependent component not have to re-render

mikerod00:12:57

of course, you could also experiment with this a bit yourself if you put something like a print in the render fn and saw when it didn’t get re-triggered from state changes

jonr16:12:41

Awesome, this is what I was assuming and want. Really appreciate all the feedback and help.

mikerod15:12:55

This form of rf/reg-sub works. I think it is bit verbose. It is when you need to basically pass query args down from the subscription to its constituent signals. You an also just use rf/reg-sub-raw due to the (1) and (2) points I made above. I just think that format is a bit more free-form and general. The one above is more constrained and may be better because of that when it works. rf/reg-sub-raw (see https://github.com/Day8/re-frame/blob/master/docs/SubscriptionFlow.md for more on it) would look like: 

;; No change to subs :layer-3-computation-1

(require [reagent.ratom :as ratom])

(rf/reg-sub-raw
 :raw-layer-3-computation-2
 (fn [c1 [q x y]]
   (ratom/reaction
    (let [c1 @(rf/subscribe [:layer-3-computation-1 x y])]
      (do-something-fancier-with c1 x y)))))

mikerod15:12:27

So overall though, the former idea of a “dynamic subscription” seemed to be about the subscription “caller” (e.g. from a view render fn) passing in subscriptions to another subscription via the query vec. Now you can handle this logic internall within the rf/reg-sub or rf/reg-sub-raw if needed. Or you can just pass plain values in if your case is a value that is already exposed at the view level for whatever reason.

kennytilton16:12:48

Taking a survey here. What value do folks see in ReactJS? I am about to deliver a new CLJS framework that does not wrap ReactJS and I want to see if I am missing something with my approach. I will now attempt to start a thread for feedback in case it is voluminous. (New to slack)

kennytilton16:12:04

I asked in the re-frame channel since that seems one of the more popular ReactJS wrappers.

kennytilton16:12:01

To get the ball rolling, I gather the declarative authoring of components and (2) speed thanks to VDOM diffing are the big wins. Not so? Are their others I missed?

danielneal18:12:27

React native is a big win - any thing that wraps react automatically gets react native compatability

danielneal18:12:57

(I use reframe with react native)

kennytilton01:12:20

Yes, thx, I forgot that one. ReactNative for free is nice. Have you jumped on MobxNative?

mikethompson03:12:31

We can reuse React components like react-flip-move

kennytilton10:12:00

Yes, thx, I should have mentioned “rich ecosystem”, too.

kennytilton10:12:33

The animated GIF on the flip-move Github page was a tad much. 🙂

danielcompton20:12:48

There's lots of VDOMesque libraries around. The benefits of React over the others are: * Big ecosystem around it * Lots of contributors focused on improving React, * Integrations around it (think Browser debugging tools, React specific error reporting, generic components) * Lots of documentation and tutorials on it, likely that front-end devs you hire will be familiar with it * You're unlikely to be the first person to hit bugs The declarative style in general works really well with ClojureScript's programming style

kennytilton22:12:19

Yep, big ecosystem. But that follows from popularity. What were React’s lures/wins before it got big? Certainly the declarative thing, as you said. (And agreed, speed was another early draw but they are not alone with VDOM.

kennytilton22:12:21

Was “big company” in there, as in “this is bound to get a ton of investment”? Or, “FB is huge, this must be good”? I recall FB themselves offered React almost apologetically because it was so unorthodox.

kennytilton03:12:07

Awesome reference. React bit starts at 26:50. David in turn references Mosely/Mark’s “Out of the Tar Pit” which is all over Brooks and “No Silver Bullet”, my first slide. Great, gonna be up all night now…

kennytilton03:12:45

At 33:00 (just after a nice shout-out to re-frame) David seems to say react has one win: eliminating stateful DOM (thx to the declarative paradigm).