Allow <Link to> to be a function

[taion]

Maybe a little QoL, thing... it'd let people do e.g.

<Link to={location => ({ ...location, query: newQuery })>

without having to worry about having location on context or wrapping the <Link>'s parent with withRouter.

[avocadowastaken]

This is really good feature! But what about push and replace?

[smashercosmo]

This is awesome

[smashercosmo]

I would like to propose also a possibility to provide a function to set isActive flag. Something like

<Link to="/hello" isActive={location => location.pathname === '/hello'} activeClassName="active">

[smashercosmo]

@jodo4x Where do you get pathname from?

[smashercosmo]

@jodo4x yes, but if your component is deeply nested you need to pass location through the components tree.

Well this issue is not suited for this discussion. I'll open a separate one.

[timdorr]

Added in #3669

[taion]

Hmm, I wonder if these functions should take e.g. { location, params } instead of just location as the arg.

[eldh]

I think { location, params } would be great.

[taion]

@eldh Thanks for your feedback! How would you use params? Would it be to essentially build a relative link?

[taion]

The reason I ask is because I can think of a few places where I could use params, but in all those it's only to work around the lack of relative links. I don't want to complicate the API here just to work around a missing feature elsewhere – would rather add that missing feature.

[eldh]

Yeah, that would be a common case. We have some places where we do filtering in such a way that it would be a nice addition. Not sure, maybe relative links could solve that too.

[taion]

@eldh Can you clarify regarding the filtering use case a bit? Just trying to understand use cases here.

I'm really torn here because (location: Location) => LocationDescriptor just feels like a cleaner and more symmetric API, and lets the user be a bit terser when writing things like

({ query, ...location }) => ({ ...location, query: { ...query, new: 'query' } })

but I don't want to rule out real use cases.

[eldh]

We have some cases where params are part of a (known) set, and to calculate filter options we'd need access to the params.

However, I'm not even sure that this api would be the cleanest way to solve that case though. And I suspect we aren't using react-router idiomatically anyway, so feel free to disregard my comments :)

[taion]

Okay, I think I'll go with (location: Location) => LocationDescriptor API for now and reserve the option to change it before cutting a final release. Thanks for your feedback!