URLStore should be refactored and pluggable

[seanadkinson]

The URLStore is getting a little messy, with essentially switch statements in most of the methods, with functionality changing based on value of _location. This lends itself nicely to a refactor with separate implementations for each type. This would also allow for other implementations, such as an implementation that supports History.js.

[ryanflorence]

yessir!

[mjackson]

👍

[mjackson]

@seanadkinson Maybe we could reuse the <Routes location> prop.

<Routes location="hash"/> <!-- sugar for <Routes location={HashLocation}/> -->
<Routes location="history"/> <!-- sugar for <Routes location={HistoryLocation}/> -->
<Routes location={HistoryJsLocation}/>

What do you think?

[sophiebits]

I like that.

[seanadkinson]

Here's first pass: odysseyscience@bef9e19

This will add Router.locationsHandlers map, which can be added to by external code. The Routes.location prop just looks here for a mapped location handler. Wasn't sure if there was a more common way to expose mutable configuration for the world to plug in to.

Still need to look closer at the tests. One was failing that said you shouldn't be able to go back before the beginning of history, but according to MDN it isn't supposed to throw an error anyway, so that test may be invalid.

This "location handler" API will be really easy to plug History.js into, something like:

Router.locationHandlers.historyjs = require('HistoryJsLocationHandler')

And

<Router.Routes location="historyjs">

The refactor also made it easy to see some legacy code in URLStore that was intending to manage history in memory - perhaps just for testing?

Initial thoughts or suggestions?

[ryanflorence]

closing, follow #169