The ‘compact’ view has been refreshed. Now slightly more compact and powerful. Thumbnail images have been moved to the right side so they can be moved higher up in the post card while also keeping the left side consistent if there is no thumbnail image.

Compact mode now no longer automatically disables the feed margins. You’ll need to use the “toggle margins” buttons in the navbar to make them full width (the setting will persist, so you only need to do it once).

It also works quite a bit better in mobile, though not perfect (there’s not much difference in overall post height when it’s scrunched down that far).

That said, “compact” view is mostly designed for desktop though I’ve done my best to make sure it looks presentable on mobile as well.

Posts can now also be rendered in compact mode on the post pages (e.g. /post/12345). All media and image posts, though, will still default to “card” mode (but can be minimized to compact). This was chosen as a compromise between not making article headline images huge and having to click twice to show an image post (e.g. meme) in full when clicking into it.

Added a new setting (Settings -> Feed -> Post Body Preview Length) to allow setting the number of characters that show in the post body in the feed before requiring a click of ‘expand’. Can even disable the body previews if you want really compact posts. This setting is also available in the “Quick Options”.

The default is 240 characters (same as the old hardcoded value in prior releases).

What’s the difference between ‘Disabled’ and ‘0’?

Setting the body preview length to disabled will hide the post body component completely in the feed (including the expand button); you will have to click into the post to see the body at all.

Setting it to 0 will not show the body preview contents but will keep the “expand” button to enable you to view the post body in the feed if you wish.

I really don’t want to (and have no plans to) create and maintain more than two basic types of view.

That said, the compact view is flexible since it’s affected by several different config options. In the future, I may add some “synthetic” view modes that change the margins, body preview length, and other config options to certain presets.

Ideas:

• Reader View: Compact posts, full width (no margins), and shows most (or all) of the post body.

• High Desnsity Mode: Compact posts, full width (no margins), post body preview disabled, flairs disabled, and thumbnails disabled (disabling thumbnails isn’t a feature currently but can be)

• ??? (Suggestions welcome)

Added a button to the bottom of the link preview modal that will let you try to view the link in an iframe. Not all websites allow this (they set the X-Frame-Options header to disallow it), but enough do that this feature can still be useful.

I tried doing a pre-flight check to determine if the link allowed loading in a frame and conditionally hide the button, but hit several snags:

1. Browser-side: CORS policy would only allow opaque fetches (which, by nature, don’t return the header I need to check).
2. Browser-side: Checking the onLoad event from the iframe doesn’t differentiate between success and failure
3. Server-side: Tried adding an API endpoint and doing a server-side fetch to get the target page headers, but Cloudflare said ‘fuck off, these are my M&Ms’
4. Server-side: I started adding shims to get past Cloudflare, but quickly realized that is not a cat/mouse game I want to play.

So, the “IFrame” button will always be present/enabled on desktop view and may or may not work for any given link. Ironically, some links that fail to fetch metadata will load in an iframe.

Have reduced memory consumption by about 15-25% overall

Removed the embedded action modals (ban, remove submissions, etc) from moderation buttons and am calling the “shared” ones.

Ironically, this is basically putting those back to the way they were when I first forked from Photon. The problem, then, was that they weren’t reactive and you had to refresh the page to see the results. Not ideal.

That was addressed with the new event dispatcher I added…

In several places, variables were bound between 3 and 4 levels of components for the purposes of triggering state changes. This worked but was cumbersome and often left some things in the old state because there was no direct link between the component initiating the action and the one that needed to react to it.

I already used Svelte-native dispatchers in many places, but there were some components that didn’t have a direct link to receive the dispatched events (similar to the bound variable conundrum)

Once I setup a global dispatcher, I started reconfiguring the reactivity to work with those events rather than binding everything down a huge chain of components.

This is expanding upon the reactivity enhancements first introduced in 1.4.2.