Defining TypeScript Types For WordPress Data

This post will discuss how TypeScript types were created for WordPress objects for the development of the NextJs application. It should be noted that due to the length of each object not all objects will be described within this post. The most important two are the schema for an author and a blog post. The creation of types for the post will be covered within this entry. 

Posts Schema

WordPress conveniently provides detailed information about their REST API at https://developer.wordpress..org making the use of their API a straightforward process. TypeScript interfaces were created that describe a blog post based on the schema defined on the WordPress developer website. The following table is extracted from the WordPress website and provides the schema for a blog post.

date

string or null,
datetime (details)
 		The date the object was published, in the site's timezone.

Context: view, edit, embed

date_gmt

string or null,
datetime (details)
 		The date the object was published, as GMT.

Context: view, edit
guid

object 		The globally unique identifier for the object.

Read only

Context: view, edit
id

integer 		Unique identifier for the object.

Read only

Context: view, edit, embed

modified

string,
datetime (details)
 		The date the object was last modified, in the site's timezone.

Read only

Context: view, edit
modified_gmt

string,
datetime (details)
 		The date the object was last modified, as GMT.

Read only

Context: view, edit
slug

string 		An alphanumeric identifier for the object unique to its type.

Context: view, edit, embed

status

string 		A named status for the object.

Context: view, edit

One of: publish, future, draft, pending, private

type

string 		Type of Post for the object.

Read only

Context: view, edit, embed

password

string 		A password to protect access to the content and excerpt.

Context: edit
generated_slug

string 		Slug automatically generated from the object title.

Read only

Context: edit
title

object 		The title for the object.

Context: view, edit, embed

content

object 		The content for the object.

Context: view, edit
author

integer 		The ID for the author of the object.

Context: view, edit, embed

excerpt

object 		The excerpt for the object.

Context: view, edit, embed

comment_status

string 		Whether or not comments are open on the object.

Context: view, edit

One of: open, closed
ping_status

string 		Whether or not the object can be pinged.

Context: view, edit

One of: open, closed
format

string 		The format for the object.

Context: view, edit

One of: standard, aside, chat, gallery, link, image, quote, status, video, audio

meta

object 		Meta fields.

Context: view, edit
sticky

boolean 		Whether or not the object should be treated as sticky.

Context: view, edit
template

string 		The theme file to use to display the object.

Context: view, edit
categories

array 		The terms assigned to the object in the category taxonomy.

Context: view, edit
tags

array 		The terms assigned to the object in the post_tag taxonomy.

Context: view, edit

(WordPress, n.d.).

Defining Interfaces

Interfaces for the schema detailed within the above table were created that can be used throughout the applications development. This provides static type checking, assisting with the catching of errors at compilation time. 

The following screenshot shows the created interfaces based on the content found in the table shown above. These types were used throughout the application, 

These interfaces can now be used throughout the code to provide static type checking. The BlogListedItem interface uses a generic type so that the type of the author can be specified. Multiple examples of the usage of this type can be found in the following image

Conclusion

By mapping the WordPress schemas the WordPress developer website provides to custom built interfaces static type checking can be performed throughout the application to help catch compilation errors. Additionally, many runtime errors such as the creation of a component with improper data is also identified through the usage of these interfaces.

References

WordPress (n.d.). Posts | REST API Handbook. [online] WordPress Developer Resources. Available at: https://developer.wordpress.org/rest-api/reference/posts/#schema [Accessed 7 Apr. 2021].

Comments

Post a Comment

Popular posts from this blog

WordPress Modifying A Child Theme & Using The OpenWeatherMap API

Image
The modification of a WordPress child theme can be accomplished in multiple stages. For my child theme modification users can search the name of a city and are provided some current weather data from openweathermap. To accomplish this I used TypeScript to make my requests and perform DOM manipulation. Child Theme Creation & OpenWeatherMap API To create a child them, navigate to the directory where WordPress themes are stored. Create a new directory that uses a similar name to the parent them you wish to extend, however append the text "-child" to the end. This text does not do anything, however this is considered best practice (WordPress, n.d.). This directory requires several files in order to be operational. Firstly, a CSS file that contains a description of the theme is required. This should be named style.css and contain text similar to the following extract. The child theme will now be available for activation thro...
Read more

Creating A WordPress Post Using The REST API

Image
The created NextJs application allows for the creation of a new blog post using the WordPress REST API by sending a HTTP POST request to  /wp/v2/posts  using the schema defined on the WordPress developer website(WordPress, n.d.). A custom built page was created that contains a form for creating blog posts. This page can only be accessed if the user has a currently authenticated session.  The Create functional component reads the state of the login session by accessing the AuthContext using the useContext hook. More can be read about the implementation of the persistence of an authenticated session by  accessing this blog entry. Creating The Posts Content Users can provide a blog with a title, an excerpt and can create HTML content for the post within the Post Content textarea shown in the following image. Each form input on this page uses the useForm form validation hook that was created for performing real time, reactiv...
Read more

Consuming The WordPress Posts Via The REST API

Image
WordPress provides a REST API that has good online documentation that includes information such as type definitions and route information(WordPress, n.d.). Fetching & Server Side Rendering As the data is stored on an external storage system, the server hosting the WordPress application, the page can not be directly served with the data if it is rendered on the client. By rendering the page on the client using Reacts default rendering technique the user will have to wait for the data to be fetched, parsed and then rendered.  A small subset of the post information is rendered for this page as the entire post is not required. To reduce the amount of fields returned from the REST API the ?_fields?= query is used, as shown below. To avoid this issue the data for the blog index page, the page that renders the posts and their excerpts, is rendered on the server. The data fetching is handled by the server meaning that when the client receives the page all of the data fetching has alrea...
Read more