Progressively loaded content #1106
Replies: 4 comments
-
|
I have the same problem with an application I'm developing. The database is not very well designed and the volume of data is significant. Some pages are slow to load for the client. To solve the problem, I chose to create a very small component called lazy, which is a highly simplified card. Here's an example of use: I agree with you, it's not optimal, but it works very well and the user doesn't see the trick. Best regards |
Beta Was this translation helpful? Give feedback.
-
|
I summarized the various possible performance issues and possible solutions here: https://sql-page.com/blog.sql?post=Performance%20Guide |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I think the lazy component is the best solution at the moment - its going to require a shift in mindset for me I think from "monolithic" to "micro", pulling out the long running/main queries into their own files. This makes things much more maintainable and reusable and I was probably going to have to do this anyway as my main project gets more and more complex, so no bad thing! I'm also experimenting with other ways of indicating to the user the page is still loading eg nprogress style status indicators, skeleton layouts. |
Beta Was this translation helpful? Give feedback.
-
|
Just in case this is of anyone use to anyone else, a simple Github style page load indicator does the job nicely I think e.g.
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Loving the progressively loaded content - not an option I had played with before!
However it throws up an interesting issue for long running queries. I have a page with a simple search form, a single entry and button, with results displayed in a table below the form (all in the same sql file). The query can take a few seconds to run and it can appear like nothing is happening/no results have been found when compress_responses is set to false because the chrome is so quick to load. With compress_responses set to true, the blank page makes it more obvious something is happening, and something is going to happen.
The obvious option is to embed the table in a card, which works well with its spinner, but it seems overkill for a simple form. For more complex pages I suppose it would encourage you to break it up in smaller more manageable files.
I'm going to have a play around to see what works best but I was wondering if anyone has any usability/UX/UI suggestions for this sort of scenario?
Beta Was this translation helpful? Give feedback.
All reactions