This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-07
Channels
- # aleph (15)
- # beginners (18)
- # boot (18)
- # business (1)
- # cider (11)
- # cljs-dev (13)
- # cljsrn (19)
- # clojure (14)
- # clojure-austin (8)
- # clojure-dusseldorf (1)
- # clojure-finland (1)
- # clojure-greece (118)
- # clojure-poland (3)
- # clojure-russia (46)
- # clojure-spec (65)
- # clojure-uk (18)
- # clojurebridge (3)
- # clojurescript (16)
- # cloverage (7)
- # core-async (8)
- # cursive (74)
- # datomic (28)
- # editors (3)
- # emacs (3)
- # ethereum (5)
- # hoplon (19)
- # jobs-rus (18)
- # lein-figwheel (1)
- # off-topic (2)
- # om (107)
- # om-next (4)
- # onyx (23)
- # pedestal (23)
- # proton (3)
- # protorepl (1)
- # re-frame (108)
- # reagent (10)
- # ring-swagger (15)
- # spacemacs (2)
- # specter (11)
- # testing (7)
- # untangled (79)
- # vim (4)
- # yada (53)
@jasonjckn That API is not anywhere near final. It is going to evolve. I would not base things on it yet.
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
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:
something like: (om/transact! this '[(delete/thing) (untangled/load {:query [:did-delete-finish?]})])
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
@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
@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
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
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
^^^ @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
Yeah definately
but that will be this weekend then is that okay?
Cool thnx man