@baptiste-from-paris I usually use Compojure server side (https://github.com/weavejester/compojure) and Secretary client side (https://github.com/gf3/secretary)

for all non-statics using one endpoint(/api) and putting everything in server-side om/parser works very smooth with the front end parser.

How do people merge novelty back into app state after remote mutations? The query that merge receives is the transact! query, which isn't particularly helpful for merging the response back into the db.

Say I have a :card/by-id table and I receive {:name "Card1", :id 1234} from the server after editing the name.

thanks @symfrog

hi, does anyone know of a way to convert om.next components to react components?

@levitanong I used om components recently straight into re-agent. Where are you looking to render the component?

@hlolli in react native’s React Navigation.

I’ve tried using om components straight, but it complains that it must be a React Component.

did you first pass it into a factory?

yup, tried that too

so

i tried SomeComponent

I tried (def some-component (om/factory SomeComponent))

passing some-component

I mean, if you can mount it into the dom with reactDOM.render, then it should be a valid react element. But I've never done react-native so not sure if there's some specialities there.

But I think I see where your question is coming from, we are used to mounting om apps with a reference to the reconciler, so its maybe not a valid react-element that's returned there.

¯\(ツ)/¯

out of desperation i’m doing weird things like set! ing the React Component fields

like here: https://github.com/reagent-project/reagent/blob/master/src/reagent/impl/template.cljs#L256

lol

try js/React.createElement and pass om element as the third parameter, sounds stupid and probably is.

(def your-element (js/React.createElement "div" #js {} your-om-element))

hmm

i’m not sure about createElement

maybe createClass is the more appropriate method

then you need to create an instance of that class with an element (trough factory?), so you're back to sqare1 ?

but the thing is ReactNavigation isn’t asking for an instance

it’s asking for the component

or am i misunderstanding and component is the same as an element?

good question https://tylermcginnis.com/react-elements-vs-react-components/ (reading myself)

bad link, here it's stated crystal clear http://stackoverflow.com/questions/30971395/difference-between-react-component-and-react-element react component is a class that can hold state.

currently trying createClass

i realize it makes no sense to call an om.next component from inside the render function of a react component

@hlolli thanks for the help, I will take a nap first. 😜

can anyone help me out by pointing me to good sample code / explanations for what the :value returned from a mutation parse actually does? Having a lot of trouble grokking it.

I'm sorta fuzzily thinking it's a hint that components can pick up to know about state invalidation but I think I'm just guessing.

also, I noticed that the om-next-kanban demo funnels all mutations through the root component: https://github.com/Jannis/om-next-kanban-demo/blob/master/src/kanban/app.cljs#L28-L66

children get what if I squint look like a form of partially-applied versions of these so the transact! call always happens with the some-component arg set to the root component.

do transact calls always have to go through the root component? Or is there some other mechanism that lets mutations get called from wherever deeper in the tree. I experimented with that and very quickly found my UI state responding in unexpected ways.

(apologies in advance if these questions are so newb as to not even be wrong).

Hi, I've been out of the loop for a couple weeks on the #om slack- Did I miss anything important? 🙂

@rgm: https://clojurians.slack.com/messages/C06DT2YSY/files/F0MSP6R8W/

oh, cool, thanks.

:value is not used at all - just documents what gets changed - for humans. You don't need to both with :value.

ha, guess that'd explain why it didn't fix a problem I was having with a rerender

Mutations can be called from any event.

Look up 'follow on reads' for when re-rendering doesn't happen.

thanks, will do.

Jannis's code is great, but lots of effort went to taking everything back to root - that was not really necessary.

OK. It was striking me as some sort of Cocoa responder-chain-esque messaging could be OK. Modulo the usual action-at-a-distance concerns.

ie. just chuck a mutation message at the reconciler from someplace on the page. Usually not that hard to find where it came from later.

All mutations will probably be in same namespace. All called through transact!.

I see the transact! console messages tell me the component ident too.

(if an ident is set)

oh, there we go... http://stackoverflow.com/a/39413526/53790 (hi @cjmurphy)

both q's answered in one: {:value ... } in a mutate is for the humans, the this in (om/transact! this ...) determines where rerenders cascade down from.

And another thing to think is that your de-normalised tree (your UI) can be whatever shape you want it to be - that can help as well - you can repeat what is the same normalised entity around your tree as much as you like. So there's plenty of flexibility.

right, yes... just starting to understand that.

OK, so if I understand right, if I ship off an (om.next/transact! a-subcomponent [(mutate-thing {:a param}) :other-thing-that-is-affected]) from the :action then any subcomponent with :other-thing-that-is-affected in its query will rerender, regardless of location in the UI tree?

Yes - that looks like a follow on read to me. The only purpose for them being that the key is in an unrelated branch.

If the key were below where you are calling the mutate from it wouldn't be needed.

right, cool. OK. Thanks.

A couple other things just clicked for me.

Where being this.

right... so if this is the root and you have a shallow hierarchy, might as well just transact from root that b/c React is gonna no-op most of it out anyway.

(and presuming you're not triggering a bunch of remote work as part of the mutate).

wait, no, guess that doesn't really matter.

obv if a mutation needs remote work then it needs it; nothing to do with the UI hierarchy.

(ok now I'm just making stuff up).

Yes. this doesn't have to be the component you are in - doesn't have to actually be this - you could have kept a reference to a component, or even have looked up a component by other means.

But almost always you don't have to resort to such tricks.

so for a reasonably shallow hierarchy and learning purposes it seems reasonable to just pass the root down in props and transact against it from leaf components.

Yes you could do that if your leaf components were changing their parent components, but normally good to have the code in the parent changing the children so they need to be re-rendered. Jannis just took that to the extreme.

gotcha ... thanks, this really helps.

So if a child is being deleted, do the transact in the immediate parent, using this.

so then the computed callback isn't having to zipper its way all the way back up to the root, and if say something somewhere else in the UI tree was displaying a count of children that's maybe a candidate for a follow-on read.

Certainly sounds like it to me - I'd guess there's an example of exactly that out there somewhere...