Our pure JavaScript Scheduler component


Post by maarten »

So I'm running into an interesting issue where my events are not being updated correctly anymore due to constrainDragToTimeline. Within our system we handle the data changes ourselves completely and implemented a beforeEventDropFinalize to handle this (this can be seen in the code example below, written in psuedo code).

This seemed to work fine, but now we want users to be able to drag and drop the events before and after the current timespan for convenience. As I seen in the example this should just be easily achievable by turning constrainDragToTimeline to false, this does work but results into the events updating in the wrong order and this doesn't look professional to our end-users anymore.

I've attached a video to show what I'm talking about: we call context.finalize(false) and the event shoots back to its original position and afterwards we handle the data ourselves and set it correctly, events are seen to jump back before settling in the newly updated position. This may seem a bit unlogical that this isn't the correct order but we previously had some other issues with animations not working smoothly and this order seemed to work, only now we're running into the weird behaviour caused by constrainDragToTimeline

What's maybe good to note: whilst debugging it is clear that once we call context.finalize(false) the event moves, but previously we called suspendRefresh, isn't this meant to put any UI updates on hold?

In the docs it says to pair constrainDragToTimeline with a validatorFn but this doesn't seem to change much..

I cannot provide a full code example due to the heavy integrations with our internal system.

import { EventModel, Grid, Scheduler, Splitter } from '../../build/scheduler.module.js?465296';

const scheduler = new Scheduler(
	{
		appendTo: 'main',
		flex: 1,
		resourceImagePath: '../_shared/images/users/',
		multiEventSelect: true,
		features: {
			stripe: true,
			sort: 'name',
			eventDrag: {
				constrainDragToTimeline: false,
			},
		},

	columns: [
		{
			type: 'resourceInfo',
			text: 'Staff',
		},
	],

	crudManager: {
		autoLoad: true,
		transport: {
			load: {
				url: 'data/data.json',
			},
		},
	},
	startDate: new Date(
		2022,
		7,
		26,
		6,
	),
	endDate: new Date(
		2022,
		7,
		26,
		20,
	),
	viewPreset: 'hourAndDay',
	listeners: {
		beforeEventDropFinalize ({context}) {
			// We want to pause Bryntum updating the UI
			// RmSchedulerProInstance.suspendRefresh();

			context.async = true;

			// Get our own data from context.eventRecords through a custom config

			// Process data and update new times within our system

			// We don't update records through bryntum, our own data is leading
			context.finalize(false);

			// Save our own data to the API

			// Continue the UI
			// await RmSchedulerProInstance.resumeRefresh(true);
		},
	},
});

new Splitter(
	{
		appendTo: 'main',
	},
);

const grid = new Grid(
	{
		appendTo: 'main',
		cls: 'b-external-grid',
		flex: '0 0 300px',
		emptyText: 'Drop events here',

	features: {
		stripe: true,
		sort: 'name',
	},

	store: {
		// Setup the Grid store to use the same data model as the Scheduler
		modelClass: EventModel,
	},

	columns: [
		{
			text: 'Unscheduled tasks',
			field: 'name',
			flex: 1,
		},
		{
			type: 'duration',
		},
	],
},
);
Attachments
Screen Recording 2023-02-02 at 16.03.35.mov
(580.51 KiB) Downloaded 18 times

Post by alex.l »

Hi,

It seems to be consistent that you have "back animation" when you return false from finalize method. This means drop is failed, so animation return an object back to original place.

In docs for https://bryntum.com/products/scheduler/docs/api/Scheduler/view/SchedulerBase#function-suspendRefresh
said

Suspends UI refresh on store operations.

So it will be suspended only for store operations updates.

try to hide an element before you call finalize(false)?

 scheduler.on('beforeeventdropfinalize', ({ context }) => {
     // ...
     context.context.element.style.display = 'none';
     context.finalize(false);
     // ...
 })

All the best,
Alex


Post by maarten »

Thanks for the response, hiding the element seems to resolve the visual issue I was facing.

Do you have any clue as to why the drop may have failed, were you able to tell if I'm doing something wrong?


Post by marcio »

Hey maarten,

It's difficult to say by the description, we would need a running example to check it. May you get one of our demos and then add your configuration for us to check?

Best regards,
Márcio


Post by mats »

This seemed to work fine, but now we want users to be able to drag and drop the events before and after the current timespan for convenience.

Also, can you please clarify this a bit so we can understand your use case?


Post Reply