Sync state with URL (Share function)

[mreishus]

Obviously there is great demand for this function since there are 3 unmerged PRs with this.

I took the ideas for #107 and

• pushed out the responsibility for each reducer to determine how it will serialize and serialize.
• Allowed for partial state updates: Each reducer can choose to only url serialize some important keys.

Note, I did use the same centralized workaround for selecting state.request.endpoint on initial load - since that is too big to store in a URL. I couldn't figure out how to push this to one reducer.

This one is pretty verbose, with lots of comments and some long variable names, but I wanted to make it easy to understand.. although sometimes I realize being too verbose can have the opposite effect.

[mreishus]

We're trying to fit all the URL parameters into the different parts of the request, but it really feels like what we're doing is not mangling app state, but performing a new semantic action not currently defined in the app: something like LOAD_REQUEST or SET_REQUEST. If we create that then I think much of the logic in this PR would disappear.

So I wonder if we could start small by creating that new action, that new semantic intent. That would let us do interesting things we currently can't, such as set a request from the console with a JSON body representing the request. That action could fit in with any other necessary work required to handle app loading, and in fact, maybe adding state-tracking for isFetchingEndpoints would be a preparatory PR that enhanced the UI while paving the way for SET_REQUEST.

I can imagine a LOAD_REQUEST - basically, it's the same as DESERIALIZE_URL in this PR, except perhaps the serialized information is coming from a field on the action instead of the previous state. However, what's the other half of this? How will we take the current state and serialize it into something that can be loaded into LOAD_REQUEST in a generalized way?

[dmsnell]

How will we take the current state and serialize it into something that can be loaded into LOAD_REQUEST in a generalized way?

This sounds like making a new selector and doing largely the same thing you did here, but maybe instead of serializing into a URL we could start by codifying the properties in a JSON payload that could be used on LOAD_REQUEST.