This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (2)
- # beginners (27)
- # boot (85)
- # cider (24)
- # cljs-dev (20)
- # cljsrn (16)
- # clojure (73)
- # clojure-brasil (2)
- # clojure-czech (152)
- # clojure-dusseldorf (7)
- # clojure-france (3)
- # clojure-japan (1)
- # clojure-norway (1)
- # clojure-poland (7)
- # clojure-russia (140)
- # clojure-uk (7)
- # clojurescript (66)
- # cursive (20)
- # datomic (8)
- # emacs (7)
- # events (1)
- # hoplon (325)
- # jobs (2)
- # jobs-discuss (69)
- # leiningen (3)
- # off-topic (6)
- # om (48)
- # onyx (82)
- # parinfer (1)
- # planck (10)
- # re-frame (53)
- # reagent (8)
- # ring (103)
- # untangled (13)
- # yada (14)
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 ?
: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)
:normalize flag has slightly changed meanings in the latest beta
@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.
`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 om.next/queries 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 om.next/queries. 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 https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L655 . @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
merge!, yes: https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L1440
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
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
@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 https://github.com/Jannis/om-next-kanban-demo 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?)
@curtosis: Om Next does
tree->db (normalization) internally if the initial app state is not an atom.
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.
ISTR dnolen might have showed something like that at Day of Datomic, but I could be misremembering.
@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 : https://github.com/thos37/om-experiments/tree/refs
@curtosis: Here u go https://github.com/madvas/todomvc-omnext-datomic-datascript . 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:
@thosmos: nice to see them all in one spot ... could be helpful in clarifying thinking.
@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.