DEV Community: Michał Hawełka

WeAreDevelopers World Congress - key takeaways

Michał Hawełka — Tue, 01 Aug 2023 06:01:52 +0000

WeAreDevelopers World Congress is one of the biggest IT events in Europe. This year I got to be one of the participants. Two days packed with talks on a wide range of topics in IT. I attended mostly those revolving around frontend development, green IT and accessibility. Here’s a quick summary of what I saw.

Sir Tim Berners-Lee's keynote

It started strong with a keynote by Sir Tim Berners-Lee, inventor of the World Wide Web. It was nice to hear his thoughts on the future of the internet - decentralized, safe and with data sovereignty, even though his ideas seem… a little bit utopian. I must say I took his words with some skepticism, but I get where he’s coming from. Great minds think big, so maybe my little brain is too overwhelmed with his ideas 😀

He focused on Solid API, the web standard of the future. I must say - all of this sounds compelling and I’ll dig deeper into the topic. Maybe then I’ll understand the hype. For now - take a look at it yourselves:

Solid Project

Fighting climate change with code

The two most interesting talks on the first day were revolving around green coding. Both “Reducing the carbon footprint of your website” by Ines Akrap (fantastic talk, it’s a pity it was so short) and “GreenCoding - Let’s build sustainable software to fight climate change!” by Tim Schade gave me a pretty good idea where to start and how to make our software “green”. Especially Ines’ talk was inspiring to me as she showed what can we do from the frontend development perspective.

That’s great - but what are the key takeaways from those talks?

First of all, it’s important to understand that Digital is not equal to Green. When talking about something being green we must consider the electricity usage, but also the source of electricity, time of day or country in which it is produced as the emissions differ quite largely.

Check this visualization on Twitter X

There’s a great article on calculating digital emissions on Sustainable Web Design’s website: Calculating Digital Emissions

And how to reduce the website’s carbon footprint? Ines gave quite a few tips to do that:

using “green” hosting - check where your hosting provider has its servers, what kind of electricity sources are they using etc.
remove unused features
reduce the number of font files
use images of the proper size
disable autoplay on the videos on your site and (if possible) use a custom clickable thumbnail instead of a video player - that would speed up loading for most of the people that won’t watch the video
use caching and CDNs

That’s just a few tips, but even those can greatly reduce your website’s carbon footprint.

One question stands - why would you care? Your website is a drop in the sea, right? Well, even if one visit to your website generates several kg of CO2 - think how much it would generate after 1000, 10000 or even a million visits. Then the numbers start to become scary.

Applied Psychology: Psychology-based UI improvements

“Applied Psychology: Psychology-based UI improvements” by Keren Kenzi was a really fast talk on how psychology principles can make websites more compelling to the user. As it was only 10 minutes it was a brief introduction to the topic, but an interesting one. I’ll read about this more.

Breaking the bias in tech

Anna John’s story about changing careers and becoming an engineering manager as a woman was inspiring. She gave us some tips on how to fight biases in Tech, both as a privileged person (straight white male, hello) and as a person in the opposite situation (pretty much everybody else unfortunately).

The key takeaways for me are as follows:

Don’t be afraid to change careers
Set a goal and use failures to your advantage
Get better at saying no and setting boundaries

Saving the world and making it a better place

Hollie Gruber talked about our possibilities as developers to do something good. How to help non-profits using our skills? How to find a suitable beneficiary? What you can do? There is no simple answer to these questions, but you can make your search easier using one of the links that Hollie shared with us:

Impact Cloud - a platform that helps connect non-profits with big companies that can provide their services free or at discount
NTEN - non-profit networking community
Fast Forward - a place where you can find top tech non-profits
Good Tech Fest - conference on doing good in tech (happening both online and in Washington, DC)
NetHope Global Summit - another meeting place where you can find out how technology can help with making this world a better place

Hollie also showed us the UN’s 17 goals for sustainable development. It was the first time I came to know about it and I encourage you to learn more about it here: UN's Goals of Sustainable Development

It’s easy to create a good-looking product, but what about a useful one?

This talk by Eleftheria Batsou was in a nutshell about the differences between UX and UI, UX principles and do’s and don’ts. Well put introductory stuff, a good start for someone that would like to dig deeper into the topic.

The most important takeaway from it though would be 10 usability heuristics for UI design - those were created by Jakob Nielsen and go as follows:

Visibility of system status
Match between the system and the real world
User control and freedom
Consistency and standards
Error prevention
Recognition rather than recall
Flexibility and efficiency of use
Aesthetic and minimal design
Help users recognize, diagnose and recover from errors
Help and documentation

They are great as you don’t have to be a UI professional to make use of those guidelines. You can read more about it on Nielsen Norman Group’s website

Accessibility with Web Components

Talk by Manuel Mauky. I’m going to be honest - Web Components are not my cup of tea. I never worked with them and I never really had any interest in them. But lately, I went through a course on Web Components on Frontend Masters and I kinda see the appeal to use them. What I didn’t see was that accessibility could be an issue. Manuel’s talk not only made me aware of this but also provided me with solutions. Cool stuff!

From zero to hero: NextJS 13 and TailwindCSS for Beginners

Talk by Marius Obert. I know, I know, NextJS and TailwindCSS are all the rage now. I also jumped on that ship and I must say I like it. Both technologies (frameworks? libraries?) are really fun to work with. So why did I go to the talk that has “beginners” in its name? Well, NextJS 13 is pretty new - I wanted to get the view from the most modern perspective. And even though most of the stuff presented wasn’t new to me I still had a great time during the talk. Kudos to Marius!

Is it worth it?

100%. Two days of inspiring talks and networking. I liked it and would recommend it if you have the option to go there next year. If you are an IT professional you’ll find something interesting there. So, see you next year in Berlin?

How to create accessible buttons in HTML

Michał Hawełka — Wed, 05 Jul 2023 08:59:45 +0000

Accessibility was always important, but lately it gained even more traction and if you don’t know how to create accessible websites, you can’t really call yourself a good frontend developer. That’s a bold statement, I know, but it’s true, just deal with it.

Today we’ll look at one of the most basic elements of any website - a button. How to make it accessible? Without further ado - let’s just jump into it.

First and foremost - use a button tag. Why? Why not a div for example? Here you have a few reasons button tag is the better choice:

It’s semantically correct. Semantic HTML is really important, it helps with code readability and also helps web crawlers better understand our website.
It’s focusable and clickable by default. You don’t need to implement those behaviours (but if you use some CSS frameworks that reset styles for every element - remember to implement hover and focus states)
It’s recognisable by screen readers. When you use any of the screen readers it will announce the button tag as, well, a button.

Is that it? That would be great, wouldn’t it?
But no, next thing we need to talk about is button content. Here we can go three ways:

Text
Icon + text
Only Icon

Text buttons

In this case the best thing we can do is to just use the text that is self explanatory. We don’t need to put any additional attributes to make this kind of button accessible.
There can be occasions where you’d be tempted to use aria-label to “overwrite” the text on the button. I strongly recommend you not to do it - it is against one of the WCAG principles.

NOTE: You can check all the code that I use in this article here: Codepen

<html lang="en">
  <body>
    <button>This is a test button</button>

    <!-- incorrect -->
    <button aria-label="This is a different button">This is another button</button>
  </body>
</html>

Icon with text buttons

The second case - icon with text is also quite simple. We can actually use the same technique as for the simple text, but with one additional thing - we’ll need to add aria-hidden=true attribute for the svg icon. This way screen readers will ignore the icon and read only the text.

One thing also worth doing is to add focusable=false attribute as some of the old browsers focus on svg for some reason.

<button>
    <svg class="svg-icon" viewBox="0 0 20 20" aria-hidden="true" focusable="false">
        <title>The icon</title>     
        <path d="M9.719,17.073l-6.562-6.51c-0.27-0.268-0.504-0.567-0.696-0.888C1.385,7.89,1.67,5.613,3.155,4.14c0.864-0.856,2.012-1.329,3.233-1.329c1.924,0,3.115,1.12,3.612,1.752c0.499-0.634,1.689-1.752,3.612-1.752c1.221,0,2.369,0.472,3.233,1.329c1.484,1.473,1.771,3.75,0.693,5.537c-0.19,0.32-0.425,0.618-0.695,0.887l-6.562,6.51C10.125,17.229,9.875,17.229,9.719,17.073 M6.388,3.61C5.379,3.61,4.431,4,3.717,4.707C2.495,5.92,2.259,7.794,3.145,9.265c0.158,0.265,0.351,0.51,0.574,0.731L10,16.228l6.281-6.232c0.224-0.221,0.416-0.466,0.573-0.729c0.887-1.472,0.651-3.346-0.571-4.56C15.57,4,14.621,3.61,13.612,3.61c-1.43,0-2.639,0.786-3.268,1.863c-0.154,0.264-0.536,0.264-0.69,0C9.029,4.397,7.82,3.61,6.388,3.61"></path>
    </svg>
  Button with icon
</button>

Icon buttons

The third case - icon only button is also pretty straightforward. We can just use aria-label on the button tag and the screen readers will ignore everything that’s inside the button (so in this case - an icon). We don’t even need to add aria-hidden=true on the icon.

<button aria-label="Like">
    <svg class="svg-icon" viewBox="0 0 20 20" focusable="false" width="40px">
        <title>The icon</title>     
        <path d="M9.719,17.073l-6.562-6.51c-0.27-0.268-0.504-0.567-0.696-0.888C1.385,7.89,1.67,5.613,3.155,4.14c0.864-0.856,2.012-1.329,3.233-1.329c1.924,0,3.115,1.12,3.612,1.752c0.499-0.634,1.689-1.752,3.612-1.752c1.221,0,2.369,0.472,3.233,1.329c1.484,1.473,1.771,3.75,0.693,5.537c-0.19,0.32-0.425,0.618-0.695,0.887l-6.562,6.51C10.125,17.229,9.875,17.229,9.719,17.073 M6.388,3.61C5.379,3.61,4.431,4,3.717,4.707C2.495,5.92,2.259,7.794,3.145,9.265c0.158,0.265,0.351,0.51,0.574,0.731L10,16.228l6.281-6.232c0.224-0.221,0.416-0.466,0.573-0.729c0.887-1.472,0.651-3.346-0.571-4.56C15.57,4,14.621,3.61,13.612,3.61c-1.43,0-2.639,0.786-3.268,1.863c-0.154,0.264-0.536,0.264-0.69,0C9.029,4.397,7.82,3.61,6.388,3.61"></path>
    </svg>
</button>

This is definitely the simplest and most supported solution. But what are the alternatives?

First one would be creating a sr-only or visuallyhidden class in your CSS and then using to create an “invisible” label. TailwindCSS defines sr-only class as follows:

.sr-only {
    **position: absolute;
    width: 1px;
    height: 1px;
    padding: 0;
    margin: -1px;
    overflow: hidden;
    clip: rect(0, 0, 0, 0);
    white-space: nowrap;
    border-width: 0;
}

When you have this class in place you can then use it like this:

<button>
    <svg class="svg-icon" viewBox="0 0 20 20" aria-hidden="true" focusable="false" width="40px">
        <title>The icon</title>     
        <path d="M9.719,17.073l-6.562-6.51c-0.27-0.268-0.504-0.567-0.696-0.888C1.385,7.89,1.67,5.613,3.155,4.14c0.864-0.856,2.012-1.329,3.233-1.329c1.924,0,3.115,1.12,3.612,1.752c0.499-0.634,1.689-1.752,3.612-1.752c1.221,0,2.369,0.472,3.233,1.329c1.484,1.473,1.771,3.75,0.693,5.537c-0.19,0.32-0.425,0.618-0.695,0.887l-6.562,6.51C10.125,17.229,9.875,17.229,9.719,17.073 M6.388,3.61C5.379,3.61,4.431,4,3.717,4.707C2.495,5.92,2.259,7.794,3.145,9.265c0.158,0.265,0.351,0.51,0.574,0.731L10,16.228l6.281-6.232c0.224-0.221,0.416-0.466,0.573-0.729c0.887-1.472,0.651-3.346-0.571-4.56C15.57,4,14.621,3.61,13.612,3.61c-1.43,0-2.639,0.786-3.268,1.863c-0.154,0.264-0.536,0.264-0.69,0C9.029,4.397,7.82,3.61,6.388,3.61"></path>
    </svg>
    <span class="sr-only">Like</span>
</button>

And as you can see and hear - it works as expected (I strongly recommend you to try focusing on the buttons with VoiceOver turned on - it really helps understanding the things that we are doing here).

Another solution is a little bit more complicated. We need to use aria-labelledby on the button and then provide a hidden label inside. Be aware that even though the label will be hidden, labelledby attribute will still be able to access it.

It would look like this:

<button aria-labelledby="likeBtn">
    <svg class="svg-icon" viewBox="0 0 20 20" aria-hidden="true" focusable="false" width="40px">
        <title>The icon</title>     
        <path d="M9.719,17.073l-6.562-6.51c-0.27-0.268-0.504-0.567-0.696-0.888C1.385,7.89,1.67,5.613,3.155,4.14c0.864-0.856,2.012-1.329,3.233-1.329c1.924,0,3.115,1.12,3.612,1.752c0.499-0.634,1.689-1.752,3.612-1.752c1.221,0,2.369,0.472,3.233,1.329c1.484,1.473,1.771,3.75,0.693,5.537c-0.19,0.32-0.425,0.618-0.695,0.887l-6.562,6.51C10.125,17.229,9.875,17.229,9.719,17.073 M6.388,3.61C5.379,3.61,4.431,4,3.717,4.707C2.495,5.92,2.259,7.794,3.145,9.265c0.158,0.265,0.351,0.51,0.574,0.731L10,16.228l6.281-6.232c0.224-0.221,0.416-0.466,0.573-0.729c0.887-1.472,0.651-3.346-0.571-4.56C15.57,4,14.621,3.61,13.612,3.61c-1.43,0-2.639,0.786-3.268,1.863c-0.154,0.264-0.536,0.264-0.69,0C9.029,4.397,7.82,3.61,6.388,3.61"></path>
    </svg>
    <span id="likeBtn" hidden>Like</span>
</button>

Setting the id on the span is important because that’s how we can access the label from the labelledby attribute.

All three solutions work the same. That’s why my favourite is just setting the aria-label, it the simplest solution.

These were the most important accessibility adjustments you can make to ensure your buttons work well with screen readers. But what about people with visual impairments that do not use screen readers? Here we have two additional things to take care about and we’ll be all set.

Sizing

First let’s talk about sizing. In the WCAG guidelines there is a criterion 2.5.5 - Target Size. It’s described as follows:

The size of the target for pointer inputs is at least 44 by 44 CSS pixels.

There are few exceptions and you can see those on the screen now, they are not relevant in this specific case.

So let’s ensure that our buttons are in fact big enough. I’m not a fan of using pixels, I’d much rather go with rems or ems. This will also help if the user changes his base font size - the button will still be sized properly.

button {
  min-height: 3rem;
  min-width: 3rem;
}

I used 3rem as usually the root font size is 16px, so 3rem gives us 48px. But if the user zooms in to, let’s say, 24px, the button will be larger.

Ok, with that out of the way - let’s handle the last thing I want to talk about today - contrast.

Contrast

WCAG guidelines say:

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1 - for AA success criterion, and 7:1 for AAA criterion.

The best tool to use here is contrast checker by WebAIM https://webaim.org/resources/contrastchecker/

You can just put your button color there and you’ll get the text color and vice versa. Simple, yet great tool. In the case of my examples let’s say I wanted a green buttons.

As you can see white text fails all of the criteria, but black should be OK. As you can see while I’m scrolling through the colors the contrast ratio changes and also different criteria are passing. With straight black we get a contrast of over 10 to 1. So that’s going to work!

And that’s it! Those are the things that you can do to make your buttons accessible. I hope you liked it, if you did - consider following me on Twitter, Dev.to and LinkedIn, more frontend and accessibility related content is on the way.

SEO handling in Strapi [Building Personal Blog Website Part 7]

Michał Hawełka — Mon, 12 Dec 2022 14:55:50 +0000

There are two approaches for SEO in Strapi - you can create a SEO component by hand or use a SEO plugin which provides an extensive component. In this guide you’ll use the plugin, but you’ll edit the component a bit so it has only the relevant (for us) data.

Open your Strapi repository and install SEO plugin:

yarn add @strapi/plugin-seo
yarn build
yarn develop

Now log in to admin panel locally and click on the SEO panel on the left hand side - this should initialize the plugin:

Go back to Content-type builder - there should be two new components created:

You’ll use only SEO one, you’ll get rid of the MetaSocial component. Why? This component assumes you’ll use a different image, title and description for each social media, while in reality the title and description will stay the same and the image used for Facebook and LinkedIn would be the same. Only for Twitter you’d need another image - and you’ll make the change to the SEO component so it allows you to upload this as well. Start with deleting metaSocial from Seo component.

Now add a new field for metaTwitterImage:

And just to keep your CMS clean - Edit MetaSocial component and press Delete - you’ll not need it anymore.

It’s time to add Seo component to your Posts. Still in Content-type builder open Post collection type and add another field:

Select Component and Use an existing component

Now select seo component, put a name (preferrably seo) and select Single component. Then save the Post model and you’ll be set.

Now in VSCode (or Terminal) commit all the files and publish changes to GitHub and Railway.

When it rebuilds, log in to admin panel on your hosted Strapi. Go to the content manager, open any of your posts and there you should be able to add SEO. Provide title, description, metaImage (preferably 1200x630 since this is a fitting size for both Facebook and LinkedIn) and metaTwitterImage (here use 560x300). If you’d like - provide SEO for all your posts. If you’re done - you can go to VSCode and open your Next.js app.

You need to do three things here:

Update GraphQL query in [slug].js so it fetch also SEO data.
Use next/head to add proper meta tags
Validate if SEO data actually exists - SEO is optional in your CMS.

Let’s start with the first task. Open [slug].js and in GraphQL query in getStaticProps method add the following fields to be fetched:

SEO {
  metaTitle
  metaDescription
  metaImage {
    data {
      attributes {
        url
      }
    }
  }
  metaTwitterImage {
    data {
      attributes {
        url
      }
    }
  }
}

Now it’s time to use the SEO data that you have. Update your Post component as follows:

export default function Post({ postData }) {
  return (
    <>
      <Head>
        <title>{postData.attributes.title}</title>
        {postData.attributes.SEO && (
          <>
            <meta
              name="description"
              content={postData.attributes.SEO.metaDescription}
            />
            <meta property="og:title" content={postData.attributes.title} />
            <meta property="og:type" content="article" />
            <meta
              property="og:image"
              content={postData.attributes.SEO.metaImage.data.attributes.url}
            />
            <meta
              property="twitter:image"
              content={
                postData.attributes.SEO.metaTwitterImage.data.attributes.url
              }
            />
            <meta property="twitter:card" content="summary_large_image" />
          </>
        )}
      </Head>
      <ReactMarkdown className="prose prose-sm md:prose-lg lg:prose-xl xl:prose-2xl prose-slate w-11/12 mx-4 my-8">
        {postData.attributes.content}
      </ReactMarkdown>
    </>
  );
}

The {postData.attributes.SEO && ( ensures that you’ll render meta tags only when the SEO data is actually provided. You should aim to provide it for every post as this not only helps with Google ranking, but also with properly displaying the relevant data while sharing posts on social media.

When that’s done rebuild your app locally to check if everything is OK. If it is - commit your changes and push them to GitHub. When the app rebuilds on Netlify open any of the posts that you provided SEO data for. First of all you should notice that on the browser bar there is an actual title of the post.

For the rest of the metadata you’ll need to go to https://developers.facebook.com/tools/debug/ and enter URL to your post and click Debug:

You should get a similar result. You see the link preview - everything looks fine. There are also warnings that you are missing og:url and og:description metatags - add those on your own if you want. Let this be my challenge for you :)

One more thing while you’re at it. Add some meta tags to your _app.js file - this will ensure that every page on your site has at least the basic metadata in place:

function MyApp({ Component, pageProps }) {
  return (
    <div className="flex flex-col items-center bg-white">
      <Head>
        <meta charset="UTF-8" />
        <meta name="author" content="YOUR NAME" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
      </Head>
      <Navbar />
      <Component {...pageProps} />
      <Footer />
    </div>
  );
}

Charset, author and viewport are a nice addition to your SEO. Title and description should be provided per page so just use the snippet below and add it to all of the pages([slug].js, index.js etc.) - you can also extract it to a separate component and use it this way - your choice:

<Head>
  <title>YOUR TITLE</title>
  <meta name="description" content="YOUR_DESCRIPTION" />
</Head>

And that’s all! Now you have a basic SEO provided on your website. In the next part we’ll dive deep into pagination, topic which will be extremely useful when the blog post count grows.

Search functionality [Building Personal Blog Website Part 6]

Michał Hawełka — Mon, 05 Dec 2022 06:15:28 +0000

Now you’ll use the experience from displaying list of posts for specific tag to create a Search component. User will be able to search for any query and should get a list of posts that fulfill the query.

Start with creating new route pages/search/[query].js - it will be mostly based on [tag].js but with a twist! This time you will not use getStaticPaths as it is not possible to generate all queries that the user can put in the search bar. You’ll need to fetch results dynamically from the client.

And as you’ll be fetching posts dynamically you need to ensure the user is aware that something is loading. Usually there are two ways of indicating this to the user visually - spinners or progress bars and skeleton content. The first solution is easier, but does not prepare the user for what’s coming and also it has some effects on a performance metric called Content Layout Shift (you can read more about it HERE). The second solution requires a bit more work, but it’s worth it - you’ll need to prepare a blank template of the loaded content to indicate to the user that something is loading. The end result will look like this:

So before you’ll implement [query].js let’s just quickly prepare this skeleton Blog Post preview. Create a new component components/BlogPostPreviewSkeleton.jsx and put this code inside:

import React from "react";

const BlogPostPreviewSkeleton = () => {
  return (
    <div
      role="status"
      className="space-y-8 animate-pulse md:space-y-0 md:space-x-8"
    >
      <div className="flex flex-col justify-between max-w-sm rounded overflow-hidden shadow-lg">
        <div className="flex justify-center items-center w-full h-48 bg-gray-300 rounded sm:w-96 dark:bg-gray-700">
          <svg
            className="w-12 h-12 text-gray-200"
            xmlns="http://www.w3.org/2000/svg"
            aria-hidden="true"
            fill="currentColor"
            viewBox="0 0 640 512"
          >
            <path d="M480 80C480 35.82 515.8 0 560 0C604.2 0 640 35.82 640 80C640 124.2 604.2 160 560 160C515.8 160 480 124.2 480 80zM0 456.1C0 445.6 2.964 435.3 8.551 426.4L225.3 81.01C231.9 70.42 243.5 64 256 64C268.5 64 280.1 70.42 286.8 81.01L412.7 281.7L460.9 202.7C464.1 196.1 472.2 192 480 192C487.8 192 495 196.1 499.1 202.7L631.1 419.1C636.9 428.6 640 439.7 640 450.9C640 484.6 612.6 512 578.9 512H55.91C25.03 512 .0006 486.1 .0006 456.1L0 456.1z" />
          </svg>
        </div>
        <div className="px-6 py-4">
          <div className="h-2.5 bg-gray-200 rounded-full dark:bg-gray-700 w-48 mb-4"></div>
          <div className="h-2 bg-gray-200 rounded-full dark:bg-gray-700 max-w-[480px] mb-2.5"></div>
          <div className="h-2 bg-gray-200 rounded-full dark:bg-gray-700 mb-2.5"></div>
          <div className="h-2 bg-gray-200 rounded-full dark:bg-gray-700 max-w-[440px] mb-2.5"></div>
          <div className="h-2 bg-gray-200 rounded-full dark:bg-gray-700 max-w-[460px] mb-2.5"></div>
          <div className="h-2 bg-gray-200 rounded-full dark:bg-gray-700 max-w-[360px]"></div>
        </div>

        <div className="px-6 pt-4 pb-2">
          <div className="h-2 bg-gray-200 rounded-full dark:bg-gray-700 mb-2.5"></div>
        </div>
        <span className="sr-only">Loading...</span>
      </div>
    </div>
  );
};

export default BlogPostPreviewSkeleton;

I used the code from Flowbite, but adjusted it to my needs (so the layout looks kinda like BlogPostPreview component). As you can see there’s also a span for screen readers (it will be read instead of all the other content that is here).

The next step would be implementing actual Search Results page. In your [query].js put this code:

import { gql } from "@apollo/client";
import { useRouter } from "next/router";
import { useEffect, useState } from "react";
import client from "../../apollo-client";
import BlogPostPreview from "../../components/BlogPostPreview";
import BlogPostPreviewSkeleton from "../../components/BlogPostPreviewSkeleton";

export default function SearchResults() {
  const router = useRouter();
  const { query } = router.query;
  const [searchResults, setSearchResults] = useState(null);

  useEffect(() => {
    const getSearchResults = async () => {
      const { data } = await client.query({
        query: gql`
          query Posts {
            posts(sort: "publishedAt:desc"
                filters: { content: { containsi: "${query}" } }) {
              data {
                attributes {
                  title
                  slug
                  tags {
                    data {
                      attributes {
                        tagId
                        name
                      }
                    }
                  }
                  publishedAt
                  excerpt
                  cover {
                    data {
                      attributes {
                        url
                      }
                    }
                  }
                }
              }
            }
          }
        `,
      });
      return setSearchResults(data.posts.data);
    };
    getSearchResults();
        return () => {
      setSearchResults(null);
    };
  }, [query]);

  const preparePostPreviews = () => {
    if (searchResults.length > 0) {
      return searchResults.map((post) => (
        <BlogPostPreview post={post} key={post.attributes.slug} />
      ));
    } else {
      return (
        <h4 className="font-mono text-black text-lg sm:col-span-2 lg:col-span-3 text-center">
          No results
        </h4>
      );
    }
  };

  return (
    <section className="my-8 mx-4">
      <h2 className="font-mono text-black text-xl md:text-4xl text-center mb-8">
        Search results for: &quot;{query}&quot;
      </h2>
      <div className="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 ">
        {searchResults ? (
          preparePostPreviews()
        ) : (
          <>
            <BlogPostPreviewSkeleton />
            <BlogPostPreviewSkeleton />
            <BlogPostPreviewSkeleton />
          </>
        )}
      </div>
    </section>
  );
}

Let’s go through this code together bit by bit.

const router = useRouter();
const { query } = router.query;
const [searchResults, setSearchResults] = useState(null);

First things to put in your newly created component are some useful declarations. router and query will be needed to properly extract search query from the URL. useState for searchResults is a internal component state keeping all the search results data inside. Initialize it with null as at the beginning you don’t have the results yet.

Now let’s look at the useEffect:

useEffect(() => {
    const getSearchResults = async () => {
      const { data } = await client.query({
        query: gql`
          query Posts {
            posts(sort: "publishedAt:desc"
                filters: { content: { containsi: "${query}" } }) {
              data {
                attributes {
                  title
                  slug
                  tags {
                    data {
                      attributes {
                        tagId
                        name
                      }
                    }
                  }
                  publishedAt
                  excerpt
                  cover {
                    data {
                      attributes {
                        url
                      }
                    }
                  }
                }
              }
            }
          }
        `,
      });
      return setSearchResults(data.posts.data);
    };
    getSearchResults();
        return () => {
      setSearchResults(null);
    };
  }, [query]);

At the beginning you are fetching the data from GraphQL API. It’s a rather standard call, but one thing is worth noting - the containsi filter. containsi filter matches the query against the selected field but it does it case insensitive. We put this GraphQL call inside a local async function to easily call it in the body of the useEffect.

There’s also setSearchResult(null) on cleanup - when the user performs another search while on the search results page, the component will first unmount and clear the previous results and then mount again with new data. And of course in the dependency array you have query - you want to reload the data as soon as the query changes.

Later in the file you have this helper function:

const preparePostPreviews = () => {
    if (searchResults.length > 0) {
      return searchResults.map((post) => (
        <BlogPostPreview post={post} key={post.attributes.slug} />
      ));
    } else {
      return (
        <h4 className="font-mono text-black text-lg sm:col-span-2 lg:col-span-3 text-center">
          No results
        </h4>
      );
    }
  };

When there are search results you want to show a BlogPostPreview for every one of those. But if the search results array is empty you want to let the user know, that there was no results.

And finally a component itself:

return (
    <section className="my-8 mx-4">
      <h2 className="font-mono text-black text-xl md:text-4xl text-center mb-8">
        Search results for: &quot;{query}&quot;
      </h2>
      <div className="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 ">
        {searchResults ? (
          preparePostPreviews()
        ) : (
          <>
            <BlogPostPreviewSkeleton />
            <BlogPostPreviewSkeleton />
            <BlogPostPreviewSkeleton />
          </>
        )}
      </div>
    </section>
  );

Until the GraphQL query is finished you render the skeleton content, but as soon as the data is through - you use preparePostPreviews function to display the content properly.

Before you hook everything up you need to do a small adjustment in BlogPostPreview. You’ll display publishDate of every post. In your code add this snippet just over the div containing the title:

<h6 className="font-mono text-black text-xs mb-2">
  {new Date(post.attributes.publishedAt).toLocaleString()}
</h6>
<hr className="mb-2" />

Now you need to make sure that publishedAt is always fetched. Go through your GraphQL queries and add publishedAt as an additional fragment of data to be fetched. For example in [slug].js:

data {
  attributes {
    title
    slug
    content
    publishedAt
    cover {
      data {
        attributes {
          url
        }
      }
    }

When this is done you can test out your newly created Search Results page. Go to localhost:3000/search/YOUR-QUERY (replace YOUR-QUERY with some text that occurs in one of your posts). After a brief moment you should see the results:

You’re not finished though! One more thing to do! Let’s create a search bar on the navigation bar.

In components/Navbar.jsx add another item into the flex container (it should be the last one):

<form onSubmit={handleSearch}>
  <div className="flex">
    <label
      htmlFor="location-search"
      className="mb-2 text-sm font-medium text-gray-900 sr-only dark:text-gray-300"
    >
      Your Email
    </label>
    <div className="flex w-full">
      <input
        type="search"
        id='location-search"'
        className="rounded-l-lg rounded-r-none block p-2.5 z-20 text-sm text-gray-900 bg-gray-50 border-l-gray-50 border-l-2 border-r-0 border border-gray-300 focus:ring-blue-500 focus:border-blue-50"
        placeholder="Search..."
        required=""
      />
      <button
        type="submit"
        className="p-2.5 text-sm font-medium text-gray-400 bg-gray-50 rounded-r-lg border border-gray-300 focus:ring-4 focus:border-blue-500 focus:ring-blue-500"
      >
        <svg
          aria-hidden="true"
          className="w-5 h-5"
          fill="none"
          stroke="currentColor"
          viewBox="0 0 24 24"
          xmlns="http://www.w3.org/2000/svg"
        >
          <path
            strokeLinecap="round"
            strokeLinejoin="round"
            strokeWidth="2"
            d="M21 21l-6-6m2-5a7 7 0 11-14 0 7 7 0 0114 0z"
          ></path>
        </svg>
        <span className="sr-only">Search</span>
      </button>
    </div>
  </div>
</form>

handleSearch method will be implemented in a minute. The navigation bar should look like this now:

Now whenever user uses the search button or press Enter in this input they should be redirected to /search/SEARCH-QUERY. Let’s implement this.

const Navbar = () => {
  const router = useRouter();

  const handleSearch = (e) => {
    e.preventDefault();
    router.push(`/search/${e.target[0].value}`);
  };
// rest of the code...
}

First you need to use preventDefault because when form is submitted the site is reloaded and you don’t want it here. Second you need to use next/router to redirect user. It’s that simple. Rebuild your app, start your dev server and try searching for something with this new search bar.

And that’s it - now publish your changes on Netlify (you know how to do this already!). In the next part of this guide you’ll start to provide SEO for your blog posts.

Displaying all posts for specific Tag [Building Personal Blog Website Part 5]

Michał Hawełka — Wed, 21 Sep 2022 11:43:30 +0000

The blog post preview cards on your homepage display not only the cover, title and excerpt, but also a list of tags. It would be great if user could click on any of the tags and then see all blog posts connected to it. And that’s what you’ll implement today.

Let’s start with creating a new route in the Next.js application. Create a new folder tag in your pages directory. Inside create a file [tag].js - the goal is to have a route like YOUR_URL/tag/tag-name.

Now inside this [tag].js file you have to implement getStaticPaths and getStaticProps similarly to the Blog Post page.

For getStaticPaths you need to get a list of all tags that your CMS has:

export async function getStaticPaths() {
  const { data } = await client.query({
    query: gql`
      query Tags {
        tags {
          data {
            attributes {
              tagId
            }
          }
        }
      }
    `,
  });
  return {
    paths: data.tags.data.map((item) => ({
      params: { tag: item.attributes.tagId },
    })),
    fallback: false,
  };
}

In getStaticProps you’ll get all of the posts with specific tag:

export async function getStaticProps({ params }) {
  const { data } = await client.query({
    query: gql`
      query Tags {
        tags (
          filters: { tagId: { eq: "${params.tag}" } }
        ) {
          data {
            attributes {
              name
              tagId
              posts {
                data {
                  attributes {
                    title
                    slug
                    excerpt
                    publishedAt
                    cover {
                        data {
                            attributes {
                                url
                            }
                        }
                    }
                    tags {
                        data {
                            attributes {
                                tagId
                                name
                            }
                        }
                    }
                  }
                }
              }
            }
          }
        }
      }
    `,
  });

  return {
    props: {
      tagData: data.tags.data[0],
    },
  };
}

And with that out of the way you will display the results in a similar manner as on the homepage:

export default function Tag({ tagData }) {
  return (
    <section className="my-8 mx-4">
      <h2 className="font-mono text-black text-xl md:text-4xl text-center mb-8">
        Articles with &quot;{tagData.attributes.name}&quot; tag
      </h2>
      <div className="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 ">
        {tagData.attributes.posts.data.map((post) => (
          <BlogPostPreview key={post.attributes.slug} post={post} />
        ))}
      </div>
    </section>
  );
}

Most of your work is already done, but you have one more thing to do - hook up this newly created page with Tags on the BlogPostPreview. Adjust components/BlogPostPreview.jsx - instead of a blank <a href=”#”> use the following next/link:

<div className="px-6 pt-4 pb-2">
        {post.attributes.tags.data.map((tag) => (
          <Link
            href={`/tag/${tag.attributes.tagId}`}
            key={tag.attributes.tagId}
          >
            <a>
              <span className="inline-block bg-gray-200 rounded-full px-3 py-1 text-sm font-semibold text-gray-700 mr-2 mb-2">
                {tag.attributes.name}
              </span>
            </a>
          </Link>
        ))}
      </div>

Now rebuild your app and open it in dev mode:

yarn build
yarn dev

Open your blog and click on any Tag. It should open a list of blog posts with this tag:

Last thing to do is to make this change live on Netlify. Commit all of your changes and push it to GitHub. Netlify will rebuild your app and in a few minutes you’ll be able to use your new feature online. Well done!

Deploying Next.js app on Netlify [Building Personal Blog Website Part 4]

Michał Hawełka — Mon, 05 Sep 2022 11:52:11 +0000

Now it’s finally time to put your app online!

First you need to push your Git repository (create automatically while creating Next.js app) to GitHub. Go to github.com and log in (or create an account if you didn’t do this already). Create a new repository clicking on the upper right corner:

Add the name, decide whether the repository should be private or public and click Create. You should see something like this

Now go to the Terminal and in your app’s root folder commit all the files (if you put your environment variables into .env file then remember to add it to .gitignore). Now let’s push your repository to GitHub:

git remote add origin YOUR_GITHUB_REPOSITORY
git push -u origin main

When it’s through you should be able to see your files in GitHub:

Now you’re ready to deploy it to Netlify. Go to netlify.com and log in. I suggest logging in with GitHub. You should land on your dashboard where you can create a new site:

Select “Import an existing project” and then connect to GitHub and select your repository:

You should see something like this:

Leave all of the default values and click Deploy site. You’ll see that deployment is in progress. Wait a few minutes until it is done.

In case the deploy fails just click on the failed deploy and try doing it again. Railway sometimes has an issue of rejecting connections at the beginning.

When it’s done you’ll see the address of you new website:

Go to this address and you should see your work online!

Now whenever you push something to your repository Netlify will automatically rebuild your app. Remember! Changing something in your CMS does not trigger rebuilding so if you want to have fresh content - you’ll have to rebuild your app on Netlify manually on the Deploys tab on your Netlify dashboard:

Let’s make some changes to the site’s layout to see this automatic rebuild in action.

What your site lacks as of this moment is a nice navigation bar, basic footer and some responsive adjustments for the mobile. Create two new components in components directory:

Navbar.jsx

import Link from "next/link";
import React from "react";

const Navbar = () => {
  return (
    <nav className="z-0 w-full">
      <div className="z-10 bg-blue-500 shadow">
        <div className="max-w-7xl mx-auto px-2 sm:px-4 lg:px-8">
          <div className="flex flex-col sm:flex-row items-center justify-between gap-4 p-2 font-mono">
            <Link href="/">
              <a className="flex-shrink-0">
                <h1 className="font-bold text-xl uppercase text-white">
                  My Personal Blog
                </h1>
              </a>
            </Link>
            <div>
              <div className="flex gap-2">
                <Link href="/">
                  <a className="px-3 py-2 text-sm font-medium text-white hover:underline hover:underline-offset-4 hover:text-white hover:font-bold transition duration-150 ease-in-out cursor-pointer focus:outline-none focus:text-white focus:bg-gray-700 ">
                    Home
                  </a>
                </Link>
                <Link href="/about">
                  <a className="px-3 py-2 text-sm font-medium text-white hover:underline hover:underline-offset-4 hover:text-white hover:font-bold transition duration-150 ease-in-out cursor-pointer focus:outline-none focus:text-white focus:bg-gray-700 ">
                    About
                  </a>
                </Link>
                <Link href="/contect">
                  <a className="px-3 py-2 text-sm font-medium text-white hover:underline hover:underline-offset-4 hover:text-white hover:font-bold transition duration-150 ease-in-out cursor-pointer focus:outline-none focus:text-white focus:bg-gray-700 ">
                    Contact
                  </a>
                </Link>
              </div>
            </div>
          </div>
        </div>
      </div>
    </nav>
  );
};

export default Navbar;

and Footer.jsx

import React from "react";

const Footer = () => {
  return (
    <footer className="bg-blue-500 py-8 w-full">
      <div className="flex flex-wrap justify-center">
        <div className="text-sm text-white font-mono font-semibold py-1">
          Copyright © YOUR_NAME 2022
        </div>
      </div>
    </footer>
  );
};

export default Footer;

Now adjust your pages/_app.js file to use those newly created components

function MyApp({ Component, pageProps }) {
  return (
    <div className="flex flex-col items-center bg-white">
      <Navbar />
      <Component {...pageProps} />
      <Footer />
    </div>
  );
}

And finally make small changes in pages/index.js to better display the post list on various screen resolutions:

export default function Home({ posts }) {
  return (
    <section className="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 gap-4 my-8 mx-4">
      {posts.map((post) => (
        <BlogPostPreview post={post} key={post.attributes.slug} />
      ))}
    </section>
  );
}

Now commit all of the files and push the changes to GitHub.

git push

Wait a few minutes and check your website hosted on Netlify.

Looks better, doesn’t it?

And that’s it for today - your website starts going somewhere! In the next part of the series you’ll implement a simple Show all posts for specific Tag feature. See you then!

Basic Next.js app - blog post page [Building Personal Blog Website Part 3]

Michał Hawełka — Mon, 29 Aug 2022 11:35:00 +0000

You can see all your posts already on your homepage as cards. But now let’s go a step further - create a subpage for every post.

Before you create a subpage for a specific blog post - let’s just do a small adjustment in your current app. You’ll make changes in the _app.js file. Markup in this file is preserved between pages and works as a kind of a page layout. By default it renders just a page component. Now you’ll move the header from your homepage there. Use this code in _app.js:

function MyApp({ Component, pageProps }) {
  return (
    <div className="flex flex-col items-center">
      <h1 className="text-3xl uppercase font-serif font-bold my-8">
        My personal blog
      </h1>
      <Component {...pageProps} />
    </div>
  );
}

And remove the same markup from your index.js file:

export default function Home({ posts }) {
  return (
    <section className="grid grid-cols-3 gap-4">
      {posts.map((post) => (
        <BlogPostPreview post={post} key={post.attributes.slug} />
      ))}
    </section>
  );
}

Now whenever you’ll create a new subpage - it’ll always have the header “My personal blog”. Of course it would be best to add a navigation bar and footer here, but that’s not the main focus in this article series, so we’ll go back to this in the future, when there will be something to navigate to.

The next step would be creating a page for every blog post. Of course you’d want it to be generic so with every new post you’d get a new /post/slug-of-blogpost page. You can easily achieve that in Next.js using dynamic routes. Dynamic routes allow you to create a template page and then during site generation all the needed information are figured out by Next.js. Let’s just see how this works.

In pages directory create a new folder post. This will correspond to a new route /post. Inside create a file [slug].js - square brackets are important - they indicate that this is a dynamic route. In our case it will allow us to get a specific route for each blog post (for example /post/test-post or /post/my-first-post).

As you are creating a statically generated site you need to tell Next.js which routes it should generate. One way to provide this information is by creating a getStaticPaths function in your [slug].js file. This function will get slugs of all the blog posts and based on that it will inform Next.js which routes are needed.

export async function getStaticPaths() {
  const { data } = await client.query({
    query: gql`
      query Posts {
        posts(
          filters: { publishedAt: { notNull: true } }
        ) {
          data {
            attributes {
              slug
            }
          }
        }
      }
    `,
  });
  return {
    paths: data.posts.data.map((item) => ({
      params: { slug: item.attributes.slug },
    })),
    fallback: false,
  };
}

The filters in the query ensure that you will get only published posts.

Now you have the list of slugs and it’s time to use it to fetch every post data. Let’s create a getStaticProps method in the same file.

export async function getStaticProps({ params }) {
  const { data } = await client.query({
    query: gql`
      query Posts {
        posts(
          sort: "publishedAt:desc"
          pagination: { limit: 1 }
          filters: { slug: { eq: "${params.slug}" } }
        ) {
          data {
            attributes {
              title
              slug
              content
              cover {
                data {
                  attributes {
                    url
                  }
                }
              }
              author {
                data {
                  attributes {
                    username
                  }
                }
              }
              tags {
                data {
                  attributes {
                    tagId
                    name
                  }
                }
              }
            }
          }
        }
      }
    `,
  });

  return {
    props: {
      postData: data.posts.data[0],
    },
  };
}

You’ll get all the data needed to properly display the post on your page. You query the GraphQL for a post with a specific slug. Unfortunately Strapi API does not allow you to get one specific post using the slug. It’s only possible using post ID, but you want to have more descriptive links than for example /post/2. /post/a-blog-post looks definitely better. That’s why you’ll make a standard Posts query with a filter to get the one with a specific slug. And the returned data is put into props of BlogPost component which you’ll create next.

Now the time has come to create your blog post page. Still in [slug].js add a new component (place it over the getStaticPaths and getStaticProps methods).

export default function Post({ postData }) {
  return <div>{postData.attributes.content}</div>;
}

But wait! Your content is written in Markdown - so the end result would look like this:

That’s not exactly what we want! To help you display Markdown properly I suggest using two additional libraries - react-markdown and TailwindCSS Typography. First one help format markdown properly, second one is a plugin for TailwindCSS which provides basic styling for articles. Let’s install both:

yarn add react-markdown @tailwindcss/typography

Now update your tailwind.config.js so it’s aware of the newly installed plugin:

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: [
    "./pages/**/*.{js,ts,jsx,tsx}",
    "./components/**/*.{js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [require("@tailwindcss/typography")],
};

With this out of the way you’ll be able display your blog posts properly:

export default function Post({ postData }) {
  return (
    <ReactMarkdown className="prose prose-sm md:prose-lg lg:prose-xl xl:prose-2xl prose-slate w-11/12 mx-4 my-8">
      {postData.attributes.content}
    </ReactMarkdown>
  );
}

You have one more thing to do before you’ll be able to see your blog posts in action. You need to hook Blog Post Page to the Blog Post Preview - so when the user clicks on the preview he/she will go to the full post.

Use next/link which is better suited for routing in Next.js apps. Go to the BlogPostPreview.jsx and replace existing <a href=”#”> and its content with:

<Link href={`/post/${post.attributes.slug}`}>
  <a>
    <Image
      className="w-full"
      src={post.attributes.cover.data.attributes.url}
      alt=""
      width={1000}
      height={480}
      objectFit="cover"
    />
    <div className="px-6 py-4">
      <div className="font-bold text-xl mb-2">
        {post.attributes.title}
      </div>
      <p className="text-gray-700 text-base">{post.attributes.excerpt}</p>
    </div>
  </a>
</Link>

Now rebuild your app and then start the development mode.

yarn build
yarn dev

Open http://localhost:3000 and click on any of the previews - you should be redirected to the blog post page:

That’s better! Of course feel free to experiment with the styling of the whole page - I’m not focusing on this here as this is not a course on css and layouts.

And that’s it! In the next part of this guide you’ll finally deploy the page on Netlify, so stay tuned!

Hosting free Strapi CMS on Railway [Building Personal Blog Website Part 1]

Michał Hawełka — Fri, 26 Aug 2022 12:24:00 +0000

This is the first part of the "Building Personal Blog Website" series. In the series we'll setup a free CMS to hold our blog content on Railway, create a React app with Next.js' static site generation and TailwindCSS to present the articles and host it on Netlify.

❗ This is an updated version of the guide. The original one used Heroku instead of Railway, but as Heroku phased out its free tier - I decided to rewrite the first parts of this series to still use only free resources.

All articles:
Part 1: Hosting free Strapi CMS on Railway

Whether you want to create a simple blog or a portfolio website it is always a good idea to use a good CMS (Content Management System) behind. For quite some time Wordpress was a go-to solution, but now the choice is not so obvious. As an ambitious developer you can of course try to write your own CMS, but let's be frank - in most cases the best way is to use an existing one. That was my approach when I started to work on my personal website.

My main interest were as follows:

ability to change website's content without changing the code
simple blog functionality
out-of-the box GraphQL integration
cheap site maintenance (preferably free)

After some time of "research" I chose Strapi CMS for the first three points and Railway for the last one.

Why Strapi?

It's lightweight - compared to other CMSs Strapi is lightweight and really simple to set up.
It's headless by design - I definitely prefer a headless CMS solution over a traditional CMS, it gives much more flexibility.
It's written in JavaScript - this definitely helps with writing extensions/plugins if you use JS on a daily basis (which I am).
It has really extensive docs - Strapi docs helped me in tons of situations, if you have a problem with Strapi it's almost guaranteed you'll find some help in the docs.

Why headless?

Main reason - it's technology agnostic - traditional CMS requires you to write templates etc. in the technology the CMS is written. With headless this problem is gone. You utilize the REST/GraphQL endpoints to fetch the data and display it however you like.

How to set this up?

To set up your Strapi CMS you’ll use Railway. The process of deployment is rather easy, but to make it even easier you’ll start with setting up Cloudinary. If you do this now - configuring Strapi to use Cloudinary as an image repository will be a piece of cake - Railway will need the API keys and then it’ll set everything up automatically.

As you are building a personal blog it is really possible that you'd want to use some images in the blog posts. The CMS is hosted on a free-tier Railway, so the storage is rather limited. That's why you need to think about other solutions. And here's where the cloud comes in.

For this I have chosen Cloudinary. It's a rather popular platform for managing assets and optimizing images. But the main reason to use it for our personal project is that it has a free tier with easy-to-use API. Config is worry-free - you'll go through it today.

But before you start - head out to Cloudinary, create a free account (the process is rather standard) and when you're done - log in and get your SDK config (Getting Started -> Configure your SDK -> Start configuring).

Save those variables somewhere and then let's create your Strapi app in Railway.

Go to Railway Strapi builder

When you do this you should see something like this (if you don’t - just refresh the page):

Here you have to provide a name for your repository. Paste your Cloudinary keys in the specific fields and for the rest of those (ADMIN_JWT_SECRET, JWT_SECRET, APP_KEYS, API_TOKEN_SALT) - generate new values in your terminal with openssl rand -base64 32(remember to save them somewhere).

EDIT: All the variables you use here are also important for local development so save those in .env file (and remember to add .env file to your .gitignore if it's not already there).

When you fill all the fields - click Deploy. And that’s it, it’s that simple. Wait a few minutes so your build will be done and then you’ll be able to continue with setting up your admin account for Strapi.

If you want you can customize your Railway domain for the cms - when the build is done go the the last tab (Settings) and there you can easily edit the domain.

Go to https://[yourapp].up.railway.app/admin to set up the admin user and then log in (chances are you'll get the error about invalid API call - if so, don't worry, we'll fix it in a moment). You should land in the dashboard (if you had the error - ignore this part and just move along to the next paragraph).

As the app is in production mode you can't really make any adjustments here. You can't create a new content-type or add a new plugin. That's why you need to go into developer mode - make changes there and redeploy the app.

Strapi created by Railway depends on postgres database, but it’s definitely an overkill to use it locally. You’ll now configure a SQLite database to be used on your local environment. First, clone the repository created by Railway. Before you install and start the development server you’ll need to do a few adjustment.

Copy the file config/database.js to config/env/production, then replace config/database.js with

const path = require("path");

module.exports = () => ({
  connection: {
    client: "sqlite",
    connection: {
      filename: path.join(__dirname, "..", ".tmp/data.db"),
    },
    useNullAsDefault: true,
  },
});

Install SQLite dependency:

yarn install better-sqlite3

IMPORTANT: Before proceeding - upgrade Strapi version in your package.json to at least 4.5.5 (and plugins also if you have any installed):

    "@strapi/plugin-i18n": "4.5.5",
    "@strapi/plugin-users-permissions": "4.5.5",
    "@strapi/provider-upload-cloudinary": "4.5.5",
    "@strapi/strapi": "4.5.5",

And now you’re ready to start the app:

yarn install
yarn develop

And when the app starts you'll need to set up admin account once again (it's stored in SQlite database, so it'll be gone after some time locally - but that's not a problem). Now when you log in you can create new content-types, configure plugins etc.

Before starting creating content-types let's just quickly install a plugin that will be really useful later - GraphQL plugin which enables the default GraphQL endpoint for your CMS (you can skip it if you're ok with using standard REST calls, but I'll be using GraphQL in the React app). You can install it easily using yarn:

yarn add @strapi/plugin-graphql

And with that out of the way let's just create a blog post type.

In the content-type builder select a "Create a new collection type".

And add some mandatory fields to it. In my case it's title, content, cover, author and slug.

For author it's important to select a proper relation:

For slug remember to make it of type UID and select title as an attached field:

After you save you can commit all the new files - the schema files etc. will tell the production app what kind of content should be possible to create.

Now you are ready to redeploy the app, just do a push:

git push

After you do this Railway will do an automatic redeploy. When it’s finished, log in with the admin credentials and do some final configuration.

What you need to do is to give public access to posts. Do this by going into Settings -> Users & Permissions Plugin -> Public -> Edit (icon).

While inside, give access to find and findOne for postsand users-permissions. This way you'll be able to query the CMS for the list of blog posts and for a specific one post (using slug).

Click Save and now let's create an author and a dummy blog post to test the endpoint (Content Manager -> User -> Create New Entry and Content Manager -> Post -> Create New Entry).

Then click on the area below cover (or whatever you named this field) and just follow the instructions on the screen to add a new image.

After saving you should see in the blog post editor that the image is in fact there.

But now to be entirely sure the image was added correctly - go to the Cloudinary website, log in and go into Media Library. There you should see your newly created image in 3-4 sizes.

After saving a post you also need to publish it so it would be visible in the API.

To check if everything works use Postman (or a similar app).

Open up Postman and in the address field put https://[yourapp].up.railway.app/graphql/ and select POST type of query. Then in the body of the query select graphql type and type this:

query {
    posts {
        data {
            attributes {
                title
                content
            }
        }
    }
}

When you send this request, you'll receive the blog post that you just created a minute ago:

As you can see the content is returned as markdown - it's much more efficient to send the data this way, but in our frontend app we'll need to convert it to HTML. We'll probably use something like react-markdown.

And that's it! We now have a hosted Strapi CMS that is accessible by both REST and GraphQL. In the next part you’ll create the Next.js app to consume the data you already have in your CMS.

Setting up a basic Next.js app locally [Building Personal Blog Website Part 2]

Michał Hawełka — Sat, 20 Aug 2022 09:42:00 +0000

Now that the basic CMS is set up on Railway and Cloudinary is configured to handle the images, the next step would be... creating a Next app.

This Next app will consume content provided by the CMS and present it on a webpage. In this part of the series basic homepage with a list of blog posts will be created and set up locally.

So let's just jump into it. First thing you need to create is a new Next.js app. You can do this by this simple command:

npx create-next-app@latest

After running it the prompt will ask for the app's name - provide one and then the project will be created.

Before you start working on an actual app let's just install some dependencies that will be useful later on - TailwindCSS for styling the app and Apollo Client for working with GraphQL.

First - let's go with TailwindCSS.

yarn add tailwindcss postcss autoprefixer
npx tailwindcss init -p

After running the init command the file tailwind.config.js will be created. You need to make a few changes to the generated one so everything will be working correctly.

Replace an empty content array with:

content: [
    "./pages/**/*.{js,ts,jsx,tsx}",
    "./components/**/*.{js,ts,jsx,tsx}",
  ],

You also need to import TailwindCSS rules to the ./styles/globals.css file:

@tailwind base;
@tailwind components;
@tailwind utilities;

And now you're done with setting up TailwindCSS. Let's move on to the Apollo Client.

yarn add @apollo/client graphql

That's it! You're ready to create your GraphQL-driven blog page.

First you need to set up an Apollo Client, that will work as a "gateway" to your GraphQL API. Create a new file in the root of the project called apollo-client.js (you can name it however you want TBH).

import { ApolloClient, InMemoryCache } from "@apollo/client";

const client = new ApolloClient({
    uri: "https://[YOUR-CMS-GRAPHQL-URL]",
    cache: new InMemoryCache(),
});

export default client;

With this in place it's time to use it! You'll start by getting a list of all blog posts to be displayed on the homepage. You'll use the Static Site Generation feature of Next.js - for this the getStaticProps method is needed.

Side note - Why SSG?

As in this tutorial series we are talking about setting up this blog for free - we are limited performance-wise. The CMS set on free Railway tier isn’t exactly a speed demon, Next.js app with SSR set on free Netlify would also be kinda slow. So, SSG seems to be the best option, even though every change on our blog would need an app rebuild. If budget is not a concern to you, then you can think about other options, but that’s not the topic of this series.

Before we go any further let's just add two more fields in your Blog post configuration. Open up a repo for your Strapi CMS and run it in development mode (yarn develop). Log in and go to the Content-Type Builder. First you'll need to create a new type named Tag.

It has an ID and a name that should be unique.

When this is done you are ready to "upgrade" your Blog post type. In the Content-Type Builder open the Post and add two new fields. First one is excerpt - the short text that will be presented on your homepage, sneak peak into the blog post. It should be of type string and preferably have some maximum length (250 characters in my case). It also should be required.

Now you need to add Tags. It will be a Relation type field and the relation is Many-to-Many as one Post can have multiple Tags and every Tag can belong to multiple Posts. Do it like this:

Now go to your Terminal and commit all of the changes that were made in your config files by Strapi. And then push your changes to rebuild the CMS hosted on Railway:

git push

When the app on Railway is rebuilt - log in and change Public user permissions so you'll be able to query Tags.

Now you can fetch the data in getStaticProps in index.js file of your Next.js app. Add this at the bottom of pages/index.js

export async function getStaticProps() {
  const { data } = await client.query({
    query: gql`
      query Posts {
        posts(
          sort: "publishedAt:desc"
          pagination: { limit: 5 }
          filters: { publishedAt: { notNull: true } }
        ) {
          data {
            attributes {
              title
              slug
              cover {
                data {
                  attributes {
                    url
                  }
                }
              }
              excerpt
              tags {
                data {
                  attributes {
                    tagId
                    name
                  }
                }
              }
            }
          }
        }
      }
    `,
  });

  return {
    props: {
      posts: data.posts.data,
    },
  };
}

What this does? On every build (yarn build) Next will perform this query before "rendering" the page/creating the static page output. This means that you will not need any loading indicators on your webpage, because the data will already be fetched. Downside of this is of course that you will have to rebuild the app on every change of content in the CMS. But for personal blogs this is a pretty good and cheap solution.

You are downloading only the most important data that will be shown on the homepage. So let's just create a simple homepage then.

You'll start with creating a new component - a card to preview the Blog Post. Create a new file components/BlogPostPreview.jsx (if there's no component folder - create it).

import Image from "next/image";
import React from "react";

const BlogPostPreview = ({ post }) => {
  return (
    <div className="max-w-sm rounded overflow-hidden shadow-lg">
      <a href="#">
        <Image
          className="w-full"
          src={post.attributes.cover.data.attributes.url}
          alt=""
          width={1000}
          height={480}
          objectFit="cover"
        />
        <div className="px-6 py-4">
          <div className="font-bold text-xl mb-2">{post.attributes.title}</div>
          <p className="text-gray-700 text-base">{post.attributes.excerpt}</p>
        </div>
      </a>
      <div className="px-6 pt-4 pb-2">
        {post.attributes.tags.data.map((tag) => (
          <a href="#" key={tag.attributes.tagId}>
            <span className="inline-block bg-gray-200 rounded-full px-3 py-1 text-sm font-semibold text-gray-700 mr-2 mb-2">
              {tag.attributes.name}
            </span>
          </a>
        ))}
      </div>
    </div>
  );
};

export default BlogPostPreview;

You get one prop here - post. It has all the fetched information inside. Then we create a simple card with a cover image, title, excerpt and a list of tags. End result will look something like that:

As you can see there are some empty a tags in the code - in the later stages of this tutorial series you'll make a use of them, don't worry.

Now it's finally the time to showcase your blog posts. In pages/index.js make use of a newly created component.

export default function Home({ posts }) {
  return (
    <div className="flex flex-col items-center">
      <h1 className="text-3xl uppercase font-serif font-bold my-8">
        My personal blog
      </h1>
      <section className="grid grid-cols-3 gap-4">
        {posts.map((post) => (
          <BlogPostPreview post={post} key={post.attributes.slug} />
        ))}
      </section>
    </div>
  );
}

One more thing before you build this - if you use Cloudinary for the images (as was done in the second part of this series) then you will need to add Cloudinary domain to the next.config.js. This is needed so you'll be able to use next/image component instead of img tag.

Wow, that was quite a ride. Let's finally build this! Run
yarn build and wait for this process to finish. If everything goes well - run yarn develop and open your site in the browser http://localhost:3000/. You should see something like this:

Of course don't forget to create a few tags and posts (you'll need to create a tag before you'll be able to use it in a post). Also as you added some new required fields - update existing posts so they have every needed information filled.

And that's it. That's the end of the second part of this tutorial series. In the next one you'll create a Blog Post Page. See you then!

[Deprecated] Using Cloudinary with Strapi CMS [Building Personal Blog Website Part 2]

Michał Hawełka — Wed, 02 Mar 2022 10:24:00 +0000

As Heroku is phasing out the free tier I'm going to rewrite the first two parts of this guide. Here you can find the updated version: COMING SOON.

This is the second part of the "Building Personal Blog Website" series. In the series we'll setup a free CMS to hold our blog content on Heroku, create a React app with Next.js' static site generation and TailwindCSS to present the articles and host it on Netlify.

All articles:
Part 1: Hosting free Strapi CMS on Heroku
Part 2: Using Cloudinary with Strapi CMS
Part 3: Setting up a basic Next.js app locally

As you are building a personal blog it is really possible that you'd want to use some images in the blog posts. The CMS is hosted on a free-tier Heroku, so the storage is rather limited. That's why you need to think about other solutions. And here's where the cloud comes in.

Save those variables somewhere and then let's go back to your Strapi app in your code editor of choice.

First you need to install a Cloudinary provider:

yarn add @strapi/provider-upload-cloudinary

Then update Strapi config in config/plugins.js file (create it if it doesn't exist):

module.exports = ({ env }) => ({
 upload: {
   config: {
     provider: "cloudinary",
     providerOptions: {
       cloud_name: env("CLOUDINARY_NAME"),
       api_key: env("CLOUDINARY_KEY"),
       api_secret: env("CLOUDINARY_SECRET"),
     },
     actionOptions: {
       upload: {},
       delete: {},
     },
   },
 },
});

Next step would be to create the environment variables through Heroku CLI so they would have proper values:

heroku config:set CLOUDINARY_NAME=[cloud_name from Cloudinary config]
heroku config:set CLOUDINARY_KEY=[api_key from Cloudinary config]
heroku config:set CLOUDINARY_SECRET=[api_secret from Cloudinary config]

You're almost done! Now you need to update the middleware for Strapi - strapi::security to be exact. Instead of just string you should put an object there (config/middleware.js):

module.exports = [
 "strapi::errors",
 {
   name: "strapi::security",
   config: {
     contentSecurityPolicy: {
       useDefaults: true,
       directives: {
         "connect-src": ["'self'", "https:"],
         "img-src": ["'self'", "data:", "blob:", "res.cloudinary.com"],
         "media-src": ["'self'", "data:", "blob:", "res.cloudinary.com"],
         upgradeInsecureRequests: null,
       },
     },
   },
 },
 "strapi::cors",
 "strapi::poweredBy",
 "strapi::logger",
 "strapi::query",
 "strapi::body",
 "strapi::session",
 "strapi::favicon",
 "strapi::public",
];

Now commit all of you changes and push:

git push heroku HEAD:main

And that's it! After the app is redeployed the CMS will use Cloudinary for storing images. Let's just quickly test this. Head out to your Strapi Admin Panel on https://[your-app].herokuapp.com/admin/.

Go into Content Manager and edit the blog post you created in the first part of this article series.

Then click on the area below cover (or whatever you named this field) and just follow the instructions on the screen to add a new image.

After saving you should see in the blog post editor that the image is in fact there.

But now to be entirely sure the image was added correctly - go to the Cloudinary website, log in and go into Media Library. There you should see your newly created image in 3-4 sizes.

Easy, right? So now that you are ready to create some blog posts with images you can start working on a React app to display them. And that will be the third part of this guide, so stay tuned!

[Deprecated] Hosting free Strapi CMS on Heroku [Building Personal Blog Website Part 1]

Michał Hawełka — Mon, 21 Feb 2022 12:03:00 +0000

As Heroku is phasing out the free tier I'm going to rewrite the first two parts of this guide. Here you can find the updated version: COMING SOON.

This is the first part of the "Building Personal Blog Website" series. In the series we'll setup a free CMS to hold our blog content on Heroku, create a React app with Next.js' static site generation and TailwindCSS to present the articles and host it on Netlify.

All articles:
Part 1: Hosting free Strapi CMS on Heroku
Part 2: Using Cloudinary with Strapi CMS
Part 3: Setting up a basic Next.js app locally

My main interest were as follows:

ability to change website's content without changing the code
simple blog functionality
out-of-the box GraphQL integration
cheap site maintenance (preferably free)

After some time of "research" I chose Strapi CMS for the first three points and Heroku for the last one.

Why Strapi?

It's lightweight - compared to other CMSs Strapi is lightweight and really simple to set up.
It's headless by design - I definitely prefer a headless CMS solution over a traditional CMS, it gives much more flexibility.
It's written in JavaScript - this definitely helps with writing extensions/plugins if you use JS on a daily basis (which I am).
It has really extensive docs - Strapi docs helped me in tons of situations, if you have an problem with Strapi it's almost guaranteed you'll find some help in the docs.

Why headless?

How to set this up?

For the most part I used a guide from Strapi Docs. This guide shows how to create a new Heroku app with Strapi installed and connect it to the free-tier postgres database. I won't go into details here and repeat what's been said in this guide. But I have just a few additions to make it work properly.

So for starters go through the guide - but don't worry if at the end it doesn't work on Heroku (you get the application error).

The error says:

error: Middleware "strapi::session": App keys are required. 
Please set app.keys in config/server.js (ex: keys: ['myKeyA', 'myKeyB'])

That's why you need to make adjustments to production config. In the production config file created during the guide earlier (env/production/server.js) add few additional fields:

module.exports = ({ env }) => ({
  url: env("MY_HEROKU_URL"),
  proxy: true,
  app: {
    keys: env.array("APP_KEYS", ["testKey1", "testKey2"]),
  },
});

The app.keys is crucial. The data that you put in server.js doesn't matter. What matters is the value that you set in Heroku environment. You can do it directly through Heroku CLI.

heroku config:set APP_KEYS=someSecretValue1,someSecretValue2

Now when you commit and push changes and redeploy the app you should be able to see that Strapi server is running. Go to https://[yourapp].herokuapp.com/admin to set up the admin user and then log in. You should land in the dashboard.

As the app is in production mode you can't really make any adjustments here. Of course you can add a new post etc. but can't create a new content-type or add a new plugin. That's why you need to go into developer mode - make changes there and redeploy the app.

Doing this is pretty simple:

yarn develop

And when the app starts you'll need to set up admin account once again (it's stored in SQlite database, so it'll be gone after some time locally - but that's not a problem). Now when you log in you can create new content-types, configure plugins etc.

yarn add @strapi/plugin-graphql

And with that out of the way let's just create a blog post type.

In the content-type builder select a "Create a new collection type".

And add some mandatory fields to it. In my case it's title, content, cover, author and slug.

For author it's important to select a proper relation:

For slug remember to make it of type UID and select title as an attached field:

After you save you can commit all the new files - the schema files etc. will tell the production app what kind of content should be possible to create.

Now you are ready to redeploy the app using Heroku CLI:

git push heroku HEAD:main

After the deploy is done you can open the app with heroku open, log in with the admin credentials and do some final configuration.

What you need to do is to give public access to posts. Do this by going into Settings -> Users & Permissions Plugin -> Public -> Edit (icon).

While inside, give access to find and findOne for posts. This way you'll be able to query the CMS for the list of blog posts and for a specific one post (using slug).

Click Save and now let's create an author and a dummy blog post to test the endpoint (Content Manager -> User -> Create New Entry and Content Manager -> Post -> Create New Entry).

After saving a post you also need to publish it so it would be visible in the API.

To check if everything works use Postman (or a similar app).

Open up Postman and in the address field put https://[yourapp].herokuapp.com/graphql/ and select POST type of query. Then in the body of the query select graphql type and type this:

query {
    posts {
        data {
            attributes {
                title
                content
            }
        }
    }
}

When you send this request, you'll receive the blog post that you just created a minute ago:

And that's it! We now have a hosted Strapi CMS that is accessible by both REST and GraphQL. Next step - hooking up Cloudinary to our CMS!

How React relit my programming passion

Michał Hawełka — Sun, 11 Apr 2021 17:32:54 +0000

My IT career went from full-on backend C++ developer to full-on frontend enthusiast in a matter of few years. I searched for my IT ‘Holy Grail’ for quite some time, but it looks like I finally found it. Disclaimer: this article is totally subjective and emotion-based, but I’ll try not to bend the facts ;)

How it all came to be

Let’s start with a bit of my background (if you want to skip that part — just go straight to React part).

I started my IT career in 2013 with a C++ student internship. It was the only programming language I knew at the time (it was used in my university courses). To be honest — I approached the field with rather cynical mindset — I liked to program, but it wasn’t my favorite thing in the world. My main motivation was to earn lots of money (you know how IT is sold by universities). But after few years of C++ programming I felt that’s not the thing I want to do in my life. I started looking for other fields/technologies and my focus turned to more “frontend” and “client-oriented” approach. That’s why in the following years I had an “adventure” with being a Product Owner and then switched to not-as-backend-as-C++ Java. I was working with it for a few years, but with every working day I got more tired of it. 2-3 years ago I can say that my programming passion died out.

2 years ago I moved to a new company, where my responsibilities wouldn’t be only in backend, but also in frontend. I started learning AngularJS and Angular — definitely liked it more than writing backend code, but still some parts of those made me uncomfortable. That’s when I looked React’s way. And that was a bullseye!

React is the way

I was interested in learning React for quite some time. Given that it powers a lot of apps I use on a daily basis, the idea to try to use it by myself arose. Unfortunately with my tendency to procrastination this idea was always just out of reach. The turning point was (oh, irony) the pandemic. Lots of websites started to offer their courses for a reduced price or even free. And that’s how I got to Udacity and their React Nanodegree. I decided to challenge myself and complete whole program in a free month. Spoiler alert — the challenge worked!

Udacity’s React Nanodegree consists of 3 main subjects — React Fundamentals, React with Redux and React Native. All of those were new to me, but now I can say I’m able to use those (of course with documentation’s help) rather freely. Also during the nanodegree I had to complete 3 projects, but two of those gave me a lot — the second project taught me a lot about React Redux and the third one about React Native.

React Redux project — Polls App

What I liked most in the React Redux project is that the course gave the user only the ‘backend’ API, the rest had to be written by the user. I started with drawing all of the views for the app, then determining which data will need to be stored in the redux store and which directly in component’s state. Then I prepared some mock components and routes just to have a general idea of the app (it wasn’t doing anything then). This is where redux came into play. I wrote actions and reducers as was taught in the course. When the app started to actually do something I got in some kind of trance. I lost track of time while writing code, I thought about the project even when I wasn’t working on it. That was the first time I felt it since… ever.

The app was just a simple polls app where user entered two options and then rest of the users could vote on option 1 or 2. And even though it was that simple — I was 100% invested in it. Now that I passed the nanodegree and the project was accepted — I still want to extend this app. I think about major refactor, because I’m aware that the code is not really ‘nice’. It was written fast (because of the challenge I gave myself), but I want it to become ‘proper’.

Here you can see the code I wrote (every comment is appreciated, I want to learn from experienced frontend professionals): https://github.com/hawelkam/polls-app

React Native project — Mobile Flashcards

Third and final project in the nanodegree was React Native app called ‘Mobile Flashcards’. It was the first mobile app that I fully created by myself. I tried Swift and Flutter before, but those felt a little bit to ‘backendy’ for me. Native approach suits me really well. I just use the ideas that I learned during web app development and used them here. The process was similar — I started with drawing views, preparing redux store data scheme and building a skeleton of the app. With experiences from the previous project this went much faster.

But as the content from nanodegree isn’t necessarily up to date (React Native course uses code with lots of deprecated stuff) I had to dive deep into docs. And that was a great learning experience. I learned about Navigators, styling and Notifications — something that was shown in the course, but unfortunately in deprecated versions. The app saves data to AsyncStorage, lets user create the cards deck, add new questions to it and quiz him/herself. Right now it’s a very simple app, but, just like with react redux project, I’m going to extend the functionalities. Work more on the UX/UI of the app. Maybe integrate it with some NoSQL database. I have lots of ideas how to make this app better. And again — it’s something I haven’t felt since…ever.
Here you can see the code I wrote (every comment is appreciated, I want to learn from experienced frontend professionals): https://github.com/hawelkam/mobile-flashcards

What I like in React

Am I the first one to say ‘JSX’?
I really like how the code written in JSX looks. It can get a little bit messy, but if you follow React’s philosophy of making everything a component— the JSX code looks clean. You know where to look for specific code even on the first glimpse of App.js. That’s something I really like in React.
Other thing I like is modularity. In plain HTML I needed to copy/paste a lot of the code to get same results, in Angular it’s better, but still a little bit too complicated for my taste, but in React you just create a functional component and use it everywhere you want. That is great especially when you attach styling to this component from the start — then you don’t need to repeat yourself not only with the code, but also with styles.
Third and final ‘big’ thing I like about React is its simplicity. Getting up to speed with is is extremely easy, especially if you have worked with any other JS framework before. It’s from the ‘easy to learn, hard to master’ category and that’s great. It allows me to learn constantly when writing something new. I always come across a technique I never used before and adapting them is a piece of cake. Of course to be the React master I’d need hundreds of hours of coding experience, but I’m optimistic I’ll get there one day!

What’s next

I think learning React is the catalyst for my full switch to frontend developer. After finishing the course I wrote one more app — this time based on the Ionic framework and after that — I started working on my portfolio website (fully created with React and react-bootstrap). I see a lot of things I want to dive deeper into like React Hooks, Styled Components, Webpack etc. and that will lead my way forward. In the meantime I moved to another company where I was hired as a full-stack developer, but after discussing my priorities with my manager I got assigned to the project where I work as a frontend developer with Angular. So i'm one step closer to my final goal ;)

The last cycle begins (?)

The experiences I’ve already had with React showed me that this is the thing I want to do. Not just for work, but also in my spare time. I have a lot of fun coding and I guess that is one of the main reasons we should do it (others being more ‘material’ ;)). From time to time I apply to some frontend positions (with React) to check if I’m ready for this kind of work now or not. If not — then I’ll be wiser about what to learn — and that is a great learning experience as well.

Final note

This post was published some time ago on my Medium account, but I updated it a bit and thought this would be a great 'starter' article for my blog here, I hopy you won't mind :)