Would like remote mutation response in post-mutation multimethod about untangled-client HOT 2 CLOSED

Can you elaborate on why this wouldn't be solved by a follow on read?
Are you trying to mutate a non untangled server?

from untangled-client.

Copied from @awkay on slack:

The Om model is that mutations can remap tempids. There is no return value. The reason for this is that there is no query, so there is no way to merge that result into your database. Thus, the follow-on remote read.

This is a common misconception about the overall model.

The model is that the mutation is abstract. The UI and Server have no coupling. The server has no idea what you're showing, and the client has little idea (other than advertised keywords on the mutation...which isn't documented well, but is part of Om) what the server is really doing.

So, in order to fix this gap, the client specifically asks for reads on the data that it knows it is displaying that could have changed on the server.

E.g.
Say you have a mutation add-friend. The server could return all manner of information: the new friend count, a success code, the list of current friends.
Now you're tempted to make a mutaiton for every possible return value? Or just send it all back?
None of that is nearly as simple as the UI directly saying: do this, and then I need to know this other thing.

If you read the Om docs David mentions listing keys on a mutation. These are where you put advisory documentation on your mutation as to what data items the mutation affects, so that a UI programmer can read that (as documentation) and decide what to explicitly query.

I'd recommend documenting the affected keys in whatever way makes sense for your developers, because this is a point of difficulty (and maintenance), though in practical systems it is pretty obvious what things you might want to read because the mutation is an abstraction with general meaning.
E.g. in the add-friend case I can guess that my friend count just changed.
It is a subtle shift, and I understand the desire to want a "return value"...but they just don't make sense in the overall model.
(and I'd argue that David is right here...this is a simple/better approach to the problem of UI composition)

from untangled-client.