Support hashed routes

[spapas]

Hello, could you also support hashed routes beyond pathname routes? For example, instead of writing http://example.com/detail/ I'd prefer to write http://example.com/#/detail to go to the detail view. This is important for easier integration of hyperapp with existing applications since with pathnames the web server must be configured to pass everything to the main page. Also it greately helps with testing.

From a quick glance at the source code of PR #6 it's rather easy, just use location.hash.substring(1) instead of location.pathname. This can be configured with a parameter in the Router function.

TIA

[jorgebucaran]

@spapas I just published 0.4.1; it works with [email protected]. Now we need to figure out how to integrate a hash-based solution to the new arch.

[leavehouse]

In case anyone is interested in this as a stopgap solution, I have hacked together a hash-router based on 0.4.1 for an app I'm writing: https://github.com/leavehouse/hyperapp-hash-router (diff). It has no Redirect, but Route and Link are working fine (Switch may work, but I haven't tested)

[zaceno]

I think it's probably better to have a hash-based router as it's own package, rather than to add hash-route-support to the official router. Yes, there's tree-shaking, but since you won't ever want to use both types of routers together (?) there's really no reason to even have them in the same package. A separate hash-based router wouldn't even have to be an official @hyperapp/hashrouter, as long as it (they) are discoverable somewhere (like on the awesome-list, for example)

[spapas]

@zaceno yes this is definitely a possible solution. However at least for me, including the hashed router in this repo and switching between the hashed and non-hashed using a switch is the preferrable solution, especially if the changes are minor (like for example in @leavehouse's solution diff https://github.com/leavehouse/hyperapp-hash-router/commit/7bc45366d2955c261522078714dcf68b0e02584d).

Keeping everything on the same package is better for maintenance, DRYness and ease of use. If you have many packages for the same (or nearly the same purpose) some of them may fall behind (because for example the repository owner doesn't have time, or disagrees with some API changes etc) and also any required changes would need to be applied to two repositories. Also, a user that installs hyperapp/router will immediately see (in the README) what he needs to do to get the hashed routes.

[zaceno]

@spapas

especially if the changes are minor

You can support hashes with quite a minor diff, sure. But a router that supports only hash-based routes can get away with being a lot slimmer (since you can just ignore all the pushState stuff, Link component is not necessary et c)

If you really have an app where you want to alternate between hash-routes and history-api, then I can see how you'd want a router-package to support both. That sounds like a quite unusual use case, though.

[spapas]

I agree that hashed and normal routes won't be used in the same app. But the problems with DRYness and poor maintainability remain.

In any case, using an extra hashed-routers package is not a problem for me and will definitely resolve this issue! Thanks!

[zaceno]

But the problems with DRYness and poor maintainability remain.

Well the point I was making was mainly that a minimal hash-router implementation and a minimal history-api-router implementation will be quite different. Basically the only duplicated code would be the route parameter/matching. (Still, that's some duplication, so I see your point)

But anyhow, that's just my theory, I don't know for sure. (I should try it out first before talking, I guess 😅 )

[Siilwyn]

An option to use hashes instead would be very useful for Electron apps too, at the moment this router isn't compatible with Electron.

[brandonros]

I'm confused... What is the purpose of this package, if it doesn't support hashes?

How are you guys setting up your servers to server the same proverbial index.html when people try to hit routes other than / on your servers?...

[spapas]

Well the trend right now (which I don't like) is to have normal routes (w/o hashes) even on SPAs.

You probably could do some fancy configuration on your http server to achive this but it is much easier with a framework like django or flaskh : Add a catch-all route https://stackoverflow.com/questions/6545741/django-catch-all-url-without-breaking-append-slash#10199446 or http://flask.pocoo.org/snippets/57/

One comment I'd like to make about that trend is that we started 20 years ago with urls being different files on the server (static html, php, jsp etc), we then, with the rise of the server side web framework, did the URL routing on the server side depending on the database rows and now we want to move everything to the client side! Signs of the times ...

[Siilwyn]

@brandonros I think actual routes are way better than hashes since the history API exists it is good to use them. However in edge-cases (such as an Electron app) hashes are needed.

Regarding server setup that is straightforward, as you said always serve the same HTML page, using rewrites. Two configuration examples:

Nginx:

location / {
    try_files /base.html =404;
}

Caddy:

rewrite {
    to {path} {path}/ /index.html
}

[maxbaluev]

At electron we can use hyperapp-hash-router