Router Hash Options

[morpatr]

Long time users, first time post. Love the language! I didn't know where to put this and submitting an issue didn't feel right. I was wondering if it would be possible to allow using different styles of hash for the router. React Router, recognizes three different styles:

• "slash" - Creates hashes like #/ and #/sunshine/lollipops
• "noslash" - Creates hashes like # and #sunshine/lollipops (I believe this is Mint's current implementation)
• "hashbang" - Creates "ajax crawlable" (deprecated by Google) hashes like #!/ and #!/sunshine/lollipops

React Router defaults their hash type to the "slash" option, but allows users to pick one of the others if they want. My experience and Googling seem to indicate that the "slash" option is the most common. Maybe it would be possible in Mint to either default to the "slash" style or allow users to pass in the style of hash they want to use? Not sure how easy that would be to implement though.

Honestly, I bring this up because I think the "noslash" isn't very attractive. Neither is the "hashbang", which is quite an old way of doing hash routing. Being able to make prettier urls would be nice.

I've seen a few workarounds that involve capturing on the * route and parsing the hash manually, but doing so means you lose the params type safety that's built into the router in the normal usage, and adds a bit more work to extract the param.

Thanks for your consideration!

[gdotdesign]

Thanks for raising this issue here as a discussion 👍

I see two distinct ways of people using routing in Mint:

• applications which are served on the root of the domain, i.e. starting with a slash: /...
• applications which are served in a sub-page, something like this: /some/deep/nested/page/....

The --relative flag is not used in the first, but in the second, and the second is where people expecting the hash based routing to work.

A possible way of solving this could be to use the <base> element. It would work by setting its href to the hash-less path when the page is loaded, but I haven't fully explored this idea.

If that doesn't work, there are alternatives:

• maybe the behavior should be tied to the --relative flag (hash based if it's used)
• a new flag --hash-routing
• a new language construct

  hash-routes {
  }
  

• a modification of the routes top level block (routes could start with # instead of /):

  routes {
    #/ {
    }
  }
  

Also, we need to think about how the pages are served, for root domain applications the server needs to serve the index.html for every defined path.

Another aspect is when using the hash based routing, anchor jumping would cause unexpected behavior.

[morpatr]

Anchor jumping is definitely a problem for hash routing. Keeping Mint out of the anchor jumping business might be the best way to go when it comes to hash routing. You can read the nearly four year saga about anchors with React-Router and in the end the resolution was to use a separate package. There are ways that developers can implement anchor-like behavior, such as using the Element.scrollIntoView(). A disclosure in the user guide would probably be enough to let hash routing users know they need to handle anchors on their own.

My preference is to keep it as transparent as possible with minimal disruption to current users. With those two criteria, it would probably be best to leave --relative as it is and not introduce another flag for --hash-routing. To me the most transparent, least disruptive option would seem to be creating the new construct:

hash-routes {

     /#/home {
          Application.initializeWithPage(Page::Home)
     }

     /#/articles {
          Application.initializeWithPage(Page::Articles)
     }

     /#/articles/:slug ( slug : String ) {
          parallel {
               Application.initializeWithPage(Page::Article)
               Stores.Article.load(slug)
          }
     }

}

Looking forward to your thought on this.

[gdotdesign]

I'm closing this since it's an old discussion.