match.params returns empty even when URL contains params

[goodbomb]

Hi, I'm in the process of upgrading to react-router 4 from v2. I'm not sure if this is a bug or not, but I'm having a really hard time getting my Header component to show the correct route params object. It doesn't seem like the match.params object is available globally like the params object was in react-router 2 and I'm not sure how to make it available to sibling components.

App.jsx (wrapped with ConnectedRouter)
-> contains Layout.jsx

const Layout = function(props) {
    return (
        <div className="layout" style={layout.base}>
            <Header inlineStyles={layout.header} params={props.match.params} />
            <Content inlineStyles={layout.content} />
            <Footer inlineStyles={layout.footer} />
        </div>
    );
};

Layout.propTypes = {
    match: PropTypes.object
};

export default Layout;

The Content component is where the bulk of my routes begin. When I try to access props.match inside of the Header component, I see this:

// Header.jsx
match: {
	isExact: false,
	params: {},
	path: "/",
	url: "/"
}

But when I access the props.match object from the nested component route, I get this:

// Content.jsx > Child > GrandChild
match: {
	isExact: true,
	params: {orgId: "1", projectId: "11", version: "1.0.0", modelId: "30"},
	path: "/orgs/:orgId/projects/:projectId/version/:version/models/:modelId",
	url: "/orgs/1/projects/11/version/1.0.0/models/30"
}

This is in the same render cycle.

1. Is it expected that the match object is not global to the entire router?
2. How do I access the same match object in my Header.jsx file as I have in my Content.jsx?

[pshrmn]

1. Yes. The match prop is <Route> relative (that is to say, inherited from the nearest parent <Route>)

// location = { pathname: '/album/123/song/456' }
// also, this is demonstrating the element tree, not the createElement statements
<BrowserRouter>
  {/* the root router creates an "empty" match, so match.params = {} */}
  <Route path='/album/:albumID' component={Album}>
    {/* match.params = { albumID: '123' } */}
    <Album>
      {/* match.path = '/album/:albumID' */}
      <Route path={`${match.path}/song/:songID`} component={Song}>
        {/* match.params = { albumID: '123', songID: '456' } */}
        <Song>

2. You would have to either
   a) change up the structure of your components so that you are matching routes at a root level and then render the <Header> and <Content> components based on the matched route
   b) have a second set of routes inside of your <Header> to figure out which route matches
   c) use some context "magic" to get route components to report their params.

I don't actually know what you need the params in your header for, so I can't really give a recommendation on which approach is "best", but it's probably either a or b.

Also, if you have any further usage questions, please use StackOverflow or Reactiflux since those communities are setup to answer questions. The issues section here is meant for bug reports.

[goodbomb]

Thanks for the response, @pshrmn. I have a custom Breadcrumb component that needs access to the global set of route params in order to render properly (swapping out the param numbers for their respective names). Having the params be relative is really counter-intuitive, especially since the location URL is available globally.

[Floriferous]

To me, it is not clear why you would ever Not include all params in the match object, I really do not see a use case where you would not want all params to be listed (opposite argument). Because as mentioned by @goodbomb, you can always read the location URL in full.

I could give you an example for my use case, it involves layouts at the root of the Router, with dynamic and "static-ish" content, that still needs to change based on the route currently viewed. (And I now have to write some URL parsing algorithm).

I would consider it a total anti-pattern to ever have two matching ids with the same name like /document/:docId/nested/:docId/nested2/:docId, where I can understand that you don't want them to be overridden. Adding a check for that in every path would do the trick.

I believe merging all match objects is the most intuitive way to go.

Edit: So for me, this is a bug, and is in the right place :)

[goodbomb]

Thanks @Floriferous, I agree completely. So should this issue be re-opened? Will the match objects be merged in a future release?

[SevenZark]

I also find it totally counter-intuitive that match would not always show this. And I need it because I'm using a container component around my routes to log page views to a database. I wound up doing it with the container because I could find no good place to do it anywhere in the page component itself (constructor would only log a page view the first time a page was loaded or reloaded from the server, and componentDidMount would log every time the page rerendered, giving, for example, three page view records when really the user only viewed the page once). But, with the container, I can do it on the initial load and then check for a pathname change on properties change, and it behaves exactly as I want that way.

What I'm left with is being forced to re-invent the wheel myself and write my own code to parse out the requested pathname in a rather clunky way that assumes certain segments are parameters, which both duplicates logic and opens up lots of great opportunities for bad page view data to be recorded.

[SevenZark]

@pshrmn Your response that this is an inappropriate place to post this suggests that user input requesting clarification on whether behavior is either expected or a bug, is unwelcome. It also seems to indicate being very closed to input on how things ought to behave, or what users of this library would like to see. I don't mean to be overly negative, especially because I love React Router and appreciate all the work on it. But this seems a little bit discouraging to the community of the library's users, and rather dismissive of user concerns.

[gunn4r]

I agree with @Floriferous, it seems counter intuitive that your params wouldn't be globally available. Would be very useful in a number of situations to have access to them.

[yornaath]

Yes the params are global in the browser, the url can be considered a global right? So i makes sense that it would be available in any withRouter component

[CaitlinWeb]

I also ran into this problem. My use case is exactly the same as goodbomb's, I have Breadcrumbs that are in the parent component with Routes as children, so it isn't getting the match I need.

Good to know this was intentional. I guess I'm not the only one who didn't pay close attention to the documentation:

A match object contains information about how a <Route path> matched the URL.

So I'm going to try matchPath within my Breadcrumbs component. Hope that helps others stumbling on this issue.

[matchPath] lets you use the same matching code that uses except outside of the normal render cycle

[McMainsLiam]

Thank you @CaitlinWeb for the matchPath suggestion, that's super helpful.

For anyone else running into this problem, this was my solution:

import { matchPath } from 'react-router'

const match = matchPath(this.props.history.location.pathname, {
          path: '/path/:param',
          exact: true,
          strict: false
        })

And then you can use the match object just like you would normally:

let parameter = match.params.param
// do what you will the the param

[himanshupathakpwd]

@spiritman110 very helpful, saved me from apocalypse

[Floriferous]

Thanks @spiritman110, didn't know that API was exposed!

It's still not an acceptable solution though, since you have to provide the path you want to match, when what's asked here is that any matched param just matches everywhere. This is really inconvenient if you want it to work anywhere in a remotely scaleable manner

I wrote this completely over the top HOC that includes @spiritman110 suggestion.

import { withRouter, matchPath } from 'react-router-dom';
import isArray from 'lodash/isArray';
import { compose, mapProps } from 'recompose';

// Lets you pass a param as a string, or an array of params, and you will get
// them as simple props from react-router, instead of drilling down
// match.params.paramName
export default (paramName, path) =>
  compose(
    withRouter,
    mapProps(({ match, history, location, ...rest }) => {
      let realMatch;
      if (path) {
        realMatch = matchPath(history.location.pathname, {
          path,
          exact: false,
          strict: false,
        });
      } else {
        realMatch = match;
      }

      if (!realMatch) {
        return { ...rest };
      }

      if (isArray(paramName)) {
        return paramName.reduce(
          (acc, param) => ({
            ...acc,
            [param]: realMatch.params[param],
          }),
          { ...rest },
        );
      }
      return { [paramName]: realMatch.params[paramName], ...rest };
    }),
  );

Here's how to use it:

const MyComponent = ({ userId }) => <div />;

// If under the Route, to avoid all the unnecessary prop drilling
export default withMatchParam('userId')(MyComponent);

// If outside a Route, as is the case in this thread
export default withMatchParam('userId', '/users/:userId')(MyComponent);

Assuming all the routes with the :userId matcher look like /user/userId23/whatever.

This issue should be revisited.