Just a quick check-in / progress report on 1.4.21
This release is looking to be a “When you do things right, people won’t be sure you’ve done anything at all” type of release. Most of the changes are architectural, so if nothing appears to have changed, then that’s what I’m going for.
Rewrote the Post Feeds
I’m in final testing phase of the post feed rewrite. That was a brute, and I spent a whole week’s worth of evenings squashing bugs, but I now have a post feed component that’s fully self-contained with regard to fetching, pagination (infinite scroll and manual), sorting, filtering, caching/snapshots, remembering where you left off, etc.
The old feed code was a hodgepodge of the original Photon code plus all the new stuff I bolted on. It worked, but it was ugly and was tightly coupled to the page it was integrated into. Since I’m going to have to do some heavy port work in the near future (more on that below), I figured it was high time to start some major refactoring and de-clutter.
The new feed component can be easily integrated anywhere, so that opens up some new feature avenues.
The new feed component has been integrated:
- On the frontpage main feed
- On community pages for the community feed
- In community profile modals - You can preview a community or check for latest posts without leaving your current spot
- In Moderation modals - It will show you the post/comment creator’s submissions in the current community
- In user profile modals: You can click anyone’s username and see their submissions right in the profile modal
For moderation purposes, those put a lot of helpful information right at your fingertips when accessing them from the moderation modal.
For user profile pages, I’m still working on the feed component there. I have a component that’s used in the modals, and that’s the likely candidate for the profile pages, but I may opt to adapt the post feed one to accept a user in addition to an optional community. The reason they’re separate is that profile submissions are fetched differently and have to display comments as well as posts. So, before I make a final decision on which way to implement that, I need to finish testing the current feed write and make sure all of the bugs have been addressed (so far, so good).
Snapshots Are Now gzip Compressed
Yes, I know IndexedDB will solve all of my storage woes. The problem is I’m not ready to integrate that yet (it’s planned for the re-write/port; see more below).
When you’re clicking from the feed into a post, Tess takes a snapshot of the current API data for that page and stores it to the browser’s session storage. The problem I keep facing and dealing with is that per key, local and session storage maxes out at 5 MB. That seems like a lot, but with infinite scroll and every post containing a full copy of the community details (the sidebar info), and multiple posts from the same community having redundant copies of that, that 5 MB fills up fast.
To address this (until I’m ready to switch to IndexedDB), I’ve added gzip compression to the snapshot data. In testing, I’m seeing about an 80-85% reduction in size compared to the uncompressed JSON. Considering all the redundant information it’s storing, that is to be expected.
Combined with the feed rewrite, the snapshots are also more useful. Before, they were just used as a way to get you back to the same spot in an infinite scrolling feed without having to fetch everything from the API up to that point. They…still do that. But, in addition, they now remember your feed position on the main feed as well as per-community.
This means if you scroll down through Community A, go home to check the main feed, pop into Community B, and then back to A, you will be returned to your previous position when going back into each.
Also, they will invalidate on browser refresh. I finally got that working reliably.
Snapshots are currently hardcoded to a maximum validity period of 15 minutes (or if you close the app/browser tab), but I am probably going to make that a config option. In practice, it means once you leave a position in the feed, you have 15 minutes to return to it before it expires and starts you back at the top.
Feedback / suggestions on that is welcome.
Svelte 5 or React?
So Svelte 5 is finally out. Initial estimates are that it’s going to take a lot of work to move from Svelte 4 to 5 (I absolutely will not let any script touch code I maintain, so it’s going to be a 100% manual process here).
I’m also considering just porting the whole thing over to React. The only reason Tess is in Svelte is because I wanted to add media support to Photon, and Photon was in Svelte. That said, while I was new to it at the time, it has grown on me. But React is what we use at work and seems to be generally more long-term stable.
I’m still mulling this over and will probably be kicking the can down the road for a while. I’m also looking for contributors, so that may factor into the decision as well.