Fork me on GitHub
#untangled
<
2016-10-07
>
tony.kay00:10:41

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

mitchelkuijpers12:10:58

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

mitchelkuijpers12:10:21

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

ethangracer12:10:59

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

mitchelkuijpers13:10:30

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

mitchelkuijpers13:10:57

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

mitchelkuijpers13:10:34

I don’t want it serverside btw

mitchelkuijpers13:10:48

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

mitchelkuijpers13:10:53

like post-mutation for reads

ethangracer13:10:59

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?

mitchelkuijpers13:10:50

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

ethangracer13:10:41

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

mitchelkuijpers13:10:56

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

mitchelkuijpers13:10:04

oh this is not hipchat 😛

ethangracer13:10:40

yeah all of the networking stuff is abstracted away

mitchelkuijpers13:10:44

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

mitchelkuijpers13:10:29

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

ethangracer13:10:53

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

ethangracer13:10:11

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

ethangracer13:10:58

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…

mitchelkuijpers13:10:04

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

mitchelkuijpers13:10:37

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

mitchelkuijpers13:10:32

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

ethangracer13:10:26

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

ethangracer13:10:30

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

ethangracer13:10:39

not exactly sure how that would work

mitchelkuijpers13:10:19

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

ethangracer13:10:20

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

ethangracer13:10:04

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

ethangracer13:10:15

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

ethangracer13:10:59

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

mitchelkuijpers13:10:39

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

mitchelkuijpers13:10:53

and http call has start -> end

ethangracer13:10:26

Well I’m no expert on websockets 🙂

ethangracer13:10:45

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

ethangracer13:10:13

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

ethangracer13:10:50

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

mitchelkuijpers13:10:49

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 🙂

ethangracer13:10:22

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

mitchelkuijpers13:10:39

Ah that’s true

mitchelkuijpers13:10:49

But then we need another load balancer 😛

mitchelkuijpers13:10:14

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

tony.kay14:10:10

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

tony.kay14:10:30

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

tony.kay14:10:19

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

tony.kay14:10:29

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

tony.kay14:10:49

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

tony.kay15:10:11

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)

tony.kay15:10:20

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

tony.kay15:10:09

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

tony.kay15:10:47

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

tony.kay15:10:26

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

mitchelkuijpers15:10:31

Aha this would be nice to have in the docs

ethangracer15:10:40

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

tony.kay15:10:22

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

tony.kay15:10:44

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

tony.kay15:10:57

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

tony.kay15:10:08

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

tony.kay15:10:44

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

tony.kay15:10:00

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

tony.kay15:10:59

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)

tony.kay15:10:13

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

tony.kay15:10:28

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

tony.kay15:10:20

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

tony.kay15:10:30

@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

tony.kay15:10:51

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

mitchelkuijpers15:10:19

but that will be this weekend then is that okay?

tony.kay15:10:55

any time is fine by me 🙂

tony.kay15:10:10

if you see me online, you can ping me