New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: data: Split store implementation out from registry. #10289

Open
wants to merge 10 commits into
base: master
from

Conversation

Projects
None yet
8 participants
@coderkevin
Contributor

coderkevin commented Oct 2, 2018

Description

The goal of this PR is to split out the implementation of @wordpress/data store implementations to be separate from the registry, opening up the registry for alternative data implementations that can all share a common interface. The ethos behind this is to allow @worpdress/data to be a universal interface for data within Gutenberg and WordPress core, regardless of the implementation of the data system backing it. The common interface for data to be registered will be:

registry.registerGenericStore( key, { getSelectors, getActions, subscribe } );
  • getSelectors() will return an object of pre-bound named selector functions.
  • getActions() will return an object of pre-bound functions.
  • subscribe() will behave as a redux store subscribe.

How has this been tested?

All existing unit tests still run, and I added another test to verify expectations of registerGenericStore parameter types. No difference in operation should be perceptible.

Types of changes

This is a refactor of the registry, to remove the implicit store implementation from it.
All code and tests should still behave the same for @wordpress/data and the Gutenberg editor.

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 registerGenericStore

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
@notnownikki

This comment has been minimized.

Show comment
Hide comment
@notnownikki

notnownikki Oct 3, 2018

Member

How do I use resolvers with this new registration method?

Member

notnownikki commented Oct 3, 2018

How do I use resolvers with this new registration method?

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Oct 3, 2018

Contributor

@notnownikki It shouldn't change a lot once this is ready. This is basically adding a new register function but the existing one will remain, it will just use this newly introduced function under the hood.

Contributor

youknowriad commented Oct 3, 2018

@notnownikki It shouldn't change a lot once this is ready. This is basically adding a new register function but the existing one will remain, it will just use this newly introduced function under the hood.

@notnownikki

This comment has been minimized.

Show comment
Hide comment
@notnownikki

notnownikki Oct 3, 2018

Member

Oh thank goodness for that, resolvers are sweet sweet magic :)

Member

notnownikki commented Oct 3, 2018

Oh thank goodness for that, resolvers are sweet sweet magic :)

@coderkevin

This comment has been minimized.

Show comment
Hide comment
@coderkevin

coderkevin Oct 9, 2018

Contributor

@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.

Contributor

coderkevin commented Oct 9, 2018

@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.

@gziolo gziolo added this to the 4.1 milestone Oct 9, 2018

@gziolo gziolo requested review from aduth, youknowriad and gziolo Oct 9, 2018

@aduth

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 README.md anyways.

Show outdated Hide outdated packages/data/src/registry.js Outdated

@gziolo gziolo modified the milestones: 4.1, 4.2 Oct 15, 2018

@gziolo

This comment has been minimized.

Show comment
Hide comment
@gziolo

gziolo Oct 15, 2018

Member

I'm moving it to 4.2 as we decided that 4.1 should be UI freeze focused. 4.2 is planned to be focused on API freeze and this PR fits perfectly to that description :)

Member

gziolo commented Oct 15, 2018

I'm moving it to 4.2 as we decided that 4.1 should be UI freeze focused. 4.2 is planned to be focused on API freeze and this PR fits perfectly to that description :)

coderkevin added some commits Oct 2, 2018

data: Start split of registry with reducer
This splits out the implementation of `registerReducer` into a separate
file, with the intention of continuing the rest of the store
implementation. This will make room for other possible implementations
with a common interface.
data: Move registerSelectors and registerActions
This moves the implementation of registerSelectors and registerActions
to the namespace-store implementation file.
data: Untangle registerResolvers
This untangles registerResolvers, puts more code into the
namespace-store, and organizes the functions upon which it depends.
data: Centralize namespace registration
This commit centralizes the logic for namespace registration, in order
to support `registerStore` better.
`register[Reducer|Actions|Selectors|Resolvers]` now are viewed as
incomplete calls to `registerStore`
data: Add registerGenericStore
This adds the registerGenericStore function and removes the `namespaces`
object in favor of a more generic `stores` object.
data: Make registerGenericStore public + add tests
This makes `registry.registerGenericStore` accessible from the result of
`createRegistry`, and adds tests for the functionality of it.
data: Add registerGenericStore to readme
This adds information about `registerGenericStore` to the readme with
two examples.
@coderkevin

This comment has been minimized.

Show comment
Hide comment
@coderkevin

coderkevin Oct 17, 2018

Contributor

@youknowriad, @aduth, @gziolo, and others, I have updated the README and added tests for registerGenericStore. Feel free to take a look at both of those for example code of how this will be used. Please review and let me know if you have further questions. Thanks!

Contributor

coderkevin commented Oct 17, 2018

@youknowriad, @aduth, @gziolo, and others, I have updated the README and added tests for registerGenericStore. Feel free to take a look at both of those for example code of how this will be used. Please review and let me know if you have further questions. Thanks!

data: Export registerGenericStore from index
This adds an export for `registerGenericStore` for the defaultRegistry.
While the defaultRegistry may be going away in the future, it's here for
now, so this should be there until it changes.
Show resolved Hide resolved packages/data/README.md Outdated
Show resolved Hide resolved packages/data/README.md Outdated
Show resolved Hide resolved packages/data/README.md Outdated
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment