This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
@drcode: welcome. Those two docs I ref’d are actually quite short. Skip the API…bunch of OO noise.
A question for anyone: I’ve noticed that any mutation :action fn will fail silently if it generates an exception. This is true of a jvm parser or a client cljs parser. Is this the intended behaviour?
I’m currently wrapping all my fns in a try/catch but that’s a lot of boilerplate. I can macro but before I do, I’d like to know the idiom for error handling in mutations. Anyone?
@steveb8n: the parser wraps the mutation :action
thunk in a try/catch and assocs any exception thrown into the returned map under the mutation name (where :value
would normally be returned). 1.0.0-alpha12 fixed a bug where :value
took precedence over the error and the error was lost
@steveb8n: not sure whether any error-handling idioms exist yet, but you could wrap your mutate
function with an error-handling / transforming function (before passing it to om/parser
)
with similar queries for different sub-components [:a :b :c]
for component 1 and [:a :b :d]
for component 2. is it ok to join the queries like
(->> (into [:a :b :c]
[:a :b :d])
(distinct)
(into []))
?if component 1 will receive the props for [:a :b :c :d]
, will it rerender if :d changes?
@thomasdeutsch: It’s all up to you. It should receive whatever the query specified though it’s up to you whether it actually does. It’s also up to you whether it re-renders when :d
changes.
@olivergeorge: there’s ideas for all your concerns. Business logic usually goes into parsing. Derived data is handled through om.next/computed
. REST integration has already been sorted out - but there’s only one end point and there is a HTTP caching story.
@olivergeorge: as far as re-frame, re-frame is very Flux-like. Om Next converts Flux into plumbing. Same as Facebook’s Relay.
@tony.kay: the fact that two or more components can have the same ident is a big part of the idea. Lot of value to be gotten out of that.
@drcode: library components should not be transacting. Use om.next/computed
to pass down callbacks. Only transact!
from components that have knowledge about what changed.
this is also the reason why you may have client only keys that unrelated components can listen on.
they can observe the same key and be blissfully unaware who else is listening on that key.
(I wonder if extra
/ get-extra
, extended
/ get-extended
or something would be more intuitive. But I'm happy with computed
as well.)
Any place I can read more about when to use computed? Or was it only discussed briefly yesterday?
I want to somewhere soon start experimenting with a range input element that will change an audio api param. I don't yet know how to approach it but I doubt I calling transact callbacks from the onChange will be performant enough. With re-frame calling dispatch sure wasn't.
@bbss: Components that have queries should only receive the query result via props. Everything else, extra data, callbacks, whatever, should be added via om/computed
. For instance: (todo-item (om/computed item {:selected true :on-click #(js/alert "Clicked")}))
.
Then, inside TodoItem
, you would extract props like so: (let [{:keys [id text]} (om/props this) {:keys [selected on-click]} (om/get-computed this)] ...)
Queries establish a contract for what components expect via props and om/computed
is, amongst other things, a way to avoid messing with that.
I see, currently I am passing the on click handler of "add a component" by merging it in with the props so I guess I need to change that.
Yes. That's what I used to do as well. (todo-item (assoc item :on-click #(js/alert "Clicked")))
for instance. You can do it but it's not a good idea.
@dnolen: regarding Ident and “listening on client local keys”. The utility of “listening on more than one” in the more general case (I’m adding something to a component in an existing code base has two names for the two things I’m now composing together) could also be useful, but that seems at odds with the path optimization problem. So, I’m wondering if tightening up the concepts (or splitting them) might be a good idea.
@monjohn: Not sure right away but the first thing I would do is drop norm-data
, pass init-data
to the reconciler and (if it is an atom), pass in :normalize true
as well.
@tony.kay: listening on some unique application specific key isn’t really add odds with the path optimization stuff
one possible idea is to propagate parent ident down to components that don’t have idents
this gives you enough context for optimization, and of course it will work even if you don’t provide that
Should I be able to define getInitialState
like this or is it wrong? (defui Item Object (getInitialState [this] ...))
I get an error/warning in return, saying getInitialState
was defined on a plain JavaScript class, not a class created using React.createClass
.
Or, phrased differently: How do we define the initial state in Om Next components with local state?
Right. The funny thing is it doesn't complain about defining componentWillReceiveProps
, AFAIR.
@dnolen Passing transaction data from library component to parent makes sense- I sort of wonder whether Om Next might benefit from giving parents access to all child transactions by default somehow, through something like a lifecycle event (though having the programmer do this explicitly, as you recommend, is also a valid solution, and very simple)
@dnolen: what I was saying about Ident: the purpose you want it for in path optimization is giving the context for the rest of the query. In that case it is acting like a “data PK”, so that the underlying parsing/read code wants to treat it that way. But in the sense of UI updates it is acting as an indicator that something about the data in use should trigger updates together. It’s not at cross purposes…it is a subtle thing that probably doesn’t deserve attention until we get more use-case examples in real applications.