Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
WIP: data: Split store implementation out from registry. #10289
The goal of this PR is to split out the implementation of
How has this been tested?
All existing unit tests still run, and I added another test to verify expectations of
Types of changes
This is a refactor of the registry, to remove the implicit store implementation from it.
After the initial interface here is settled, I plan on creating at least one example PR in another repo to validate the operation of using another implementation via
@youknowriad, @aduth, @gziolo, and others, I think this PR is ready for reviewing. There are other things I'd like to do, like deprecating some functions and the plugin mechanism, then making store configs immutable when added (except to store state, of course), which would simplify things further, but that will take more work to untangle.
I'm satisfied with this as a first step into separating out the interfaces from the implementation, and it should allow alternative stores to be implemented.
getSelectors()will return an object of pre-bound named selector functions.
getActions()will return an object of pre-bound functions.
To one who is creating a non-Redux-based store, what does "pre-bound" mean to them?
To this and my earlier comment, I'm curious what a minimal example of a custom store might look like. This seems like a good thing to include in