Relative <Link to>

[Robinfr]

Right now it seems that the Link component is always absolute. It would be nice that if the to URL does not start with a / that it becomes relative to the current route.

E.g. current route is: http://localhost/#/zoo/

<Link to="giraffe">Giraffe</Link>

Clicking on the link should bring me to http://localhost/#/zoo/giraffe/ instead of http://localhost/#/giraffe/

[mjackson]

Yes, I agree. This is a feature I'd love to support.

[knowbody]

I do like it, however I wouldn't make it a default Link behaviour.

Sometimes I just like that "I don't need to think" what path my component is at and I just use the absolute path (as it is now). But I do agree that it would be useful to support relative path.

[mjackson]

Ideally it would work just like <Route path>, IMO. If it's relative, the link is relative. If it's absolute, the link is absolute.

[knowbody]

oh yeah! I might work on that tomorrow

[jussi-kalliokoski]

👍 this would make routes easier to compose too without having to know where they're placed, e.g. order form with links to the different stages of it can be reused in multiple contexts:

• /orders/new contains navigation of its children
• /orders/new/contact-details
• /orders/new/billing-information
• /orders/new/confirmation
• /dashboard/orders/new
• /dashboard/orders/new/contact-details
• /dashboard/orders/new/billing-information
• /dashboard/orders/new/confirmation

can just be declared as (component: omitted for brevity):

// routes.js

const NewOrderForm = {
    path: "orders/new",
    childRoutes: [{
        path: "contact-details",
    }, {
        path: "billing-information",
    }, {
        path: "confirmation",
    }],
}

const DashBoard = {
    path: "dashboard",
    childRoutes: [
        NewOrderForm,
    ],
}

export default [{
    path: "/",
    childRoutes: [
        NewOrderForm,
        Dashboard,
    ],
}]

[jussi-kalliokoski]

FWIW, relative paths would also be handy on pushState/replaceState for symmetry (I'm using redux and some of my actions have redirects in them, so coming back to this order form thing, ORDER_CREATED redirects to a success page that's relative to the order form).

[mjackson]

relative paths would also be handy on pushState/replaceState for symmetry

I don't think I agree here. pushState and replaceState are an imperative API and can be called from practically anywhere. But <Link to> is a declarative API that should always render at the same URL.

[jussi-kalliokoski]

But is a declarative API that should always render at the same URL.

Ahh so would this actually make the links relative to route that they're declared in instead of the current route?

If not, while pushState and replaceState can be called from practically anywhere, that's still within a context (a browser window can only have one URL at a time), so I'm not sure I see the problem. It would be far more useful than the current behavior which treats relative URLs as absolute (which is worse than throwing an error, IMO).

[qimingweng]

In addition to relative Link redirects, something I do often is this:

/* replaceState would be history.replaceState or something similar, this just wraps it */
function addQuery(replaceState, path, query = {}, next = {}) {
  const nextQuery = assign({}, query, next);
  replaceState(null, path, nextQuery);
};

And I think the addition of new query keys could also be made easier. I originally mentioned this in #2226 but not sure if this issue might also cover it.

I agree that it's also useful to be able to wipe it clean, but I think it creates harder to maintain apps when I have to pass around location strings that are irrelevant to the rest of the logic but are required by replaceState

[taion]

Wouldn't you do something like

replaceState({query: {...query, ...next}, ...location})

?

[qimingweng]

@taion yes that looks nicer, but the caller still needs to know about the current query and location - I think maybe that shouldn't be necessary in all cases.

Not that I want to generalize too many components, but just that those components don't necessarily need to know their location for any other reason, so I find it extraneous.