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’t remember and can’t 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’t 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’ve been thinking about more and more is to just make Om Next work with any VDOM implementation

anmonteiro14:09:40

but I don’t 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’t really know if it would fit Om Next’s use case

anmonteiro14:09:43

I’ve been thinking about it mostly in the context of people that don’t 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’re using ClojureScript you probably are OK with a bundle size higher than normal 😛

peeja14:09:31

Fair 🙂

gardnervickers19:09:15

Hey! @anmonteiro, I’ve 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’s there’s 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!