Premium support for our pure JavaScript UI components


Post by matb »

Our eventStore change event listener receives change events for more than just the actually changed scheduler event on drag or resize operations.

The additional, seemingly irrelevant scheduler events for which the change events are triggered seem to have in common:

  • the event's 'changes' property includes properties wrapEndDate or wrapStartDate

  • they make use of preamble or postamble

We need to trigger further external api calls for the actually changed scheduler event and need to prevent such api calls for those additional change events.

So if we could find a way

  • to safeley distinguish between those two kinds of change events

  • or much better to prevent those additional change events in the first place

this would help a lot.

We have recently upgraded scheduler pro from version 4.3.0 to version 5.0.2.

Recreating a working example which shows the described behaviour would require quite some. We hope, it won't be necessary for the question at hand.

Thanks in advance!


Post by marcio »

Hi,

That's correct, the eventStore is related to data and the scheduler events are related to the Scheduler UI component. That's why we have different events being triggered on drag or resize.

You can check here the available actions that will trigger the change listener in the EventStore https://www.bryntum.com/docs/scheduler-pro/api/SchedulerPro/data/EventStore#event-change

With that, you can just check with an if the actions that you want to handle and avoid the others of being handled the same way.

eventStore : {
            listeners : {
                change : ({ action }) => {
                    // Will only display the log in the "add" action
                    if (action === 'add') {
                        console.log(action);
                    }
                }
            }
        }

Best regards,
Márcio


Post by matb »

Thanks for the quick response!

Unfortunately, filtering by action won't help here. All the events mentioned above are of the type action === 'update'.

To rephrase the problem: one single UI change (like resize or drag) will lead to several EventStore events of the type action === 'update'.

What we are trying right now, is to switch from EventStore events to Scheduler events. Rollback in case of errors seems to be a bit more tricky for the Scheduler events, though.

Anyway it would be great to know how to address this phenomenon. Also, is there a rule of thumb for when to use Scheduler events and when to use Store events?


Post by alex.l »

Hi matb,

In case your change (resize, drag-n-drop, etc) affects to other events and they need to be updated, it will trigger change event.
In case you moved the event to another resource, it will trigger change event for assignmentStore too. This is correct data layer behaviour and you need to save all changed data into database for all change events to have correct data version.
You could make a timeout and collect data if you want.
Our built-in CrudManager can manage that and have great sync logic
https://bryntum.com/docs/scheduler-pro/guide/SchedulerPro/basics/project_data
https://bryntum.com/docs/scheduler-pro/guide/Scheduler/data/crud_manager

For UI level, we have events like
https://bryntum.com/docs/scheduler-pro/api/SchedulerPro/feature/EventResize#event-eventResizeEnd
https://bryntum.com/docs/scheduler-pro/api/Scheduler/feature/EventDrag#event-afterEventDrop
etc.

All the best,
Alex


Post by matb »

Hi Alex,

thanks again for the quick response.

You say, one single UI-event like a resize event might trigger several change events, since there are several stores.

We observe, that one single UI-event like a resize event triggers several change events in a single store. In this case the event store.

You also say, all changed data needs to be persisted.

But some of these change events only provide data like wrapStartDate and wrapEndDate, which is not represented at all in our backend system. This is why we safely want to ignore those to avoid useless api calls. Addition: some of these unexpected change events affect event models which haven't even been touched by the user.


Post by alex.l »

Thank you for clarifications, now I see that you meant and reproduced that. It's a bug, I've opened a ticket to fix this https://github.com/bryntum/support/issues/4892
Small comments about this

We observe, that one single UI-event like a resize event triggers several change events in a single store. In this case the event store.

It's also possible to have few change events for one store, in case your change affects on other events in the store. So, first change event will be immediately triggered after the change action (ex. resize), and more may be triggered after project recalculations, in case other events will be updated (ex. new start/end dates) because of this change (dependencies, constraints, etc).

All the best,
Alex


Post by matb »

I see. Thanks so much for taking care of it!

As a workaround and also to filter out additional change events as described by you, we now specifially pick the change events, that shall trigger api calls.

One last question: is it possible to compare the event-modelId in an event store change event to the originally UI-manipulated event-modelId?


Post by marcio »

Hey matb,

You can use that comparison, just make sure to be comparing the same model.

Best regards,
Márcio


Post by matb »

Got it. What I meant was rather if one can see in an event-store change event, if it affects the very same eventModel, the user interacted with.

Generally my questions have been answered though, thanks a lot!


Post Reply