Fork me on GitHub

I’m poking at the reconciler in tests, and I’d like to assert on the props that a component will receive but can’t figure out how to do that.


I saw (parser (#'om/to-env reconciler) query) in the test suite which makes sense if query is the root query, but I’d like to reconstruct the parser result for a nested component


How can I get to something along the lines of (parser (#’om/to-env reconciler) (om/get-query SomeSubComponent)), assuming I need to reconstruct the parent path somehow but I’m not sure...


Howdi, I've just read the tutorials and started to implement two components. It seems like the callback that is used to merge changes to the state in a send-function does not trigger reads. I expected that when I call the cb with a map containing a new value for a key, and I have a query in a component for the same key, as well as a read function for the same key, then the read function would be called..? Do I have to use something like transact! in order to trigger the necessary reads?


@molstt If I’m not mistaken in your initial transact! call you can add read keys to your expression like '[(my/mutation) :read-this :read-that]


@jfntn It sounds like you may be looking for full-query


although it may be tricky to use in isolation, since it depends on the path where the component is mounted


@peeja interesting! Missed that one, will try it out


Though it needs an instantiated component and I haven’t dealt with those at all so far, but I guess you would need to in any case…?


@jfntn ok, currently I don't have any initial transaction. I read from a remote in a send-function (as in the remote tutorial) and use the callback to "transact" some novel state.. Shouldn't that have the same effect (rerenderings) as a transaction? om/transact! requires a component or the reconciler, so I would have to do some redesign if I have to do that..


@jfntn Well, sure, but the path that makes it a full query has to come from somewhere. 🙂 You could mount the same component at different places, and it would have a different full-query.


I suppose you could put something like [{:some-key [{:another-key (om/get-query SomeSubComponent)}]}] in your test, and consider the [:some-key :another-key] part of your test data. That is, you're saying this component's query does the right thing if it's mounted at that path.


@molstt does the remote read merges state that’s not part of the initiating component?


@peeja yes that’s what I was thinking, it might become overwhelming to assert over the entire app-state after a while but at this point this is probably the better option


@jfntn the novelty goes straight into a previously unused entry via the callback, then there is another component that has the entry (key) in its query and read function. So, I would say the answer is yes.


@molstt try to (clojure.pprint/pprint (deref reconciler)) after the remote read comes in, it’ll show you the current state, it should help understand where your data ended up


thanks, will try that


Looking for some advice: We've got a fair bit of domain logic that calculates values based on domain data. In an Om Next world, our data maps don't always have all of the possible keys anymore: they only have they keys that a component queried for. When a component uses a key's value directly in its render, it's obvious what to query for. But when it needs to pass data to some domain logic to calculate something, there's no way to know what to query for without looking through the code or documenting it in a docstring.


Are there any good techniques people have for surfacing what keys you need to be querying for?


Is there a good way to use clojure.spec to do that, perhaps?


Essentially, I want to be able to compose subqueries that I get from functions, not just components. (Although that may not literally be how a good solution would work.)


@jfntn yes, the data enters the reconciler, so I suppose it's my other component's reading that's problematic, will focus on that


@peeja interesting problem, it sounds like anything auto-magic would be pretty involved, especially since a lot of the spec implementation doesn’t seem friendly to introspection at this point.


Having plain s/fdef specs would be a good starter tough


Yeah, it may be enough to just validate that I'm passing it the right keys in dev/test using spec