-
-
Notifications
You must be signed in to change notification settings - Fork 407
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support navigating to hash URLs for in-page navigation #709
Comments
How would this play together with location type |
I like this proposal! Perhaps because I've proposed something similar earlier: 😄
We should think about what other use-cases there are. For example encoding open modals, scroll position, etc. As mentioned in my quoted issue above, there is some precedent in CSS @jelhan For location type hash we could split the hash on some character, e.g. |
location type |
I think a first iteration on that feature should add support for URL fragments in general. This would enable different use cases. Scrolling to an anchor after transition would be one of them. Persisting state, which should not be sent to the server in the URL, would be another. To support URLs fragments, I think the following changes are needed:
Open questions:
|
Sounds good! I think we should swap This also avoids the naming overload we'd have with the |
Naming is very difficult here in my opinion. I used
I fully agree that it is confusing if <LinkTo @query={{hash sortBy="title"}} @hash="person-13"> It doesn't get easier as existing argument for setting query parameters does not follow naming in I would tend to follow the |
oh no. even the URL docs are contradictory! 🙃 yeah, following URL interface is probs best |
There doesn't seem to be any character, which is allowed in a fragment but is not allowed in a path or query component of a URI. 😢 Accordingly to RFC 3986: Uniform Resource Identifier (URI): Generic Syntax a fragment may contain the following characters:
That's exactly the same as for query component of an URI:
And a subset of which is allowed in path component of an URI:
|
I think it would be fine to split on an uncommon character, such as |
This would be a great feature. Is there an actual path to RFC here? |
potentially. 🤔 the least hacky thing we'd need for this is to have some for he framework to let us know that rendering after a transition has "settled" (even keeping in mind that pages could spin up intervals and all that, which keep us from normal settled state) The re-working of the routing layer may be a prereq for this tho, as the existing routing layer is opt-in to everything, which is kind of annoying to work with (QPs, no hashes at all, etc). We'd have to add in hash support to RouteInfo, etc, where keeping that information should just be default. |
I wonder if the new Polaris router ideas would resolve this. |
I saw this comment in another thread:
|
@sandstrom I was just on a core team meeting where the router stuff was being discussed. We want to be clear that active progress is being made here and very soon we should have some more public information and be able to help rope the community in a bit more! |
@wagenet did things ever get to a place where you could share more publicly? |
if supported, maybe hash / anchor / id navigation would look like this in user-land:
(and then letting the actual router (router_js) handle
#
navigations. atm, the navigation look like:It just drops the hash
The text was updated successfully, but these errors were encountered: