Fork me on GitHub

hi guys, I have a weird problem regarding read in om, the params when we send ( target = :remote ) and the params when the function reread is different. Does anyone experience the same issue ?


The :normalize flag doesn't work in my app. om still normalizes correctly depending on whether I pass in an atom or a naked map, but the :normalize flag doesn't seem able to sway its behavior either way (true / false). Does anybody else have this issue? (I'm using alpha32)


@francoiswirion: the :normalize flag has slightly changed meanings in the latest beta


it won't normalize your app-state if you pass an atom


it simply means that it'll normalize remote novelty when it arrives


@anmonteiro: Ah ok, thanks for the explanation. Should I update the documentation? It currently says: > :normalize - whether to normalize the data provided by the user. If reconciler is given IAtom for :state this defaults to false.


So :normalize now determines the behavior of merge!?


`After debugging, I find out the problem of inconsistent params is : 1- In my root component, I do set-query! when I swap out components ( page component ). While swapping out, I have the default params on the page component which is not the correct one. This time the wrong params are set in under root component. 2- When the component is mounted, I use set-query! inside component to change its params to the correct one, the one that would be sent to remote server, now the params is set under that component in 3- When I have data return from remote, the read function of a key is being reread, and of course it's read through root component instead of directly through the child. That's being said, in the read function the params is not the same params I sent to remote server. I can see that I can try to set the correct query before the component mounted, but it doesn't solve the problem since the query would be changed inside child component at run time. is there any good solution in this case ? Thanks in advanced. # The part of next that set the params . @anmonteiro: is there anyway that we can get the same params in this case ? Thanks.


@francoiswirion: not sure whether to update the docs yet, this might not be the intended behavior, so I would hold off on that


@anmonteiro: Understood. And thanks.


So, I’ve been studying the Wiki guide on “Remote Synchronization”, and it’s raised a more general question: Why use params, and om/set-query!, rather than updating data in the app’s state?


@uwo: I think my patch to allow :root in remote reads is wrong -- it makes sense that you return a QueryExpr ast, not a QueryRoot. :query-root and process-roots are supposed to be used here, I think. but it seems that :query-root only works for joins, not (parametrized) props as used in the autocompleter example


@tomjack thanks for the follow up


what are people mostly using for app-state: om-next db format, datascript, datomic? Some combination?


my core data is in datomic, so there's not really any reason I couldn't store app state in there too; just curious what other folks are gravitating toward so far.


In Om.Next, what is the proper way of finding out if some parser’s read method was called by some component’s IQuery or as a second argument in a mutation query expression in! ?


@curtosis: what people mostly use is irrelevant. Just because everyone is using it is not a good enough argument for me


That being said, you can reuse some parts with datascript, although plain om-next has nicer integration without datascript


The combination of both isn't the best choice, design-wise


@iwankaramazow: true; I'm really looking for whether something is emerging as best practice -- or, barring that, some good examples. 😉


@madvas: the answer is quite obvious 😛 if your parser method does how you programmed it, done 😛


@curtosis: Keep in mind that with datomic+datascript u can reuse same DB queries for local optimistic updates and real db updates. which is great advantage imho


@curtosis: you could start out with plain Om Next until you get the hang of it... More examples...


yeah... I'm finding pretty useful, for example. though it's a little odd in that it uses db->tree but never tree->db (so it's not normalized, I suppose?)


and yes, @madvas I'm definitely liking the idea of datascript+datomic.


@curtosis: Om Next does tree->db (normalization) internally if the initial app state is not an atom.


aha! good to know!


idem for a merge with data coming in from a remote


Erm, sorry, tree->db of course. 😉


got a handy example of the combination of datascript+datomic? I don't feel like I've grokked how that would play out yet. I think I understand how remotes work, at least from the wiki tutorial, but it's a big step over to that.


Hmm, I don't think there are any available


ISTR dnolen might have showed something like that at Day of Datomic, but I could be misremembering.


@curtosis: I have wip todomvc datomic+datascript, I can push it in few moments, mmnt simple_smile


nifty, thanks!


I have to step out for a bit but I'll keep an ear to the slack.


@curtosis: a tiny piece of the puzzle is a little mod of the ident tutorial comparing two type of idents in datascript, one based on a string attribute, and one based on :db/id :


@curtosis: Here u go . But I’m also still Om.Next newbie, so keep that in mind 😄


not sure what to do about params (treat as part of the join/prop key?) or metadata (merge right into left?)


join-query is basically om/merge-joins. for params, it kind of treats them as part of the join key, except:


@madvas: thanks, I'll take a look!


@thosmos: nice to see them all in one spot ... could be helpful in clarifying thinking.


also need to do something about links for a use case like that. hmm.


@madvas, to your question (I’m also a newbie), it was days before it dawned on me that the parser only processes the queries on the root component. After that, it’s up to you to invoke the parser again (recursively) within the read functions. I’ll admit I’m still a bit confused why it can’t run deeper, but maybe that will help.


@kendall.buchanan: thanks, oh, yea, I guess this was kinda explained in


Here’s the tutorial that helped me see how to recursively call parse:… about half-way down.