✨ Feature - Optional hash-based routing

[MattCheely]

Problem

Hash routing isn't popular in modern frameworks, but there are scenarios where it's quite useful, most notably when the desired (or only) hosting stack is a very simple one that only serves static files (e.g. github pages, S3, etc)

Solution

This PR creates a new config setting: app.options.useHashRouting that will cause the generated routing modules to parse the URL fragment as if it is the path, query and fragment. The url property on route objects still reflects the real browser URL, however.

Notes

This is currently still a work-in-progress, but I wanted to share the basic approach for feedback before I continue to polish it. There are a number of failing tests that need to be resolved, the example is not a useful example, and of course probably some code to clean up in a few places.

A brief overview of the changes:

A new HashRouting module is generated that provides the transformation from the browser URL to a Url value appropriate for hash-based routing. This gets it's own module because it ends up being referenced in several places:

• Route.Path, so that fromUrl matches against segments in the browser URL hash
• Route.Query, so that fromUrl matches against query-like strings in the URL hash
• Route, so that the generated Route' record's hash field is taken from the hash within the hash (yo dawg)

I initially considered updating just Route, but Route.Path.fromUrl is called directly by elm-land in several places, and is useful on it's own for users. IMO, it would be strange and confusing if Route.Path and Route.Query did something different from route when imported and used directly.

One alternate option might be to move it all into a single module, although I having the HashRouting module separate might have some value in documenting how to set up hash-triggered redirects in the event that an app wants to transition from hash routing to push-state routing.

Did I say this overview would be brief? 😅

[netlify]

✅ Deploy Preview for elm-land canceled.

Name	Link
🔨 Latest commit	a6aff8a
🔍 Latest deploy log	https://app.netlify.com/sites/elm-land/deploys/6358799db4939800095a5a25

[MattCheely]

I think that apart from the terrible example this is now in a spot that I'm happy enough with it to start getting feedback. Things I am particularly wondering are:

• Should there be an example at all? What should it look like?
• Is there a reasonable way to test this that doesn't involve writing E2E tests for the generated apps?

I had an idea for a silly Vite plugin/server trick where enabling hash routing would send a message to the browser Vite client and trigger an update to window.location to add/remove the hash so the app stays on the same logical page, but decided to table it in the interest of simplicity for now.

[ryan-haskell]

I'm going to merge this in, and take care of any changes that need to be made to get it working with the new Route.Path implementation – this will be released with v0.18.0 🚀

Thanks again, @MattCheely !