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.
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
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