DataTable #loading overridden template is not always rendered #2547
Labels
Type: Bug
Issue contains a bug related to a specific component. Something about the component is not working
Milestone
Hi everyone,
I found a what I think it's a bug (unless I misunderstood the loading template documentation of the DataTable)
I'm submitting a ... (check one with "x")
CodeSandbox Case (Bug Reports)
https://codesandbox.io/s/awesome-sound-optdzm?file=/src/App.vue
Current behavior
When overriding the #loading template of the DataTable, it gets rendered the first time the DataTable gets rendered, but not the following times. Instead, the default loading template gets rendered (which includes an overlay + a spinner).
More globally, after looking at the code, it seems the #loading template is rendered only when there is no row to display in the DataTable
Expected behavior
The #loading template should be rendered and superseed the default loading rendering when it is defined, whatever if there are rows to display or not.
Minimal reproduction of the problem with instructions
https://codesandbox.io/s/awesome-sound-optdzm?file=/src/App.vue
I made a codesandbox where I'm using the paginator feature of the DataTable and switch the loading prop on and off when changing pages. We can see that the custom loading template is rendered on first page loading, but afterwards, when changing pages, it is not rendered anymore.
What is the motivation / use case for changing the behavior?
Mainly about consistency.
One use case (shown in the codebox) is having the loading template customized so to allow loading rows to be cancelled or display a progressbar component instead of a spinner icon.
I have looked for workarounds, using the BlockUI component on top of the DataTable for example, but unfortunately, we cannot customize the BlockUI overlay either (but that will be a RFC for later ^^)
Vue version: 3.2.33
PrimeVue version: 3.12.16
Browser: Not relevant I guess, but tested only on Chrome
I'll try to include a PR with a fix proposal if the issue is indeed qualified as a bug.
The text was updated successfully, but these errors were encountered: