How to handle client side routing/links

[nihaals]

For example, Next.js gives Link (docs). If we have multiple projects, for example a mod manager, we might need to support different routers in our components (e.g. an "every path uses the same HTML file" style router or a hash based router (SPA?))?
/cc @MythicManiac @ebkr

If we are able to use Next.js for all of our projects, we would still need our linking to work as expected during the Django migration phase. Maybe having some kind of i18n style object that maps path names to actual paths could be used which is passed into ThunderstoreProvider along with a Link component (so we could just use <a> on Django).

[nihaals]

The other project would be a SPA so we would probably have 3 different links:

• Next.js
• react-router (possibly hash-based)
• Standard <a> tags

The idea I had was using the context and mapping path names to paths which are essentially templates. For example:

<ThunderstoreProvider
  value={{
    paths: { modInfo: "/{community}/mod/{modName}" },
    link: ({ path }) => <a href={path}></a>,
  }}
>

The link component would have a proper interface and more props though and the actual component can use a subset, for example, <a> might not use prefetch while Next.js will.

A suggestion from @MythicManiac is to instead have each link be a prop. For example, for the link from mod info to dependants mentioned in #43 (there might be unrelated props missing here like author):

<ModInfo
  community="ror2"
  mod="BepInExPack"
  dependencyLink={({ modName, community }) => (
    <a href={`/${community}/mod/${modName}/dependencies`}>{modName}</a>
  )}
/>

The actual path building could also be moved to avoid duplication. An advantage of this is it's easy to set the visible part of the link (here it's modName) but this could also be added to the context solution with the object. For example:

{
  paths: { modInfo: { path: "/{community}/mod/{modName}", content: "{modName}" } },
  link: ({ path, content }) => <a href={path}>{content}</a>,
}

Another thing to keep in mind is that it would be probably be simpler to migrate from the page props system to context than the other way around as you could first just use the context to get the props then over time slowly migrate over to not having it be a page component prop.

[nihaals]

The other project I was referring to was the Overwolf mod manager. It's still early stages for what will be included (in the next version) but that's out of scope for this issue