Filter field: Disable while waiting for async data

[thomaspink]

Should the filter field be disabled while async data is loaded to prevent the user from deleting nodes that relate to the currently loaded data.

This can then lead to a broken state if the user removes the original async node (via backspace) while the request is still pending (See issue #1436 )

[lukasholzer]

I think disabling without a reason would irritate the user as he might think he broke something by accident.

Maybe having a small loading distractor that provides feedback that something is ongoing would be the better approach but I would discuss this with @dynatrace-oss/ux-core – what is their opinion on that?

[thomaspink]

@lukasholzer a loading-indicator is already shown while a request is pending. See this example.

The question is, how do (or should) we prevent the user from interacting with the filter field and causing an invalid state by accident, while loading async data. If not, we shift the handling to the consumer who has to implement a way to cancel the async request when the user interacts and maybe switches to a different node.

[kathrin-aigner]

I don't see a problem with disabling the field while the loading action is happening (If there is no additional loading indicator a small loading indicator instead of the filter can be placed so that the user knows what happens.) Is it somehow possible to cancel the loading action?

[thomaspink]

@kathrin-aigner Yes. The consumer can cancel the loading.

[thomaspink]

As discussed with UX we do not fully disable the filter field, only the input field should switch to a "readonly" mode so no characters (also backspace) can be entered. Removing completed tags (filters) should still be possible via click on the X

[dominikmessner]

Will this affect all implementations, or will we be able to restore the old behavior? I think if the async request takes a long time to load, it might still be more convenient if the user is able to cancel it.

I also investigated the reason this bug came up in first place. Our filter field implementation/wrapper already handled cancelling the requests, but it looks like the events changed in one of the recent releases.
Previously onFilterChanges fired whenever the node was deleted, but since a few weeks we need to listen to onCurrentFilterChanged to detect these cases. Not sure if this was changed on purpose, or if it is a bug.