Fork me on GitHub

Is there a reference somewhere describing the current state of Om Now vs Om Next? I thought last year that the movement was towards Om Next but I see that work is actively continuing on the former AND the Om Now basic tutorial was edited as recently as Nov 13, but Om Next’s Quick Start was edited last on Sept 13.


@eugekev: there hasn't been work in Om (Now) for a while


I see how you may have thought that, given both projects live in the same repo. See here for more context:


Much thanks @anmonteiro - exactly the clarification I was looking for. Must also add: I find om next much easier to grok given some JavaScript react experience I have. Great thanks to all devs


Hey, all. I'm trying to make a button that transacts a mutation on-click which goes to the remote server, but I'd like the button to show a "Working…" state until the mutation succeeds (or fails) remotely. Are there any good patterns for this yet?


I can imagine ad hoc ways of doing it by adding a key somewhere in the local implementation and removing it when the request comes back, but I'd like to come up with something that doesn't require recreating a bunch of moving parts each time I want to use it.


Id love to hear a good way to do it too. I solved it by transacting in the app state loading to true on click, and the server response has {:loading false} that merges, causing a accurate loading indicator. But the ugly thing about this is that Im sending {:loading? false} across the wire for seemingly no good reason.


Hmm... I have seen some patterns but nothing that really strikes me as "the way to do it" ... Basically a loading message while waiting on the mutation? How do you have your mutations re-integrate into your app?


@ag just out of curiosity, did you figure out how to parse next-props ?


does anybody have a good resource on what the funky chicken is going on with including cljc files among cljs/clj ?


> did you figure out how to parse next-props ? @sova nope ;(


@peeja @hlolli The closest comment from Nolen on this is here: Likely your client will receive something from the server after the button is done working (a database id for instance) wherever that data is stored in the client state, place a :loading marker and then have the UI reference that marker to display the loading message. The marker will be overwritten once the server data has arrived. (still a bit ugly, I agree)


@drcode I've seen that, but I'm not sure there's a great way to make that approach work. For one thing, that means any time I put a button in my UI, I have to compose its query into whatever component it's rendered in, and I have to make up a key for that query to live under.


@peeja- Yeah, I agree it's messy... I suppose what's needed long term is a way to query the remoting process in some abstract way so you can ask it "what is the status of the remote request associated with this transaction?"


Oh, that's interesting.


It still means composing the query of each button into its parent's query


and making up a bogus key for it


It's frustrating that a component which is only ever going to use idents for its query, and therefore has no logical place to be nested in a larger query, still has to be "mounted" in the query tree under some bogus key


@peeja I've given up on the idea that queries should be tidy. Instead, my rule now is that queries are super messy, but the parsers can use arbitrary transformations to insulate the app state from the messiness, and as long as the app state is clean, who cares if the queries are messy?


Well, considering the query represents a data model that lives across multiple codebases and servers, I care. 🙂


I mean, that's overstating it a bit: it just means that it's the local parser's job to clean that up before passing it on


but that cleanup is getting harder and harder to do


@peeja I guess I consider the query to be a sort of "View" on the data (with all the messiness that views can have, due to UI idiosyncracies they have to serve, such as needing to display highly specific info in a otherwise very general button)


@peeja but yeah, I struggle with OmNext queries on a regular basis... this stuff is hard.


Yeah, I guess that makes some sense


Guys, need help. Still can't figure out the normalization stuff. My head is exploding. If I have state data like this:

{:app/data [{:id :foo, :table/data [1 2 3]}
            {:id :bar, :table/data [4 5 6]}]}
and after setting the idents and then when I run (om/tree->db Root init-data true) it returns:
{:app/data       [[:table/by-id :foo] [:table/by-id :bar]]
  {:id :foo
   [1 2 3]}
  {:id :bar
   [4 5 6]}} #{:table/by-id}}
now running this:
(om/db->tree '[:app/data] (om/tree->db Root init-data true) reconciler)
returns something like:
{:app/data [[:table/by-id :foo] [:table/by-id :bar]]}
- But how do I grab table/data for specific table? What is the syntax of the query will be? - Can I expect to be able to grab that data without having to implement read method for :app/data? just by using om/db->tree?


what is the map-ident argument in db->tree? how can I use it?


@ag your problem is that the query is not specific enough to denormalize the data


if you ask Om Next to denormalize a single property, it'll just return that property to you


try this:

(def normalized (om/tree->db Root init-data true))
(om/db->tree (om/get-query Root) normalized normalized)


there needs to be a join for Om to look past the single prop


I understand. What I can’t figure out how to use “reference” syntax in join query so this returns the right thing, but it returns it with both :id and :table/data of :foo

(om/db->tree '[{:app/data [[:table/by-id :foo]]}] @reconciler @reconciler)
How do I force it to grab only :table/data of :foo?


@ag maybe (om/db->tree [{:app/data [:table/data :id]}] [:table/by-id :foo] @reconciler)


an ident if effectively a piece of data, which you can pass as the 2nd argument to db->tree


ehhh… what…? oh… eh… mkay


if you pass the full app state as the 2nd arg of db->tree it can be potentially very slow


as it'll denormalize the entire state everytime


I don’t think it’s working (approach you suggesting), maybe I am missing something else


@ag my bad, try this instead:

(om/db->tree [:table/data :id] [:table/by-id :foo] @reconciler)


you don't need to put :app/data in the query, of course, since you just want a single item


so use the query which describes it


alright that worked


but I’m more confused to be honest even more than before


Thanks Antonio!


what don't you understand?


no, no, I was just totally surprised by db->tree arguments


now it totally makes sense


I’m still a bit befuddled I guess


God, I wish someone wrote a book on OmNext that explains its mechanics