Really dumb question, but how does r/atom work exactly?

I'm trying to implement a similar system in regular ol' javascript, but don't know how to proceed from this point (where I just have a dumb version of a regular atom)

@emccue I posted a little explanation of how r/atom works in the re-frame channel yesterday: https://clojurians.slack.com/archives/C073DKH9P/p1508598109000063 should probably try to put it somewhere else, like a blog post 😜

the specific answer for your question would depend on what you’re trying to do next with your ‘special atom’. are you trying to associate some other chunks of code with ‘dependencies’ (eg. r/atom’s that were dereferenced during execution of that code), to re-run that chunk whenever one of its dependencies changes? if so, a starting point for thinking about the problem might be: somehow that chunk of code needs to be wrapped to ‘observe’ which ‘special atoms’ are dereferenced during evaluation, and the ‘special atom’ needs to be modified slightly during dereference to see if any of these ‘observors’ are present

@emccue in JS land you can try taking cues from https://github.com/mobxjs/mobx

Does anyone know a good way to forcibly prevent re-agent from re-rendering a component? I’ve tried :should-component-update (constantly false), but to no avail

I’ve heard that using :key can also help

also, does anyone know, which of these is preferable from a reagent architecture standpoint?

;; within a parent component's `render` function
(when @(rf/subscribe [:search/active?])
  [search/render])

;; within the search component's render
(defn render []
  (when @(rf/subscribe [:search/active?])
    ;; ...

My suspicion is that the latter is preferable since reagent will register the reaction at the search component level instead of the parent component. Is this a fair assumption?

These two questions may seem unrelated, but when I refactored from the former example to the latter, my need for :should-component-update (constantly false) or :key both went away, so I’m tempted to assume I did the right thing

@wpcarro it might help if you explained your problem in terms of what you wanted to accomplish

re: the 2nd question, the 2nd option should be preferable, because fewer React Elements need to be rerendered

@pesterhazy good call. Apologies… I have a D3 canvas that has been rendering unexpectedly after a certain, unrelated change to app-db. I have fixed the solution by refactoring (shown above). I was primarily looking for validation about the change. I’m still unsure as to why reagent cannot keep track of my D3 canvas without the presence of ^{:key "constant"} or something similar

What makes things additionally confusing to me is that reagent does not re-render the D3 canvas in these two scenarios…

;; 1.
;; within a parent component's `render` function
[search/render @(rf/subscribe [:search/active?])]

;; 2.
;; within the search component's render
(defn render []
  (when @(rf/subscribe [:search/active?])
    ;; ...

;; 3.
;; within a parent component's `render` function
(when @(rf/subscribe [:search/active?])
  [search/render])

Why should examples 1 and 3 affect the way that reagent keeps track of the D3 canvas (which is a sibling component to the search)

@wpcarro which ones re-render in your opinion?

@pesterhazy I’m using clairvoyant and re-frame-tracer, which tell me that main (ie “parent component”), search, and canvas are all rendering when [:search/active?] changes its value in examples 1 and 3.

It makes sense that main and search would render under these circumstances, but not canvas since the props provided to it have not changed nor has any of its subscription values changed

what exactly is confusing to you?

why would the position of the (@rf/subscribe ...) calls affect the rendering of the canvas component when both subscribes are in the parent component?

@wpcarro You provide examples for search, but ask about canvas. Should the examples read canvas in place of search?

sorry I'm not understanding what is canvas, search etc... none of these appear in the code?

can you put up a minimal repro gist?

@pesterhazy yes one minute

@p-himik good question. No the examples should read search in this case. Will post a gist involving main and canvas

https://gist.github.com/wpcarro/07d75f283e817202abe87049e2a2a8f3

if you deref an ratom anywhere in a fn, the whole component will rerender if its value changes

that's why it's useful to move derefs into child components

in main.cljs in both versions 1 & 2, the derefing is happening in main/render Why should the outcomes of the render fn change?

ah

and you fixed it by adding keys?

then I think I know what the "problem" is

strangely enough version 1 does not render canvas while version 2 does…

in v2, you insert an element into the dom, depending on whether :search/active? is true

React's diffing algorithm isn't smart enough to detect [:a :b] and [:b] as variants of each other

it checks the first element: "It was :a: but now it's :b. How could that be the same tree? So I'll just give up and throw away the existing DOM and recreate everything."

The reconciliation is based on heuristics. A more complex algorithm would do the right thing here, but it would take too long to run.

So you need to help React by providing hints.

You can add keys.

You could also wrap the (when ...) in a div so the overall Dom structure remains the same.

@pesterhazy very interesting

Usually oaccsional re-mounts don't matter much, but because you're using a stateful component, you want to keep it mounted at all cost

so because [:a :b] is considered entirely different from [:b], React throws away [:a :b] instead of just throwing away :a … is that right?

seems like conditional renders like (when predicate [:dom]) are dangerous

Yeah it just says "screw it, I can't reconcile those in a graceful style"

it is dangerous, unless you add keys (which is good practice anyway)

lovely! so when I moved the subs to the children components, it prevented main from rendering, and I avoided the risk altogether

in other words, React’s diff algo didn’t even need to run

you subtly changed the dom structure

yeah

wonderful

note that the same issue would appear in React proper I think - it's not Reagent specific

I feel like I should use :key on the canvas to prevent regressions

@pesterhazy that’s what it sounds like to me

I've scratched my head over this precise issue before

that’s great though… I think I totally understand what’s going on now

happy to hear that!

many thanks @pesterhazy

I've asked a question on re-frame's Github issue about complex components: https://github.com/Day8/re-frame/issues/264#issuecomment-338485510 I hope to get more visibility to the issue itself and maybe to get some ideas from the people in this channel.