• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

WP Dev Life

A Journey through WordPress

  • About Jay
  • Dev Tools
  • Contact Us

Archives for November 2019

Using withSelect for WordPress Block Components

November 26, 2019 by Jay

I’ve been working on a block that requires the use of fetching data from the WordPress REST API in a couple of my components. The first component needing data was my PostList component. This component is responsible for displaying a list of posts in the editor as well as inside of a modal for my post picker component. The second was for fetching the categories that each post was assigned, so that I could display the category names for each post.

Thankfully the Core Data API in WordPress allows us to use the withSelect higher order component to fetch this data and pass it to our component as props. The getEntityRecords function allows us to fetch data to certain REST API endpoints to get back any data we want to use within our component.

There currently isn’t a documented list of entities that we’re able to query, however the Gutenberg source code provides us the default entities. Note that the widgetArea entity is experimental as of writing. For this article we’ll focus on the postType and taxonomy entities.

NameBase URL
site/wp/v2/settings
postType/wp/v2/types
media/wp/v2/media
taxonomy/wp/v2/taxonomies
widgetArea/__experimental/widget-areas

Exploring the Data API

Using your browser’s JavaScript console we can explore the WordPress Data API. The data API is exposed as the wp.data object. If you type in wp.data.select("core") this will access the core data API. From there we can run wp.data.select("core").getEntityRecords()which will return an empty array. getEntityRecords expects 4 parameters.

  • state Object: State tree
  • kind string: Entity kind.
  • name string: Entity name.
  • query ?Object: Optional terms query.

To select all of our posts in the console run: wp.data.select("core").getEntityRecords('postType', 'post', { per_page: -1 }) If you get back null the first time run it again and you’ll get back an object with all of your posts. In this case the entity kind was postType, post was the entity name since we wanted back that specific post type. We could have replaced that with any other post type or custom post type that was exposed on the REST API to get back those specific results. The object that we passed is the terms query. Using the REST API parameters, corresponding to their endpoints, we can filter the data we want to get back . For Post Query Parameters see the REST API Handbook. We’ll use these next as we build our basic component.

Building our Component

React has begun moving away from class based components, and in truth not every component needs to be an entire class when functional components can do everything just as well. First we need our component that we’ll pass to withSelect and our withSelect export.

import { withSelect } from '@wordpress/data';

const PostList = ( props ) => {
  return(
    // Post Info will be displayed here
  )
}

export default withSelect( (select, ownProps ) => {
  const { getEntityRecords } = select( 'core ');
  const postQuery = {
    per_page: 10,
    page: 2
  }
  return {
    postList: getEntityRecords('postType', 'post' postQuery ),
  }
})(PostList)

In the above example we wrap the PostList component in a withSelect higher order component, and use getEntityRecords to fetch back postList and pass that as props to the PostList component. The postQuery can further be modified using more parameters. If you wanted to dynamically control the parameters you could do so with attributes or passing them into the PostList component as props from a component higher up in the block.

Using Lodash Map to display data

If we were to try to render any data we got the result from the REST API, we would get some errors so we first need to verify that the data we got back is expected, and that it’s of a good length. We then will render a placeholder if we don’t have the data back, which will show the data once that select has finished.

import { map } from 'lodash';
import { withSelect } from '@wordpress/data';
import { Placeholder, Spinner } from '@wordpress/components';
import { Fragment } from '@wordpress/element';

const PostList = ( props ) => {
  const { postList } = props;
  const hasPosts = Array.isArray( postList ) && postList.length;
  if ( ! hasPosts ) {
    return (
      <Placeholder
       icon="excerpt-view"
       label={ __( 'Post Block', '' ) }
      >
	{ ! Array.isArray( postList ) ? <Spinner /> : __( 'No posts found.', '' ) }
      </Placeholder>
    );
  }
  return(
    <Fragment>
      {
        map( postList, ( post ) => {
          return (
	    <div>{ post.title.raw }</div>
          );
      })}
    </Fragment>
  );
}

export default withSelect( (select, ownProps ) => {
  const { getEntityRecords } = select( 'core ');
  const postQuery = {
    per_page: 10,
    page: 2
  }
  return {
    postList: getEntityRecords('postType', 'post' postQuery ),
  }
})(PostList)

Conclusion

This example component should be enough to get off the ground writing your own components fetching data from the REST API. I hope that as Gutenberg grows the number of entities can grow as well to target all of the endpoints. Once I figured out how components can all fit together and power one another the new editor has become a blast to develop for. It can almost be described as a giant puzzle. I have not yet gotten a full understanding of the compose function which can help join your higher order components together, but once I do I’ll have a follow up article exploring that. I love to talk development on Twitter so if you’re up for chatting Gutenberg or React give me a shout.

Filed Under: Programming, REST API, WordPress

Gutenberg: Attributes vs State

November 23, 2019 by Jay

It’s been almost three full months since I became a professional developer, and in that time my team and I launched the new Torque website. This was the team’s first foray into Gutenberg and React, and my first real foray into it. I’d explored a few things and knew some concepts, but still struggled in some areas. The blocks we ended up creating work, however there’s room for improvement.

We created two separate blocks that needed shared functionality. After trying to fix the bugs in those blocks we came to the conclusion that we should just have one block that could cover all of the use cases of the two blocks. This may sound complex, and it is. It’s a block that’s meant to be used in place of two different blocks with those blocks and displays having different markup on the frontend.

The Challenge

One of the main challenges with this Post block is I need to be able to show either the latest posts, or show specifically picked posts. This means I need attributes that correspond to values in a WP_Query or REST API call, and that these values should be saved in the block so that the frontend is able to process them.

So I setup attributes for order, orderBy, categories, per_page, etc. I used a QueryControls component to set the attributes in the sidebar, but I need the same QueryControls component in the PostPicker component that I created. This component is a Modal window that pops open that has query controls, and displays a list of posts next to a checkbox. When you check the box, the post ID is added to an array that is also an attribute.

The main challenge I ran into is that when I was using the QueryControls in the PostPicker component the query would update behind the modal too and result in multiple components re-rendering but that’s not what I wanted.

How should I approach this?

I was reading a lot of the React documentation yesterday, especially around Functional Components vs Class Components, as well as State management. My thinking now, instead of having each QueryControl component control attributes, what if we use React’s State Management hooks to manage the QueryControls for the PostPicker, while the attributes stay attached to the main QueryControls component.

Conclusion

There’s a lot of work to be done still with the new editor, and there’s a lot to learn about the inner workings. We already see a large number of Block Suite plugins, but I feel like not many of them are pushing the limits yet, mostly due to the lack of documentation about what the limits are. I get my blocks into really weird states but I think this exercise of creating this Super Post Block proof of concept, to bring back to my team is definitely going to open up an avenue for me to get back into technical writing to contribute back to the WordPress community so that others don’t struggle as much with the same issues I’ve ran into.

Filed Under: WordPress

Primary Sidebar

Learn Linux

Use LinuxAcademy to learn Linux, AWS, or other Cloud technologies.

Find Something

Categories

Recent Posts

  • Using withSelect for WordPress Block Components
  • Gutenberg: Attributes vs State
  • Getting Started with Unit Tests
  • WordPress REST API
  • Authentication and the REST API

Archives

  • November 2019
  • May 2019
  • January 2019
  • July 2018
  • February 2018

Copyright © 2025 · Wp Devlife on Genesis Framework · WordPress · Log in