Split history syncing from action creators

[timdorr]

Big thanks to @gaearon for opening up this can of worms and writing a bunch of code to fix it!

Here's the history (pun intended) of what led to this:
#252 (comment) -> #255 -> #257 -> reduxjs/redux#1362 (PR)

A big giant chunk of this code is copypasta from Dan's work on that Redux PR. I just mashed some buttons until it looked right.

Changes

The provided action creators and middleware are now separate from the history<->state syncing function. For the vast majority of cases, using action creators to trigger navigation is obsoleted by React Router's new history singletons provided in 2.0. Building this functionality in by default and coupling it to our history syncing logic no longer makes sense.

We now sync by enhancing the history instance to listen for navigation events and dispatch those into the store. The enhanced history has its listen method overridden to respond to store changes, rather than directly to navigation events. When this history is provided to <Router>, the router will listen to it and receive these store changes. This means if we time travel with the store, the router will receive those store changes and update based on the location in the store, instead of what the browser says. Normal navigation events (hitting your browser back/forward buttons, telling a history singleton to push a location) flow through the history's listener like normal, so all the usual stuff works A-OK.

TODOs

• Add tests
• Update the documentation
• Find bugs/edge cases and fix them as best we can.
• Fix server side rendering

Fixes #193
Fixes #252

[gaearon]

Let's use spread here so we don't have to worry about polyfilling Object.assign(). Babel still doesn't replace this call automatically does it?

[timdorr]

It does. And Travis' version of Firefox (31) is old enough not to have Object.assign built in. So it doesn't really matter either way, but I will probably switch it to a spread. Haven't made it this far down in the file yet 😄

[gaearon]

Does it need some special flag?
http://babeljs.io/repl/#?experimental=false&evaluate=false&loose=false&spec=false&code=Object.assign(a%2C%20b)%0A%0A

[SimenB]

I think you need this

[gaearon]

Thank you very much for getting this moving! I might be able to find some time to contribute in the next week but this is already shaping up nicely 🙃

[ryanflorence]

👏

[webmasterkai]

Can someone confirm for me that this is just syncing state with rackt/history and the use of react-router is secondary? Any objections to me making a pull request against the synchronicity with the change suggestions above?

[gaearon]

Can someone confirm for me that this is just syncing state with rackt/history and the use of react-router is secondary?

This is correct. react-router in the library name is just for marketing purposes because that’s what people google for.

Any objections to me making a pull request against the synchronicity with the change suggestions above?

I’m pretty sure any contributions are welcome!

[webmasterkai]

Was it decided somewhere how defaultState based on current location should be set? This is something that was handled before that seems to be missing now. Having to manually do the following seems a bit inelegant.

const history = createHistory()
function initLocation() {
  let locationBeforeTransitions
  history.listen(loc => locationBeforeTransitions = loc)()
  return locationBeforeTransitions
}
const initialState = {
  routing: {
    locationBeforeTransitions: initLocation()
  }
}
const store = createStore(reducer, initialState)

Is it the job for a store enhancer?

Yes, it is set with an action on invocation of syncHistoryWithStore(). However, dispatching an action afterward feels like a hack when it's possible to set initialState correctly.

[romseguy]

Sorry for jumping in without reading the whole thread but I gave 4.0.0-beta.1 a spin along with RR2.0.0. I'm using SSR and accessing e.g /login is correctly matched and rendered on the server, but I am redirected to / shortly after. Accessing the route from view-source:http://localhost:3000/login here's the store's routing state I get from the server:

{
  "routing": {
    "locationBeforeTransitions": {
      "pathname": "\/",
      "search": "",
      "hash": "",
      "state": null,
      "action": "POP",
      "key": "0t38e1",
      "query": {

      },
      "$searchBase": {
        "search": "",
        "searchBase": ""
      }
    }
  }
}

I'm not familiar with the internals but I'd guess the store isn't synced with history state after /login is matched.

My (trimmed down) implementation:

// server.js
import { createMemoryHistory } from 'react-router'

const { store, syncedHistory } = createStoreWithHistory(createMemoryHistory())
const location = syncedHistory.createLocation(req.url)
match({routes, location}, (error, redirectLocation, routingProps) => {/* ... */})

// client.js
import { browserHistory } from 'react-router'

const { store, syncedHistory } = createStoreWithHistory(browserHistory, window.__data)

ReactDOM.render((
    <Provider store={store}>
      <Router history={syncedHistory}>
        {routes}
      </Router>
    </Provider>
  ),
  node
)

// createStoreWithHistory.js
import { syncHistoryWithStore } from 'react-router-redux'
import { createStore } from 'redux'

function createStoreWithHistory(history, initialState) {
  const store = createStore(reducer, initialState)
  return {store, syncedHistory: syncHistoryWithStore(history, store)}
}

[timdorr]

@SimenB I can look at IE8 compatibility and implement Redux's solution.

Yes, you can keep using the plain history singleton from React Router. The only difference between the two is the listen implementation, so push and the rest of it is the exact same function.

@romseguy I haven't done any SSR testing yet. But try this instead:

import { createMemoryHistory } from 'react-router'

const { store, syncedHistory } = createStoreWithHistory(createMemoryHistory())
match({routes, location: req.url, history: syncedHistory}, (error, redirectLocation, routingProps) => {/* ... */})

You definitely need to pass the enhanced history into match, otherwise it doesn't get used in the router.

[romseguy]

Same problem.

[svrcekmichal]

Having the same issue as @romseguy , created this issue #284

[timdorr]

@romseguy & @svrcekmichal This was fixed by properly seeding our memory history with the right path:

const memoryHistory = createMemoryHistory(req.path)

I'll have to check that our SSR docs on react-router are consistent.

[timdorr]

I haven't seen any serious issues come up, so I'm going to merge this into master. I've cut a 3.0.x branch and will leave that as default for a while until 4.0.0 goes final.

While there haven't been any changes to the code, I'm going to push an rc1 release shortly. Hopefully, that will signal to more people to give it a try. It works well! That should root out some further bugs and we can make this thing about as good as it can be.

[romseguy]

Thank you @timdorr and everyone else, works great now.

[transtone]

how to use it, is there a doc?