How to build a simple off-canvas panel in React

Photo by Arthur Mazi on Unsplash

On my last few React projects I’ve had a need for a simple off-canvas panel. One was for the mobile menu on my portfolio site and another was for a web app I was building in my day job with a London local authority. The functionality for these panels in both projects were pretty simple. For the mobile navigation, the panel would open and appear on-canvas when the hamburger menu was clicked and would close and return off-canvas when navigating to another page of my website. The web app I was building was opened when a row on a table of data was clicked and closed when the the close button on the panel was clicked. All fairly simple stuff…

However, with the web app I was tasked with building it using Microsoft’s Fluent UI design system. I initially attempted to use the panel component in the design system, but felt all of the options provided were overkill and required a lot of boiler plate code for something so simple. FluentUI also uses Typescript and I wasn’t using Typescript on this project as it was a simple proof of concept piece of work and again meant more boilerplate code.

In the end I built my own component and was able to reuse it across projects. So here’s my code and how I did it.

I started by building the panel component first. This component would take a toggle and event prop. The toggle prop simply toggles the open/close class on the element. The animation is handled by CSS.

When using the panel for the mobile navigation, you’ll want the panel to automatically close when a menu link in the panel is clicked, to do this add an onClick={togglePanel} to the panel element.

const Panel = ({ children, toggle, event }) => {
  return (
    <section
    className={`panel ${toggle}`}
        onClick={event}
      >
      {children}
    </section>
  );
};

.panel {
  padding: 15px 15px;
  display: flex;
  flex-flow: column;
  position: fixed;
  top: 0;
  bottom: 0;
  height: 100vh;
  overflow: hidden;
  z-index: 999;
  background-color: #334050;
  visibility: visibility;
  -moz-transition: right 500ms ease !important;
  -ms-transition: right 500ms ease !important;
  -webkit-transition: right 500ms ease !important;
  -o-transition: right 500ms ease !important;
  transition: right 500ms ease !important;
  box-shadow: 0px 0.6px 1.8px rgba(0, 0, 0, 0.1),
    0px 3.2px 7.2px rgba(0, 0, 0, 0.13);
}

.closed {
  right: -100vw;
  z-index: 9999;
}

.open {
  right: 0;
  z-index: 9999;
}

To use the panel, we manage some simple state in app.js or whatever parent component we use it in. This will set the toggle state. It’s set to closed initially so so we give it the false boolean. We then use a simple event handler to run the toggle event which toggles the class on the panel element.

const App = () => {
  const [panel, setPanel] = useState(false);
  const togglePanel = () => setPanel(!panel);
  let toggle = panel ? `open` : `close`;

  const openPanel = () => {
    togglePanel();
  };

  return (
    <Panel toggle={toggle} event={togglePanel}>
      {/* content */}
    </Panel>
  )
}

And it’s as simple as that.

Software Engineering in the UK public sector

What I’ve learnt from my 2 years as a Front End Engineer in the public sector.

Photo by Daniel Ali on Unsplash

I joined one of London’s councils almost 2 years ago as a Front End Engineer. For most of my career before this, I had worked for several large e-commerce businesses. I wanted to take an opportunity to discuss some of differences I’ve found in both industries and some of the things I’ve learnt over these past 2 years.

The one major difference from working in software engineering in the UK Public Sector compared to doing the same job in the e-commerce sector is the huge focus on designing and building products that are accessible for all. Accessibility matters. This was something I knew would be a significant difference before taking the job. Looking back on my time working in e-commerce, I can say that for the businesses I worked for, accessibility was never mentioned at all. One of the reasons I joined the council, was to learn more about how to make a website or application accessible as it was something I had began getting interested in. Prior to my time with the council, I was focused on simply writing semantic code that included all the basic features that help accessibility, those basics like title attributes on links and alt tags on images. Aside from running my websites through Google’s Lighthouse, I can’t say I ever spent a lot of time building accessibility compliant websites or reading WCAG.

As part of a Product Design team, I now think about the accessibility of a product or feature at the design stage with my product designers. I then think about how this will translate to my code. It can be a difficult job getting it right but it’s something we have to do, because as a Government organisation we can be penalised if we don’t. At the end of the day, the services a council or other public service offers is meant for everyone and in some cases, people are reliant on them, so you can’t exclude anyone. I’ve really enjoyed learning about accessibility and it’s requirements. My team are currently in the process of creating a design system for the council’s digital products, so including these considerations in features and components is at the forefront of this. When I write HTML, Javascript or JSX now, I have to ask myself, will an assistive screen reader be able to read it properly? Can a keyboard user navigate a page consistently? Are page elements visible to everyone? Am I excluding anyone I can think of. That’s usually a good start. I have attended the last 2 Gov UK Design Systems Days, which is also focused on accessible design, and I’ve learnt a lot through those.

Another big difference I’ve found, is how the Product team has to do things on a budget. In the Private Sector, money most of the time, is no object. Though, a lot of council’s, my employers included have previously relied on using proprietary software, where they have paid big license fees to have zero control over the code base, because historically they’ve not had big enough teams to write or manage their own code. Thankfully, for my own employer, they have seen the need for having their own Product team and bringing their tech management in house, otherwise I wouldn’t have a job. It takes a little while to untangle themselves from historical tech decisions however, so before you can re-platform to an Open Source CMS like Drupal, you’re still maintaining code you’ve written as a work-around for that licensed CMS with it’s locked down code base that you know will overwrite your code in it’s latest release. Not good, I can tell you!

This then leads to the other big difference… Open Source. As my employer now has its own Product Team, that design and build its own products, there is a big switch to using Open Source platforms and products. This is good news, as not only is Open Source free, it usually has a community that you can reach out to when needed, or you can fork the code and build your own version on top among other things.

The last difference I’ve noticed in the Public Sector, is around design. Firstly, the number of different design disciplines. In the Private Sector, I had only ever worked with Product Designers, UX Designers and UI Designers. In the council, you have Product Designers, Content Designers and Service Designers. Service Designers design the public service in digital form, so how a service like paying your council tax, may function online (something like going to a website, signing in to an account and paying via the website etc.) The Content Designer then designs any content for this service, and the tone of voice for it. The Product Designer designs the product itself, (so the website or the account section of the website for paying the council tax). Each of these roles play a significant part and all work together in some way. For example, we plan to include a tone of voice for our design system, because how we speak to our users matters and we want it to be consistent. I don’t think this was ever a consideration in the e-commerce businesses I worked at outside of the market voice which never impacted my work.

Secondly, most of the design in Public Service products can seem a little boring. The purpose is function over style much of the time. Eye catching design doesn’t always exist and to be honest that is one of the only things that I miss a little from the Private Sector. Occasionally, you get to have both in the form of micro-sites or apps and products not linked to the council’s main brand or external users.

That’s a brief overview of the differences I’ve come across in my time as a Front End Engineer in the Public Sector in the UK. If there are other Engineers, Devs or Designers out there that have similar or different experiences I’d love to hear from you. Leave a comment and let me know about them.

Thanks for reading.

This story is also available @ https://www.nmk.dev/post/software-engineering-in-the-uk-public-sector-81afcccca8a7

How to build a headless WordPress website with ReactJS & Frontity - Pt. 3

Reasons to try Frontity

Adding content to your Frontity project is very simple. In fact, the Mars-Theme includes all of the components that will do the heavy lifting for you. Lets get started with where you’d expect: src/components/index.js. This component will look something like the following:

import { Global, css, connect, styled, Head } from "frontity";
import Switch from "@frontity/components/switch";
import Header from "./header";
import List from "./list";
import Post from "./post";
import Loading from "./loading";
import Title from "./title";
import PageError from "./page-error";

/**
 * Theme is the root React component of our theme. The one we will export
 * in roots.
 *
 * @param props - The props injected by Frontity's {@link connect} HOC.
 *
 * @returns The top-level react component representing the theme.
 */
const Theme = ({ state }) => {
  // Get information about the current URL.
  const data = state.source.get(state.router.link);

return (
    <>
      {/* Add some metatags to the <head> of the HTML. */}
      <Title />
      <Head>
        <meta name="description" content={state.frontity.description} />
        <html lang="en" />
      </Head>

{/* Add some global styles for the whole site, like body or a's. 
      Not classes here because we use CSS-in-JS. Only global HTML tags. */}
      <Global styles={globalStyles} />

{/* Add the header of the site. */}
      <HeadContainer>
        <Header />
      </HeadContainer>

{/* Add the main section. It renders a different component depending
      on the type of URL we are in. */}
      <Main>
        <Switch>
          <Loading when={data.isFetching} />
          <List when={data.isArchive} />
          <Post when={data.isPostType} />
          <PageError when={data.isError} />
        </Switch>
      </Main>
    </>
  );
};

Above, I have highlighted in bold the parts of the component that will load the content. Much like in other React frameworks, Frontity uses a <Switch> component for page routing and it contains a post.js component which is where the WordPress data is actually fetched from.

The post.js component will resemble the following:

import { useEffect } from "react";
import { connect, styled } from "frontity";
import Link from "./link";
import List from "./list";
import FeaturedMedia from "./featured-media";

/**
 * The Post component that Mars uses to render any kind of "post type", like
 * posts, pages, attachments, etc.
 *
 * It doesn't receive any prop but the Frontity store, which it receives from
 * {@link connect}. The current Frontity state is used to know which post type
 * should be rendered.
 *
 * @param props - The Frontity store (state, actions, and libraries).
 *
 * @example
 * ```js
 * <Switch>
 *   <Post when={data.isPostType} />
 * </Switch>
 * ```
 *
 * @returns The {@link Post} element rendered.
 */
const Post = ({ state, actions, libraries }) => {
  // Get information about the current URL.
  const data = state.source.get(state.router.link);
  // Get the data of the post.
  const post = state.source[data.type][data.id];
  // Get the data of the author.
  const author = state.source.author[post.author];
  // Get a human readable date.
  const date = new Date(post.date);

// Get the html2react component.
  const Html2React = libraries.html2react.Component;

/**
   * Once the post has loaded in the DOM, prefetch both the
   * home posts and the list component so if the user visits
   * the home page, everything is ready and it loads instantly.
   */
  useEffect(() => {
    actions.source.fetch("/");
    List.preload();
  }, [actions.source]);

// Load the post, but only if the data is ready.
  return data.isReady ? (
    <Container>
      <div>
        <Title dangerouslySetInnerHTML={{ __html: post.title.rendered }} />

{/* Hide author and date on pages */}
        {!data.isPage && (
          <div>
            {author && (
              <StyledLink link={author.link}>
                <Author>
                  By <b>{author.name}</b>
                </Author>
              </StyledLink>
            )}
            <DateWrapper>
              {" "}
              on <b>{date.toDateString()}</b>
            </DateWrapper>
          </div>
        )}
      </div>

{/* Look at the settings to see if we should include the featured image */}
      {state.theme.featured.showOnPost && (
        <FeaturedMedia id={post.featured_media} />
      )}

{data.isAttachment ? (
        // If the post is an attachment, just render the description property,
        // which already contains the thumbnail.
        <div dangerouslySetInnerHTML={{ __html: post.description.rendered }} />
      ) : (
        // Render the content using the Html2React component so the HTML is
        // processed by the processors we included in the
        // libraries.html2react.processors array.
        <Content>
          <Html2React html={post.content.rendered} />
        </Content>
      )}
    </Container>
  ) : null;
};

I have highlighted the areas that will automatically fetch your content data and display it depending on whether it’s a Page or a Post. This component fetches the data from Frontity state and will then conditionally render the parts of the page necessary for a Page or a Post. dangerouslySetInnerHTML is used to set meta data such as "titles" and "descriptions", but the main page content data is displayed using one of Frontity’s built-in libraries called html2react. Frontity defines libraries as "a reusable set of tools. However, it is NOT aimed to change the state, but rather other parts of the application and is available for use by many packages". - https://docs.frontity.org/learning-frontity - Core concepts

By now your Frontity project will be displaying content and dynamic menus from your WordPress website. If you inspect the content in your browser inspector, you can see the class names of the divs and sections I recommended adding in the WordPress Block editor earlier (based on your own design). All that’s left for you to do, is build out your design in components just like you would for any React application fetching various data from Frontity’s API. CSS in JS is used for styling your application and means your CSS can be contained within each component. But why CSS in JS?

Because:

It Only loads the CSS needed for each page which improves the performance

You don’t have to worry about classes and its problems with duplication, typos, etc

You don’t have to worry about vendor prefixing so you can write your CSS based on the current standard and Frontity handles the rest for you

You can use all the power of JavaScript to style your components and create dynamic styles with much less code.

And there you have it, you’re up and running with your first WordPress and Frontity app. Decoupled WordPress with Frontity and ReactJS. Enjoy!

Go back to…
+ How to build a headless WordPress website with Frontity / ReactJS - Pt. 1

How to build a headless WordPress website with Frontity / ReactJS - Pt. 2

This story is also available @ https://www.nmk.dev/post/how-to-build-a-headless-wordpress-website-with-frontity-reactjs-pt-3-ff98d654ac75

How to build a headless WordPress website with ReactJS & Frontity - Pt. 2



The next steps to setting up your Frontity project…

Step 2: As Frontity is a React framework, you’ll need to have Node installed before creating your project. Ensure that you do, and then create a new Frontity project by entering the following command in your terminal:

npx frontity create my-frontity-project

You’ll be prompted with the following:

1st terminal message prompt

Enter (y) to proceed. During the install process, the terminal will again prompt you with the following:

2nd terminal message prompt

You’ll be asked to select a starter theme. It’s recommended that if it’s your first time using Frontity, then you should select @frontity/mars-theme to start with. By using the Mars-Theme, Frontity essentially gives you a fully bootstrapped project set up with a starter theme that can be easily customised. The Frontity documentation will also use the Mars-Theme as a reference, so it’s easy to follow along with Frontity’s own installation and customisation guides. Once you’ve selected this, the installation will complete and a directory with the same name as the project name you used will be created. It will have a structure similar to this:

my-frontity-project/
|__ node_modules/
|__ package.json
|__ frontity.settings.js
|__ favicon.ico
|__ packages/
    |__ mars-theme/

What your Frontity project will look like after installation

You can run the project locally by executing this command from the terminal:

cd my-frontity-project && npx frontity dev

Doing so will load your Frontity project at http://localhost:3000/ where you’ll see the Mars-Theme you also installed. It should look like the following:

Test Frontity blog with Mars-Theme

At the moment your Frontity project is using content data from Frontity’s own test WordPress site - https://test.frontity.org/. This is good news because it means that your Frontity project is pulling data from the WordPress REST API, just not your own site’s yet. So lets fix that…

In your Frontity project, openfrontity.settings.js in your I.D.E. of choice. You should see the following code:

const settings = {
  ...,
  packages: [
    ...,
    {
      name: "@frontity/wp-source",
      state: {
        source: {
          // Change this url to point to your WordPress site.
          url: "https://test.frontity.org/"
        }
      }
    }
  ]
}

To set your own WordPress installation as the data source you can connect your own WordPress site to your Frontity project by setting the state.source.url property in the frontity.settings.js file.

Since the point of this tutorial is to go a little more in depth than the example used in the Frontity documentation, there is one more change you’ll need to make on the WordPress installation side…

The Frontity WordPress test site (https://test.frontity.org/) is a blog and the example in Frontity’s documentation assumes you’re setting up a blog site. However, my tutorial is showing you how to set up a website with a blog included. So if your own WordPress installation has pages and no posts at this point, you probably won’t be seeing your content in the Mars-Theme on your localhost. To fix this, hop back over to your WordPress site, and go to your website’s homepage and click "customise" in the top admin bar. You’ll then see the following:

The side customise panel in WordPress

Click on "Homepage Settings" and then set your homepage as a static page like the following:



There is also the option on there to set your posts page, if you have added a posts/blog page you can set that also at this point.

Once these have been set, head back in to your Frontity project and open frontity.settings.js file again. In this settings file, you can reflect the changes you just made by adding the following:

const settings = {
  ...,
  packages: [
    ...,
    {
      name: "@frontity/wp-source",
      state: {
        source: {
          // Change this url to point to your WordPress site.
          url: "https://test.frontity.org/", 
          homepage: "/homepage", 
          postsPage: "/blog"
        }
      }
    }
  ]
}

Now, you’ll see your static homepage rendered in your localhost with the Mars-Theme. You’ll also notice that it’s not using your WordPress site’s menu, instead it’s still displaying the menu relating to the Frontity test site. This is actually hard coded in the Mars-Theme in frontity.settings.js. Let’s remove those menu items and instead pull in our dynamic menu from our WordPress installation, called from the REST API. Remember we already exposed this on the WordPress REST API side, so we just have to make some changes in our Frontity project to get this working.

First, in frontity.settings.js under "packages" / "name" / "state" / "theme", you’ll see "menu", which looks like the following:

"menu": [
  [
    "Home",
    "/"
  ],
  [
    "Nature",
    "/category/nature/"
  ],
  [
    "Travel",
    "/category/travel/"
  ],
  [
    "Japan",
    "/tag/japan/"
  ],
  [
    "About Us",
    "/about-us/"
  ]
],

Delete the above from frontity.settings.js. Once you’ve done that, then open the "components" directory under the "src" directory in your Frontity project’s Mars-Theme - src/components/ and add a new directory called "handlers" inside the components directory - src/components/handlers.Then add a menu-handlers.js file inside src/components/handlers/menu-handlers.js. In order to fetch entities from the WordPress API we need to add a handler. This will be a menuHandler.js component and it will contain the following code:

const menuHandler = {
    name: "menus",
    priority: 10,
    pattern: "/menu/:slug",
    func: async ({ link, params, state, libraries }) => {
        console.log("PARAMS:", params);
        const { slug } = params;

// Fetch the menu data from the endpoint
        const response = await libraries.source.api.get({
            endpoint: `/menus/v1/menus/${slug}`,
        });

// Parse the JSON to get the object
        const menuData = await response.json();

// Add the menu items to source.data
        const menu = state.source.data[link];
        console.log(link);
        Object.assign(menu, {
            items: menuData.items,
            isMenu: true,
        });
    },
};

export default menuHandler;

Once you’ve added the handler, you’ll need to import it in to your index.js file - packages/mars-theme/src/index.js. That will look like the following:

// ...
import menuHandler from "./components/handlers/menu-handler";

// ...

libraries: {
  // ...
  source: {
    handlers: [menuHandler],
  },
},

You’ll also have to add a beforeSSR method to the actions object like the following:

actions: {
  theme: {
    // ...
    beforeSSR: async ({ state, actions }) => {
      await actions.source.fetch(`/menu/${state.theme.menuUrl}/`);
    }
  },
},

At this point you should be able to see your WordPress website’s menu data in the console.logs in menu-handler.js. All you need to do now is create your ownNavigation.js component. I’m not going to cover all of the details for this part, as it’ll largely depend on your website’s design, but I will explain how to get the menu data in to the component from the REST API. Your component should look something like the following:

const Nav = ({ state }) => {
  const items = state.source.get(`/menu/${state.theme.menuUrl}`).items;

  console.log('ITEMS:', items);

  <SiteNavigation>
   ...
  </SiteNavigation>

}

Frontity defines state as "A JavaScript object containing all the state exposed by your package".

That concludes adding a dynamic menu.
Learn more about fetching menus from the WordPress REST API

Continue reading…
+ How to build a headless WordPress website with Frontity / ReactJS - Pt. 3

Go back to…
+ How to build a headless WordPress website with Frontity / ReactJS - Pt. 1

This story is also available @ https://www.nmk.dev/post/how-to-build-a-headless-wordpress-website-with-frontity-reactjs-pt-2-3933990bab54

How to build a headless WordPress website with ReactJS & Frontity - Pt. 1



I’ve previously written about Frontity the React framework for WordPress and how it can be a useful and very easy way to decouple WordPress from it’s front-end. Using the WordPress REST API and Frontity allows you to harness all the power of ReactJS and it’s component driven design model for your website’s front-end and still use WordPress for storing and serving your content.

In this 3 part tutorial, I want to summarise how you can get started with the framework and build a website with a decoupled WordPress as a headless Content Management System and a Frontity front-end application. Although the Frontity documentation is comprehensive, I found when I built my first Frontity website I had to dig through the documentation, basic tutorials and ask questions on the community forum to get the answers to some of the questions I had. Frontity’s "getting started" tutorial shows you how to set up a basic blog, but my use case for Frontity was a WordPress website, so the aim of this tutorial, will be to tell you how I did that.

This tutorial will cover the basic details, but I’ll also include links to the relevant documentation where full explanations on the framework’s concepts can be found.

Before I get started. I’m going to do a little recap on how exactly Frontity works.

So, here’s a little overview straight from the Frontity documentation…

"In a Frontity project, WordPress is used as a headless or decoupled CMS, just for managing the content. Frontity uses data from the WordPress REST API and generates the final HTML that is displayed in the browser using React.

You still use your WordPress dashboard to edit and create content in exactly the same way that you are accustomed to. As you make changes content is automatically updated in your Frontity site, just as it is when using a traditional WordPress theme.

Frontity apps require both a Node.js server and a WordPress server (PHP) to run on. And there are two main Frontity Modes (architectures or configurations):

Decoupled Mode: in this mode Frontity fetches the data from the REST API of the WordPress Server and returns the final HTML to the visitor as an Isomorphic React App.

Embedded Mode: in this mode the Frontity Embedded Mode plugin replaces the PHP theme and makes a request to the Frontity server to retrieve the HTML as an Isomorphic React App, which is returned to the visitor by WordPress.

Depending on the mode used, the main domain (e.g. www.domain.com) will be connected either to the WordPress/PHP Server (in Embedded mode) or to the Frontity/Node.js server (in Decoupled mode)." - How does Frontity work?

For the purposes of this tutorial, I will focus solely on the most commonly used (and in my opinion preferred) mode - Decoupled Mode.

Step 1

As stated above, the Decoupled Mode requires a WordPress Server. So the first place I like to start is finding a hosting provider and installing WordPress on it. Assuming you have purchased a domain name and hosting provider previously, I’ll spare you with these details. As long as you can install WordPress, then you’re good to go.

One thing to consider before you install WordPress however (although it’s not necessary), if you have the option to add a sub domain, sometimes it’s preferable to install WordPress on a subdomain like "wp.mydomain.com" with the intention of pointing the main domain "mydomain.com" at your Frontity installation that will be hosted elsewhere, my recommendation is Vercel, where in most cases, the free package can be used. Alternatively, your WordPress installation can live on an entirely different domain name.

Frontity only works with WordPress Versions <= 6.0.1 so if you’ve installed a more recent version, which at the time of writing is the case, then you’ll need to roll back to this.

Frontity works out of the box without having to install anything else on the WordPress side. However, the documentation only covers manually added menus. If you want the menus on your frontend to be automatically added when you add menu items in WordPress, then you’ll need to add a plugin to your WordPress installation. You’ll need to install and activate the WP-REST-API V2 Menus plugin. This plugin will help to expose your menus in the REST API.

Assuming you already have your design ready, you should start by adding the page/pages and then the menu/s to WordPress. Again, I’m working on the assumption that you’re familiar with the basics of WordPress in 2022, to spare you the details.

At this point, you should have some pages and menus added to your WordPress installation. And if you navigate to "mydomain.com/wp-json/menus/v1/locations" you’ll find that the menus have indeed been exposed in your site’s WordPress REST API.

You can also try adding some content to the pages, I usually do this in the WordPress block editor. Based on my design I’ll add blocks that basically outline and divide up my design’s structure, adding class names to content sections/divs I intend to style in Frontity. This will include content like images, pdf documents and even contact forms. It’s important to remember that WordPress plugins can be used in a Frontity front-end app.



Continue reading…

How to build a headless WordPress website with Frontity / ReactJS - Pt. 2 
+ How to build a headless WordPress website with Frontity / ReactJS - Pt. 3

This story is also available @ https://www.nmk.dev/post/how-to-build-a-headless-wordpress-website-with-frontity-reactjs-pt-1-9cc49f63981e

The Frontity Demo on its website

Fronting up: Headless Wordpress and React with Frontity

About a year ago, I was approached about building a new website with a CMS for a client as a freelance project. Firstly, I don’t do that many paid freelance projects these days, and secondly when I have in the past, I usually keep it simple and reach for the world’s most favourite Content Management System - Wordpress [sic]. I have used Wordpress as a go to CMS in plenty of small freelance projects in the past as many others probably have, because it offers a basic CMS for free and has been around so long I’m familiar with how it works. I’m not a PHP developer, so I usually just buy a premium theme and install it, make some customisation, and boom… We’re good to go.

This time however, I wanted to see if there was a way I could incorporate using React in the project and build a React application, as my skill set is Javascript and I’m trying to use React for building front ends where possible. So I spent some time researching free headless Content Management Systems and there were only a couple of options that I thought feasible. Pretty much all of these relied on leveraging something like Gatsby or Hugo, as well as GraphQL and in some cases a CMS like Drupal or Netlify and other JAMStack tech. All of which I hadn’t used before and since this was a paid for job, I didn’t have that much time to start learning those frameworks or tech stacks.

Then I stumbled upon a framework called Frontity. Frontity allows you to leverage Wordpress as a headless CMS using the Wordpress REST API. You can then build your front end app in Frontity using React components, and "Frontity will Provide an instant experience with dynamic content using Serverless Pre-rendering (SPR)." You can then deploy the front end app to any Node.js or severless hosting provider, though they recommend using Vercel, which I happen to use in my other projects anyway, so this was another advantage for me. The recommended install model & the one I stuck to, has your Wordpress installation installed on a sub domain of your main domain and then your main domain name pointing to the Vercel Sever.

"Frontity will Provide an instant experience with dynamic content using Serverless Pre-rendering (SPR)."

All in all, Frontity ticks a lot of boxes for this kind of project. My client has the familiarity of posting and editing content in Wordpress and I have the familiarity and freedom of building the front end components in React and Javascript. Your finished website/Frontity app is also pretty fast, compared to a Wordpress website and page routing is taken care of by the Frontity API, so there’s no need for expertise in React Router. In fact because it’s an opinionated framework that is built specifically to work with only Wordpress, it has it’s own state manager and uses CSS-in-JS for the styling. Thanks to this, you don’t have to figure out how to configure these tools or learn additional frameworks and tech like GraphQL, Redux or Webpack. Everything is baked in and it’s pretty easy to get up and running with it.

Frontity also has a few of its own node packages you’ll need to install to handle certain functionality and you can also install any other npm packages you wish. Frontity also has some pre-existing themes that you can install to start your project with a basic structure and then customise. It also has extensions that can be activated and deactivated without code changes and are reusable across projects. Its also SEO friendly and does both server-side & client-side rendering.

Something I found extremely useful though was that Wordpress plugins can still be used on the front end as long as they are compatible with the Wordpress REST API. So this meant things like contact forms, and PDF readers are all handled by Wordpress. It also allows you to work with Custom Post Types and Custom Taxonomies if you so wish, you’ll just have to tweak a few settings in your project.

So is there good documentation I hear you ask? Well, yes there’s excellent documentation and an active community and message board. There’s also a youtube channel with some really helpful videos. My only concern and a recent one at that, is that Frontity was recently acquired by Wordpress’ parent company Automattic. What this was going to mean for the framework, I wasn’t initially sure, but according to a blog post and Twitter thread the team behind Frontity have joined Automattic to work on Wordpress Core. I did notice a drop in active users on the Frontity community and it did start to get slow in getting support at times, but then other users usually reach out, I try to return the favour when possible. However, because it’s an Open Source technology, the hope is that its users & community will still try to help in actively maintaining it moving forward. Here’s hoping anyway, so spreading the word about the framework I hope will entice others to check it out.

In conclusion, I think Frontity provides a really useful framework and easy to use API to both hobby web developers and freelance web developers who need an affordable headless CMS that’s probably familiar to them and that will work with a React tech stack. I just hope that there is a future for Frontity, now that it’s not as actively maintained by the founding team. Hopefully I’ve piqued your interest and you’ll check it out and consider it for a future project.

This story is also available @ https://www.nmk.dev/post/fronting-up-headless-wordpress-and-react-with-frontity-10422993a9db

Incrementing and Decrementing Dates in Javascript

Manipulating dates in Javascript

In my day job for a London Council, I recently I had to build the front end for a reservation system where users could reserve appointment slots for a Covid-19 test. I was going to build it using Vanilla Javascript and ES6. How it was going to work, was that the backend, where the appointment slots were created would be provided to me as a JSON feed, so I just needed to be able to find a way to consume the feed and then build out the front end with the data.

This was all relatively straightforward to do, I fetched the JSON feed and was able to build out the relative parts of the application, until I came to the part where I had to build the date controls. The date controls would use a set of ‘previous’ and ‘next’ buttons, where clicking ‘previous’ would decrement the date by 1 day and the ‘next’ button would increment the date by 1 day. The url for the JSON feed would have a date in ISO-8601 format (YYYY-MM-DD) as a variable that if incremented or decremented, the updated url would be used to fetch the new JSON data.

Having never really worked much with dates in the past, and having used dayJS the few times when I had, my initial thought was to reach for it again. DayJS exists because working with dates in Javascript is usually a nightmare for most devs. However dayJS didn’t seem to offer what I was looking for, and would have been overkill anyway, given the extra weight it would have added to my bundle. I had tried searching Stack Overflow for an answer and couldn’t quite find an example for my use case. In the end I used the native Javascript Date Object, but knowing where to start with it and knowing which of the pitfalls surrounding Javascript Dates to avoid was initially tricky. I spent a few hours reading MDN and W3CSchools to better understand the myriad of methods that can be used with dates. Whether or not daylight saving was going to affect what I wanted to do. And how to add/subtract 1 day in Javascript. All things that have to be considered when handling dates.

With the lack of examples of what I was trying to achieve, available on Stack Overflow, medium or elsewhere on the Internet I decided I’d document how I solved this issue for what I felt would be fairly common use case.

Below is what my fetch call with the typical url would look like, or so I thought initially…

fetch(`https://www.some-url/apps/bookings/calendar-json.php?todaysDate=${year}-${month}-${day}`)

let today = new Date();
let yyyy = today.getFullYear();
let mm = today.getMonth()+1; // getMonth() is zero-based
let dd  = today.getDate();

Initially, I tried to have 3 separate variables for the day, month & year and then increment them individually. Since what I was trying to do, was effectively a counter only with dates, I started by building a simple counter in Javascript. I could then increment or decrement the day variable. However, what I found was that manipulating the day separately, meant that the month wouldn’t increment/decrement in tandem with when you reach the end of/beginning of the month.

I realised I would need to use the setTime and getTime methods to achieve what I wanted.

Rather than separate out day, month & year as individual variables I set it as just one. So now my fetch call looked like this…

fetch(`https://www.some-url/apps/bookings/calendar-json.php?todaysDate=${date}`)

First I simply get the date, :

let date = new Date();
console.log(date);
// returns Mon Nov 01 2021 17:28:54 GMT+0000 (Greenwich Mean Time)

Then call the setTime method on the date variable. The setTime() method sets a date and time by adding or subtracting a specified number of milliseconds to/from midnight January 1, 1970. Then I pass the getTime method on the date variable in to the setTime method. The getTime() method returns the number of milliseconds since January 1, 1970.

Doing this will give us today’s date in milliseconds since January 1, 1970.

let today = date.setTime(date.getTime());
console.log(today)

Then I needed to have a variable that represented a full day in milliseconds, in order to add or subtract. 1 day in milliseconds can be calculated like so:

let day = 24 * 60 * 60 * 1000;

I also initialise 2 variables for setting the dates.

let dateVal; 
let urlDate;

dateVal will store the result from adding together today in milliseconds and 1 day in milliseconds. urlDate will store the dateVal result in a human readable formatted date form.

Then in order to increment or decrement I need an eventListener on the set of controls and inside them I do my addition and subtraction respectively. 
That looks like this:

const next = document.querySelector(".next");
next.addEventListener("click", (e) => {
   dateVal = today += day;
   urlDate = new Date(dateVal);
   let formattedDate = urlDate.toISOString().slice(0, 10);
   console.log(formattedDate);
});

const prev = document.querySelector(".prev");
prev.addEventListener("click", (e) => {
   dateVal = today -= day;
   urlDate = new Date(dateVal);
   let formattedDate = urlDate.toISOString().slice(0, 10);
   console.log(formattedDate);
});

Once I have the result from adding/subtracting today in milliseconds to/from 1 day in milliseconds, I then need to pass that in to the date object constructor to get back an actual formatted date which will be stored in urlDate.

Once I have the incremented or decremented date from the eventListener, then it will need to be converted to ISO-8601 format, I can do that by calling the toISOString() method on urlDate. ISOString() method returns a time with it, but as I don’t need this, it can be removed by .slicing the string at the 10th character (see above).

fetch(`https://www.some-url/apps/bookings/calendar-json.php?todaysDate=${formattedDate}`)

Boom! And there we have it. Something which is actually pretty easy to solve, but my fear of working with dates in Javascript initially held me back. Before reaching for a date plugin or module in your next project, why not have a go at it using the Date object natively.

And here’s a working codesandbox:



This story is also available @ https://www.nmk.dev/post/incrementing-decrementing-dates-in-javascript-3af8dc13f797

On my last few React projects I’ve had a need for a simple off-canvas panel. One was for the mobile menu on my portfolio site and another…

How to build a simple off-canvas panel in React

What I’ve learnt from my 2 years as a Front End Engineer in the public sector.

Software Engineering in the UK public sector

Niall McKenna

My Writing

How to build a simple off-canvas panel in React

Software Engineering in the UK public sector

How to build a headless WordPress website with Frontity/ReactJS — Pt. 3

How to build a headless WordPress website with Frontity/ReactJS — Pt. 2

How to build a headless WordPress website with Frontity/ReactJS — Pt. 1

Fronting up: Headless Wordpress and React with Frontity

Incrementing and Decrementing Dates in Javascript

Follow Me