Fork me on GitHub
#untangled
<
2016-10-24
>
tony.kay15:10:00

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???

tony.kay15:10:52

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

gardnervickers15:10:16

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

tony.kay15:10:25

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

gardnervickers15:10:18

Ah as an alternative to the fallback mutations?

tony.kay15:10:30

yes, that is one use

tony.kay15:10:34

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

tony.kay15:10:54

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

tony.kay15:10:22

instead of (load [:current-user])

tony.kay15:10:54

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

tony.kay15:10:03

and less to implement

gardnervickers15:10:24

Gotcha, thats very interesting.

tony.kay15:10:47

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

tony.kay15:10:39

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

gardnervickers16:10:58

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 <…>})]
While our on-page-load callback just calls
[(fetch-profile {:token <…>})]

gardnervickers16:10:08

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

tony.kay16:10:52

Same here. It would reduce network chatter to detect problems

tony.kay16:10:04

well, depending on how you implement

tony.kay16:10:53

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

tony.kay18:10:30

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)

tony.kay18:10:36

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.

jasonjckn18:10:45

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

tony.kay18:10:04

they trigger a return handler. See the template example

tony.kay18:10:15

sure. Trivial to use. State atom is in env

tony.kay18:10:59

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

jasonjckn18:10:14

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

tony.kay18:10:24

I think that is the Om standard

tony.kay18:10:30

if it isn't, I should fix it

jasonjckn18:10:37

i see :value a ton in OM

jasonjckn18:10:40

never seen :result yet

tony.kay18:10:48

that's beacuse default merge throws it away

tony.kay18:10:40

Yeah, :result

jasonjckn18:10:39

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

jasonjckn18:10:48

:value shows up in the OM next docs for reads

jasonjckn18:10:45

":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."

adambrosio18:10:31

but what does :action return

tony.kay18:10:07

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

tony.kay18:10:24

on mutations, value is about advertising updated data

tony.kay18:10:27

not returning a result.

jasonjckn18:10:24

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

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

tony.kay18:10:15

Chat about :result

tony.kay18:10:30

see #om around this timestamp

tony.kay18:10:15

I had forgotten that Om even supported it

tony.kay18:10:48

that discussion is what spurred me to make the addition

jasonjckn18:10:09

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

tony.kay18:10:13

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

tony.kay18:10:45

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

tony.kay18:10:06

so I might want to change that

jasonjckn18:10:20

@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⁠⁠⁠⁠

jasonjckn18:10:25

yes you did something slightly different

gardnervickers18:10:43

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.

tony.kay18:10:24

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

gardnervickers18:10:53

Alright cool, figured as much 😄

tony.kay18:10:41

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

jasonjckn18:10:49

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

tony.kay18:10:47

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

jasonjckn18:10:03

seems okay to me

tony.kay18:10:05

don't remember when the migrate happens

tony.kay18:10:08

before or after

tony.kay18:10:11

so that might be useful

tony.kay18:10:26

should check that order and doc it

tony.kay18:10:59

migrate is first, as I'd expect

tony.kay18:10:10

done and pushed. On clojars 0.6.0-SNAPSHOT

tony.kay18:10:14

template updated too

tony.kay19:10:52

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

tony.kay19:10:01

might be confusing when debugging?

adambrosio19:10:49

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

jasonjckn19:10:06

i'm agnostic on the subject

tony.kay19:10:07

@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

tony.kay19:10:21

if you remapped 6 things, it would just be confusing

tony.kay19:10:46

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

tony.kay19:10:13

done and pushed. tempids not passed through