Our pure JavaScript Scheduler component


Post by malicksidibe »

Hello Bryntum Team,

I recently encountered a behavior where default values defined in a custom EventModel are not applied when calling eventStore.add({}).

I am using the project’s CrudManager to load and sync data and have configured a custom EventStore with a subclassed CommonEventModel. The model defines a default value for the name field:

export class CommonEventModel extends EventModel {
  static get fields() {
    return [
      { name: 'name', type: 'string', defaultValue: 'TEST DEFAULT VALUE' },
    ];
  }
}

Here is my custom event store setup:

class CustomEventStore extends EventStore {
  static $name = 'CommonEventStore';
  static modelClass: CommonEventModel;
}
const commonEventStore = new CustomEventStore();

console.log(' commonEventStore', commonEventStore.add({})); // name is undefined

Calling eventStore.add({}) does not apply the defaultValue defined in the model. The name field remains undefined.

Configuration Overview:

export const schedulerProProps: BryntumSchedulerProProps = {
  project: {
    autoLoad: true,
    autoSync: true,
    transport: {
      load: { url: 'http://localhost:3001/api/scheduler/load' },
      sync: { url: 'http://localhost:3001/api/scheduler/sync' }
    },
    eventStore: {
      modelClass: CommonEventModel
    }
  }
  // eventStore: commonEventStore // Also tested manually
};

The component is rendered using the React wrapper:

<BryntumSchedulerPro
  ref={schedulerRef}
  onBeforeEventAdd={({ eventRecord }) => {
    console.log('onBeforeEventAdd', eventRecord); // name is still undefined
  }}
   onBeforeTaskEdit={({ taskElement, taskRecord }) => {
   
if (taskRecord?.isPhantom && taskRecord?.hasGeneratedId) { console.log('taskRecord', taskRecord); // taskRecord.name is set to the Scheduler's default "New Event" instead of using the defaultValue from CommonEventModel ("TEST DEFAULT VALUE"). // Also, taskRecord is an of generatedModelClass(...) rather than generatedCommonEventModel(...), // unlike when creating a new event via `new CommonEventModel({})`.
navigate(`/event/${taskRecord.id}/create`); } else { navigate(`/event/${taskRecord.id}/edit`); } return false; }} {...schedulerProProps} />

I was able to reproduce the same issue using your Planned vs Actual example:
https://bryntum.com/products/schedulerpro/examples/planned-vs-actual/

Modified Task model class:

class Task extends EventModel {
  static fields = [
    { name: 'name', type: 'string', defaultValue: 'TEST VALUE' },
    { name: 'durationUnit', defaultValue: 'h' },
    { name: 'plannedStartDate', type: 'date' },
    { name: 'plannedEndDate', type: 'date' },
    { name: 'actualStartDate', type: 'date' },
    { name: 'actualEndDate', type: 'date' },

{ name: 'startDate', dataSource: 'actualStartDate' },
{ name: 'endDate', dataSource: 'actualEndDate' }
  ];
}

After calling eventStore.add({}), the default value is still not applied.


Is this the expected behavior when using eventStore.add({}) via the project configuration and a custom model class?

If so, is there a recommended way to ensure default values are applied when using the CrudManager and Bryntum Scheduler React wrapper?

Thank you in advance!

Best regards,
Malick


Post by marcio »

Hey Malick,

Thanks for reaching out.

I tried on the demo that you mentioned, and it worked correctly. The new task has the TEST VALUE in the name field.

Please see the attached video to see it working.

Attachments
Screen Recording 2025-05-05 at 12.50.51.mov
(7.12 MiB) Downloaded 7 times

Best regards,
Márcio

How to ask for help? Please read our Support Policy


Post by malicksidibe »

Hey Marcio,

thank you for the fast response!

I can indeed confirm that adding a new Event via schedulerPro.project.eventStore.add({}) results in the correct values being set.

However, when creating a new Event using double-click on the scheduler or the right-click “Add Event” context menu, the values are not being set.
They are also not present during runtime of "onBeforeTaskEdit" or "onBeforeEventAdd" where I'd expect them also to be present. (The eventRecords here are also not instances of the modelClass.)

You can reproduce the behaviour by adding the following to the config of myScheduler in the example:

const myScheduler = new MyScheduler({
    appendTo  : 'container',
    startDate : '2024-03-11T06:00',
    endDate   : '2024-03-11T20:00',
    onBeforeTaskEdit: ({ taskElement, taskRecord }) => {
        console.log('onBeforeTaskEdit', taskRecord.name)
    },
        onBeforeEventAdd: ({ eventRecord }) => {
        console.log('onBeforeEventAdd', eventRecord.name)
    },
    project   : {
        autoLoad               : true,
        // Constraint should not be set when event date changes, because when switching actual / planned mode,
        // constraint date has prio over the start date. If constraint date is needed, consider to add and manage the
        // corresponding actualConstraintDate / plannedConstraintDate fields.
        addConstraintOnDateSet : false,
        eventStore             : {
            modelClass : Task,
            // Opt out of using raw data, need to clone the incoming data objects for the way this demo maps multiple
            // fields to the same datasource to work
            useRawData : false
        },
        loadUrl : './data/data.json'
    }
});

With the same default value for the Task subclass of EventModel:

class Task extends EventModel {
    static fields = [
           { name: 'name', type: 'string', defaultValue: 'TEST VALUE' },
        { name : 'durationUnit', defaultValue : 'h' },
        { name : 'plannedStartDate', type : 'date' },
        { name : 'plannedEndDate', type : 'date' },
        { name : 'actualStartDate', type : 'date' },
        { name : 'actualEndDate', type : 'date' },

    { name : 'startDate', dataSource : 'actualStartDate' },
    { name : 'endDate', dataSource : 'actualEndDate' }
];
}

I would expect events added via the UI (e.g., double-click or context menu) to be instances of the adjusted EventModel (Task in this case), and that the defined defaultValues—such as 'TEST VALUE' for name—are properly applied, including at runtime within onBeforeTaskEdit and onBeforeEventAdd.
Currently, this does not seem to be the case.

Best regards,
Malick


Post by malicksidibe »

Hey Marcio,

I also noticed that when adding an event using "schedulerPro.project.eventStore.add", a sync is triggered immediately after the event is added.
However, when adding an event via the scheduler’s context menu or by double-clicking, no immediate sync occurs — the sync only happens after clicking the save button in the editor.

Is there a way to create/add phantom events without triggering a sync right away?

Best regards,
Malick


Post by ghulam.ghous »

Hey,

However, when creating a new Event using double-click on the scheduler or the right-click “Add Event” context menu, the values are not being set.

Please use the autoCreate config to handle this there, we set a default name for events created using gesture or context menu. https://bryntum.com/products/schedulerpro/docs/#Scheduler/view/SchedulerBase#property-autoCreate

autoCreate       : { newName : 'TEST VALUE' },

I also noticed that when adding an event using "schedulerPro.project.eventStore.add", a sync is triggered immediately after the event is added.
However, when adding an event via the scheduler’s context menu or by double-clicking, no immediate sync occurs — the sync only happens after clicking the save button in the editor.

You can avoid the sync by using the suspendAutoSync and then once you done, you can resume it using resumeAutoSync.
https://bryntum.com/products/schedulerpro/docs/#Scheduler/crud/AbstractCrudManagerMixin#function-suspendAutoSync
https://bryntum.com/products/schedulerpro/docs/#Scheduler/crud/AbstractCrudManagerMixin#function-resumeAutoSync


Post by malicksidibe »

Hello ghulam,

thank you for your reply.

Could you explain for me the use case for setting defaultValue in the Task subclass of EventModel if the defaultValue is actually or ultimately set using the autoCreate config? In this case i am still assuming that the provided event or taskRecords are not instances of the modelClass provided to the eventStore.

I would expect events added via the UI (e.g., double-click or context menu) to be instances of the adjusted EventModel (Task in this case), and that the defined defaultValues—such as 'TEST VALUE' for name—are properly applied, including at runtime within onBeforeTaskEdit and onBeforeEventAdd.
Currently, this does not seem to be the case.

Would you confirm this?


Post by marcio »

Hey Malick,

The defaultValue in the EventModel subclass is intended for use when creating instances programmatically, such as when using

eventStore.add({})

However, when events are added via the UI (e.g., double-click or context menu), the autoCreate config is used to set initial values, including the name. This is why you see the default name set by autoCreate rather than the defaultValue from your model class.

If you need the default values from your model class to be applied when using the UI, you might need to handle this manually in the event creation logic or use the autoCreate config to align with your model's defaults.

Best regards,
Márcio

How to ask for help? Please read our Support Policy


Post Reply