[email protected]
[email protected]
I have just upgrade from [email protected] to react-router && [email protected] 7 and after changing the breaking changes exactly to exact, Router to BrowserRouter, Match to Route and react-router to react-router-dom, all of the Routes match all the time.
Or better said, Route's that never matched and should never match do match.
An example is below:
I have 2 Routes:
exact pattern="/"exact pattern="/page/:pageID" If I go to http://localhost:3000/legal, both components render.
The code is run in create-react-app test, then npm i react-router-dom@next --save then replacing the content of App.js with:
```import React from 'react';
import {
BrowserRouter,
Route,
Switch
} from 'react-router-dom';
class Test extends React.Component {
render() {
return (
return null;
}} />
)
}
}
export default Test;
```
Nothing from the documentation page is helpful:
https://reacttraining.com/react-router/#route
Thanks!
Same for me... in my SSR application the initial route is rendered correctly by the server, but after this on the client, in interactive mode, I only see the initial route being matched.
This is my test setup. I worked in beta6, but is broken in beta7.
<Switch>
<Route exact path="/" component={() => { console.log("RENDER HOME"); return null }} />
<Route path="/about" component={() => { console.log("RENDER ABOUT"); return null }} />
<Route component={() => { console.log("RENDER 404"); return null }}/>
</Switch>
@eek path not pattern
@swernerx Cannot reproduce (codepen)
Okay that's definitely crazy. Any way to combine it with SSR in codepen?
@swernerx for what it's worth, I've been running into this issue as well. I can't for the life of me track down the change or error. SSR is surprisingly working just fine but I can't get a <BrowserRouter> to work with or without server rendering...
...though I'm thinking this isn't related to the <BrowserRouter> matching all.
@swernerx @cpeddecord Do either of you have a sample repo? The simplest way to debug would be to find the matchPath code in dev tools and add a breakpoint after the match has been calculated (here). The values that you are interested in are the pathname (the pathname of the current location), path (the pattern that you are attempting to match), and match (if this is not null, then the path matched the pathname).
nah, found it's related to https://github.com/ReactTraining/react-router/issues/4634. My app is laid out something like:
<BrowserRouter>
<connect(ApplicationShell)>
<Switch>
<Route>
<Switch>
<Route />
<Route />
</Switch>
</Route>
<Route />
</Switch>
</connect(ApplicationShell)>
</BrowserRouter>
@pshrmn finding that issue was a god-send, I've been debugging code for a few days now trying to track down what had happened, where this previous pattern had worked in the past.
Thanks for all the hints. I now reworked the codepen demo to show the issue we all seem to experience:
http://codepen.io/swernerx/pen/xqENXP
This stuff definitely worked in beta6 and should be pretty common usage.
You can fix it when you replace ConnectedDiv with PlainDiv.
Right now this bug breaks common HOC patterns as used by react-redux and react-intl.
@timdorr I would suggest for reopening the bug right now.
@swernerx React Router used to make attempts to get around shouldComponentUpdate blocks by using subscriptions. Long story short, they are terrible. They cause extra renders and make working with the context a pain.
You should pass the current location to connect so that the sCU call by the component that connect creates returns true. You can read some more about this in the blocked updates guide.
I understand where you are coming from. I even understand that you figure that subscriptions are terrible. I read the document you linked - thanks for the details mentioned there.
I still think we definitely have a major issue here. In larger applications we have quite a deep structure of components where deep inside there might be further usage of Route and NavLink. As far as I understand the document we have to pass the location to every instance which uses connect() (react-redux), injectIntl (react-intl), reduxForm (redux-form). This cannot really be the way we want to achieve good developer experience or just maintenance.
We don't know what HoC's you're using. If you have a bunch that you use commonly, I would set up a "meta-HoC" of sorts to apply them all together in one wrapper.
Most helpful comment
Same for me... in my SSR application the initial route is rendered correctly by the server, but after this on the client, in interactive mode, I only see the initial route being matched.
This is my test setup. I worked in beta6, but is broken in beta7.