Clojurians Log v2

@jasonjckn That API is not anywhere near final. It is going to evolve. I would not base things on it yet.

gotcha

Is there any way to know when a remote mutate is done? something like :post-mutation for a mutation

I thought that was the multimethod post-mutate but I was obviously wrong

@mitchelkuijpers The client only has a post-mutation because you may need to do some extra work after data from the server has been loaded into the client-side database. On the server, I don’t think that there’s a similar issue — what do you want the server-side post mutation for?

For example we do a optimistic update where we delete something, we just delete it and then when the delete was successfull we want to show a extra flag

For this update we don’t need another read, that is the biggest problem

I don’t want it serverside btw

I just want a post remote mutations is done (if that makes sense)

like post-mutation for reads

I’m not sure I understand why knowing that the server-side mutation has completed is important. If the server-side deletion wasn’t successful and you throw an error, it will be propagated to the client. If the server-side deletion was successful, why indicate to the client that the happy path was successful? Isn’t that implied by the fact that an error wasn’t thrown?

I get your point but that does not mean our UX designer agrees 😛

haha fair enough, so the desire is to have an indication that the remote worked? You’d probably have to implement websockets and send some kind of message back, but you’d have to ask @mahinshaw more about that

I just want to know that the mutation http-call is doen

s/doen/done

oh this is not hipchat 😛

yeah all of the networking stuff is abstracted away

Let’s say you have a form on which you want to do a save and when the save is done you want to close a modal, If you want to implement this you have to have a read after

We misunderstood post-mutation to do this (because we used to have something similar in our homegrown om.next parser)

Right, except a follow on read in the deletion case would just remove the deleted item the client-side database

You wouldn’t know that the particular item that was just deleted had been deleted successfully

True

So either your server would have to return some piece of information that indicated which item was previously deleted, and you could compare that with some saved state of which item is currently being deleted…

Maybe we are thinking wrong… But it can be hard to convince our UX designer of this. Also we have to integrate with atlassian products which don’t do optimistic updates

So our users then start refreshing after changes to be sure that the changes are saved

I see

So we would like to start a progress indicator when a thing is being updated for example and then a post-remote-mutation on which we can reset that indicator

If we wanted to integrate that kind of functionality into untangled, I think we would have to do it in the networking layer — untangled.client.impl.network

In the UntangledNetwork’s send protocol method, which would have to gain access to the app state and put some marker indicating that the post returned successfully

not exactly sure how that would work

Me neither I am just blurting this out, I get that this does not really fit with the "untangled way"

also, so you know, you are free to implement your own UntangledNetwork

yeah it’s not the intended pattern as I understand it, but I can also understand why your UX person would want it.

let’s see what others think when they get a chance to browse

I think websockets or a custom untangled network are the best options

I don’t really get why we would need websockets for this

and http call has start -> end

Well I’m no expert on websockets 🙂

Me neither 🙂

My very cursory understanding is that with websockets the server can push data to the client

So if the client says “delete this thing” the server could respond with “this thing was deleted"

In a more declarative way, instead of just making the inference from the closed xhr

Aha that’s true, but when I send to the server (delete x) and then the xhr returns with a 200 this could mean the same. But I think you get the problem 🙂

yes, it is the same, AND because websockets is a separate untangled library you might have more flexibility with it than the standard networking

Ah that’s true

But then we need another load balancer 😛

But thnx we’ll see what the others have to say

@mitchelkuijpers So, if what you want to do is simulate sync processing, then there is a way to do that:

Send the mutation, and follow it with a remote read for the status that blocks

something like: (om/transact! this '[(delete/thing) (untangled/load {:query [:did-delete-finish?]})])

the load can have a post-mutation as well, of course

basically, any time you want a "return result" just follow it with a remote read

if you need to identify "which one", then send a tempid with the delete (which will get remapped in the app state and network queue)

(let [did (om/tempid)] (om/transact! this `[(delete {:id did}) (untangled/load  {:query [(:finished? {:id did})] ...})]))

process the delete in a future, and put it in a server-side tracking map with that ID

etc etc

@ethangracer Make sure you put this in the interactions stuff you're doing in dev guide ^^^ 🙂

would not hurt to have a few cookbook recipes around this kind of thing. Return values from remote mutations seems to be a hot topic, esp with ppl integrating with legacy stuff

Aha this would be nice to have in the docs

Thnx @tony.kay

@tony.kay not sure I fully understand. If you are deleting something that already exists, you currently have a database ID for it. what’s the tempid for?

to track the operation itself...you want to block on the thing that is doing the delete

otherwise you might get a false negative (yep, that thing is still here) if you processed the delete in the bg

then again, if you made delete itself sync on the server, then you could use the object id

so yeah, I was making that example more complicated than it needs to be

Untangled guarantees writes before reads, BTW within a single transaction...that should be documented as well

e.g. flipping the load and the delete would still work because they would be reorderd in the xaction

https://github.com/untangled-web/untangled-client/blob/master/src/untangled/client/impl/application.cljs#L70

two separate calls to om/transact! would also follow this reordering rule, assuming you did it on the same user interaction (UI thread never released)

This could be a potential source of confusion. The reasoning is that any loads are for the client...and mutations could not possibly rely on the information they provide (since it has not arrived before the mutation is queued). Thus, processing the reads before a mutation can only ever give you out-of-date data

Of course, if you wanted out-of-date data, then you're screwed 🙂

^^^ @mahinshaw @adambros this info might also be of interest in docs you might be working on

@mitchelkuijpers would love a contribution to the cookbook if you'd care to write one about the case you asked about, but in more general-purpose terms

if you'd need help getting started on that, I'd be glad to show you around

Yeah definately

but that will be this weekend then is that okay?

any time is fine by me 🙂

if you see me online, you can ping me

Cool thnx man