Fork me on GitHub

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


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 🙂


@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


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.


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


@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: (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