Fork me on GitHub

remember? you can grab the parser from keys

(defmethod readf :foo
  [{:keys [state query ast parser]} k params] ....)


nevermind… I found it


Anyone see a problem with follow-on reads breaking rendering when both parent and child query the same-named property? I’ve got a parent-child that both query the same prop name, and if I include it as a follow-on read when adding a new child things blow up (no queries found for component at path).


( Is there any good way to render one reconciler inside another? I have a timetravel/log/undo reconciler because I want om goodness in my undo tree, but I also want to render it under the top level html tag of the actual page.


what's the best way to do chained mutations? I have a validate (remote) mutation and a save (remote) mutation, i would like to create a validate-and-save mutation out of composing those 2 (with save being executed after validate is finished and returned from remote)


hey guys… for some reason when I return {:remove ast} it wouldn’t propagate to the send. Anyone has any clue why could that be? @anmonteiro maybe some compassus magic I don’t know about?


@ag let me guess 🙂


you’re doing recursive parsing




i.e. calling the parser from the parser


the thing is that :remote needs to be returned at the top-level, just like a regular recursive function call


@ag also, when it clicks for you why that is the case, would you mind adding an entry to the Om Next FAQ?


I think I’ve been answering this question every week for a long time, so I would have somewhere to direct people 🙂


“if... it clicks”. Using Om.Next I feel enlightened. But most of the time I feel stupid


@ag I love feeling stupid, and I think it’s something everyone should strive for 🙂


just means you’re in the process of learning


@anmonteiro hate to ask directly, any suggestions for my question earlier?


@dzannotti I didn’t read it


let me scroll up


@dzannotti can’t you do both in 1 roundtrip?


@anmonteiro i could, but i still need validate separately (because it can be called manually) and i would end up duplicating the validation code this way


@dzannotti no I mean: (om/transact! [(validate!) (save!)])


if both are :remote they’ll be batched


and you still can use validate! separately in other contexts


uhm... yeah i could, but i'd rather the component not be aware of the logic behind it (and just call validate-and-save), also the batching assumes that the save mutation can't rely on the result of validate (which in this case is fine)


@anmonteiro still something not right. I have a component that set-route! that delegates to another component, that has a query. for its dispatch I return {:remote ast} and it’s not even trying to send anything to the back-end 😞


@ag happy to look at a minimal case, but there’s just not enough information for me to understand what might be going on


right… do you remember that sample project you have showed me how to use compassus the first time? Now, I am serving things for the index page from the back-end. and that works. Now in that component in on-click I do e.g.: c/set-route! this :foo and :foo in core.cljs said to use Foo component. Foo component has a query, parser dispatching correctly on the correct key, but I cannot make it fetch data from the back-end 😞 returning {:remote ast} or {remote true} or whatever not forcing the fetch


is it possible to cut a way the root from the ast tree in a read function (replacing the ast in the env)? when routing (via union query) I was partially successful doing so, but subsequent queries unexpectedly also looks truncated. May I have destroyed some state tampering with the ast?


@anmonteiro is it possible it’s a bug in compassus? It looks like I’m trying extremely trivial case - it fetches data from remote for index-route, but for whatever route after that it refuses to even propagate to send func. Is there a trick I have to use? I tried :query-root true - still nothing


@ag could definitely be a bug in Compassus. A minimal repro would really help


it’d be awesome to get that in for the nearing 0.3.0 release


if we confirm it’s indeed a bug


alright… gimme a minute… I’ll cleanup things and push it out.. I’ll ping you



ag21:10:58 so here… initial route fetches data. you click on an item… and it doesn’t 😞


@anmonteiro so in the second defmethod target is nil.. is that right? Compare it with the first defmethod (the one that does fetch data) first time target is nil, on the second pass it’s not nil