Empty routeParams cause

[borisyankov]

I have several routes.
They have their shouldComponentUpdate functions called, and the only thing that invalidates them is empty object routeParams (current and previous values are {}).

Am I doing something wrong?
Is there a way not to inject these?

If this is intended, wouldn't it be a good idea to always return the same empty object in getRouteParams.js (maybe overthinking it, if there is another way to solve)

[taion]

We could calculate all the route params up front. Alternatively, maybe we should modify how this prop works anyway. It's weird to recalculate it on render for each route.

[taion]

I don't think it's safe to use the same empty object – we'd be in a really weird position if someone were to modify that object. In general returning mutable const values from a library is not good practice.

I'm thinking we should probably just get rid of routeParams as currently set up for the next release.

It doesn't make a lot of sense to me to make everyone pay the tax per-route of calculating routeParams, when most routes don't actually use routeParams.

cc @reactjs/routing Thoughts?

[borisyankov]

@taion What about changing:

if (!route.path)
    return routeParams

to something like

// outside the function
const emptyObject = {}

// inside the function
if (!route.path)
    return emptyObject

And maybe the same object needs to be returned for when getParamNames(route.path) is []

[borisyankov]

Hmm, I realized what was your concern.
If someone mutates this empty object, then they will get the mutated object next time.

[taion]

I don't think there's much we can do about this in the current API. I would like to look into deprecating routeParams, though.

Any thoughts?

[timdorr]

Are they able to get around errors like { path: 'users/:id', children: [{ path: 'posts/:id' }] }? That would be the only reason I see for keeping them, though a pretty shitty reason nonetheless 😄

[taion]

@timdorr

It doesn't work for that though – right now routeParams is just the subset of params that match the param names in the current path, so in that case both the parent and the child path will see e.g. routeParams.id as [userId, postId].

Maybe we can fix this in matching, though.

[timdorr]

Eh, I don't really want to fix that. That is a user error/bad practice.

I say we drop routeParams. No real reason to maintain both it and params at the same time.

[taion]

Folded into #3611.