Router does not ignore hash part

Is there a way to make the router ignore the hash part, if using /-based routes?

[japgolly]

FYI I haven’t read or responded to this yet, but I do plan to when I have time. Don’t want you to mistake my silence for dismissal. Thanks for your patience.

On Mon., 13 May 2019, 7:17 pm Akos Vandra, [e-mail] wrote:

My problem, and why I still feel that including the same thing (that ends up unused) in thirty routes is a hack because the application’s routing layer should not know or care about whether the rendered html contains a “scrolling link”, one with a fragment in it (whose handling is completely handled by the browser). Seems like an single-responsibility violation and also that’s a lot of code repetition.

If we follow this workaround - and I uphold my opinion on this - suddenly ** a basic change to the markup (adding a fragment link), that doesn’t even touch the JS/ScalaJS code will require changes to the router, and this is definitely something I’d like to avoid. **

Now don’t get me wrong, I’m a super-invested guy in strongly typing - and frown upon everything else - I guess that’s why we use scalajs instead of js, right?, but this has very little to do with type safety. I don’t see the connection between ignoring the fragment part, and the introduction of type safety issues. The fragment simply does not make part of the processed information (the same way the browsers widow size, or language settings are not part of the routing info - although I could imagine wanting to route the user to other routes based in that info - but in most cases it’s not needed). It is also not part of the caseClass, so why should the framework assume it to be empty then? If we want to make an assumption to the fragment part of the url - we need to make it part of the caseClass for sure. But if we don’t, it’s actually counter-intuitive that we are making assumptions on it.

Also according to the https://tools.ietf.org/html/rfc3986#section-3 http://RFC the fragment part of the url is not part of the path (or in RFC terms the hier-part), so remainingPath is a bit misleading, it should only match up to the start of the fragment, or the query params.

I understand that in some cases (like when people use fragment-based routing), the fragment must NOT be ignored, but in other cases (where people use real html5 path-level routing), it can be desired. So it should be a configuration option.

Having a caseClass without a parameter, and having it with an extra parameter that is never read (mind the difference between an optional field that is Some/None, and one that is NEVER read) contains exactly the same amount of information (actually if the compiler would be smart enough it could optimize it away). The principle of “something-that-contains-the-same-value” and “something-whose-value-is-only-written-and-never-read” carries NO information applies.

@japgolly https://github.com/japgolly what are you thougts on this?

So to solve this issue, I would consider something like this (although either a breaking change, or we need to find an alternative name for the remainingPath matcher). Note that this is just some raw brainstorming material here:

A router configuration parameter that allows partial matching the URL (ignoring the query or the fragment part, or both, or even the end of the path, but I’m not sure there is an actual use case for this)

• remainingUrl should match everything (the way remainingPath works right now)
• remainingPath should only match the path part of the url (the naive approach would suggest to match up to the first ? or #). To keep backward compatibility, we should probably come up with a new name for this, and deprecate remainingPath in favour of remaningUrl
• remainingFragment (should match the remaining fragment. Actually I’m not sure it’s implementation would be any different to remainingUrl, unless we can make sure that we are actually already in the fragment part)
• ignoreFragment (should be like ‘#’ ~ remainingFragment), but provide Unit - in case you only want to ignore it for a single route, or a few.
• remainingQuery should match the remaining query params, and probably provide a Map(String->String)
• possibly an ignore RouteMapper [is this a thing? ], that takes a RouteB[Any] and returns a RouteB[Unit] - this would allow to write things like / “stuff” / int / “bar” / uuid.option / remainingPath.ignore

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/japgolly/scalajs-react/issues/546#issuecomment-491744157, or mute the thread https://github.com/notifications/unsubscribe-auth/AABRRN7SB62ANNIY4BXCV6LPVEW3JANCNFSM4HLIKXNQ .

[axos88]

@japgolly ? Just hit this again. And the fun part is that an external srervice is redirecting to my SPA, and I may or may not get a query part, and the order of the query arguments changes from request to request…

In this case I’d like the ability to extract the query params, but I don’t care about their order… Accessing them from within the route is fine too though. (Possibly an initialStateFromProps, and access the data through ctl?)