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

wp.data Overview #8354

Open
mtias opened this Issue Aug 1, 2018 · 5 comments

Comments

Projects
None yet
5 participants
@mtias
Contributor

mtias commented Aug 1, 2018

This issue seeks to organize pending work and improvements around the wp.data module.

Tasks

  • Adding support for sync generators to allow async action creators. #7546, #8096
  • Add support for Core Data Entities Actions. #7175
  • Adding and updating entities. #10089
  • Add support for action creators as generators. #6999, #8096
  • Write documentation / examples.

Blocks

  • Update all blocks to not have direct API calls.

@gziolo gziolo added this to To Do in API freeze via automation Aug 2, 2018

@gziolo gziolo removed this from To Do in API freeze Aug 13, 2018

@gziolo

This comment has been minimized.

Show comment
Hide comment
@gziolo

gziolo Aug 13, 2018

Member

There are no breaking changes planned, removing from API freeze.

Member

gziolo commented Aug 13, 2018

There are no breaking changes planned, removing from API freeze.

@gziolo

This comment has been minimized.

Show comment
Hide comment
@gziolo

gziolo Aug 13, 2018

Member

I opened #8911 which explicitly imports @wordpress/core-data for packages which call select( 'core' ).*.

I also noticed the following when looking at the implementation of core-data:

  • isPreviewEmbedFallback, getEmbedPreview are used only with embeds block
  • getThemeSupports is used with editor package
  • getAuthors - referenced only in editor
  • getUserQueryResults - should be internal as it is used only in getAuthors...
  • everything else is entity based
  • it's not possible to customize entities, we use defaultEntities and kinds as provided by core

The general question is, what should be the strategy for including stores in a given package. In other words, how do we want to ensure that each package works out of the box with all the selectors and action it has listed in the codebase.

Member

gziolo commented Aug 13, 2018

I opened #8911 which explicitly imports @wordpress/core-data for packages which call select( 'core' ).*.

I also noticed the following when looking at the implementation of core-data:

  • isPreviewEmbedFallback, getEmbedPreview are used only with embeds block
  • getThemeSupports is used with editor package
  • getAuthors - referenced only in editor
  • getUserQueryResults - should be internal as it is used only in getAuthors...
  • everything else is entity based
  • it's not possible to customize entities, we use defaultEntities and kinds as provided by core

The general question is, what should be the strategy for including stores in a given package. In other words, how do we want to ensure that each package works out of the box with all the selectors and action it has listed in the codebase.

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Aug 13, 2018

Contributor

The original purpose oof core-data is a data abstraction for WordPress which includes all the data available via REST API (exclusing plugins data):

  • Posts
  • Users
  • Taxonomies
  • Media
  • Embed Proxy Endpoint
  • Settings (theme supports)

So I think these make sense there.

Extending entities:

  • I'm not certain yet we should make the entities extensible or instead provide helpers to build entities in other data packages. (for example woo/data)

The general question is, what should be the strategy for including stores in a given package. In other words, how do we want to ensure that each package works out of the box with all the selectors and action it has listed in the codebase.

I think explicitness (adding import '@wordpress/core-data' etc...) should be favored but there's an open question about how to detect/automate those. (Maybe an eslint rule is possible)

Contributor

youknowriad commented Aug 13, 2018

The original purpose oof core-data is a data abstraction for WordPress which includes all the data available via REST API (exclusing plugins data):

  • Posts
  • Users
  • Taxonomies
  • Media
  • Embed Proxy Endpoint
  • Settings (theme supports)

So I think these make sense there.

Extending entities:

  • I'm not certain yet we should make the entities extensible or instead provide helpers to build entities in other data packages. (for example woo/data)

The general question is, what should be the strategy for including stores in a given package. In other words, how do we want to ensure that each package works out of the box with all the selectors and action it has listed in the codebase.

I think explicitness (adding import '@wordpress/core-data' etc...) should be favored but there's an open question about how to detect/automate those. (Maybe an eslint rule is possible)

@coderkevin

This comment has been minimized.

Show comment
Hide comment
@coderkevin

coderkevin Aug 21, 2018

Contributor

I've done some experimental work to add some more advanced functionality via the fresh-data project.

This is with a plugin internal to @wordpress/data
#8754

This is with the plugin external from @wordpress/data
woocommerce/wc-admin#301

In all, the plugin architecture allowed me to get done what I needed to do this, even with the few key differences in architecture, such as component data mapping, requirements fulfillment, and multi-resource operations.

Contributor

coderkevin commented Aug 21, 2018

I've done some experimental work to add some more advanced functionality via the fresh-data project.

This is with a plugin internal to @wordpress/data
#8754

This is with the plugin external from @wordpress/data
woocommerce/wc-admin#301

In all, the plugin architecture allowed me to get done what I needed to do this, even with the few key differences in architecture, such as component data mapping, requirements fulfillment, and multi-resource operations.

@coderkevin

This comment has been minimized.

Show comment
Hide comment
@coderkevin

coderkevin Aug 21, 2018

Contributor

I'm also working on some experimental code for a single plugin to hold a larger tree of state within the Calypso project. The goal here is to allow a @wordpress/data workflow while maintaining compatibility with the existing system. Automattic/wp-calypso#26838

Contributor

coderkevin commented Aug 21, 2018

I'm also working on some experimental code for a single plugin to hold a larger tree of state within the Calypso project. The goal here is to allow a @wordpress/data workflow while maintaining compatibility with the existing system. Automattic/wp-calypso#26838

@mtias mtias added this to the API Freeze milestone Oct 7, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment