This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-02
Channels
- # beginners (61)
- # boot (84)
- # cider (43)
- # cljsrn (2)
- # clojure (99)
- # clojure-android (3)
- # clojure-austin (2)
- # clojure-italy (5)
- # clojure-russia (43)
- # clojure-spec (93)
- # clojure-uk (41)
- # clojurescript (94)
- # clojutre (1)
- # cloverage (8)
- # core-async (31)
- # cursive (3)
- # datomic (14)
- # defnpodcast (1)
- # editors-rus (7)
- # events (1)
- # hoplon (15)
- # leiningen (3)
- # luminus (6)
- # om (142)
- # onyx (86)
- # other-languages (4)
- # pedestal (1)
- # planck (1)
- # portland-or (5)
- # re-frame (96)
- # reagent (16)
- # ring-swagger (17)
- # rum (73)
- # specter (25)
- # untangled (14)
- # yada (142)
reagent manages updates by marking components as dirty manually
in a way it circumvents the two official ways of updating components provided by react (state, props)
I wouldn't be surprised if this confused tools
you can verify if components re-render by adding logging to the render method
hmm, can someone point out what I’m doing wrong here in trying to “pass-through” reagent components?
(defn foo [props]
[:div
(:val props)])
(defn child [props]
(into [:ul]
(map (fn [x]
[:li
[(:renderer props) x]])
(:source props))))
(defn parent []
[child {:source [{:val "a"} {:val "b"}]
:renderer foo}])
I would imagine that given the above ^, parent would ultimately spit out an ul
with two lis
. Can you hand-down the renderer function in this way? I dont see any reason why not...
the issue I’m getting is that foo
is invoked incorrectly. It is invoked twice, where props
is always null the first time (for some reason), even if I confirm that inside the mapped fn, x
is what you would expect: {:val “a”}
. The second time it’s invoked, the correct props {:val “a”}
are handed in, and the returned data structure is the correct hiccup, but the final output reagent creates is the result of the first invocation, when props was null. Any ideas why this would happen?
I’ve also tried making it a dynamic list as opposed to static hiccup, but the issue still arises:
(defn child [props]
[:ul
(for [x (:source props)]
[:li
[(:renderer props) x]])])
Have you tried:
(defn child [props]
(into
[:ul]
(for [x (:source props)]
[:li
[(:renderer props) x]])))
ah that’s a good thought - as if maybe the for
was never realized. alas, still the same issue @martinklepsch