Fork me on GitHub
#om
<
2016-09-10
>
anmonteiro14:09:51

@peeja just replied to your comment in my post. Happy to discuss anything else here

peeja14:09:17

Won't a key like that only update components that read it?

anmonteiro14:09:43

Ah right, I forgot to continue that thought 馃檪

anmonteiro14:09:03

what I do is make the top-level div have that as the react-key

anmonteiro14:09:16

so because the react-key changes, the children of that div will forcibly update

anmonteiro14:09:42

but as I said, it might have bad consequences for local state, I can鈥檛 remember and can鈥檛 really try it out now

peeja14:09:16

Yeah, I think that rebuilds the DOM and remounts all the components

peeja14:09:19

Should act the same as re-running add-root!

anmonteiro14:09:13

I didn鈥檛 get around to thinking about other solutions, so yours looks interesting

anmonteiro14:09:24

I starred the gist to have a look later, but currently juggling a lot of things

peeja14:09:41

What I posted appears to be working great, but it's liable to break at any React update 馃檪

anmonteiro14:09:17

One thing I鈥檝e been thinking about more and more is to just make Om Next work with any VDOM implementation

anmonteiro14:09:40

but I don鈥檛 really have the time to even start thinking about what it would take to accomplish such thing 馃檪

peeja14:09:09

Dang, that sounds sweet, and also like a ton of work 馃檪

peeja14:09:41

Any VDOM in particular you're thinking of? I've never worked with any other than React, and I'm not clear what the others have to offer

anmonteiro14:09:53

yeah, I just saw a Cycle.js demo 2 days ago at a conf

anmonteiro14:09:21

looked really cool but I don鈥檛 really know if it would fit Om Next鈥檚 use case

anmonteiro14:09:43

I鈥檝e been thinking about it mostly in the context of people that don鈥檛 really want to bundle React for its size

anmonteiro14:09:56

there are lighter weight impls out there

peeja14:09:23

Yeah, that makes sense. It seems like React has a lot of code to cover uses that Om code never has, being functional

anmonteiro14:09:26

though if you鈥檙e using ClojureScript you probably are OK with a bundle size higher than normal 馃槢

peeja14:09:31

Fair 馃檪

gardnervickers19:09:15

Hey! @anmonteiro, I鈥檝e been using Omify on a project of mine and it seems that the resulting component does not have .-state set which throws an exception in merge-pending-props! when Om tries to (gobj/set cst "omcljs$prev$value" prev). I looked over the omnify! macro and it seem鈥檚 there鈥檚 no default present for initLocalState.

anmonteiro23:09:03

@gardnervickers: that may well be true, omify is quite dirty at this point, I mostly wanted to prove it could work

anmonteiro23:09:20

Mind opening an issue so we can track that? Thanks!