Palindrom
Make it possible to identify when server has successfully navigated to a new URL (`_ver#c$` is not bumped)
Right now any change in local modal will result in client side version increase. Currently it's stored in the model["/_ver#c$"] property.
Palindrom has an event onRemoteChange, which can be used to monitor incoming patches, a patch from server with /_ver#c$ value of N guarantees, that server has applied all patches with /_ver#c$ less or equal to N. Every patch from client side has a response patch from server, the response patch may or may not contain some extra changes from server side, but it always indicates that server has successfully applied the initial patch.
I am currently using this mechanism to calculate how much time server takes to process a patch.
On the other hand, navigating to other pages, so called morphing URL, is not updating the client side version (the /_ver#c$) value. There is also no extra callback which would be triggered when server has successfully performed navigation.
This makes it impossible to identify the moment, when server has finished navigation and applied the requested changes.
In my setup, there are a few background jobs, which are constantly updating database objects and sessions, which result in random patches push from server to client, thus I can't rely on server to client patch after requesting navigation to identify whether server has performed the navigation.
cc @tomalec, @warpech, @alshakero
In my setup, there are a few background jobs, which are constantly updating database objects and sessions, which result in random patches push from server to client[...]
Sorry for the semi-offtopic, but starting with what change/commit server changes are pushed to client without them being triggered by a client to server change (socket update)?
Sorry for the semi-offtopic, but starting with what change/commit server changes are pushed to client without them being triggered by a client to server change (socket update)?
Since quite some time ago 😃. Read more here - CalculatePatchAndPushOnWebSocket.
Thanks for bringing this topic!
To be honest I think we didn't consider navigation / URL morphing as a part of OT. palindrom-dom which implements morph methods, does not use JSON Patch queue at all. Also, the entire morphURL call is completely detached from the Patches flow, which makes me afraid we may loose some patches when called in unfortunate moment.
To have a nice solution, we may need some architectural re-design.
First, I'd like to understand precisely what you need.
There is also no extra callback which would be triggered when server has successfully performed navigation.
Do you need such callback on server- or client-side? And what do you mean by "server ... performed navigation"? This is the client that morphs the page, so the client performs navigation. Do you mean that you would like the client, after it "performed navigation" - after it changed the history state and applied the changes, send the acknowledge patch? Or rather attach/encode somehow version bums in the HTTP GET request somehow.
Is "server ... performed navigation" = "a moment when redirection requested by the server started (finished) by the client"?
If we would incorporate URL morphing tighter in JSON Patch OT, how would you imagine the behavior, when server sends redirect request, which get's rejected/ignored due to JSON Patch transformations? Maybe it should be inclusive transformation, so given server is the source of truth, it would be able to force redirect, no matter what the client did in the meantime.
A solution from my gut feelings, without gully understanding the case, would be to send version bump via WebSocket immediately after or before the HTTP GET.
A solution from my gut feelings, without gully understanding the case, would be to send version bump via WebSocket immediately after or before the HTTP GET.
My scenario is the following:
- Initiate a session.
- Establish a Palindrom connection with the session.
- Do some changes via view-model update.
- Wait until server acknowledges the changes by listening to the
onRemoteChangecallback from Palindrom. - Form a new URL.
- Perform URL morphing by calling the
morphUrlAPI from PalindromDom. - How?? Waiting until Palindrom applies all necessary view-model changes caused by the navigation.
- Perform some more changes via view-model. At this stage the view-model should already be transformed to represent the new page.
Again, this is done for the sake of performance testing, I am trying to mimic a user scenario, when user performs some actions on different pages. Naturally, I perform all client - server communication via Palindrom & view-model.
You have two ways to do this. You can subscribe to palindrom-after-navigation event that is dispatched on window.
Or you can do await morphUrl(url) as morphUrl is async now!
@alshakero While being correct, the above reply misses the problem reported in the OT. The problem here is that the local version is should be bumped upon a navigation request but it is not.
You can try that by navigating and then examining the contents of palindrom.queue.localVersion and palindrom.queue.remoteVersion. The first one is not bumped by the client, but the latter is bumped by the server.
For consistency, the client should bump the local version upon navigation request, because that's a patch that modifies the requested state.
Discussion in #232 tells it is impossible to finish this issue before changes in server-side. Unassigning from @alshakero for the time being.