Summary

A "fragment" is the HTML spec's name for the part of the URL after a # symbol:

https://redwoodjs.com/docs/deploy/baremetal#server-setup
                                            ^^^^^^^^^^^^  <- fragment

The default browser behavior is to scroll down to the first element in the DOM that has an id attribute matching that fragment:

<div id="server-setup">
  <!-- ... -->
</div>

Right now there's no way, using the standard routes helper functions, to construct a URL that includes a fragment. A workaround is to append it to the generated path:

<Link to={`${routes.post({ id: 123 })}#comments`}>See Comments</Link>

Motivation

Fragments are a standard part of URLs and part of the HTML spec, and we should be able to create those URLs using our recommended tools (the routes helpers). It's very common to want to redirect somewhere else and jump to a certain section of the page.

Note that depending on how the page is build, the required DOM element may not be present on the page, and so the browser will not actually be able to scroll down to it. I would like to support this behavior as well, but this Issue is specifically just about being able to create the URL.

Detailed proposal

I propose adding support for a fragment key to the named routes helpers, in some form or another. One possibility is:

routes.post({ id: 123, fragment: 'comments' })

This means that you could no longer create a query string variable named fragment, which would make this change backwards incompatible for anyone that was already using that name. (Today, if you wrote the above code, you'd get the path /post/123?fragment=comments

I'd also be open to prefixing this key with something, such as an underscore like _fragment, which indicates that it has special significance as far as Redwood is concerned. My only concern is that informally in the JS community, prefixing something with an underscore denotes it as "private" functionality that the end user generally shouldn't mess with.

Another option would be to have these helpers accept a second, optional argument:

routes.post({ id: 123}, { fragment: 'comments' })

This would be completely new functionality and thus not break existing route generation.

For what it's worth, in the Rails helpers this key is named anchor and that's just the way it is: you can't use anchor for a query string variable and it's fine.

It's possible we could use fragment but provide a codemod that searches through your codebase for any usage of routes.something({ fragment: '' }) and give you a warning? It would be nice to just pick something and go for it, rather than wring our hands that maybe someone used that word, and make the UX worse for everyone else for all time.

Are you interested in working on this?

• I'm interested in working on this