Feature: move subclasses to sub-tab

[calumbell]

We would like to update the sidebar (implemented in layouts/default.vue) so that when a class is being viewed via the /class/[id] route, its subclasses are visible in the sidebar. Something like this:

It might be worth considering how we avoid allowing the sidebar to people excessively long. One idea might be to hide the other classes in the sidebar when one is already being viewed, but this might impair navigation too much.

[calumbell]

Alright, so I have taken a look at getting this feature implemented, and here are my thoughts. Essay incoming.

TLDR: probably best to wait until API V2 before undertaking this fix. I'll tag this issue as blocked, but if you have a genius solution to solve it then be my guest!

One Possible Solution

Adding the subclasses as a nested section to each class would require a refactor of how we currently handle the genration of navlinks. With possibly three-layers of nested links, recursive generation of subroutes seems like the wisest idea.

Assume we can format route data from the in the form:

type Route = {
  title: string,
  url: string,
  subroutes = Array<Route>;
}

Then the follow pseudo-code might be a good way to recursively generate the nav-links:

function generateLink(route: Route, baseUrl = '/') {
  if (!route.title || !route.url) return;
  return <li>
     <a :href="baseUrl + route.url">{{ route.title }}</a>
     <ul v-if="route.subroutes.length > 0">
        {{ subroutes.map((subroute) => generateLink(subroute, baseUrl + url)) }}
     </ul>
  </li>
}

This might be called in the component template like:

<template>
  ...
  // Navlinks
  <ul>
    {{ routes.map((route) => generateLink(route)) }}
  </ul>
</template>

(NB. this is pseudo-code and hasn't been tested)

The Issue

The principal obstacle to this solution is fetching and formatting the API data in a way that avoids spaghetti while keeping the API response payloads as small as possible given how the Open5e API handles subclasses (archetypes in the parlance of the API)

Subclasses do not have their own endpoint, they are returned as an array for a given class. ie. Barbarian subclasses are access via the archetypes property returned by https://api.open5e.com/classes/barbarian/ . This property contains an array of archetype objects.

If we request the archetype data in the layout.vue component, it pulls ALL the archetype data. This includes the lengthly desc fields when all we need are the name and slug fields. Due to the weird nesting of the subclasses, I am not sure how to coerce the query params into only returning

Compare this to the size of the response payload from the current reversion of the website. Requesting the 'archetypes' field from /classes increases the response size by several orders of magnitude. This will scale horribly as we add more subclasses to the API.

Taking a peek at API v2, this shouldn't be so much of a problem. Classes and subclasses are now both returned directly from the /classes route, but can be easily filter by the subclass_of field (null for base classes, a base class slug for subclasses)