[REACT] Events missing after applying and removing a filter with remote filters

[jimmycallin]

Hi!

I'm experiencing issues with remote resource filters with lazy loading. If you download the example app and toggle the filtering on and then back off, i would expect the events to reappear. Instead, it looks like the resources are properly readded, but not the events. Any idea what's happening?

Thanks,
Jimmy

[joakim.l]

Hi Jimmy!

Thanks for reporting.
I'll add that to the current issue: https://github.com/bryntum/support/issues/11053
I'll debug and see whats wrong, and update you here when I know more.

[joakim.l]

Update:

We've find a few bugs when investigating this issue, which will be fixed in the next release.

I have a question:
The regular behaviour for lazy loading and remote filtering, is when the resource store gets filtered, all related stores data gets cleared as well. This is because the record indexes are invalid after filtering, and regular lazy loading is based on record indexes. But when the resource store is a tree store, we use resourceIds instead. Which are not invalidated by filtering. Would you expect the event and assignment stores to be cleared and reloaded when the resource store is remotely filtered, or would you expect them to keep their currently loaded data, and only load for resources not yet loaded?

[jimmycallin]

Update:

We've find a few bugs when investigating this issue, which will be fixed in the next release.

I have a question:
The regular behaviour for lazy loading and remote filtering, is when the resource store gets filtered, all related stores data gets cleared as well. This is because the record indexes are invalid after filtering, and regular lazy loading is based on record indexes. But when the resource store is a tree store, we use resourceIds instead. Which are not invalidated by filtering. Would you expect the event and assignment stores to be cleared and reloaded when the resource store is remotely filtered, or would you expect them to keep their currently loaded data, and only load for resources not yet loaded?

Glad to hear you're making progress!

Good question, it's a bit difficult for me to understand the impact either way would have. It does make sense to me that dependent stores would be invalidated as well, and it sounds like it's more consistent with non-tree remote filtering.

[joakim.l]

Ok, thanks for the input!

[jimmycallin]

Hi again!

Not sure if I'm doing something wrong or if it's intended behavior, but to me it looks like when I trigger filtering on the resource store that the store empties while loading new data. This is causing issues with scroll preservation, as if you trigger a filter when having scrolled far down, you always get reset to top of the scheduler. It would be great if the behavior instead was to keep the old data around until the remote filter has resolved, and allowing it to preserve scroll. This is especially important for us, as we have a mode where we filter based on the current date range as reported by onDateRangeChange to reduce the displayed of resources to those who have data within the date range.

If this sounds like unintended behavior, I can help reproduce this once the referred support issue has been fixed and I can see how it behaves after that.

[alex.l]

Hi,

to keep the old data around until the remote filter has resolved, and allowing it to preserve scroll.

It's not possible to predict what data will stay and around what data we should keep the scroll, if position of that data will unpredictable jumps and data might be absolutely new or contain few records or nothing, or more data. So what scroll position is correct? I am afraid, it's too hard to implement it on framework level.

[jimmycallin]

Hi,

to keep the old data around until the remote filter has resolved, and allowing it to preserve scroll.

It's not possible to predict what data will stay and around what data we should keep the scroll, if position of that data will unpredictable jumps and data might be absolutely new or contain few records or nothing, or more data. So what scroll position is correct? I am afraid, it's too hard to implement it on framework level.

I understand scroll preservation can be tricky, but showing stale data while fetching is a very common pattern and should be possible right?

[alex.l]

Yes, that sounds as intended - do not update and mask grid, until data received. What do you see now?