Queries related to recurring event functionality[REACT]

[Sagun01]

Few queries relating to the recurring events functionality.

• Do we need to create separate id for recurring eg- recurrenceId in our server or there is any predefined key that is in scheduler for recurring events.

• Is there anything in scheduler which provides the array of dates or do we need to create dates manually in our server eg - I am creating event for the date 20 to 21 march and repeat it to daily with an end date - 23, so the events created will have dates 20-21,21-22,22-23 march, so these are to be made at the server or bryntum provide us array of these dates.
  or something like this provided by bryntum.

I haven't found anything relating to this in the bryntum.

[arcady]

Recurring events is a pure client-side feature. Event occurrences are not persisted on the server nor loaded from it. They are generated in the runtime by the scheduler.

There is a special field on the event model that defines whether and how the event should be repeated: https://bryntum.com/docs/scheduler/#Scheduler/model/EventModel#field-recurrenceRule (model level functionality is provided by https://bryntum.com/docs/scheduler/#Scheduler/model/mixin/RecurringTimeSpan mixin class).

If there is a recurrence rule specified the event is treated as recurring and the scheduler generates occurrences for it (https://bryntum.com/docs/scheduler/#Scheduler/model/EventModel#property-occurrences - return event occurrences list).

[Sagun01]

So we can not use recurring flight functionality by maintaining our database up to date with the bryntum store ?

[arcady]

Do you mean you want to have each event occurrence persisted on the server side?

Well I'm afraid that's not how it's meant to work.
By design the scheduler generates occurrences on-the-fly for the visible timespan only. So every time user changes the scheduler timespan the occurrences get regenerated.

You can try overriding the behaviour if you want it to follow a different logic.

[Sagun01]

Cool, let's try by overriding the behavior.

[Sagun01]

I tried using reusing the scheduler components - RecurrenceConfirmationPopup

    const confirmation = new RecurrenceConfirmationPopup();
    confirmation.confirm({
      eventRecord,
      actionType: 'delete',
      changerFn: (data) => console.log('---delete----', data),
      cancelFn: () => console.log('------cancel----'),
    });

For the buttons "Delete All Future Events" and "Delete Only This Event" does scheduler provide any handle function so that we can use it.
What I found - changerFn is called on clicking these button but we do not get to know either of which is clicked.
Because I can't find any function to control these button I cannot reuse it for my logic.

[Sagun01]

Is there any solution for this?

[arcady]

There are some methods on RecurrenceConfirmationPopup class but they are not documented yet. I've made a ticket on turning them to public: https://github.com/bryntum/support/issues/460

The methods are:
onChangeMultipleButtonClick - is triggered when you click to apply changes to all/further occurrences
onChangeSingleButtonClick - is triggered when you click to apply changes to this occurrence only

The methods are handlers for the corresponding buttons and they in turn call these two methods responsible for business logic: processMultipleRecords, processSingleRecord.

I think we'll make all of them public.

[Sagun01]

1. Can you please give the date till when can these methods will be made public?
2. Can you also provide other functions like onChangeMultipleButtonClick, onChangeSingleButtonClick where we get to know which button is clicked on recurrence popup without having business logic in them(Not calling processMultipleRecords, processSingleRecord) this is because we are implementing different logic and handling recurrence flight functionality at server side by reusing the bryntum UI components?

[mats]

1. No date available but hopefully should be in the coming patch releases

2. We'll discuss as part of this ticket