Table loading animations

I have a table component where the named query data binding could take several seconds to run. I'd like to put a loading or wait animation while it's running, otherwise it appears nothing is happening. I didn't see anything in the documentation about a loading prop, like reports.

Is there a best practice way to address this?

There's (currently) no wait to access meta-information about a binding like this, so your only option (currently) is to run your named query via scripting, setting your loading state as a side effect before and after the query is running.

As an unrelated aside, "several seconds" is quite long for a DB query - is that actually the query time, or is it expensive to create the table row components or some other aspect of the operation?

1 Like

I do what Paul said, for things that can take some time and that the user HAVE TO wait for: open an unclosable modal with the loading animation before the operations, then close it at the end. You can even make a decorator for it.

I'm not sure what happens if the page/tab/browser/computer is closed/shut down before the end of the operation though.

only option (currently) is to run your named query via scripting, setting your loading state as a side effect before and after the query is running.

The named query has some dropdown and date filters and then I have a script to give it some conditional formatting. Are you saying to run the query directly in the script instead of the query binding? Firing it onActionPerformed from the component?

Thinking, maybe I could add a "search" button where it doesn't run until the user selects the filters and hits the button...

As an unrelated aside, "several seconds" is quite long for a DB query - is that actually the query time, or is it expensive to create the table row components or some other aspect of the operation?

It's a pretty expensive query I'm unioning two views with a total of 9 CTEs and 8 left joins across 4 tables. I'm working on refactoring it and making indexes so it runs faster. Current longest wait so far was ~3.5s but it feels like forever in the project. I choose to blame it on SQL Server core limit and not my poor query writing. :smiley:

1 Like

This is usually a good pattern, in my opinion.

I'll add that the "(currently)" I added is because we do have plans to expose some kind of "meta" information about property binding state to expressions, which would allow you to do this directly. However, that feature is not coming anytime soon, so using a script is definitely the way to go.

Fair enough :wink:
A few seconds is definitely reasonable for a really complex query - the alarm bells just go off in my head because sometimes it's someone with "select top 100 from one table" taking 20 seconds, and that's scary.

I wish it were that simple. It started out pretty bad (10-20 seconds) but I think getting it down to where I have it may not be good, but good enough. Just trying to find a way to let the user know something is happening. Some of the guinea pigs get click happy when they don't receive feedback on actions that aren't instantaneous.

Something something instant gratification...

Thanks again for all your help!

2 Likes

customer: "I clicked on the button but didn't receive the email !"
dev: checks logs, 20 clicks registered in a 5 seconds window
customer: "I received the same email 20 times, something's wrong with your code !"

Well... ive had worse, some old project (7.9) wanted some updates...
image
i dont have access to the old db to make indexes... So for now its just filtereing in the gateway instead of the db untill someone finds out how to access that db again

1 Like

... it was 23 clicks and subsequent row creations, ~200ms apart.

2023-10-25 12:04:08.5966667
2023-10-25 12:04:08.7633333
2023-10-25 12:04:08.9233333
2023-10-25 12:04:09.1000000
2023-10-25 12:04:09.3066667
2023-10-25 12:04:09.4900000
2023-10-25 12:04:09.6766667
2023-10-25 12:04:09.8666667
2023-10-25 12:04:10.0700000
2023-10-25 12:04:10.2666667
2023-10-25 12:04:10.4466667
2023-10-25 12:04:10.6500000
2023-10-25 12:04:10.8633333
2023-10-25 12:04:11.0833333
2023-10-25 12:04:11.2766667
2023-10-25 12:04:11.7700000
2023-10-25 12:04:12.1700000
2023-10-25 12:04:12.3766667
2023-10-25 12:04:12.6300000
2023-10-25 12:04:13.0666667
2023-10-25 12:04:13.2666667
2023-10-25 12:04:13.4566667
2023-10-25 12:04:13.6600000

another tester was 9 times and another was 68 times...

2 Likes

someone was angry

2 Likes

Or there's something in the code that would make multiple if held down? That 200ms is suspiciously close to the default Vision Client poll rate.

1 Like

Or korean starcraft players started using ignition.

I can't imagine someone clicking 20 times on a button in this time frame.

1 Like

Still noone holds down a button for 5 seconds.

But maybe its just one a second and it get multiplied it a little. Could be some true limit testing though, its actually good that testers try to break the program

A software tester walks into a bar.
Runs into a bar.
Crawls into a bar.
Dances into a bar.
Flies into a bar.
Jumps into a bar.
And orders:
a beer.
2 beers.
0 beers.
99999999 beers.
a lizard in a beer glass.
-1 beer.
"qwertyuiop" beers.
Testing complete.
A real customer walks into the bar and asks where the bathroom is.
The bar goes up in flames.