Typed path nodes skip renderPath in navigate() and redirect()

[everton-dgn]

I maintain an SSR app with canonical routes such as /about and public URLs such as /en/about and /pt/about. One router serves all requests. transformUrl handles matching, and history.utils.renderPath handles outgoing hrefs. With a prefix adapter, a typed node and its called form go to different places.

This example hard-codes the locale to en, on @solidjs/router 2.0.0-next.38:

import { browserHistory, createRouter, useNavigate } from "@solidjs/router";

const inner = browserHistory();

function About() {
  const navigate = useNavigate();
  return (
    <>
      <a href={Router.paths.other}>Link</a>
      <button onClick={() => navigate(Router.paths.other)}>Node</button>
      <button onClick={() => navigate(Router.paths.other())}>Called</button>
    </>
  );
}

const Router = createRouter({
  routes: [
    { path: "/about", component: About },
    { path: "/other", component: () => <p>Other</p> }
  ],
  history: {
    ...inner,
    utils: { ...inner.utils, renderPath: path => `/en${path}` }
  },
  scrollRestoration: true,
  transformUrl: path => path.replace(/^\/(en|pt)(?=\/|$)/, "") || "/"
});

export default Router;

Mount at /en/about and try each control from a fresh load. The link and Called button reach /en/other; Node reaches /other. Calling the node or using String(Router.paths.other) preserves the prefix in both navigate() and action redirects. Those forms also pass TypeScript checking.

navigate() deliberately reads the node's logical HREF value, while calling or stringifying it applies renderPath. Hash history handles its prefix in its parser and writer; this adapter inherits the browser history writer. The separate redirect() helper in @solidjs/web also reads HREF: a bare node loses the prefix at runtime. That call currently fails typechecking with TS2345, so I kept it out of the example.

Is bypassing renderPath the intended contract for typed nodes with adapters like this? The README shows bare nodes in navigation. A note there could explain when to call the node, or the adapter contract could make the two forms agree. That seems worth settling before adding a reverse transform, given #465. I'd keep useLocation() aligned with the browser URL, as discussed in #466.

A base resolved once per server request and once per client mount could be an alternative API. Unlike the reactive change in #64, it would stay fixed during navigation. It would need to preserve shared compilation and account for the base captured by paths. There is a separate bug to address first: with base: "/pt", both navigate(Router.paths.x) and navigate(Router.paths.x()) reach /pt/pt/x.

I tested these cases in Vitest/jsdom against dc1e0b0, with solid-js and @solidjs/web 2.0.0-rc.14. In concurrent SSR tests on one router, a renderPath reading getRequestEvent().request.url produced /en/about and /pt/about and kept the prefix in useLocation(). The example passes typechecking. Hydration and a request-scoped base implementation remain untested.