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 we’ll use to illustrate and practice the various concepts and apis around wp.data. The app we’re going to work with does the following:

• A view that displays products in a product directory. Each product has an add to cart button for adding the product to a cart.
• A view that displays the contents of the cart, the total for the items the cart, and a way to remove items from the cart.
• A view for adding, editing and deleting existing products (it might serve as the admin view eventually).

So, go ahead and play around with this app I’ll be here when you get back.

You back? Great! The code portion of the app is here. Go ahead and take a few minutes to look at the code.

Now that you’ve taken a look at the code, let’s think about the design of the app for a few minutes. 

What type of state exists in the app? If you answered local or tree state, you are correct. The app has no global or redux like state and all the data regarding the products and the cart is utilized and maintained in the main component and passed through to child components via props. 

While tree state is fine for simple slices of a ui tree, for this particular app there’s some problems that can start surfacing as the app begins to grow in functionality. Can you think of any? 

Let’s list a few of them:

• Prop drilling hell. This is when you need to get data to a component in a branch of the tree multiple levels deep and you have to pass it through multiple levels.  You can see some of that beginning to appear in our application.
• If we want to change the shape of the product object, we’d have to modify everywhere it is implemented.
• There’s duplication of logic happening between how the cart tracks what products it is attached to and how products are updated in the tree state.
• There’s additional complexity involved when it comes to updating the products in the cart if they are deleted from the directory (did you spot the bug here?)

That’s just with the app in its current design. Eventually we’d probably want to store product and cart information outside of the client somewhere, likely on a server via some sort of REST api. Once we start doing that we’ll probably run into difficulties due to the tight coupling of data retrieval to the presentational components.

It’s usually at this point in a complex app’s design that you start to recognize the need for some sort of global state and this is where wp.data comes in.

Sidenote:
When I’m designing react applications, I usually try to avoid jumping to using global state (or in this case wp.data) right away because sometimes it’s not needed. It also is much easier to map out the needs of the app as you build it before complicating the app with the global state.

Series Navigation

WordPress Data: How to Register a Custom StoreWordPress Data Store Properties: Actions