I have various types of content stored in a postgres database. The content can be notes, reports, media files, emails, and so on. I need to render all these items in a chronological order with the most recent entries on top.
My current approach looks like this:
I fetch all that content using quite a big SQL statement using many JOINs. The result looks like this:
id, created_at, updated_at, ... note_text, media_filesjson, media_description, media_title, email_sender, email_recipient, email_subject, email_body, and so on
Only the attributes needed for a certain type of content are populated, the others are nulled.
When iterating through that pile of data, containers with elements for all types of content get generated on each iteration. E.g. with 5 different types of content, 5 containers get generated, but only one of them gets populated with the corresponding data. The other 4 containers will be hidden.
The query seems unnecessary big and the overhead of 4 hidden containers tremendeously slows the app down. It takes up to ten seconds until this part of the app gets rendered.
Is there a better approach to achieve the same thing (chronological order) without that much overhead?
Would you mind sharing screenshot examples of exactly how you're generating and populating the various containers? It sounds like there may be a different approach here but I'm not sure what would be best.
One thought, for example, is that if you're pulling in one main set of data and then only want to have a listview or so render when a user clicks over to it, you could use a Query JSON with SQL query or JavaScript query that runs based on user interaction to fetch data from your big SQL query that runs on page load.
Again though, that might not be the right fit so it'd be awesome if you could tell us a bit more about your use case!
Okay, I just optimized the query to run in 100ms instead of 2 seconds (benchmarked in pgadmin 4). The resulting dataset still looks exactly the same.
I used CTEs to fetch pre-filtered data, then only JOIN the pre-filtered data in the final SELECT.
That's already a huge speed optimization. Unfortunately, the issue with the unnecessary amount of hidden UI elements persists. At 10 different types of content and 20 entries, I still get 200 boxes and 180 of them hidden I would be super grateful about any hints on how to optimize this too!
This is tricky, I'm not sure the best way to optimize this at the moment Have you thought of implementing something like pagination for the listview or does it have to be scrollable? test-app-timeline-paginated.json
Thank you, @Kabirdas!
This seems like a feasible solution once certain pages are getting too big. Unfortunately, unnecessary hidden DOM still slows the app down.
We generally face performance issues with our app. Page load is quite slow on normal computers. On a terminal server it's barely usable since opening up a new page takes an eternity.
Any other suggestions are highly appreciated and I'll keep you updated, once I have more time to work on this.
Unfortunately, I'm not finding a better option. We have a couple of feature requests open for virtualizing listviews and dynamically generating components that might help here but there aren't plans for completing them at the moment. If that changes and they're included we can let you know!
If the chronological ordering weren't strictly necessary you may be able to have separate listviews for each type which would cut down on the number of components generated by a lot, but that's very different from what you're asking here
I would be super grateful about any hints on how to optimize this too!
Have you thought of implementing something like pagination for the listview or does it have to be scrollable?