This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-22
Channels
- # aws (4)
- # bangalore-clj (2)
- # beginners (99)
- # boot (8)
- # clojars (22)
- # clojure (87)
- # clojure-dev (2)
- # clojure-greece (10)
- # clojure-russia (22)
- # clojurescript (80)
- # cursive (4)
- # data-science (2)
- # datomic (10)
- # emacs (1)
- # fulcro (1)
- # garden (2)
- # luminus (1)
- # lumo (29)
- # off-topic (20)
- # om (6)
- # onyx (18)
- # parinfer (7)
- # perun (1)
- # portkey (28)
- # re-frame (93)
- # reagent (59)
- # ring-swagger (2)
- # shadow-cljs (31)
- # slack-help (15)
- # spacemacs (5)
- # uncomplicate (3)
- # yada (6)
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
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])
vs.
;; 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?])]
and
;; 2.
;; within the search component's render
(defn render []
(when @(rf/subscribe [:search/active?])
;; ...
but not in this third example
;; 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
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?
and you fixed it by adding key
s?
then I think I know what the "problem" is
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?
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
you subtly changed the dom structure
note that the same issue would appear in React proper I think - it's not Reagent specific
@pesterhazy thatās what it sounds like to me
I've scratched my head over this precise issue before
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.