wp.data Overview

[mtias]

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. Data Module: Adding support for sync generators to allow async action creators #7546, Data: Add redux-routine package for synchronous generator flow #8096
• Add support for Core Data Entities Actions. Add support for Core Data Entities Actions #7175
• Adding and updating entities. Data: Support adding and updating entities #10089
• Add support for action creators as generators. Data Module: Add support for action creators as generators #6999, Data: Add redux-routine package for synchronous generator flow #8096
• Write documentation / examples.

Blocks

• Update all blocks to not have direct API calls.

[gziolo]

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

[gziolo]

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]

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]

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/woocommerce-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]

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

[youknowriad]

Most of the basic pieces landed or are going to land in #10089 I'm closing this meta issue for now. It served its purpose.

There are still things I want to improve on the data module but it could happen later without breaking changes.