Fork me on GitHub

@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


@adam thanks. That'll save me some time simple_smile


@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)


Trying that now...


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])
(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 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 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.)


just released 1.0.0-alpha14 - breaking change


normalize -> tree->db


denormalize -> db->tree


updated all the corresponding docs


I am able to get a lanes and components thing going with datascript, cool stuff. 😄


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.


You don't need to normalize yourself.


@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


@jannis: I made that change and now I see the data.


seems like useful reading to take my test.check post to its logical conclusion


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?


@jannis bogus stupid React warning


Will probably change the method name to avoid


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)


Yeah not excited about introducing an event model yet.


@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.


And on renaming the getInitialState…I’ve been thinking the doc matching issue could be addressed by doing the standard camel-case <-> clojure hypenated naming for all of the methods would make a consistent story that everyone could easily do the translation on.


@adam: Instead of wrapping mutate, I wrapped the parse invocation with a fn that logs to timbre and removes stack trace from results for clients. This also handles exceptions in read fns as well as mutate. Thanks for the guidance.