So, due to an oversight on my part, I missed the fact that there was a pretty easy way to get return values to work on mutations from the server (instead of requiring a follow-on remote read). The latter is a great and viable way to leverage the normal mechanisms of Untangled to get the desired effect; however, I think it would be pretty easy to inject a step in the merge phase that could collect results of mutations and dispatch them to a function of your choosing (configured at startup). I'm assuming there would be interest in that???

The render refresh story for mutations would still be follow-on local reads, of course.

We have not required anything like that yet, when would it be useful?

'[(add-item ...)] --> {'add-item {:failed ...}} --> calls return handler (rh app-state sym value) (or something similar)

Ah as an alternative to the fallback mutations?

yes, that is one use

[(am-logged-in?)] on start -> {'am-logged-in? {:user-id 33 :name "Sam"}} -> (rh app-state 'am-logged-in {:user-id ...})

e.g. user reloaded page and your session is still good

instead of (load [:current-user])

everything can be done without it, but in some cases it is easier to think abt

and less to implement

Gotcha, thats very interesting.

then your rh can be a multimethod or whatever you find easy .... just a function

might make sense to ahve the signature match parser read/mutate for consistency

[env k p]

We’ve benefited quite a bit from separating things out into multiple small mutations. For example our login form might look like this

[(log-in {:username <..>})
 (fetch-profile {:token <…>})]

[(fetch-profile {:token <…>})]

I definitely see where you’re approach would be useful though

Same here. It would reduce network chatter to detect problems

well, depending on how you implement

throwing an exception on mutation and including a fallback works well, and stops the processing

OK, return values supported from server mutations now: on 0.6.0-SNAPSHOT. Example in the untangled-template-workspace on master (https://github.com/awkay/untangled-template-workspace)

was easy enough to add. I tend to prefer the follow-on reads, but I can see targeted use cases. I am a little worried that it will weaken ppls designs.

any docs on this? where do the return values get loaded in app state?

they don't

they trigger a return handler. See the template example

k

https://github.com/awkay/untangled-template-workspace/blob/master/src/client/template/core.cljs#L8

https://github.com/awkay/untangled-template-workspace/blob/master/src/server/template/api/mutations.clj#L15

interesting

thanks

sure. Trivial to use. State atom is in env

also fixes the bug of mutation symbols ending up in app state

nice

@tony.kay ":result" made more sense than ":value" used everywhere else?

I think that is the Om standard

if it isn't, I should fix it

i see :value a ton in OM

never seen :result yet

that's beacuse default merge throws it away

k

https://github.com/omcljs/om/blob/master/src/main/om/next/impl/parser.cljc#L291

Yeah, :result

it doesn't show up in the OM next docs though? it's an internal key?

:value shows up in the OM next docs for reads

":mutate - a function of three arguments [env key params] that should return a valid parse mutation result map. This map should contain a :value and an :action entry."

https://github.com/omcljs/om/wiki/Documentation-(om.next)#parser

but what does :action return

mutation :value must be nil or a map with structure {:keys [...]}")))

on mutations, value is about advertising updated data

not returning a result.

yah ok, I guess this would be too confusing, but technically feasible:

{:value {:keys [...]}
 :action (fn [] ... {:tempids .. :value ...})}

Chat about :result

see #om around this timestamp

gotcha

I had forgotten that Om even supported it

that discussion is what spurred me to make the addition

yah I had no idea until you said that, i thought you added this feature fresh to untangled

technically, though, I'm realizing I changed it a bit

any value you return gets assoc'd to :result by Om

so I might want to change that

@arohner right. one thing I forgot to mention is that whatever you return from the ⁠⁠⁠⁠:action⁠⁠⁠⁠ thunk will be ⁠⁠⁠⁠assoc⁠⁠⁠⁠ed to the returning response under ⁠⁠⁠⁠:result⁠⁠⁠⁠

yes you did something slightly different

yep

I’m not sure how much protection Untangled would want to provide around this, but we learned the hard way that data-fetch/load will break tab unions where the server-property argument is the same as the top level client-db key.

@gardnervickers nothing we can really do about it. It's your naming convention and state

Alright cool, figured as much 😄

@jasonjckn fixing that delta....and the proj file was wrong on the template

@tony.kay great stuff, mutation results have been frequently talked about for non-optimistic updates, good checkbox to tick

that too

with that cahnge the return handler gets the tempids remap map...I guess that's ok

seems okay to me

don't remember when the migrate happens

before or after

so that might be useful

should check that order and doc it

migrate is first, as I'd expect

done and pushed. On clojars 0.6.0-SNAPSHOT

template updated too

I kinda feel like we should elide tempids, since they're already handled

might be confusing when debugging?

would it be useful to see the real ids part of :tempids in case you wanted to something with/on them?

i'm agnostic on the subject

@adambros not that I can think of. You'd need to know more, whch you'd have to include in the rv from your mutation, at which point you can include the specific id(s) there

if you remapped 6 things, it would just be confusing

cause you would not know what the tempids meant (they've lready been migrated out of existence in your app state)

done and pushed. tempids not passed through