[REACT] Undo / Redo Inconsistent Crud changes

[dpontes]

Hello Bryntum team!

We are experiencing some inconsistencies regarding the undo/redo and the changes available in the crudManager.

That happens when we don't perform a crudManager.acceptChanges();

Basically, if I move a scheduled event to a different timeline, the Undo / Redo will always trigger new changes in the crudManager.

But the same doesn't happen when scheduling / unscheduling events.

We just perform a crudManager.acceptChanges() after receiving a valid reply from the server.

Our server has a set of validation process that is triggered when it receives a new Change from the STM, so if the user performs multiple changes in a very short period, the server interrupts the running validation and starts new validation considering the latest changes received (which is an accumulated set of changes).

The fact that Undo is not triggering changes means that even though the Previous action was undone, it won't send that information to the server.

Example case:

Supposing the server take 5 seconds to validate a Scheduling action:

Drag Unscheduled event to scheduler => Trigger STM => there are crud changes => send to server
Server starts validation of the scheduled changes...
Undo is Clicked right after => Trigger STM => no changes in crud => nothing is send to the server

With that, after 5 seconds the server will finish the validation and apply the Scheduling action to the db. Which is wrong as the user clicked Undo for that action.

If we consider the same case but moving scheduled events to a new timeline:
Drag scheduled event from 5AM to 6AM => Trigger STM => there are crud changes => send to server 6AM
Server starts validation with the 6AM change...
Undo is Clicked right after => Trigger STM => there are changes => send to server 5AM
Server receives new change with 5AM, will interrupt the running validation and start a new validation with the most recent changes (5AM)

Follow attached a snippet and source code using drag-from-grid as a starting point.

You can see the logs are different when Undoing a Scheduling action compared to a Drag already scheduled event to a new timeline

bryntum-undo-redo-crud-changes-inconsistent-behavior.mp4

(4.72 MiB) Downloaded 36 times

drag-from-grid-undo-redo-inconsistent-crud-changes.zip

(2.32 MiB) Downloaded 30 times

[alex.l]

Hi,

I've opened a ticket to investigate this problem https://github.com/bryntum/support/issues/6986
Thank you for the report and test case!

[nickolay]

@dpontes Hi, I believe everything works as expected here. You probably want the "apply changes" to always happen, but the fact, that it always happens for event move actually seems to be a bug - I'll be fixing it.

Let me go into details. The normal data flow is something like this:
1) Clean state - data is loaded, there's are no changes.
2) Then there's some local change - data becomes "dirty", and crudManager.changes will contain a summary of changes. The changes are not yet sent to the server.
3) Now, if, at this point, we'll undo the change - the data becomes "clean" again, and crudManager.changes will be empty. This is what happens when you undo the drag of unplanned task quickly - local change is reverted and data becomes "clean".
4) However, If we undo the change after the successful application of the server's response (which ends up with acceptChanges() call), the data will become "dirty" again.

In your setup, you probably need to call acceptChanges() right after sending your changes to the server, not after receiving the response from it.

See also the videos I posted to the ticket.

[dpontes]

Hi Nick,

Thanks a lot for the details.

I think if that is how the library should work, I believe I can simply send to server to interrupt any running validation if I ever receive "no changes" from the crud.

Following the flow you mentioned, this is how it would work:

Scenario 1: Undo is clicked quick enough so server still haven't applied changes, and "bryntum.acceptChanges()" is not called.
1) Clean state, data loaded, no changes
2) Schedule Event
3) Has Crud changes => We send that to the server and starts the data validation
4) Undo is clicked
5) No crud changes => If server is still in the process of validating, that should be interrupted and no changes should be applied to the backend

Scenario 2: Undo is clicked after server already applied changes and "bryntum.acceptChanges()" is called
1) Clean state, data loaded, no changes
2) Schedule Event
3) Has Crud changes => We send that to the server and starts the data validation
4) Server finished validation and applies the changes
5) We receive the okay from the server and finally perform acceptChanges()
6) Undo is clicked
7) Has Crud changes => send to server information that Event is now Unscheduled.

[nickolay]

Probably this will work. However, one thing to consider is that while you await for the confirmation from the server, there might be other local changes from the user, so when you call acceptChanges on the server's response arrival those will be "forgotten". The only reliable way to solve this problem is to mask the UI while waiting for the server response, to prevent user actions.

I'd also not recommend to listen the STM events for managing your data - you should only be listening the CRUD events on the stores and project. STM only performs the data manipulation, and also it is used internally to rollback changes when needed, so your listeners may be triggered at the unexpected moment.

Perhaps check the CRUD manager guide for the more coherent data handling approach. CRUD manager is quite customizable, you can implement your own format, transport etc.

[dpontes]

Hi Nick,

Thanks for the details.

Indeed we currently use the STM listeners "recordingStop" and "restoringStop" to call a function and check if there are crud changes.

Following what you mentioned, I am guessing it would be best to use the listener "onHasChanges" from crudManager for that?

Is there a place in the docs where I can see all of the available CrudManager listeners, or the only place I can find that is through the source code?

[nickolay]

Right, onHasChanges looks like a better choice for tracking the data changes. You can find the available events of the crudmanager mixin here: https://bryntum.com/products/schedulerpro/docs/api/Scheduler/crud/AbstractCrudManagerMixin#events