by Darren Ethier (@nerrad)
This series is an overview of the @wordpress/data package surfacing the various interfaces you can use for managing data and state in your WordPress (or React) application.
For the past couple of years, my involvement with the Gutenberg project in WordPress has frequently taken me into the innards of @wordpress/data. I’ve had to use it for projects integrating with the new WordPress Block Editor (Gutenberg), new interfaces and user experiences utilizing the new WordPress JavaScript packages, and I’ve also been directly involved […]
The WordPress data module (or package) is a critical component of the new WordPress Editor as demonstrated by it’s implementation in (at the time of writing) 7 other WordPress packages: @wordpress/block-directory registers a store with the core/block-directory namespace. @wordpress/block-editor registers a store with the core/block-editor namespace. @wordpress/blocks registers a store with the core/blocks namespace. @wordpress/core-data […]
The primary way in which you interact with state in wp.data is through a registered store. In this post we’re going to give an overview of the api for registering a store and then subsequent posts will dive into the specific components of the store config. registerStore( reducerKey, options ) Every data store found in […]
In the last post I gave you a quick overview of the api for registering a new data store. I mentioned that this next post would take a closer look at the individual properties of a store, but before we do that, let’s take a brief break and take a look at an app that […]
In the previous post of this series, we took a brief interlude to take a look at an app that is using tree state to manage the data the app is using. We discovered that, while the app was functional, some potential problems with using state this way were beginning to surface. In this post, […]
The job of selectors is to provide an interface to access state from the registered data store. With wp.data this is the primary way that your store state is exposed and allows you to encapsulate logic surrounding exposing that data. For instance, let’s say you just want to store all products in the store state […]
Often with any sort of state in a given application, there can be times in an application’s lifecycle where you want to be able to execute some sort of logic as a part of the flow in setting state or updating state. A good example of this is asynchronous data flows between the client and […]
Before we took our side detour into learning about the controls property, I mentioned that since we now have a selector for getting products, it’d be good to implement a way to retrieve the products from the server. This is where resolvers come in. Let’s get started by creating a resolver for retrieving products. If […]
Now we have a resolver for asynchronously getting products via a REST api endpoint, we have some action creators, and we have a selector. We haven’t got to the reducer yet, but before we get to it, let’s consider another problem we haven’t addressed yet. When we update or create a product using our ui, […]
In the exploration through wp.data, we’ve already created the necessary properties needed to register the custom products store for our example app. This includes, action creators, selectors, controls, and resolvers. Now it’s time to get to the last property we need for registering our store, and that’s the reducer. The reducer is arguably the most […]