om

Please ask the channel first, not @dnolen directly!
peeja 2017-04-18T19:42:54.024614Z

I think I'm missing the theory behind :keys in the merge result. The default-merge causes the entire root component to queue, correct?

peeja 2017-04-18T19:43:28.035537Z

It seems to me that any good merge implementation would have to, since new data may require new components to be rendered.

peeja 2017-04-18T19:44:02.046802Z

It's not enough to find components which need to be queued if some of the components which need queuing may not exist yet.

ag 2017-04-18T20:26:09.897372Z

@anmonteiro do you have anything good to read on how Compassus handles idents in components wrapped in a mixin?

ag 2017-04-18T20:40:25.185488Z

so if I have a route and a component associated, and that component has a query with Ident, when the novelty comes back from server, it suppose to normalize data based on the Ident, right?

ag 2017-04-18T20:51:36.408966Z

when novelty comes back from server and there’s a query in the root component that has Ident somewhere that data should be normalized automatically, right? you don’t have to have any custom merge fn or whatever?

ag 2017-04-18T23:10:05.436011Z

I just tried with a simple om app, and it does normalize automatically when novelty comes from the back-end, if there’s a query with ident.

ag 2017-04-18T23:10:26.439800Z

I can’t find a way to make Compassus respect idents though

ag 2017-04-18T23:44:17.774577Z

Ok, I have figured it out… apparently this

ag 2017-04-18T23:44:38.777977Z

the last sentence is quite important…

ag 2017-04-18T23:45:18.784242Z

Om by default works without the second argument - Compassus needs query to be passed in that callback, otherwise Idents down the tree will be ignored and normalization won’t happen