Allow for path based routes instead of query param based routes

[SlexAxton]

Is your feature request related to a problem? Please describe. I understand why the default router uses ?path=/foo in order to handle routing, I think this allows storybook to work in the most places without a hassle. However, it's not necessarily the most usable/aesthetic way to do routing. I'd love storybook to either support real routes, or routing hooks to allow me to implement this myself.

Describe the solution you'd like In the routing implementation now, routes are built by generating a path as ${currentLocation}?path=/some/path/here and then calling replaceState with this new path.

Solution 1

We can have a configuration option along the lines of "routeRewritingSupported": Boolean (which defaults to false).

We can document an nginx rewrite to support this setup. We'd also need to inject a <base href=…> in order to support loading of the static files (and or use a static file path prefix).

Solution 2

We can expose hooks into the routing functions in order to replace them with any implementation you'd like.

This would make implementing real paths a little more difficult, but would allow for additional remixes on urls for other purposes. I'd essentially implement Solution 1 using Solution 2 if we went that route (pun intended).

Describe alternatives you've considered I could just not care about routes as much, which is fair, but it seems good for a docs site.

Are you able to assist bring the feature to reality? I could implement this if folks agreed that it should exist.

Additional context

The nginx config for this rewrite stuff in my playground atm looks like:

location / {
  # root
  rewrite    ^/$ /index.html break;
  # paths (things that dont have dots)
  rewrite    ^/([^\.]+)$ /index.html?path=$1 break; # probably not necessary to expose the path but whatever
  # static files
  rewrite ^/(.*)$    /$1 break;
}

[ndelangen]

Hey Alex,

We want to, it's the reason why we have @storybook/router. So we can eventually implement this and roll-it-out with a flick of a switch in 1 place.

The reason we haven't yet, is because storybook currently supports hosting from the local file-system..

The problem is with 404 handling mostly.

---

If we take this step, we'd have to either:

• generate a html file for every story, for a static version of storybook This is actually easier to do now we have main.js, but is still hard. We have sb extract now but it requires puppeteer.
• we accept hosting storybook from the fs is no longer supported, or find some other method for redirecting back to the index.html

We just don't know what http-server solution someone will be hosting storybook with, and therefore we don't know how to configure the redirects.

What's your suggestion @SlexAxton ?

[SlexAxton]

I am actually using the output from build-storybook (i have an nginx proxy in front of s3), i think as long as it isn't required it seems like it's possible to add as a non-default option.

Essentially my suggestion is that you can opt-in to this behavior if you promise that you've implemented a server that does the right thing. (so it can be on by default in dev mode, and off by default in static generation mode)

[ndelangen]

I'd be fine with this being an opt-in!

[SlexAxton]

I’m still interested in contributing this code, stalebot.

[tobi1220]

Is there any update on this?

[ndelangen]

no, no updates so far.