Proposal: non-blocking updates refactor

[eloytoro]

I do not intend for this PR to get merged, its just a proposal

Non-Blocking react-router

The main issue here is that in order to know the router state from a component this component must be either rendered using a <Route component={Component} or HoC'd withRouter(Component) and even then the component will probably not update itself when the route changes.

This happens because Route doesnt update itself when the history changes. Because of react-router's context re-definition strategy Route components will basically hide the history from Routes that are deep into the VDOM tree behind a virtual history layer thats defined by its parent.

I myself would much rather pay attention to the Router's history context because its global in a sense that I only care about what's in the user's browser address field, not what the current context allows me to see.

This approach would make it much easier to listen to history changes from each of the Routes, each one would be able to tell if it should update itself or not depending on the way the path matches the current history.location.

Here's a test case of what I'm trying to achieve (and the current implementation of react-router wont do)

  it('updates itself even when the match is different', () => {
    const node = document.createElement('div')

    let push
    let count = 0
    ReactDOM.render((
      <MemoryRouter initialEntries={[ '/sushi/california' ]}>
        <Route path="/sushi/:roll" render={({ history, match }) => {
          push = history.push
          count = count + 1
          return <div>{count}</div>
        }}/>
    </MemoryRouter>
    ), node)
    push('/sushi/dynamite')
    expect(node.innerHTML).toContain(2)
    push('/sushi/dynamite')
    expect(node.innerHTML).toContain(2)
    push('/sushi/dynamite/eat')
    expect(node.innerHTML).toContain(2)
    push('/sushi/california')
    expect(node.innerHTML).toContain(3)
  })

Notice that the component only re-renders when the match is different

[timdorr]

The inverse of this was already discussed in #4598.

Lots of details in there. But to re-hash Ryan's comments:

1. They are hard to understand
2. They don’t feel like React
3. They were causing lots of re-rendering on popstate that we’d have to start doing our own scheduling/batching to get around D: With every new nested Route you'd get another round of rendering.