This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-03-31
Channels
- # arachne (4)
- # beginners (21)
- # boot (36)
- # cider (59)
- # cljsrn (8)
- # clojure (260)
- # clojure-filipino (3)
- # clojure-greece (3)
- # clojure-italy (15)
- # clojure-russia (58)
- # clojure-spec (54)
- # clojure-uk (99)
- # clojureremote (5)
- # clojurescript (65)
- # core-matrix (1)
- # cursive (17)
- # data-science (9)
- # datascript (7)
- # datomic (33)
- # emacs (8)
- # hoplon (2)
- # jobs (1)
- # jobs-discuss (2)
- # lein-figwheel (2)
- # lumo (2)
- # numerical-computing (1)
- # off-topic (22)
- # om (78)
- # onyx (17)
- # parinfer (3)
- # pedestal (5)
- # perun (1)
- # powderkeg (19)
- # protorepl (37)
- # re-frame (3)
- # rum (2)
- # spacemacs (1)
- # uncomplicate (8)
- # unrepl (78)
- # untangled (29)
- # yada (41)
@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.
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.
yup, tried that too
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
try js/React.createElement
and pass om element as the third parameter, sounds stupid and probably is.
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.
Hi, I've been out of the loop for a couple weeks on the #om slack- Did I miss anything important? 🙂
:value
is not used at all - just documents what gets changed - for humans. You don't need to both with :value
.
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.
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.
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.
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.
obv if a mutation needs remote work then it needs it; nothing to do with the UI hierarchy.
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.
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.
So if a child is being deleted, do the transact in the immediate parent, using this
.