Request State provision implementation

Currently, Provider serves as the central point of all request states. stateProvider and default state converge at Provider component which would often be implemented at the root of user's app. Provider uses React Context to provide updates to all Request and Requests via withRequestSelector and withRequest.

withRequestSelector renamed to withSingleRequest

Although it works great, on a second thought, it could have a better architecture. The main issue is updates on the context tree can have bad performance. Refer this. Provider only re-renders context tree only if there is an update to a request state in store/cache but a lot of updates can leave app lagging. For instance using Request with maps and location popovers which can be in thousands.

Instead of the current implementation,

the default state provider (React.Component.state) should be ignored and a new external default light-weighted state provider should be in its place.
stateProvider should be passed down the Context tree instead of request states.
withRequest and withSingleRequest should be the new managers of request states via stateProvider

Any plugged-in stateProvider will be passed down via Context but the tree is never going get re-rendered (right from Provider mount to exit) since the stateProvider will never be changed. This will keep the Context tree static hypothetically.

With this, withRequest and withSingleRequest will be the new convergence point of all request states and only request states in context. That means update to a request state would only affect nodes of Request subscribing to that particular request state id and not the whole context tree. This is a performance improvement as a matter of fact.

Also multi-store cache like mobx can be seamlessly integrated since every Request node can have its own subscription of its store (stateProvider) optionally passed via withRequest or withSingleRequest.

orar / questrar

Request State provision implementation #16