Right now, to implement a redirect fallback in a switch, you need to do
<Switch>
<Route path="/foo" component={Bar}/>
<Route path="/bar" component={Baz}/>
<Route render={() => <Redirect to="/foo"/>}/>
</Switch>
How about checking for the to parameter in the Switch loop and matching directly:
<Switch>
<Route path="/foo" component={Bar}/>
<Route path="/bar" component={Baz}/>
<Redirect to="/foo"/>
</Switch>
An interesting idea. However, I'm not sure it would have the intended consequence. To me, it looks like the Redirect is either misplaced or will always be performed, regardless of the Switch's match. The Route with a render prop is more verbose, but definitely clearer about what's going to happen here.
So, to me, it's harder to see at a glance that the last <Route/> does not have a path and will always match. I read the second version as "Oh, a switch, that only renders the first match... looks like
You could do this if the undefined path is not clear:
const createRedirect = to => () => <Redirect to={to} />
// ...
<Route path="/*" component={createRedirect('/foo')} />
A bit sugary to my taste, with runtime cycles and memory going to devel time enjoyment…
I like it. Maybe in this case <Redirect> could also take a from prop (like we did in previous versions) so you could use a few of them in a <Switch>.
<Switch>
<Route exact path="/home" .../>
// Simple <Redirect>
<Route path="/about" .../>
<Redirect from="/company" to="/about"/>
// <Redirect> with dynamic URL segments
<Route path="/users/:userId" .../>
<Redirect from="/profile/:userId" to="/users/:userId"/>
// A <Redirect> without a "from" prop always matches. Same as a <Route> with no "path".
<Redirect to="/home"/>
</Switch>
@mjackson turns out that was remarkably easy to do - just make from an alias for path
@wmertens Feels like validation that we're on the right track! :D
@wmertens Feels like validation that we're on the right track! :D
Definitely, I love the new API! I was pretty annoyed with the previous RR versions, but now, I'm a fan! 💯 (especially with the upcoming relative path support, leading to true componentization)
What do you think of:
<Switch>
<Route exact path="/home" .../>
<Route path="/about" .../>
// redirectTo prop has lower precedence than component and render props
<Route path="/company" redirectTo="/about"/>
<Route path="/users/:userId" .../>
<Route path="/profile/:userId" redirectTo="/users/:userId" redirectPush/> // redirectPush boolean
<Route path="/profile/:userId" redirectPushTo="/users/:userId" /> // another way to do push
// always matches
<Route redirectTo="/home"/>
</Switch>
PS: What's the use-case for redirect with push?
@hamzakubba <Redirect push> pushes a new location onto the the history stack whereas the default <Redirect> replaces the current location.
@pshrmn I know, I meant why would anyone want to do that? I was curious why it was implemented on the Redirect component in the first place.
@hamzakubba I like the <Redirect> component better than overloading <Route>'s props.
Is this supported now? I thought it was but couldn't get it to work - went with <Route component={NoMatch} /> isntead
Most helpful comment
I like it. Maybe in this case
<Redirect>could also take afromprop (like we did in previous versions) so you could use a few of them in a<Switch>.