Fork me on GitHub
#om
<
2017-10-01
>
souenzzo01:10:58

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

souenzzo04:10:48

Is common call a defui inside another defui? Examples?

levitanong10:10:20

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

levitanong10:10:12

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

levitanong10:10:24

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

levitanong10:10:30

and then it’ll be less underdocumented!

wilkerlucio13:10:36

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?

wilkerlucio15:10:41

thanks @U61HA86AG, 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

wilkerlucio16:10:28

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

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

wilkerlucio16:10:48

code-wise, this should be equivalent:

wilkerlucio16:10:17

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

wilkerlucio16:10:13

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

sundarj16:10:36

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

sundarj16:10:38

i guess that is also about adding elements though

sundarj16:10:55

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

levitanong17:10:59

@U066U8JQJ 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.