https://twitter.com/anmonteiro90/status/768241791598465025

I think I need a nap. I'm having a hard time even figuring out how to look this up. I've got a mutation that's creating an invitation. The mutation is returning the tempid map as it should, but I also want to return some extra data such as the invitation token in the response. I'm blanking on how to do this. Any pointers to an example or a reference?

@grzm we’ve found that 99% of the time, there is no need to return any data from the server because the client does an optimistic update

we only return non-tempid data from the server through reads

gotcha.

not sure if others have played with returning data through mutations

should work if you put a :value key in addition to a :tempids key I would think

Maybe some way of doing a post-mutation data fetch?

Right now I can't even find the basic docs on what a mutation can return.

yeah we readily admit that documentation needs a lot of work

I believe that it is the same format as Om's

Oh, I'm blaming my lack of a nap 🙂

as far as server mutations are concerned

so you should be able to return a :value on a server mutation

that value would end up in the client app state, keyed by the mutation symbol

I was skimming through the om stuff, but didn't find anything there either.

tried asking in #om?

Not that it's not there, just that I'm not finding it right now.

That's the next step 🙂

Thanks, @ethangracer

@grzm: We have done something like post-mutation data fetches in a few places. We have something like this: (om/transact! this [(widget/new-data-stream {:widget-id ~id}) (widget/load-data-stream {:widget-id ~id})])

Where load-data-stream is:

;; Does a remote lazy load via untangled functions - note that the remote line
;; here is special.
(defmethod m/mutate 'widget/load-data-stream
  [{:keys [state component ref] :as env} _ {:keys [id] :as params}]
  {:remote (df/remote-load env)
   :action (fn []
             (let [query (om/focus-query (om/get-query widget/DefaultWidget) [:widget/data-source])]
               (df/load-data-action state query
                                    :ident (if id [:widget/by-id id] ref))))})

And df is untangled.client.data-fetch

FYI: Anyone wanting to use a newer version of Figwheel. Our script and setup in user.clj in various projects won't quite work due to recent sidecar changes. The new component-local-state recipe in the untangled cookbook has been updated to work properly. The changes of interest are in user.clj.

The new recipe is: https://github.com/untangled-web/untangled-cookbook/tree/master/recipes/component-local-state

Demonstrates doing some graphical stuff with HTML5 canvas involving both props and component local state to accomplish quick updates for transient interactions, while maintaining important data in app state.

@grzm What @therabidbanana said, OR you can embed a (untangled/load-data) call directly in your top-level transaction as a post-read. The cookbook has such an example (demonstrating non-optimistic update).

let me see if I can find that...maybe it was in the getting started videos

https://youtu.be/t49JYB27fv8?t=24m56s

@grzm this section of the video shows how to do "non-optimistic" updates....which is essentially sending a mutation to the server, and following it with a fetch.

This is a question that is asked periodically: How do I return a value from a mutation? The answer is "you don't". Mutations are abstract, there is no query (which would be needed to merge such a response to app state). Instead, you do a mutation, and follow it with a read of the thing you want to know.

By doing it via a read, you include a query (and possibly a post-mutation). This combination allows you to integrate the data properly. Without the query (and possibly the post-mutation) Om/Untangled would have no idea of where to put your "return value", nor how to normalize it into the database.

The final result from that video is on the basic-server tag of the getting started files: https://github.com/untangled-web/getting-started-video.git (checkout the basic-server branch)

@ethangracer no return values from mutations. See above comments.

I added these comments to the cookbook, so at least they're written down somewhere "official" now