Headless Hackathon Takeaways

In early 2019 the Studygroup I’m in decided to take part in a hackathon hosted by Zac Gordon. The goal was to build a headless WordPress site.

Our Headless Site:

A meal planning site that allows you to create your meal plan for the next week from a list of stored recipes.

WordPress Installation

For the WordPress side of things we created a Custom Post Type to store all our Recipes. With the ability to create Block Templates for Post Types we were able to create a Block that saved data to the post meta fields.

acfk_prep_timeint (seconds)true
acfk_cooking_timeint (seconds)true
acfk_prep_timeint (seconds)true

All of that data can now easily be accessed though the WordPress REST API .

Frontend structure

This react application uses the new hooks syntax, and is based around the usage of context. Upon loading the page, the recipes will be fetched from the WordPress Rest API, transformed into a nicer data structure, and stored inside the availableRecipeContext. This context it wrapped around all the routes, so you can always have access to all the recipes from the server. This data will also never be modified.

The recipes you want to add to a day, are stored inside the day component itself, so each day is living in its own ‘sandbox’. That way we can make sure, that there is no direct way of modifying the recipes in a day from outside the day.

The only exposed way for you to interact with the data of the day, is by passing a prop called recipeToAdd into the day. This prop needs to be an object with the recipe and an callback function called done attached to it. Once the passed recipe is added to the day, the callback function will be called.

Upon adding a recipe to a day, it will get an unique identifier, to enable having the same recipe multiple times in a day and still being able to remove each one individually.

Personal Goals

For me a main focus going into the project was trying some testing in React. But at the very beginning we decided to go full in on React Hooks, that were just released while we had the hackathon.

One of the hardest problems to tacke, was the data structure, because we tried to avoid to just have everything stored at the top. So for example no components outside the day view should have access to the recipes that are stored in a day. But we still wanted to be able to add a recipe to a day from outside the day component. So we needed to get creative there. In the end we build a function to add a recipe to a day that is passed into each of the days and shares that recipe with it. Kind of like talking to an API to add the recipe, but not being able to access the recipes that are already in there.

Another struggle was that we wanted to have the entire application keyboard accessible. In the end we ran out of time and actually have some bugs in the visual experience resulting from keyboard optimizations. So this is something that I want to look at further in the future.

Regarding the earlier mentioned testing, I only got to the point where I wrote basic snapshot and render unit testing. But nonetheless learned a lot about jest, puppeteer and react-testing-library.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.