Colocating docusaurus with app and internal urls

[nickbabcock]

Similar to a previous discussion, I have an app with the following routes:

/
├── /account
├── /api
# ...
├── /blog
├── /changelog
├── /docs

Moving blog, docs, and other content heavy pages (like changelog) to docusaurus are clear wins. However, the actual deployment has gone awry as the "back to app" navbar item (href of /) doesn't cause the user to be navigated there. Same thing if the /account route is mentioned in a blog article.

As alluded to in previous discussions, the cause of the problem is that docusaurus thinks it owns these URLs and wants to handle routing instead of doing a full-page navigation.

Is there a way (or does it make sense as a feature) to communicate to docusaurus the following URL paths are outside of its domain?

Or is the only solution to prepend the url to all hrefs and write markdown like:

Go to your <a href={`${useDocusaurusContext().siteConfig.url}/account`}>account page</a>

Or is the recommendation to split docusaurus into two. Have a blog only instance with a base url of /blog and move the changelog under a docs only instance with a base url of /docs. Then update each routeBasePath accordingly. I don't relish the thought of maintaining two separate docusaurus installs and keeping them in sync.

Or is there a baseUrl that makes sense to have everything hosted under? The best one I've come up with is /content, so it's /content/blog, /content/docs/, /content/changelog. This doesn't solve the markdown issue (as /account will be emitted as /content/account). And I'd need to set up the redirects from the current pages.

[slorber]

You can use the pathname:// protocol to link to things that are outside the SPA and yet are non fully qualified URLs.

https://docusaurus.io/docs/advanced/routing#escaping-from-spa-redirects

Where did you look for this info in our doc? Maybe we could document this as well in that place? You are not alone looking for this info so our current doc may be not good enough for discoverability

[nickbabcock]

Thank you, using pathname:/// is working. I'm embarrassed that I missed this documentation. But I think you are right that there may be potential for some doc improvements.

For the app link in the navbar, I consulted the Navbar link. The wording around to and href fields could be shored up, as href doesn't guarantee a full page navigation, and to doesn't guarantee client-side routing.

The below example has to being used, but a full page navigation is still executed. As a new docusaurus user, the line between these two fields seem blurred.

{
  to: "pathname:///",
  label: "back to app",
}

More importantly, this could be a good opportunity to call out pathname:/// or link to the routing docs section. If I would have saw that, I think I could have extrapolated that to markdown and not posted this question.

For markdown specifically, it would have been nice to see a pathname:/// example in the Markdown links section, as this protocol looks to be a unique feature of how docusaurus processes markdown, so probably worth a call out.

[slorber]

Thanks, will keep this in mind for updating the docs :)