We're having the following error and crash in production, when re-rendering Scheduler. Is there any reason why this might be happening using Angular prod build? This does not happen in dev mode.
First time it loads correctly, but if user leaves the view and reenters it, it seems to crash on the triggerBeforeUpdate function, when setting assignmentsData, following the Scheduler constructor.
Error reentering Scheduler in Angular app - prod build.PNG (235.53 KiB) Viewed 1944 times
Error reentering Scheduler in Angular app 2 - prod build.PNG (30.73 KiB) Viewed 1942 times
Do we have to manually destroy some of the Scheduler properties (stores, etc) when using Angular 10?
Yes, in the meantime I've managed to replicate this using the attached test case. Can you please check it? You have to run it with production build.
Run with http-server, for instance, in angular 8 folder (which is using Angular 10), inside dist folder.
Then, click on the links above (sorry about the duplicate navigate anchor links)
Evidence - navigate between components.PNG (76.15 KiB) Viewed 1933 times
Navigate to scheduler and then to the Test component. Click again in Scheduler component to confirm the error.
Thanks for the demo, I was able to run it and reproduced the bug you mentioned.
The problem is that Angular destroys only HTML markup and not the Scheduler instance, stores, etc. So, you need to extend your code with a destroy function on routing, or not destroy it at all but show/hide.
We have an example how to manage that here: https://bryntum.com/examples/scheduler/angular/advanced/dist/advanced
Please, take a look, it should help you to handle this in a proper way.
OK. Reuse strategy is not an option for us. We don't have a specific route for Scheduler. The components are generated at runtime (using angular dynamic components) and this could introduce side effects.
Why does schedulerInstance.destroy() does not perform the dispose operations? What are the additional operations we could do on our side, before the bug is fixed?
I'm not following...your zip doesn't have destroy being called on scheduler instances. It's using the router reuse strategy, so the error is not triggered.
In my example, where we don't use the Router Reuse strategy, I've called destroy on the schedulerInstance and the error occurs..