Fork me on GitHub
#om
<
2016-07-24
>
mclarke19:07:52

is there a pattern in om next for combining a remote mutation and a remote read as part of the same query expression?

mclarke19:07:06

e.g. if you call (om/transact! this ‘[(create-object) :list/objects]) on the client, is it sane to send the mutation and receive the full list of objects back in the response, including the newly-created object?

anmonteiro19:07:39

@mclarke: that’s how I’d do it. are you having any problems with that approach?

anmonteiro19:07:55

after all doing all of that in a single batched request is one of the reasons Om Next exists 🙂

mclarke19:07:16

yeah that was my understanding as well haha

mclarke19:07:30

i think i’m doing something wrong on the client then, since the full query isn’t being sent, just the mutation

mclarke19:07:02

the component i’m calling transact! from has a query [{:apps/items (om/get-query Application)}], should the read argument to transact! be just a keyword or can it be the full “fat” query

mclarke19:07:10

i thought i remembered reading om performs a lookup based on the keyword to generate the query for you, but that could be mistaken

mclarke19:07:07

transform-reads is what i was thinking of

anmonteiro19:07:10

@mclarke: yeah, just the keyword is enough. but I don’t think follow-on reads perform remote reads

mclarke19:07:28

i see - i was playing with (om/force) as a way to trigger the second read, but didn’t have success with that either

mclarke19:07:08

is a follow-on read in transact! different from the combined “mutate & read” query that i’m trying to send to the remote?

mclarke19:07:05

e.g. maybe i should refactor to call (om/transact! this ‘[(create-object)]) and in the client-side mutate function somehow rewrite the query that is sent server-side from [(create-object)] to [(create-object) {:list/objects [...]}] or something similar

anmonteiro19:07:51

@mclarke: I think force should work

anmonteiro19:07:06

actually the parser doesn’t seem to recognize it, I’ll have to look with more time

mclarke19:07:21

ah got it. if it did recognize force, i think it would trigger a second network call to re-read the data after the mutate is sent server-side, correct?

mclarke19:07:25

(appreciate the help on this sunday, i’ve been banging my head against this for a while now :P)

anmonteiro19:07:21

@mclarke: I’m unsure if it would trigger a 2nd network call or batch both queries

mclarke19:07:44

got it - i could see how either behavior might be preferred in different situations

anmonteiro19:07:36

@dnolen: in case you’re thinking about cutting a release with the recent fixes, I’d still like to get a fix in for #727 before that if you don’t mind

dnolen19:07:48

@anmonteiro: ok, will wait for that

mclarke22:07:43

@anmonteiro: looks like (om/force) should generate the remote query i’m trying to build (something like [(create-object) :object/list] that is sent to the backend server, despite the presence of existing cached data for :object/list). maybe i’m using force wrong, but the behavior i’m seeing with alpha40 is that a call to transact! with (om/force) on the read key only includes the mutation and not the read in the remote query

mclarke22:07:26

e.g. calling this: (om/transact! reconciler (vector ‘(create-object) (om/force :apps/items)))

anmonteiro22:07:45

@mclarke: right, as I said before, it doesn’t seem that the parser recognizes force for reads, only mutations

anmonteiro22:07:12

let me check if there’s something you can override in the reconciler to provide the behavior you seek

anmonteiro22:07:07

nah, doesn’t seem like

mclarke22:07:09

oh reading the source i thought it still gets picked up as [quote ast]

mclarke22:07:27

makes sense, i thought it might work for both reads and mutates based on:

(parser/expr->ast (om/force :apps/items))
{:type :prop, :dispatch-key :apps/items, :key :apps/items, :target :remote}
but i must be looking at the wrong path

anmonteiro22:07:29

@mclarke: actually it seems that your remote reads should be happening https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L888

anmonteiro22:07:55

so I’d bet on a problem in your parser?

mclarke22:07:10

@anmonteiro: ah that was the insight, i had assumed that force would automagically include the query fragment, but i still needed to return :remote true in the parser read as well. thanks for your help today!