@anmonteiro Compassus code is very elegant and pleasant to look at! Lots of test code too!! Congrats and thank you for writing such amazing free software with amazing doc I may add. I really enjoyed reading your blod about om query syntax earlier today as well. You are very talented 😉

Happy to help :-)

(om.next/class->any reconciler SomeComponent) doesn't always return a component. Through trial and error, I realize that components that aren't rendered aren't found. That's probably expected. Since I have components that only exist so they can have a query and query params, what do I need to do to be able to find those components?

@alpheus Just a stab in the dark really, but maybe render something invisible as a workaround? like a hidden input or something...

I'll try that

yes, that works. I'll have to read up on the React component lifecycle

@alpheus What are you using instantiated-but-not-rendered components for that you can't use the class for?

Hello, beginner’s question here: I have trouble understanding how the om.next parser’s read function works. I’m looking at example in https://github.com/omcljs/om/wiki/Components,-Identity-&-Normalization: the Person component’s IQuery is [:name :points :age], however, there is no implementation of the read multimethod for these keys (not even the default one). I was expecting that the read fn gets called for each key in component’s query, but that seems to be wrong? What’s the point in specifying keys in the IQuery that are not handled by the read fn?

@bbktsk those keys are mapped using the get-people function

@dzannotti But what’s the point in declaring these keys in the IQuery fn? get-people is not touching that.

@bbktsk Person queries [:name :points :age] off the given ident

think of it as a sort of symlink

:list/one [[:person/by-name "John"]... is a sort of list of symlinks, the read function resolve those symlinks to their real value, and then picks off the keys that the Person component wants and passes them over. However since those are symlinks, the reconciler needs to know what's their identity so it can keeps all components that reference the same symlink target in sync

@bbktsk @dzannotti I have been (or am going through) the same discovery processes as @bbktsk. What is not clear is the code path that a query follows. I think there is some reading being done explicitly in the tutorial code and some "behind the scenes" in the library.. Is that right? The list reads are supplied by tutorial code but the reading of person properties is done by code in the library (maybe db->tree?) Am I close?

@dzannotti I think can see how the read function (or specifically, get-people called from read) resolves the symlinks. But I still do not understand when is the value if Person’s IQuery used in this case. Is that during the normalization? When the reconciler receives the non-normalized initial state, it uses it to retrieve necessary information a build a normalized state?

Nope, that’s not it, just tried it 8(

Hmmm. If I replace Person’s IQuery with just [], everything still works, apparently. Thats… confusing.

@bbktsk I found you have to do a lot of googling and set up a lot of little experiments to figure out what is going on. After a while you get a a feel for it. Rather than replace with [] try [:some-prop] what happens then?

@alasdair I hope that’s not a trick question 😎 No change, everything works, and the state I’m printing with some debug statements inside still looks the same.

@bbktsk I think what is happening is that the top level query is '[{:list/one [:name :points :age]} {:list/two [:name :points :age]}], the parser breaks this down and finds two joins, it breaks those down and finds the list identifiers, your read function hooks in at this point and returns values for the lists, the standard parser then continues to lookup the [:name :points :age].

@bbktsk no, not a trick question - I was wondering if you're invoking some wild-card behvaiour

@alasdair I do not think that’s the case, if I remove these keys from the IQuery it still works.

Also, not sure what you mean by “standard parser” - in some examples, I have seen that read fn has :default implementation that just reads the key from the state, but that’s not present here.

@bbktsk I think I am in your world of confusion then; I have deleted my copy of the tutorial so can't replicate right now. But what I found very useful was to create a cut down example with a Component that simply displays it's query and its' properties ~ you think plug in different state and query to see what happens.

@bbktsk By standard I meant the db->tree function, if you give it simple, normalized data and a query it will return the result.

@alasdair I’m trying that, but I’m feeling lost a little. Well, a lot 😎 Thanks for help anyway, will try playing with db->tree .

@bbktsk Good luck

sorry, i was called away, @bbktsk i can say that the feeling of confusion is normal, it takes about 2 weeks to really start understanding om.next and stop going "wtf is this" - after that it's all downhill and everything makes much more sense faster, reading the code for those parts might be helpful too, it's quite readable (beside a few single character named variables)