Paul Cook,
Back

The now deceased WordPress/React project

Introduction

I’ve had two major technology itches that I’ve been needed scratched lately: React and the WordPress REST API.

So, with that in mind I set out to build a small app that uses the WordPress REST API of a small site I maintain for my church (naobcyouth.org) as the backend, and then a small React app as the frontend.

Finished project

Before you continue on, here’s a link to the finished project hosted through Zeit Now:

NAOBCYM React App

And then here is a link to the GitHub repo:

GitHub Link

Please check it out!

Challenges and how I overcame them

Routing

I come from Angular/Ionic land where everything is tied up in a neat little (weighty) Typescript bow, so the fact that React is so light took some getting used to. One of the first areas this came up was with routing.

I settled on using React Router as from what I could tell this is the most popular solution in the community, and my goal was really just to get a grasp on React, not spend a bunch time with routing.

Well, routing ended up being the thing I spent most time on (surprise)!

There were two major issues I ran into with routing:

1. How to pass data from page to page

In Ionic this is trivial. With React Router it really isn’t that difficult, either, but seeing as I was also learning React at the same time it held me up some.

2. Pagination

This probably was the problem I spent the longest time with. One of the main issues I was facing is that clicking on the pagination links didn’t cause the component to re-render, and so my new data was never requested from the server.

How I solved it

Well, I did eventually figure out how to pass the data from page to page, but I decided just to make an API call every time someone went to a new page rather than passing the post data end. This seemed like a better solution as I didn’t have to worry whether someone typed in the URL to navigate to the page or not.

And as for pagination it was really a matter of figuring out more about the component lifecycle:

componentWillUpdate(nextProps) {
  if (nextProps.page !== this.props.page) {
    this.getPosts(nextProps.page);
    return true;
  }
}

componentWillUpdate allowed me to check to see what my page property was, and to get the posts I needed for each page.

Response Headers

When I started the project I was using the Fetch API to get my remote data, but I ran into this issue where I wasn’t able to access my headers. I would console.log(res.headers) and I would see a Headers object that was completely empty.

This was no good at all. I needed those headers! The WordPress REST API sends back a response that has the total number of items, and the number of pages of items based on how many items you’re requesting per page (max is 100, default is 10).

How I solved it

Eventually, I sidestepped the issue by using the lovely HTTP client Axios which gave me everything I needed in one nice little object.

What I learned

  1. One of the main things I learned was how nice React was to work with. Just using vanilla ES6 is really a joy after dealing with all the Typescript and tooling of Angular. Now, don’t get me wrong, I like Angular and I like Typescript, but the change was nice.
  2. The React ecosystem is DEEP. I toyed around with the idea of using a state management library like Flux or Redux, but quickly nixed the idea because I wanted to learn REACT not React and some other library. I have heard tremendous things about Redux, but my first project (and a simple one at that) wasn’t the time to learn it.
  3. The promise of the WordPress REST API. The more I look into it the more I’m realizing how much this enables website developers who use WordPress to do. Possibilities seem endless here.
  4. Zeit Now feels like the future. I used it to deploy my app, and the ease of doing so was spooky. Check it out sometime.

A few resources I used

Docs

Tutorials

And there’s others I’m sure I’m forgetting!