Fork me on GitHub

has there been any attempts on server-side rendering for om next?


as far as i can tell there are 3 ways: prerender, nashorn & a foam-like hack (convert cljs back to clj)


wondering which one is the most feasible


to answer my own question: found this


hi guys, can some one explain to me how mutation works in om next. I know how to run mutate, but I wonder that in :value of mutation function, we will specify the content will be returned back. And my question is , the component itself will get that data and merge to current data ? and how do we handle the error return from backend ?


@anmonteiro: Thanks for writing the recursion article. I'm a bit confused by how ident is handled. .. and declare its Ident, a unique key by which each data item is identified. In other examples I've seen the ident declared on the child components (each data item), as opposed to a parent. Is that necessary on account of the recursive query? or what is the motivation one way or the other?


@nxqd: the :value of a mutation contains a map with :keys and/or :tempids (from the quick-start tutorial) It just says 'I want a reread for this or that key'. The Reconciler has a :merge-tree key which default to the standard clojurescript merge, that function merges your old and new data. After merging, your Root component gets its new props, which flows down React-style. As to error handling, it depends on what you want to accomplish...


An example of another style of merging new and old data is the following: (defn custom-merge-tree [a b] (if (map? a) (merge-with into a b) b)) It'll merge keys without overwriting,


thanks @iwankaramazow. I'm trying to wrap my head around reconciler and om next engine.


@locks: PT living and studying in Germany


@rburns: the ident in union queries is located where the union entry query is. It's valid for all union queries, not only recursive as in the post


@anmonteiro: is the alternative not valid for union queries?


@rburns: if you look at the composite design pattern, Leaf and Composite inherit from the Component Class. In the recursive example you could look at it as Component is a child of the Root-Component. Leaf and Composite aren't childs from Component, they are a particular kind of Component. (no idea if this makes sense)


meaning relative to the design pattern the ident is implemented in the base class?


yep, In other examples I've seen the ident declared on the child components the base class is the child component here


hmm, maybe on the other hand you could move the Ident to Leaf & Composite , but it seems to be 'better' design to give that responsibility to the base class


ah wait you can't


looking at the render function clears some things up. I guess I'm just curious how the choice affects om's mechanics, if at all.


I just tried moving the Ident to Leaf & Composite , seems it isn't really possible


@iwankaramazow: you mentioned redux + falcor being a mess, I wouldn't call our codebase (which uses them) a mess but it ain't elegant either. Did you have a look at the recent update to redux-falcor? The author seems to have switched to a "component declares paths" style, a little closer to in some sense.


@bbss the project was finished around 15 december 2015, just before the latest redux-falcor update. So I can't comment on the current situation. Basically keeping the redux state and falcor model in sync gave me a lot of problems. Get & Set operations were fine, call was problematic. The normalization & reshaping logic from backend to falcor router was very error prone too. It worked, but it took a lot of time.


I extended redux-falcor with a lot of things to make it work.


Honestly I can't believe Netflix uses the thing they open-sourced in production.

Pablo Fernandez12:01:30

Is both Om and Om Next on topic here?

Pablo Fernandez12:01:41

In the Om Next quick start, it says "When writing a backend parser you will usually supply env yourself.” By backend, is it talking about Clojure running on the server (not ClojureScript running on the client)?


but it’s not necessary either

Pablo Fernandez12:01:06

What is not necessary, passing env or the server side?


using Clojure on the server side


if you’re not none of that statement even applies

Pablo Fernandez12:01:04

Ah, yeah. I am using Clojure on the server side.


@dnolen: Is there a reason why provides transit readers and writers as custom functions instead of maps of read and writer handlers which could be merged with other read and write handler maps?


Current ring-middleware-format options only allows providing read and write handlers as maps


Ah, and sorry about not reading the topic first


@juhoteperi: it could be done that way, but it’s really not that important


no idea why ring-middleware-format imposes such a design and I don’t really care about that


the handlers are exposed anyway in Om so it’s really not a real problem anyway


Well, I care because I'm looking into fixing the problem if there is one, but I'm first trying to understand if there's a reason why read and write handlers are not maps


@juhoteperi: it just doesn’t matter


not going to change it at this time


@jannis: Not currently as r-m-f doesn't provide decoder and encoder options, but that's probably going to change


@juhoteperi: I'm not sure I understand. The code above uses r-m-f with :decoder and :encoder options.


@jannis: Oh right, but restful middlewares don't allow those options


@juhoteperi: Right, you mean wrap-restful-format, wrap-restful-params etc.?


@jannis: Yes. If you are interested the issue is being discussed here:

Pablo Fernandez13:01:36

Do Om Next apps tend to have only one reconciler?


@pupeno: there’s not good support for having more than one outside of devcards or something like that


so effectively for anything serious - yes

Pablo Fernandez13:01:14

Ok. I’m just confirming my assumptions to see if I understand things correctly.


I'm working on recursive queries with Datascript and I have a question about om/process-roots. It would seem unnecessary when using an external state store, but I want to make sure there isn't some magic under the hood controlling component re-rendering based on keys.


@bplatz: process-roots is just about controlling what goes across the wire


that is identify which parts of the query actually have some interpretation on the server


it can also be used to do sophisticated incremental data fetching


Thanks. So I'm sure some datascript users might need it but I'm backing with datomic and just returning datoms from the server, so the om query is just client-side scaffolding.


if you don’t need process-roots don’t use it


it’s a completely optional a la carte thing


can anyone point me at documentation or an example about how to handle associated data models. As an example, I could have a list of users at some place/component and at another place/component I want to show messages of those users, combining data from message and user in the same place.


@juhoteperi FYI what I did about the transit handlers for now is replicating the handlers from in my own code and passing those via :handlers options down to the reader/writer.


i’m confused by the syntax of (get-in …) when i’m looking at some om code


inside here the author uses (get-in app [:main-app :background-color]) but then later on he uses (get-in app [:zoom-factor])


how come he can switch like that? everything is contained in :main-app


i’ve tried it in my code but i get errors if i skip the :main-app


ah i’m sorry.. it wasn’t clear to me


@anmonteiro only gotcha was the file named devdemos/om-next.cljs. Those dang hyphens. We need an automated check for that crap. 😀


@bhauman: cool stuff, thanks! Working on improving the reload story, might have something for you to look at later


for people hacking on Om Next - it’s now possible to run the tests from the command line via bin/test


this assumes you have Node.js installed