Hi!
Since the update to Calendar 4.3.9 or 5.0.0 the events disappear without reason.
After changing the resources old events disappear.
You can test this behavior at https://github.com/poettl/longevo-bryntum-support
Please check the Readme.
Thanks!
I'm afraid that is not debuggable. It's compressed code. There's an enormous framework in the way making all call stacks hundreds of frames deep.
If this is a bug in the Calendar, we need a much much much simpler reproduction case.
If it's reproducible at all, it could be reproduced with 50 lines of code.
I am faced with this:
How does one even get in to set a breakpoint in ResourceView.js? Where even is ResourceView.js?
If you can describe what steps you are taking to get this issue, I can try to reproduce in simple code.
I found the refresh method inside calendar.lite.umd.js, and look at the call stack. There's a scrollbar there. It's 250 frames deep.
In contrast, this example version of the UI has 30 frames:
So when I select a resource, it hits that breakpoint about eight times! I have no idea what's causing all that.
And when I select a second resource, it gets there again with more events in the store:
So that's 38 for these two:
Let's see what is there when I unselect.
OK, I just stepped in through the data collection process, and got into where the ResourceView filters incoming events to only accept events for its own Resource.
The issue is that somehow the Resource record instance in the eventRecord is not the same instance that is stored in the resource Store. The ids match as you see.
This can be a problem if the events are loaded separately from the resources.
You could work around this by overriding this `ResourceView' method as below:
createSubViewFilter(resource) {
// Match our resource *id* against the event's assigned resource *id*s in case
// the resources and events are loaded separately and have different instances.
return e => e.resources.map(r => r.id).includes(resource.id);
}I'm not sure how the data in the stores could get out of sync. Loading the project should keep everything in sync. Ir loads the resources first, and then when it loads the events, the resourceId field is used to find the resource record from the resource store, so there is only one instance.
Having multiple instances of theoretically the same entity is not good for data consistency.
How is the data being loaded?
OK, So having stepped back to see where the data is coming from I get here:
As you see, it's setting the events first. Not sure where this code comes from. It's in bryntum-calendar-angular.js, but I can't see it in our codebase. It gets into CalendarWrapper which just passes the properties in.
As you can see the events come before the resources. I will add some tweak to the code to make it apply the resources before the events to see if that works.
This Wrapper bit could be what has changed.
Here's a ticket: https://github.com/bryntum/support/issues/4307
Fixing the order doesn't remove the issue.
You have a resource "store" (whatever the equivalent is) from which you create that alternative filtering UI in the alternative Sidebar. (Is there an overriding reason to use all those alternative widgets?)
But when you load events on demand, you also load resources. But that doesn't update that alternative resource "store" in the alternative Sidebar. Those records are unchanged. So the comparison of resources can never be the same again. The new resources just loaded into the real resourceStore are new objects.
If you just load all resources into the ResourceStore at the startup of the app, this won't be necessary. Then you would just load events on demand. The resources are what they are. Only the event load changes.