Clojurians Log v2

Om is underdocumented. There is some github project to use as ""reference""?

Is common call a defui inside another defui? Examples?

@souenzzo Probably an antipattern. there is ui which you can use anonymously. defui is a global definition.

https://github.com/anmonteiro/om-next-fullstack is a good reference

you could also help out by listing out what needs extra documentation

and then those of us who are familiar can fill those out for you.

and then it’ll be less underdocumented!

when you create a custom component that take children, every time I do this with Om.next in end up in those react key situations, but I don't really understand it, if by doing the regular dom/div I can place items without key, why that doesn't work when I try (apply dom/div nil children)? Is there a way around it?

have you read this? https://reactjs.org/docs/lists-and-keys.html

thanks @sundarj, but I did, and this is a different problem, the one mentioned in this article is when you have variable list of elements, in my case it's more like just fixed siblings, just layouting, not dynmic elements

in om.dom for example, it's totally ok to do this:

(dom/div nil
  (dom/div nil "a")
  (dom/div nil "b"))

code-wise, this should be equivalent:

(apply dom div nil
  [(dom/div nil "a") (dom/div nil "b")])

shoudn't?

I mean, react keys solves when have the possibility to move those nodes around, but for the regular static case I think auto-keys can be safely assigned/are not needed

i was under the impression that you should always add keys, even if only for perf reasons

https://reactjs.org/docs/reconciliation.html#recursing-on-children

i guess that is also about adding elements though

if they are static it shouldn't matter, you're right

@wilkerlucio I think it really is a different case if you’re passing a vector. There’s no guarantee that this data structure could change in the future.