This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-02
Channels
- # aleph (6)
- # beginners (57)
- # boot (1)
- # cider (27)
- # clara (23)
- # cljs-dev (166)
- # clojure (287)
- # clojure-dev (23)
- # clojure-greece (1)
- # clojure-italy (2)
- # clojure-russia (13)
- # clojure-spec (34)
- # clojure-uk (36)
- # clojurescript (68)
- # core-async (63)
- # core-logic (1)
- # cursive (1)
- # data-science (1)
- # datomic (26)
- # duct (1)
- # emacs (10)
- # figwheel (8)
- # fulcro (2)
- # garden (16)
- # graphql (8)
- # hoplon (20)
- # jobs (2)
- # leiningen (10)
- # off-topic (16)
- # onyx (2)
- # portkey (5)
- # quil (1)
- # re-frame (63)
- # reagent (95)
- # reitit (6)
- # remote-jobs (1)
- # ring (6)
- # rum (1)
- # shadow-cljs (76)
- # spacemacs (26)
- # specter (11)
- # sql (7)
- # unrepl (68)
- # vim (2)
- # yada (2)
@lee.justin.m so are you generally just dealing w/ component local state then and using specter to help manipulate the data?
If state is truly not shared between components, then I use local state (one exception is that sometimes I use a container/view pattern, but I consider those “one component” in a sense).
Otherwise, everything is in a single ratom. All mutations are done through functions that use specter and are always synchronous. Anything that involves the server is in a different file, and calls the state mutators as needed (e.g. setting a “loading” flag, setting progress updates, then adding the data and clearing the flag). It seems to work pretty well for me.
My project is small so code reuse among a big team of devs just isn’t a big priority for me.
reframe docs are thorough. this is a nice doc to get why frameworks might be good for you. https://github.com/Day8/re-frame/blob/master/docs/FAQs/DoINeedReFrame.md
@lee.justin.m i too am very much in the "build my own architecture camp" (from that document). I found re-frame to be too heavy on the boilerplate (but it is refreshing to see a motivation document that honest about whether the library it's describing is actually required)
Any good lib to use modal window? I found reagent-modals, but is the mostly used? or any better option?
generally yes, but I don’t understand what you are trying to do at all. are you trying to pass a new atom to :field-1
?
@fabrao I’m stilll not 100% following you, but I suspect what you really want is to use a cursor. https://github.com/reagent-project/reagent-cookbook/tree/master/basics/cursors
if you want to create a bunch of input elements dynamically, you probably want to store the user’s input from those inputs in a single atom that is either global, or lives local to the parent component. you can just pass a reagent cursor as a parameter to each input. the input can treat the cursor as a normal atom and then the component’s atom will be automatically updated
This is the first I’ve seen that… I wonder if that is really a nice solution to the problem described…
I read what was up on https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-16.html
What solutions have folks chosen for pop;-overs? I wanted to use goog.ui.Tooltip but am having rendering-order problems trying to attach it to things that don't exist yet
How so?
https://dev.to/swyx/a-walkthrough-of-that-react-suspense-demo--4j6a is something I was recently looking at, but not exclusively this
Ah! Got it! Use the :ref key on the element to get something approximately an onload of the element
I have this code: (map-indexed (fn [i d] [:> t-row {:key (str "row-" i) :onClick #(js/alert (:name d))} [:> t-cell {:key (str "name-" i)} (:name d)] [:> t-cell {:key (str "age-" i)} (:age d)] [:> t-cell {:key (str "gender-" i)} (:gender d)]]) (:page-data @table-state)) generating this error: Warning: Every element in a seq should have a unique :key
not sure what's missing - haven't i added a unique key to each element in the seq?
Don't see what's missing when looking at the output (from the warning msg) either: https://pastebin.com/pbWTRdzn
@doubleagent do you have react dev tools installed in chrome? you can inspect the keys using that tool to see if that syntax is actually working
i would have thought that would have worked, but there’s something i don’t quite get with the way reagent does keys — the way you are doing it works with native html elements, but if you try to do that with a normal reagent component it doesn’t work and you have to use with-meta
instead. i wonder if that’s true here too
Thanks. I'm still learning and not always sure where to look. Looks like semantic-ui is adding an element and not giving it a key
also the td
tag isn't getting a key
@justinlee doesn't appear to work
i should point out that you need to do it for every element of course because i’m not sure where the key warning is coming from
i get the same warning
except when i tag as meta I don't see :key
in the warning message output
the key warning only applies when there series of sibling elements with the same tag
btw, if i’m reading the message right i interpret that to say that the warning is happening at the row level, not the cell level
also that may not be an error for the keys to have disappeared. i doubt it prints metadata.
you're probably right about that
@doubleagent please try this:
(for [[i d] (map-indexed vector (:page-data @table-state))]
^{:key (str "row-" i)}
[:> t-row {:onClick #(js/alert (:name d))}
[:> t-cell (:name d)]
[:> t-cell(:age d)]
[:> t-cell (:gender d)]])
Thanks I'll give them both a shot
@justinlee no worries 🙂
I just used the ^
shorthand for metadata
didn't copy verbatim
@gadfly361 thanks your idea worked
This is what I have now: (map-indexed (fn [i d] ^{:key (str "row-" i)} [:> t-row {:onClick #(js/alert (:name d))} [:> t-cell {:key (str "name-" i)} (:name d)] [:> t-cell {:key (str "age-" i)} (:age d)] [:> t-cell {:key (str "gender-" i)} (:gender d)]]) (:page-data @table-state))
Ok awesome, so looks like what @lee.justin.m was recommending does work then (sans the typo)
actually don't need the :key
on each t-cell
either
which you also suggested
if you want you could just do ^{:key i}
— it only needs to be unique within that specific sequence
yeah good point
as an aside, the only gotcha i should note about using indexes for keys is if your data gets swapped out entirely ... itll think stuff survives that isn't actually the same stuff
one piece of magic I do not understand is how reagent/react knows when I’ve typed out 3 components in a row vs. mapping over some data to create 3 components in a row
@gadfly361 i’m not 100% sure, but I don’t think that’s true if the props change
I think if your data is ["A" "B" "C"] and you switch it to ["A" "E" "C"] by swapping the ratom table-state
, you may run in to an issue ... i dont think any props are involved there
if you mutate the ratom, the parent component will generate a new set of child components, which presumably will take “A” or “B” or whatever as a prop. somehow the data has to get to the child. i am almost positive that if you render a list with the same keys but where, say the second thing has new props, the child will get updated.
that suggests that you are right and you need to be careful. i always thought it was just a perf thing
in any event, just be mindful of using indexes as they are not actually guaranteed to be unique if your dataset changes
@lee.justin.m oh cool, hadn't actually seen that reference before that calls out indexes explicitly
if you mutate the ratom, the parent component will generate a new set of child components, which presumably will take “A” or “B” or whatever as a prop. somehow the data has to get to the child. i am almost positive that if you render a list with the same keys but where, say the second thing has new props, the child will get updated.
that document says that you can possibly get into issues with input elements, but it sounds relatively obscure. i believe if you just render non-input elements it’ll always work, although it may be inefficient if you reorder
i think i've had issues with like react-flip-move and other visualization kind of things
@lee.justin.m I think why you don't need keys on the t-cell
is because of the granularity of the resulting seq
(map-indexed
(fn [i d]
^{:key (str "row-" i)}
[:> t-row {:onClick #(js/alert (:name d))}
[:> t-cell (:name d)]
[:> t-cell (:age d)]
[:> t-cell (:gender d)]])
[{:name "Foo"
:age 20
:gender "male"}
{:name "Bar"
:age 32
:gender "female"}])
;; Which would effectively turn in to:
;; (
;; [:> t-row {:onClick #(js/alert "Foo")} [:> t-cell "Foo"] [:> t-cell 20] [:> t-cell "male"]]
;; [:> t-row {:onClick #(js/alert "Bar")} [:> t-cell "Bar"] [:> t-cell 32] [:> t-cell "female"]]
;; )
This just produces a seq of two elements, so you only need keys at the top-level to be able to identify each@gadfly361 try this out. the first table will not generate an error. i.e. if you comment out the second table you get no errors.
(def data
[{:name "Foo"
:age 20
:gender "male"}
{:name "Bar"
:age 32
:gender "female"}])
(defn test-component
[]
[:div
[:table>tbody
(map-indexed
(fn [i d]
^{:key (str "row-" i)}
[:tr {:onClick #(js/alert (:name d))}
[:td (:name d)]
[:td (:age d)]
[:td (:gender d)]])
data)]
[:table>tbody
(map-indexed
(fn [i d]
^{:key (str "row-" i)}
[:tr
(map (fn [d] [:td d]) (vals d))])
data)]])