I took a few days to reacquaint myself with GraphQL the last few days. It’s hugely popular with developers as a way to efficiently work with data, providing an efficient way to get a specific set of data to use in a code base. It’s compelling once you understand how to use it.

So I went ahead and installed WPGraphQL, on a WordPress instance I have, to put my feet on the pedals and begin riding. For a few months, I was contemplating creating a custom-built look to a website, and I also wanted to try out using Astro. This was a good opportunity.

It’s trivial to set Astro up, running:

npm create astro@latest

It asks if I want to use TypeScript, so sure, why not. I’m familiar with it, this’ll give me more experience to use it, all it’ll do is take up more time if it’s not easy to put together.

Okay, so then I begin setting up a very simple couple of template files in Astro.

+ src
  + data
    </> wordpress.ts # This is where I fetch the data
  + layouts
    </> default.ts # This is the baseline application wrapper
  + pages
    + blog
      </> [slug].astro # Blog post
    </> index.astro # Blog roll

Getting to this point wasn’t too difficult, just following the steps and updating to my project. The head scratcher comes from the actual TypeScript that’s required.

Here’s the blog roll code.

---
import	Layout from '../layouts/default.astro';
import { wpquery } from '../data/wordpress';

const data = await wpquery({
	query: `
		query LoadAllPostsExcerpt {
			posts {
				nodes {
					title
					slug
					excerpt
				}
			}
		}
	`,
});
---

<layout title="Test">
	<h1>Posts</h1>

	{
		data.posts.nodes.map((post: any) => {
			return (
				<article class="post-preview">
					<h2>
						<a href={`/blog/${post.slug}`}>{post.title}</a>
					</h2>
					<fragment set:html={post.excerpt}></fragment>
					<a href={`/blog/${post.slug}`}>read post →</a>
				</article>
			)
		}
	)}
</layout>

Here’s the focus of this code: data.posts.nodes.map((post: any) => {...}.

There’s nothing simple in WordPress about declaring a type on various data, like post: any. In my code, I’ve resorted to the data type any so many times it becomes pointless to continue using TypeScript.

So I have looked all over for a solution. It exists, of course, but from what I can see, it’d look something like post: Post after having to add another abstraction to define what is Post. Tedious and silly, if you ask me.

Already using TypeScript is an abstraction, one I’m finding to not be so useful.

With the above said, let me end this with a general headless WordPress confusion. The future of WordPress, clearly, is Gutenberg. However, according to the author of WPGraphQL,

“[…] much of WordPress was built with decoupling in mind, the WP REST API and Gutenberg were not.”

In fact, it’s worse than this for anyone using modern WordPress using Gutenberg.

“Gutenberg didn’t have a server-side registry for blocks. At this time, all blocks in Gutenberg were fully registered in JavaScript, which is not executed or understood by the WordPress server.

This means that unlike Post Types, Taxonomies, Meta, Sidebars, Settings, and other constructs that make up WordPress, Gutenberg blocks don’t adhere to any type of contract with the WordPress server.

This means that the WordPress server knows nothing about blocks. There are no agreements between Gutenberg blocks and other systems in WordPress, or systems trying to interact with WordPress via APIs.

Blocks were practically non-existent as far as the application layer of WordPress was concerned.”

So this means, if I have decided that Block Themes and Full-Site Editing is the future and I want to support it, and I also want to go headless, I’m in for a world of pain.

Are developers truly going to continue supporting or going with WordPress unless/until they fully get on board with Block Themes? I don’t think I can see myself continue with WordPress as it’s moving forward. With its forced use of React for Gutenberg, to the weird ways you have to set data, attributes, styles, or other options, this looks like a complete lock-in to a specific way of building websites. Maybe this is great for some, but I am having major doubts I’ll stick this out for much longer.