[REACT] Proper way to destroy scheduler instance

[Gaetek]

Hello,
We have a react app where we use Bryntym Scheduler Pro and we also use jqxGrid. The issue we're having is that when we first navigate to a page with the scheduler, then navigate to a page with jqxGrid and try to change the filtering option, it completely freezes. This does not happen if we don't visit a page with Bryntum scheduler first, indicating that it is the cause of the issue.
Changing this causes the tab to freeze:
https://imgur.com/mn5xK8N
Also, using Firefox's performance profiler reveals that the freeze is caused by the Bryntum Scheduler. It attempts to handle some event, even though it's not being rendered:
https://imgur.com/a/hB1O0nK
Clicking on the highlighted line opens up this:
https://imgur.com/a/m9mnJyb
So, how am I supposed to destroy the scheduler instance, so that it doesn't affect other pages that are irrelevant to it?
Note we are using react-router-dom for navigation.

Thank you,

[mats]

Just call https://bryntum.com/docs/scheduler/#Scheduler/view/Scheduler#function-destroy-static and it will be destroyed properly.

If you still face some issue - please provide some test case we can debug.

[Gaetek]

How exactly am I supposed to call that? I tried running

schedulerRef.current.instance.destroy()

where schedulerRef is reference to the BryntumSchedulerPro component. The issue is still present.

[mats]

Ok then we need a test case so we can inspect and see what is going on in your app

[Gaetek]

I've attached a modified version of your 'simple' React example. There are two links at the top of the page, if you visit Grid first, it works fine, but if you first visit Scheduler then the freeze will happen.
1) Go to "Scheduler"
2) Go to Grid
3) Hover over one of the columns to see the options
4) Expand the column options
5) Change the value of "Show rows where:" select.

If it doesn't happen at the first change, do it again. I always reproduce it by the second change.

[saki]

The scheduler is destroyed automatically – you shouldn't need to do anything. This seems to be a bug in the scheduler destroy logic. See the ticket here: https://github.com/bryntum/support/issues/3212

[Gaetek]

Ok, thank you. I'll keep an eye on that ticket for resolution.