Fork me on GitHub
#om
<
2016-04-13
>
jimmy02:04:18

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 ?

francoiswirion13:04:06

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)

anmonteiro13:04:45

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

anmonteiro13:04:00

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

anmonteiro13:04:27

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

francoiswirion13:04:04

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

francoiswirion13:04:34

So :normalize now determines the behavior of merge!?

jimmy14:04:56

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

anmonteiro14:04:55

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

francoiswirion14:04:49

@anmonteiro: Understood. And thanks.

kendall.buchanan15:04:35

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?

tomjack16:04:47

@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

uwo16:04:46

@tomjack thanks for the follow up

curtosis17:04:29

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

curtosis17:04:51

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.

madvas18:04:27

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 om.next/transact! ?

iwankaramazow18:04:15

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

iwankaramazow18:04:50

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

iwankaramazow18:04:31

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

curtosis18:04:16

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

iwankaramazow18:04:42

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

madvas18:04:44

@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

iwankaramazow18:04:07

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

curtosis18:04:21

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

curtosis18:04:52

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

jannis18:04:54

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

curtosis18:04:02

aha! good to know!

iwankaramazow18:04:13

idem for a merge with data coming in from a remote

jannis18:04:20

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

curtosis18:04:26

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.

iwankaramazow18:04:07

Hmm, I don't think there are any available

curtosis18:04:47

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

madvas18:04:26

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

curtosis18:04:07

nifty, thanks!

curtosis18:04:20

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

thosmos19:04:20

@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

madvas19:04:09

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

tomjack20:04:26

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

tomjack20:04:20

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

curtosis20:04:43

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

curtosis20:04:22

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

tomjack20:04:09

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

kendall.buchanan21:04:52

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

madvas21:04:59

@kendall.buchanan: thanks, oh, yea, I guess this was kinda explained in https://awkay.github.io/om-tutorial/

kendall.buchanan21:04:37

Here’s the tutorial that helped me see how to recursively call parse: https://github.com/awkay/om/wiki/Om-Next-Overview… about half-way down.