Fork me on GitHub
#om
<
2016-06-16
>
anmonteiro11:06:22

@petterik: right, that problem shouldn't happen with unions. You'll probably get into others which will seem to suggest you should re-root queries, but I wouldn't fall for that!

anmonteiro11:06:55

I have yet to find a scenario where process-roots is useful

anmonteiro11:06:20

So far just leveraging the AST has been more than enough, and much more flexible too

cmcfarlen12:06:27

@anmonteiro: Can you explain (or point to an example) where leveraging the AST is used to manipulate the query such that a remote read is handled as a "query-root" alike but the results are merged deep into the client state?

cmcfarlen12:06:29

I'm thinking of a scenario like loading additional (remote) details for some nested item on demand.

jimmy13:06:59

@anmonteiro: can you help me out with this ? I think it's a good idea that the params of component-path->query should be kept in sync with the individual component as well. If you might have a different approach to this problem, I would love to know. Thanks in advanced.

ethangracer15:06:37

@anmonteiro: have you had any time to think about our discussion about having something in om like datomic’s db-before and db-after?

ethangracer15:06:57

ran into another scenario this morning where it would have been handy

hlolli16:06:00

Does ComponentDidMount not provide previous state and current state parameters? Im sure tough its not the same.

jimmy16:06:43

@hlolli: no it doesn't. only ComponentWillUpdate provides prev-state

anmonteiro17:06:44

@cmcfarlen: that doesn’t seem troubling to me if you’re using normalization

anmonteiro17:06:10

after all normalized data is not deep in the app-state, but at the top level

anmonteiro17:06:54

I suppose you’d need to have some custom logic in merge or send