Add context.route.location #4589

pshrmn · 2017-02-23T16:11:15Z

When a <Switch> or a <Route> has a location prop, its children should match using that location instead of the current history.location.

This also adds a modal example since the PR changes enable it and that seems to be a popular request.

timdorr · 2017-02-23T17:49:10Z

packages/react-router/modules/Route.js

+    if (!this.props.location) {
+      // Start listening here so we can <Redirect> on the initial render.
+      this.unlisten = parentRouter.listen(() => {
+        Object.assign(this.router, parentRouter, {


Why Object.assign? We support object spread (it's 8 lines above this 😄 )

Spread would create a new object.

this.router = { ...this.router, ...parentRouter, match: computeMatch(...) } // compiles to this.router = _extends({}, this.router, parentRouter, { match: computeMatch(...) });

@timdorr We mutate this.context.router intentionally.

Yep, I've got it now 👍

pshrmn · 2017-02-26T05:34:54Z

This can be simplified once #4598 is merged. Will hold off on updating this until then.

pshrmn · 2017-02-28T14:20:48Z

This has been updated to work with the new context API. context.route.location is the location used to render the parent.

Each <Route> will set this value in getChildContext. Typically, this will be the same as history.location. When a <Route> is given a location prop, this will be that object.

The <Switch> passes the location that it uses to match routes to the <Route> that it renders. This allows its children to know what location its parent <Route> was rendered "in" without having to have the <Switch> implement gCC

we can just use a Route to make a match, no need for special-case code

mjackson · 2017-03-01T00:31:16Z

Hey @pshrmn, I did my best to resolve conflicts with this branch and current v4. Please give it the thumbs up and I'll merge away.

pshrmn · 2017-03-01T01:50:00Z

There are a couple of tweaks that I think need to be made still. I will commit those later tonight. Was there ever any decision on whether to add context.route directly in <Router> or to have it render a <Route path='/' />?

The default `context.route.location` value is the same as `context.history.location`. However, if a <Route> has a `location` prop, then all of its children will see that location object as `context.route.location`. This also updates the `<Switch>` component to pass its location as a prop to the component that it renders.

When calling computeMatch from componentWillReceiveProps, we need to use nextContext, not this.context

pshrmn

Leaving a few comments on new changes.

pshrmn · 2017-03-01T05:18:10Z

packages/react-router-website/modules/components/FakeBrowser/index.js

@@ -61,7 +61,7 @@ class FakeBrowser extends React.Component {

    return (
      <MemoryRouter getUserConfirmation={getUserConfirmation}>
-        <Route render={({ canGo, goBack, goForward, push, location }) => (
+        <Route render={({ history, location }) => (


I had to fix a few things in the examples to get them working with the new { match, location, history } props.

pshrmn · 2017-03-01T05:19:17Z

packages/react-router/modules/Route.js

@@ -62,15 +63,15 @@ class Route extends React.Component {
    )

    this.setState({
-      match: this.computeMatch(nextProps)
+      match: this.computeMatch(nextProps, nextContext)


Need to use the next context object here. Otherwise when there is no location prop, the previous location will be used when computing the new match.

pshrmn · 2017-03-01T05:20:43Z

packages/react-router/modules/Route.js

-    const { history } = this.context
-    const { location } = history
+    const { history, route } = this.context
+    const location = this.props.location || route.location


Just making sure that the component rendered by the route receives the correct location.

mjackson · 2017-03-02T17:40:28Z

@pshrmn We're going to add context.route directly in <Router> instead of rendering a root <Route>. I think this will make it easier for folks to understand using the DevTools.

pshrmn · 2017-03-02T18:04:25Z

@mjackson Yes, I saw that you switched it back shortly after I had asked the question. This should be good to merge if everything looks fine to you.

mjackson · 2017-03-03T06:27:14Z

Thanks @pshrmn

timdorr reviewed Feb 23, 2017

View reviewed changes

pshrmn mentioned this pull request Feb 23, 2017

V4 Modals #4584

Closed

pshrmn force-pushed the pass-props branch from b77dc35 to df3bf90 Compare February 24, 2017 20:32

pshrmn mentioned this pull request Feb 24, 2017

remove subscriptions #4598

Closed

pshrmn force-pushed the pass-props branch from df3bf90 to dbf75ee Compare February 28, 2017 06:18

pshrmn changed the title ~~Prefer prop location over parent location~~ Add context.route.location Feb 28, 2017

pshrmn referenced this pull request Feb 28, 2017

get root context.route tests passing again

361e1b5

we can just use a Route to make a match, no need for special-case code

pshrmn added 5 commits February 28, 2017 22:22

Add a modal example

c921cb0

Pass correct location to Route's rendered component

adf11fd

pass context to Route's computeMatch

9ace1c5

When calling computeMatch from componentWillReceiveProps, we need to use nextContext, not this.context

Fix websites example to work with new Route prop signature

b2d946c

pshrmn force-pushed the pass-props branch from 94e3011 to b2d946c Compare March 1, 2017 05:16

pshrmn commented Mar 1, 2017

View reviewed changes

mjackson merged commit b9be9a9 into remix-run:v4 Mar 3, 2017

pshrmn deleted the pass-props branch March 3, 2017 07:36

agundermann mentioned this pull request Mar 28, 2017

Use <Route location> in react-router-config example #4858

Merged

lock bot locked as resolved and limited conversation to collaborators Jan 18, 2019

Uh oh!

Add context.route.location #4589

Add context.route.location #4589

Uh oh!

Conversation

pshrmn commented Feb 23, 2017

Uh oh!

timdorr Feb 23, 2017

Choose a reason for hiding this comment

Uh oh!

pshrmn Feb 23, 2017

Choose a reason for hiding this comment

Uh oh!

mjackson Feb 24, 2017

Choose a reason for hiding this comment

Uh oh!

timdorr Feb 25, 2017

Choose a reason for hiding this comment

Uh oh!

pshrmn commented Feb 26, 2017

Uh oh!

pshrmn commented Feb 28, 2017

Uh oh!

mjackson commented Mar 1, 2017

Uh oh!

pshrmn commented Mar 1, 2017

Uh oh!

pshrmn left a comment

Choose a reason for hiding this comment

Uh oh!

pshrmn Mar 1, 2017

Choose a reason for hiding this comment

Uh oh!

pshrmn Mar 1, 2017

Choose a reason for hiding this comment

Uh oh!

pshrmn Mar 1, 2017

Choose a reason for hiding this comment

Uh oh!

mjackson commented Mar 2, 2017

Uh oh!

pshrmn commented Mar 2, 2017

Uh oh!

mjackson commented Mar 3, 2017

Uh oh!

Uh oh!