@anmonteiro It appears to me that the compassus parser, for remote reads (that is, with a target), returns not a query but a single-element vector containing the query. Is that a known issue?
(It doesn't seem to break Om, though I'm not sure why.)
@peeja doesn’t break Om because we wrap send
https://github.com/compassus/compassus/blob/master/src/main/compassus/core.cljc#L289
do you need a different behavior?
Oh. Huh.
Wouldn't it be better to make the parser do the right thing?
@peeja so we previously had expr->ast
in the parser
but you noticed that wasn’t the right behavior 🙂
But we own the parser. We can make it return anything, right?
We can just unwrap it there
I don’t recall what the problem was exactly
I think it was that it returned the query wrapped in a vector 🙂
I know we fixed it here https://github.com/compassus/compassus/commit/8db377181842674334914ccf51fba0ab94e271c0
oh right, we were doing (expr->ast (first ret))
Yeah, that was it
thus ignoring (rest ret)
I don’t see any easy fix
I do. I can PR it
We just need to make it the parser's job, not the read
's job
@peeja PR welcome if you know how it should be fixed
Hmm. Do we have some guarantee that :compassus.core/mixin-data
and :compassus.core/route-data
won't be read at the same time?
The current setup appears to assume they won't
I think they could?
when you’re re-rendering from root
Oh, no, you're right. There are test cases that cover it.
@anmonteiro So, if I'm reading this right, if :compassus.core/mixin-data
and :compassus.core/route-data
are read at the same time, the result of the parser will be a vector of two elements, one for each of those queries. Then wrap-send
will concatenate those queries into a single query, and that's what'll go to the send
.
But: if the two queries have any keys in common, that'll break
I'm not sure what the best way to deal with that is, but that's a potential issue that exists today.
I think that’s fair
@peeja thanks. I’ll review during the weekend
Cheers!