See also: Dear spotify product manager by Lu Wilson, Redesigning Spotify by Juxtopposed

Unable to Remove DJ Shortcut On Desktop

On desktop they have added a link to the DJ feature at the top of Your Library, below pinned playlists. Despite not being a playlist (nor a feature I use), it continues to appear even when you have set the filter to only show playlists. As far as I know it cannot be removed? But it can be pinned. Despite already being permalocked to the top. The day after writing the previous paragraph, I noticed they added the DJ to the same section in the mobile app. In the mobile app a long press on the DJ icon does shows you an option to hide it, which seems to sync across all my devices. Why is this option not available in the desktop client!

Custom Playlist Sorting

For as long as I can remember you can order the playlists you have created/followed in any order along the left side of the desktop app. You can even put them in nested folders which is fantastic. I have many playlists organised into folders in particular orders. I know how to get to the playlist I want quickly because I have put it in a particular place. This custom order and "Recently played" are the only two i would ever want.

Spotify seems to hate this use case. To my knowledge its never been possible to rearrange order of playlists on the mobile app, only the desktop client.

When you attempt to add a song to playlist on mobile, there isn't even an option to sort by recently played anymore. This is diametrically opposed to desktop, where the right click menu will ONLY allow you to sort by custom order.

Smart Shuffle Button Cycle Lock

Spotify has added a feature called Smart Shuffle that works like normal shuffling, but also adds recommended songs in-between ever few tracks in the queue. On paper I like this feature, though I have never found myself actually using it. I was introduced to it through the following infuriating UX.

I go the the Now Playing screen on the Android Spotify client. The playlist I am listening to is currently set to shuffle (regular shuffle), but I would like to turn off regular shuffle. I press the button with a shuffle icon, which has for 10+ years been a single toggle that would instantly take effect. Instead of a simple 2 option toggle, I find that it has been converted in to a 3 option cycle button, where pressing it cycles through the options of Linear -> Shuffle -> Smart Shuffle -> Linear. I can see the thinking behind this decision, but it breaks muscle memory established all other music players for decades. That is not my issue though.

When you click the button and move the state from Shuffle to Smart Shuffle, the application begins loading the Smart Shuffle recommendations which means it must query Spotify servers, which is an operation that takes multiple seconds. While this occurs, the button with a Shuffle icon becomes a button with a loading spinner, and becomes unclickable. I must wait multiple seconds before I can turn off Smart Shuffle.

Linear -> Shuffle -> Loading (multiple seconds) -> Smart Shuffle -> Linear

This is deeply infuriating. I never even wanted to use Smart Shuffle in the first place and now I must wait for it.

This occurred every time I wanted to turn off Shuffle. Which is a lot.

As of 2024-01-21, this loading state of the button appears to have been removed, thankfully.

Smart Shuffle Cycle Order

Oh sorry did I say the order was Linear -> Shuffle -> Smart Shuffle? Its actually Linear -> Smart Shuffle -> Shuffle. Wait no go back. Wait... it's a different order on my phone vs on desktop? This is real wtf.

Smart Shuffle Popup

I clicked shuffle once and this came up. Thankfully it only ever appeared once on 2023-11-14, but it never should have in the first place.

Overflow Menu Loading

For some godforsaken reason, the overflow menu for a track sometimes appears to require a network request before it can show. If this request is slow, it will show a loading spinner in place of the menu, until the server responds. Or in some cases, the overflow menu will fail to load entirely. This is insane, since for the most part, the options on this menu are identical. This is doubly insane since the menu can load without any issue what-so-ever in offline mode.

I have only ever experienced this issue on the Android mobile app, which for many years did not support swiping on a song to queue a song. At this time you were only able to queue a song. through the overflow menu, which often times meant waiting multiple seconds for menu to appear. God forbid you wanting to queue multiple songs in a row. Thankfully you can now bypass the menu loading by swiping a track to the right.

Oh wait!

Can't Swipe to Queue on Blend Playlists

On Android you cannot swipe to queue a playlist if the playlist is a blend playlist??? Why would this screen use a different component to represent a list of songs to every other screen in the app?

Secret Sliding Menu

This one I only just noticed now while typing this post. There is a sliding menu that appears if you click on your profile picture in the corner of any of the 3 main screens. It seems a bit sparse, like it would be better suited to being a drop down? In any case this menu can actually be accessed from any playlist folder screen as well, despite there being no indication of this. This only seems to work on playlist folder screens though, as it doesn't work for any other subpages.

This one was annoying as I accidentally triggered in when attempting to swipe in from the left to go back a screen.

Can't Swipe Up to Access Player

On Android you can swipe down on the player interface but you cannot swipe up to reveal it. When you attempt this you will almost definitely skip the song that is currently playing, since the minimised version of the player only detects left and right swipes.

Top Bar Alignment

Who the fuck let this happen.

Liked Songs Filters Are Actually a Playlist

For years, if you used the text filter on your Liked Songs and then played one of the songs, the queue would only populate with songs that matched that filter. This could be useful for only listening to a particular artist within your Liked Songs, but was usually just annoying.

As of 2024 it appears this behaviour has been removed.

Search Results Are Actually a Playlist

Similar to the previous issue, if you searched for a song using the search tab, and then played one of the results, the queue would populate with all the other search results meaning you would hear the same song repeated several times, or covers, or random other tracks with similar names.

As of 2024 it appears this behaviour has been removed.

Useless Music Video Indicator

They have added a subtitle and icon for songs with music videos, which looks like it is clickable or has some feature attached to it. But it just... doesn't?

Upcoming Complaints

• Rapidly toggling through Shuffle button states can cause the cycle to desync in strange ways
• Spotify (regular) Shuffle algorithm has some problems

RTK Query with React is pretty great! The primary pattern you find yourself using with it is:

1. writing a small API definition that provides
   1. the endpoint url
   2. type definitions for request args and response schema
   3. (usually) simply logic for converting passed argument type into request params/body
   4. (usually) simple logic for converting response payload into the response schema
2. importing a hook that RTK Query automatically generates for you
3. reuse the same hook across multiple components

RTK Query handles loading states, stale while revalidate states, error states, type safety, and caching.

When writing React components, the caching is the most impactful of these. You can just call the same hook in many different components, and as long as the params are the same the same it will only be a single network request. This removes the need for many invocations useState and Redux state calls, since you can just feign a call to the backend every time you need that data.

There is a little boilerplate you have to write, but the meat of a basic RTK Query definition will look something like this:

    getLocation: build.query<Location, { id: number }>({
      query: ({ ids }) => ({
        url: "api/v1/location",
        params: { id },
      }),
      transformResponse: (response: any) => response.data,
    }),

This will generate a hook called useGetLocation which will be cached. Suddenly you never need to store a Location object in state to share it across components and you can just call useGetLocation({id:5}) every time you need it. It also provides a lazy version of the hook that returns a normal function you can use to retrieve the data, which is good for APIs that need to be called multiple times.

function LocationCard({ id }: {id: number}) {
    const {data: location, isLoading} = useGetLocation({id:id});
    const [getLocationsLazy] = useLazyGetLocation();
    ...
    return (
        <div>
            {location.address}
        </div>
    );
}

For straightforward GET requests this pattern stellar. RTK Query encourages you to put all the API definitions into a single file (src/api/api.ts), or into a small number files with particular scopes. For small-medium applications this works well, if you know the URL of an endpoint you want to hit you can just search within the api.ts file, use the accompanying hook and you are good to go, type safety and all. I'm sure this single file approach would breakdown for big applications but its very pleasant at smaller scales.

RTK Query also lets you do POST/PUT/PATCH requests with a similar definition style. Instead of using build.query, you use build.mutation.

    addLocation: build.mutation<
      { location_id: number; site_id: number; address: string; abn: string; user_id: number },
      NewLocation
    >({
      query: (body) => ({
        url: "api/v1/location",
        method: "POST",
        body: body,
      }),
    }),
    patchLocation: build.mutation<void, { id: number; data: Partial<Location> }>({
      query: ({ id, data }) => {
        return {
          method: "PATCH",
          url: `api/v1/location/${primaryKey}`,
          body: data,
        };
      },
      transformResponse: (response: any) => response.data,
    }),

The hooks generated here will return a function that can be used to send requests.

function LocationCard({id}: {id:number}) {
    const {data: location, isLoading} = useGetLocationQuery({id:id})
    const [patchLocation, isPatchLoading] = usePatchLocationMutation()

    function onUpdate(locationUpdate:Partial<Location>) {
        patchLocation(locationUpdate)
    }
    ...
    return (
        <div>
            {location.address}
            ...
            {/* some input that calls onUpdate on change */}
        </div>
    )
}

But wait! If I patch a location, how will the useGetLocation hook know that it's cache is invalid?

Cache Invalidation

RTK Query uses a tag system for cache invalidation, where a tag represents a kind of query. Queries can assign themselves tags, and mutations can provide a list of tags they will invalidate.

These can be static

    getLocation: build.query<Location, { id: number }>({
      query: ({ ids }) => ({
        url: "api/v1/location",
        params: { id },
      }),
      transformResponse: (response: any) => response.data,
      providesTags: ['Location'],
    }),

or dynamic, based on the params given

    getLocation: build.query<Location, { id: number }>({
      query: ({ ids }) => ({
        url: "api/v1/location",
        params: { id },
      }),
      transformResponse: (response: any) => response.data,
      providesTags: (result, error, arg) => [{type:"Location", id: id}]
    }),

And similarly for mutations

    patchLocation: build.mutation<void, { id: number; data: Partial<Location> }>({
      query: ({ id, data }) => {
        return {
          method: "PATCH",
          url: `api/v1/location/${primaryKey}`,
          body: data,
        };
      },
      transformResponse: (response: any) => response.data,
      invalidatesTags: (result, error, arg) => [{ type: 'Location', id: arg.id }] // or just ["Location"] to invalidate the whole category
    }),

Where you can, dynamic tags are generally better since you have much more granular control. Again, this works pretty well for straightforward queries.

Pagination

RTK Query doesn't include a mechanism for paging data, but passing a page number as a param works fine if you have discrete pages.

    getLocations: build.query<Location, { page: number }>({
      query: ({ page }) => ({
        url: "api/v1/locations",
        params: { page }
      }),
      transformResponse: (response: any) => response.data,
      providesTags: (result, error, arg) => [...result.map(location => {type:"Location", id: location.id}), {type:"Location", id: "LIST"}],
    }),

But what about infinite scroll?

When infinitely scrolling, normally you'd have an array that stores all the results that have been loaded so far, and then you'd append new results to the end of this list when they are loaded in (maybe even dropping some entries from the start if you are memory constrained). The hook generated by the previous example will only ever let you access one page's entries at a time.

RTK Query doesn't have any special functions for infinite scrolling, but the pieces it gives you are enough to make it work. When writing a query definition you can explicitly set which params contribute are used to define unique cache entries, and another function to say how old cache entries should be overwritten by new ones.

    getLocations: build.query<Location, { page: number }>({
      query: () => ({
        url: "api/v1/locations",
        params: { page }

      }),
      transformResponse: (response: any) => response.data,
      providesTags: (result, error, arg) => [...result.map(location => {type:"Location", id: location.id}), {type:"Location", id: "LIST"}],

      // overwrite cached value when page value changes, treat page
      serializeQueryArgs: ({ queryArgs }) => ({ ...queryArgs, page: undefined }),

      // when overwriting cache value, append new data to old list
      merge: (currentCache, newData, otherArgs) => {
          currentCache.items.push(...newData);
      },
    }),

This works riiiiight until you need to invalidate the cache. Say you have a page with infinite scroll via pressing a load more button at the bottom, and the user has pressed it 3 times. At this stage, the hook will look like const {data} = useGetLocationsQuery({page: 4});. If page size is 20, data, will contain 80 entries. Then you edit an entry that appears on page 3. Or you add a new location. Both of these operation will invalidate the cache, but the merge strategy provided will simply add the new cache to the end of the previous cache, so const {data} = useGetLocationsQuery({page: 4}); will now have 100 entries, 80 from the original 4 pages and 20 from the 4th page repeated again. Ideally the merge function would have a way of distinguishing cache updates that are due to tag invalidation from cache updates due to parameter changes, but there is currently no way to do this.

Workarounds

There are a number of discussion of how to mitigate this. The solution I went with looks like this.

Firstly, the response payload must include the page number metadata. This is usually the case with paginated endpoints, but this data now needs to be included in the cached result in the query definition.

When merging the cache, only append the new data if the new data page number is greater than the old value:

type PaginatedData<ItemType> = {
  page: number;
  pages: number;
  per_page: number;
  total: number;
  items: ItemType[];
};
...

    getLocations: build.query<PaginatedData<Location>, { page: number }>({
      query: () => ({
        url: "api/v1/locations",
        params: { page }

      }),
      transformResponse: (response: any) => response.data,
      providesTags: (result, error, arg) => [...result.map(location => {type:"Location", id: location.id}), {type:"Location", id: "LIST"}],

      // overwrite cached value when page value changes, treat page
      serializeQueryArgs: ({ queryArgs }) => ({ ...queryArgs, page: undefined }),

      // when overwriting cache value, append new data to old list if page value increases
      merge: (currentCache, newData, otherArgs) => {
        if (newData.page > currentCache.page) {
          currentCache.items.push(...newData.items);
          currentCache = { ...newData, items: currentCache.items };
        } else {
          return newData;
        }
      },
    }),

Then in the component where the hook is called, ensure that the page number is reset to 1 whenever a mutation occurs that will invalidate the useGetLocationsQuery data. Since this page isn't an increase from the previous, the old cache will be discarded. This can be annoying since the component that triggers the mutation and invalidates the data may be completely seperate from the component that queries for the data.

function EditLocationAddress({id}: {id:number}) {
    const [patchLocation, isPatchLoading] = usePatchLocationMutation();

    function onUpdate(locationUpdate:Partial<Location>) {
        patchLocation(locationUpdate);
        // TODO somehow reset the page number to 0 in all relevant places
    }
    ...
    return (
        <div>
            {/* some input that calls onUpdate on change */}
        </div>
    );
}

There is probably a clever way of doing this where the cached page number is used as the canonical page number across all components, and then you could force a reset back to one from any component, but I haven't needed to implement this just yet in any applications.

Maybe something like this? I haven't tried it yet.

function EditLocationAddress({id}: {id:number}) {
    const [patchLocation, isPatchLoading] = usePatchLocationMutation();
    const [getLocationsLazy] = useLazyGetLocationsQuery();

    function onUpdate(locationUpdate:Partial<Location>) {
        patchLocation(locationUpdate);
        getLocationsLazy(
            { page: 1 },
            true // lazy queries ignore cache by default, true overrides this
        );
    }
    ...
    return (
        <div>
            {/* some input that calls onUpdate on change */}
        </div>
    );
}

Break any of these rules sooner than say anything outright barbarous.

George Orwell

This whole website is a living document, but this page is especially living. These are strong beliefs that are weakly held, I'm certain many of these will change over time.

Some of these will seem trivial and obvious, but they are all written because I have seem them consistently violated in professional settings. These writing were initially intended to be a code practices guide, but they became just angry venting.

The Error

The type error was being triggered by a chord component, where the key was undefined. The chords are pulled from Ultimate Guitar, so I inspected the JSON payload from the original source.

Why the hell is there a [ch]H[/ch] chord in there? That's definitely the cause as I never accounted for non-existent keys. Looking at Ultimate Guitar, it renders as a B chord.

Huh?

One Google Search Later

Germany and the Netherlands ha(d/ve) their own musical key notation that include(d/s) a H chord. This site claims it ended in "1994/1995", though I've seen other sources claim its still taught this way. This comes as an artefact of the bizarre history Western music notation, which is a problem I seem to keep running into recently in my attempts to learn more about music theory.

I learned in music school that the chord is called "B" (like in the rest of the world), but the note is called "H" (eg. the C Major scale would be C, D, E, F, G, A, H, C).

TobTobXX, who reported the bug

Western Music's Stupid Origins

Western music is based on ecclesiastic modes used in church in the early Middle Ages, which only used the diatonic notes of the C scale (natural notes). The musical notation systems of the time reflected this, not accounting for notes outside of the C scale. When sharps and flats later came into more common use, the existing notation systems needed a way to distinguish them from the natural notes they sat between.

This problem first arose with B natural and B flat, according to the Encyclopedia Britannica. The first method of distinguishing B from B flat was using two different forms of the lowercase "b" character:

Niecks, Frederick. “The Flat, Sharp, and Natural. A Historical Sketch.” Proceedings of the Musical Association, vol. 16, 1889, pp. 79–100.

Somewhere along the line in Germany, monks transcribing these square and round "b" characters confused the squared "b" for "h", and this was later assumed to be intentional. "H" became a convention for writing B natural, while the "b" character remained convention for writing B flat. "B" and "b" became amalgamated, both coming to represent modern B flat.

In the rest of the world, this "H" note didn't catch on.

In time, notation for sharp and flat notes other than B flat was needed. This use of square and round "b" to denote B and B flat eventually evolved into our modern notation for indicating natural and non-natural, accidentals. ♭ comes from the round "b", while ♯ and ♮ come from the square "b".

Somehow, Germany still hasn't fully corrected this mistake, continuing to use "H" to represent B natural in many places. Including Ultimate Guitar. Ugh.

Resolution

I don't love dealing with problems caused by the whims of millennia dead monks, but this was an interesting rabbit hole to fall into. The issue has since been patched, and I look forward to my mistakes ruining someone's day in 3023.

requires = [
    'jmespath>=0.7.1,<2.0.0',
    'python-dateutil>=2.1,<3.0.0',
    # Prior to Python 3.10, Python doesn't require openssl 1.1.1
    # but urllib3 2.0+ does. This means all botocore users will be
    # broken by default on Amazon Linux 2 and AWS Lambda without this pin.
    'urllib3>=1.25.4,<1.27 ; python_version < "3.10"',
    'urllib3>=1.25.4,!=2.2.0,<3 ; python_version >= "3.10"',
]

will not have the Python version shown when running poetry show, despite some the package ranges depending on the Python version of the project. On a Python project where the pyproject.toml specifies Python 3.9, poetry show will only return the urllib3 version range that is valid for Python 3.9.

[~/projects/prosebit] (develop)  
> head pyproject.toml
[tool.poetry]
name = "prosebit"
version = "0.1.0"
description = ""
authors = ["Your Name <you@example.com>"]
readme = "README.md"

[tool.poetry.dependencies]
python = "3.9"

[~/projects/prosebit] (develop)  
> poetry show botocore
 name         : botocore                               
 version      : 1.34.144                               
 description  : Low-level, data-driven core of boto 3. 

dependencies
 - jmespath >=0.7.1,<2.0.0
 - python-dateutil >=2.1,<3.0.0
 - urllib3 >=1.25.4,<1.27

required by
 - boto3 >=1.34.144,<1.35.0
 - s3transfer >=1.33.2,<2.0a.0

On a Python project where the pyproject.toml specifies Python 3.10, poetry show will only return the urllib3 version range that is valid for Python 3.10.

[~/projects/prosebit] (develop)  
> head pyproject.toml
[tool.poetry]
name = "prosebit"
version = "0.1.0"
description = ""
authors = ["Your Name <you@example.com>"]
readme = "README.md"

[tool.poetry.dependencies]
python = "3.10"

[~/projects/prosebit] (develop)  
> poetry show botocore
 name         : botocore                               
 version      : 1.34.144                               
 description  : Low-level, data-driven core of boto 3. 

dependencies
 - jmespath >=0.7.1,<2.0.0
 - python-dateutil >=2.1,<3.0.0
 - urllib3 >=1.25.4,<2.2.0 || >2.2.0,<3

required by
 - boto3 >=1.34.144,<1.35.0
 - s3transfer >=1.33.2,<2.0a.0

On a Python project where a range is specified that covers multiple urllib3 package ranges, poetry show will show both ranges without specifying that the ranges apply to different Python versions.

[~/projects/prosebit] (develop)  
> head pyproject.toml
[tool.poetry]
name = "prosebit"
version = "0.1.0"
description = ""
authors = ["Your Name <you@example.com>"]
readme = "README.md"

[tool.poetry.dependencies]
python = ">=3.9,<3.12"

[~/projects/prosebit] (develop)  
> poetry show botocore
 name         : botocore                               
 version      : 1.34.144                               
 description  : Low-level, data-driven core of boto 3. 

dependencies
 - jmespath >=0.7.1,<2.0.0
 - python-dateutil >=2.1,<3.0.0
 - urllib3 >=1.25.4,<1.27
 - urllib3 >=1.25.4,<2.2.0 || >2.2.0,<3

required by
 - boto3 >=1.34.144,<1.35.0
 - s3transfer >=1.33.2,<2.0a.0

Despite displaying both ranges in poetry show, Poetry will only use the oldest range when running poetry lock or poetry install . This can lead to a disconnect between the package ranges that Poetry is reporting as valid and the package ranges that Poetry will actually attempt to use when running.

I discovered this the hard way when trying to install kinde-python-sdk and boto3 within the same project. boto3 requires botocore which requires urllib3. kinde-python-sdk also requires urllib3. Since my project was set to use python = ">=3.9,<3.12", Poetry was listing both ranges in poetry show, but only using the range urllib3 >=1.25.4,<1.27 when installing botocore. This resulted in headaches because kinde-python-sdk requires urllib3 >=2.2.1,<2.3.0, so it appeared like botocore and kinde-python-sdk could coexist when I ran poetry show, but failed to install every time I tried.

Another important detail to note is that this is all dependent on the Python version specified in pyproject.toml. The Python version you are actually running does not change the behaviour of Poetry. I ran into all of these problems when running Python 3.11, so was confused for hours.

poetry show should report the Python versions that each package dependency range is valid for, since this turned a relatively simple dependency conflict into a multi-hour dependency conflict. I was only able to figure out the exact cause by reading the setup script for botocore.

Useless Dropdowns

This dropdown should list the environments instead of revealing a button to take you to a page that lists the environments. This is an unnecessary second click.

This also means you are unable to switch environment without losing the page you are on.

Unclickable Icons

For some reason the left facing chevron is not clickable, only the word "Home" is.

Bizarre Breadcrumbs

When you go to the "Users Profile" screen, the top left back icon doesn't take you back to the "Users" screen, but remains a "Home" button.

The only way to navigate back is the the small grey "User" text above the user's name.

This is something that almost all basic websites can get right. Breadcrumb navigation or consistent back behaviour would be vastly preferable here.

There is little consistency between parts of the interface that are clickable and those that are not. This makes navigating quite difficult.

This is horrific. I knew this kind of bullshit would happen eventually, but I didn't expect it so soon.

Here is how platforms die: first, they are good to their users; then they abuse their users to make things better for their business customers; finally, they abuse those business customers to claw back all the value for themselves. Then, they die.

Cory Doctorow

If you look into the source of a LinkedIn profile page (at your own personal risk) you'll find a text element like this

will have HTML like this

<div class="display-flex flex-row justify-space-between">
    <div class="
          display-flex flex-column full-width">

        <div class="display-flex flex-wrap align-items-center full-height">
            <span class="mr1 t-bold">
                <span aria-hidden="true"><!---->Product manager, Creative coder<!----></span>
                <span class="visually-hidden"><!---->Product manager, Creative coder<!----></span>
            </span>
            <!----><!----><!---->
        </div>
        <span class="t-14 t-normal">
            <span aria-hidden="true"><!---->Freelancer/Consultant<!----></span>
            <span class="visually-hidden"><!---->Freelancer/Consultant<!----></span>
        </span>
        <span class="t-14 t-normal t-black--light">
            <span aria-hidden="true"><!---->2009 - 2018 · 9 yrs<!----></span>
            <span class="visually-hidden"><!---->2009 - 2018 · 9 yrs<!----></span>
        </span>
        <span class="t-14 t-normal t-black--light">
            <span aria-hidden="true"><!---->Europe<!----></span>
            <span class="visually-hidden"><!---->Europe<!----></span>
        </span>

    </div>

    <!---->
    <div class="pvs-entity__action-container">
        <!---->
    </div>
</div>

Gross. Why the hidden duplicated text? Why the empty comments? Why seperate aria versions of text? Is this related to using Ember? LinkedIn has so many little unpleasantries like this.

2024 Update: LinkedIn Still Shit

Still here. Still broken. Still annoying

2025 Update: Slack also does this

When you highlight, copy and paste a name.

I have 20GiB+ of photos on my phone and would like a backup. My primary Nextcloud account is synced to my PCs, so any file added to it will be downloaded to all devices. I don't need local access to these photos on all my PCs, so I created a seperate Nextcloud account just for camera roll uploads. If I needed to access these photos from a PC I could log in to the Nextcloud web interface with the camera roll account.

Attempting to use Auto-Upload on my phone's Camera folder was messy. It kept uploading photos to the wrong Nextcloud account, incorrectly counting how many files there were, and did not supporting bidirectional sync. It was unpredictable how long it would take to actually trigger an upload, not having a manual way of starting one. It also limited automatic uploads to a single folder. These issues were all seperate from the fact that the UI was extremely glitchy as it tried to show 20GiB of photos.

I found using FolderSync a much better experience. It let me set up bidirectional sync between custom Nextcloud folders and local folders, let me choose cadence for syncing (with many configuration options like only allowing upload when charging) and allowed me to manually trigger a sync. The premium version is absolutely worth it. I'm only scratching the surface of what it can do here, but for my needs it's perfect.