DEV Community: Kieran Roberts

cvrsnap.com: Blog post cover image creator to help you publish quicker

Kieran Roberts — Fri, 31 Jan 2025 08:04:26 +0000

Introducing cvrsnap.com 🫰.

CvrSnap is a free tool I recently built as a small side project and it lets you quickly create blog post cover images that you can download as a PNG. Its designed to help you build something that looks good quickly so you can spend less time designing, and more time publishing. You can customise foreground text and its layout, customise the background, choose provided download dimensions, and more. The editor persists your progress if you need take a pause. Behind the scenes CvrSnap is a 1 page client-side React app built using React Router v7, TypeScript, MantineUI, Zustand, IndexedDB, and SST to provision the services Amazon CloudFront, Amazon S3, and Amazon Route 53.

I wanted to share the tool with all of you in case it can be of use to you, and also write a little case study for the project. If you are in need of a nice cover image for your next blog post, please do try it out and let me know if theres anything else you would want to make your ideal cover image as quickly as possible. You can reach out to me @Kieran6Dev, on LinkedIn, or through the comments here.

Why did I build this tool?

A blog post cover image is something I need every time I write a new post. I dont have a current template designed (somewhere like Figma) for me to re-use across my posts and I dont want to spend the time designing one because I always find it difficult to settle on something when starting from nothing. I just want to visit some domain, click a few buttons and be done with it. You might ask:

But wouldnt it take longer to build the app than to design a new cover template in Figma

Yes. But I am a developer and I thought this would be more fun. Plus it might be useful to someone else.

I dont care about elaborate blog cover images for my own posts. As long as the title is in the image, and maybe my name as the author. Generic cover images from the internet (Unsplash as an example) are also something I dont care for. With that in mind I set out to build a simple, clean editing user interface where I could go anytime I needed a new blog cover image.

Who is the tool for?

Someone who needs a good looking blog cover image with text as the primary foreground, usually for the blog title and author (you can remove the text if you so choose).
You don't want a generic cover image from an internet image platform.
You don't want to spend hours starting from scratch using a design tool. You just want to pick some preset templates, maybe change some font settings etc.
You want to do all of this in a modern and user-friendly editor.

CvrSnap is also free.

The live site

cvrsnap.com

codebase - (If you like and use the app, take a second to give it a star on GitHub)

CvrSnap example covers

Here are some example covers images I quickly built using CvrSnap:

Requirements

A very simple landing page
Editing interface
Minimum set of customisation options to start with.
1 click image download in PNG format that accurately resembles the preview.
An editor that would persist the selected design options.
Different download size options.
Light/dark theme toggle.

Tech Stack

Build Specifics

React Router v7 & the rendering approach

The backbone of the app is built using React Router v7. I started out development in an SSR approach using React Router as a framework. But during development I realised it would be better served as a single page client side application. There would be no sever side data fetching requirements from external APIs or databases. The key for a dashboard type app is to optimise for snappy UI and quick transitions. SSR has been pushed as a default for a little while now but I dont believe its necessary in all cases, and overkill (possibly a little detrimental) here.

The new version of React Router was a little confusing to me at first because you can decide to run it as full framework, or as a simple routing library. I think theres work that can be done to better explain this product now its merged with Remix. Currently CvrSnap is running using React Router as a framework with SRR: false in the React Router config to specify we intend to use a single page client rendering strategy. This is primarily due to the fact I started out the app in framework mode without settling on the preferred rendering strategy.

I will likely refactor to use React Router simply as a routing library instead of the framework option currently in use. I believe this is usually how you would adopt a single page with React Router as described here. Im currently putting together a small starter kit (not done) for the the tech behind CvrSnap and I have implemented React Router simply for routing there as a trial run which looks good.

Outside of how the client side rendering is approached here, I am happy with the decision to prefer it to SSR for now.

The persistent editor: Zustand + IndexedDB

Before building the app, I knew I wanted to persist the editor state for the user. If the user navigates to a different page, or away from the app, when they come back they should see the same design they left behind.

Its quite frustrating to use apps in this realm that dont persist your progress. You make some changes, think you are done and finish up, then realise you actually want to adjust something.

🤦 Whoops, now you have to start all over again.

CvrSnap does not have user authentication, and doesnt need it. Also no external database storage beyond browser based storage. Since no sensitive data needs to be persisted, browser storage becomes a nice solution for the needs of the app. The data that does need to be persisted is simply non-sensitive arbitrary numbers and strings, corresponding to text content, font sizes etc.

IndexedDB

The core of the editor state is persisted using IndexedDB. IndexedDB is simply an API for client-side storage of a large amount of structured data. I preferred this option for storing the current cover preview state over Window.localStorage for a few key reasons:

I would be writing to the storage quite often (as cover settings are updated). Local storage updates are synchronous: blocking the main thread with reads and writes. Therefore performance would likely take a hit.
IndexedDB allows structured data which I would would be working with (objects) without requiring it to be serialised.
IndexedDB can store larger amounts of data, something which might become relevant as the app grows.

Window.localStorage is however utilised for a couple of small scale settings like the sidebar open state and sidebar open sections states.

All the current settings of the active cover image preview are saved using IndexedDB in combination with the state management tool Zustand.

Note: The only editor state that is not currently persisted are user uploaded images. Users can upload their own image to the background. I didnt want to persist personal images mostly for privacy reasons.

Zustand is simply a small, fast, barebones state management tool. When you navigate on the client between the / page and /create page, that is Zustand persisting your current editor state. I have integrated Zustand with the persist middleware from zustand/middleware, allowing you to store the Zustand state in a storage option of your choice. You can see this in effect after you perform the initial page load.

To demonstrate the approach, here is a simplified solution:

import { create } from 'zustand';
import { get, set, del } from 'idb-keyval';
import { persist, createJSONStorage, StateStorage } from 'zustand/middleware';

// Interact with IndexedDB using the promise based keyval store 'idb-keyval'
const indexDBStorage: StateStorage = {
  getItem: async (name: string): Promise<string | null> => {
    return (await get(name)) ?? null;
  },
  setItem: async (name: string, value: string): Promise<void> => {
    await set(name, value);
  },
  removeItem: async (name: string): Promise<void> => {
    await del(name);
  }
};


export const useStore = create(
  {
   hasHydrated: false,
   setHasHydrated: (state) => set({ hasHydrated: state }),
   // Rest of the state initialisation + update functions

  },
  {
      name: 'editor-storage',
      storage: createJSONStorage(() => indexDBStorage),
      // Pick the state you want to persist.
      partialize: (state) => ({
        template: state.template,
        primaryText: state.primaryText,
      }),
      // Updating version becomes useful when we have breaking changes
      version: 1,
      onRehydrateStorage: () => (state, error) => {
        if (error) {
          // do something
        } else if (state) {
          state.setHasHydrated(true);
        }
      }
    }
)

One thing to note about persisting the state in IndexedDB is that the operations are asynchronous. This means the store is hydrated from IndexedDB some time later after store creation (after initial render). Therefore, there is a slight delay in having this data available in the editor. When the storage has been successfully hydrated in the onRehydrateStorage function, we set the hasHydrated state to true and use it wherever its needed.

Dom to image handling

I experimented with several different packages that allow me to capture a DOM node as an image and saw mixed results. I settled on html-to-image for the time being. So far it seems to be the most accurate representation of the DOM I have, with minimal configuration Crucially I was also able to capture clip-path elements correctly using html-to-image, an alternative solution I also was experimenting with (html2canvas) did not support this. The background templates make use of the CSS property clip-path to create custom backgrounds so this was a dealbreaker. Theres still some optimisation and experimenting I want to do to optimise the final images.

The logic behind downloading the PNG is pretty simple. The PNG image blob is generated from the DOM with htmlToImage.toBlob, setting the intended dimensions, quality etc. Then the blob is downloaded on the client with the help of file-saver: fs.saveAs(blob, 'cvrsnap-cover.png')

MantineUI

I wasnt looking to spend time writing custom UI elements and design specs for this app. Since there might be some very interactive UI also, I decided to integrate a UI component library. I read good things about the React component library MantineUI and decided it would be a good fit for the project to get things done quicker. Its open source, TypeScript based, and adaptable to various modern Frameworks. The component list of its core library is extensive and I would need to utilise several different various complex element compositions in the app.

CSS modules is recommended alongside Mantine and thats what I went for, using CSS variables where helpful. From someone who enjoys TailwindCSS as my primary tool, I was missing it a little here but it was also nice to write regular CSS again. Something which I have not done for a while.

Infrastructure

The last piece of the puzzle is the infrastructure. Its been a long time since I had to deploy a client side single page application and I was open to exploring different possibilities.

Recently I have been diving into learning and building in the cloud using AWS. Amazon CloudFront, Amazon S3, and Amazon Route 53 are some of the services I have been exploring and I set on deploying the site this way. What are these services:

CloudFront is a web service that speeds up distribution of your static and dynamic web content.
S3 is an object storage service where you can store data inside containers called buckets.
Route 53 is a highly available and scalable cloud domain name system (DNS) service.

While I had been experimenting and learning so far mostly using the AWS web interface, for CvrSnap I wanted to define the infrastructure as code (IaC). I briefly thought about using the AWS Cloud Development Kit (AWS CDK) before coming across the Serverless Stack (SST) and deciding that would be a nice approach. SST is a framework where you define everything your full-stack app needs in code and SST abstracts away a significant amount of the infra configuration and provisioning. Even more so than the AWS CDK. I though this would help me get to production quicker as I am not yet proficient in provisioning resources using the CDK despite working in and around CDK apps a little, then I could explore the CDK at a later date.

This article on AWSFundamentals has a great section detailing IaC, AWS CDK, and the benefits of SST if you want more information: blog.awsfundamentals.com/social-stats-dashboard-sst-nextjs#heading-serverless-stack-sst

Infra provisioning for the static site is taken care of by SST during deployment using a few simple lines of code:

// infra/web.ts
import { config } from "../config";

export const frontend = new sst.aws.StaticSite("Frontend", {
  path: "packages/frontend",
  build: {
    output: "build/client",
    command: "pnpm build",
  },
  indexPage: "index.html",
  domain:
  $app.stage === 'production'
    ? {
        name: config.domain,
        redirects: [`www.${config.domain}`],
      }
    : undefined,
});

I have also taken the time to dive into what SST does behind the scenes when calling sst.aws.StaticSite during my learning sessions, exploring which resources get created and how they interact. For someone who is still relatively new to building in AWS, I found SST to be really neat. I could get to production much faster with infra guaranteed by SST, and spend time digging into the lower level details afterwards.

Im excited to explore more possibilities if the app ever requires further resources such as functions, storage etc. If you want to explore SST yourself, this resource provided a nice practical walkthrough: https://guide.sst.dev/

Getting back to the underlying infra, the static build output built is stored in a general purpose S3 bucket. Public access to the bucket is blocked and only the CloudFront distribution has access to the bucket through origin access control settings. I got to really dive into S3 bucket permissions/policies and origin access control settings when I has having a problem with initial deployments. Turns out my build output path was incorrect 😄, but at least I got to dig down into these topics. Finally after configuring Route 53 DNS service for cvrsnap.com , traffic could then be routed to the domain using the CloudFront distribution.

There are multiple guides out there that goes into depth on similar infra step-by-step, search for AWS CloudFront S3 Route 53 and youll find plenty of articles if youre interested.

What went well

Product: Editor

I believe the app provides what I initially intended. Simple templates and options to get you moving quickly. Early on I was experimenting with a more custom approach, allowing dragging and resizing of text and an overall slightly more interactive editor. But I realised that didnt fit my initial purpose for it not to be complicated and open ended with its options. It has pre-designed layouts and options by design. Data is persisted so the user shouldnt get that feeling of losing something they started. It also feels fast and snappy which is key.

There is a decent amount of customisation options here, between the text and the backgrounds options and Im happy that you can make covers that dont all look completely identical. Im excited to expand the options here (specifically with more complex templates) while keeping the simplicity of making something look good quickly.

Personal: Learning

I took a lot of learning and enjoyment from this project. A first time user of React Router v7, MantineUI, and the whole SST setup, I was able to expand my knowledge significantly. I now have the experience to make decisions between stacks involving these tools in the future. It was a great help in letting me become comfortable working with S3 buckets and CloudFront distributions which fits in nicely with the upskilling Im currently doing.

There is invaluable knowledge and experience you gain when building your own projects from scratch. From the product development side, infrastructure, backend, continuous integration (CI), analytics, testing etc etc.

What can be improved

Mobile UX

The app is mobile responsive, and while I just released a new update to improve the mobile UX, I think there are still improvements to make here. Things like scroll position when switching sections and adding a scroll top button are two things that come to mind. Previously you would have to scroll to the top to see the preview, but I recently shipped and update so you have access to a preview button wherever you are scrolled which helped the UX significantly there.

Finally the default cover image text size is a constant. So on mobile it is too large for the preview size. You can manually reduce it to look appropriate but its not ideal. I dont really want to adjust the font size as the screen size changes but I need to do some thinking on this.

Customisation options

There can always be more customisation options, as long as they dont add design fatigue to the user since that would defeat the purpose of the app. Im not intending to introduce drag/resizing or anything open ended like that. Things like:

More complex background templates.
Templates that have a placeholder where you can upload an avatar to the cover.
Background gradients.

Landing page

The current landing is a bare bones one without too much thought. The editor was the primary focus but now thats taking shape, the landing page can get an upgrade.

Improved hero section
Updated editor image
More sections demonstrating the app and cover image details

React router: Library or Framework

To run the app as a true client 1 pager, I will probably refactor the app to use React router only for the routing as explained above. This tech debt could have been avoided if I started out this way.

Summary

CvrSnap is a free tool designed to help users create custom blog post cover images quickly and easily. Built as a client-side React app, CvrSnap leverages modern technologies like React Router v7, TypeScript, and AWS. The app's editor persistently saves user progress using IndexedDB and Zustand and PNG download is a simple click away.

If you made it this far, you are my hero. If you use CvrSnap to download an image you use in a blog post, please share the post with me on LinkedIn, or Bluesky and Id be happy to read/share.

My process for writing blog articles with actionable steps you can follow

Kieran Roberts — Fri, 30 Apr 2021 12:25:38 +0000

If you've ever tried writing blog articles yourself I'm sure you've realized it is not an easy thing. There are difficulties at every stage of the process from planning all the way through to publishing. I want to share my process from beginning to end which so far seems to be working for me.

Everyone is different. What works for me might not work for you. But in the very least it will give you some idea of how you can go about it.

Consistency is key and consistency becomes easier if you are able to break down the problem into manageable steps.

Here are my steps for writing articles 👏.

My Blogging Steps

Pick a topic
- What should I write about?
- Use your experiences with the chosen topic
Plan the the main points
- Write out the main headings
- Show the reader a preview of the main topics
Write the introduction
- Start with what you want the article to achieve
Start writing
- Write/read/check and repeat
Proof read your work
- From the heading to the last character
Publishing
- Where to publish?
- Create a custom article preview image
- Share it

1) Pick a Topic

What should I write about? 🤔

This is usually one of my biggest problems for new writers. It was difficult for me to know what to write about at first. I would think that I didn't know enough about something to write a whole article on it. But I soon realized you don't need to be an expert.

Just sharing your experience on a topic is enough. More than enough, it's awesome 😉. If you're stuck on ideas I will offer a solution that's worked for me thus far.

Think about what you're currently learning/ working on or recently worked with.

Maybe your learning about the CSS Box Model.

Write about that!

Or maybe your working on or recently finished a personal project.

Write about that!

Or perhaps you've been optimizing your site for performance scores.

Write about that!

As developers we're always working on something so why not use that as a focus for your articles.

I promise that if you keep writing consistently then ideas will start to flow and it will become easier. Now I regularly have multiple drafts on the go which is great because now I can plan ahead.

If you think of an idea write a few points inside a draft or wherever else you can in case you forget later on!

Use your experiences with the chosen topic 🙂

Great! Now you have a topic and you've chosen something you've recently worked with and because you have, you are in a position where you can apply your own experience. It is an awesome thing when you can apply this knowledge to your articles.

One of my earlier articles was all about the benefits I had personally experienced since taking up a blog. Because it was something I was actively working with I was able to provide tips I knew were real.

You can check out that article here 👉 Why it's awesome for new developers to blog as they learn

It will help your articles to connect with the readers if you apply your own experience to the problem.

2.) Plan the main points

Write out the main headings ✍

Now that you have a great topic in mind let's start with the article 😃.

Start by listing the main topics that you expect to cover in the article and format them into headers. This gives you an idea of the structure of your article and also means you won't forget to cover an important point later on.

Show the reader a preview of the main topics 😃

This is something I like to do but it's up to you. Unless it's a very short article I like to see a content list near the top that gives me an outline of the main topics covered. You can use the headings you created and turn them into a list.

It's nice to cater to the reader when possible. Not every reader is going to read the whole article. Listing the main content covered gives them the ability to better find the things they might be looking for.

3.) Write the introduction

Start with what you want the article to achieve 👏

I sometimes write my introduction before I do anything else. Usually I know the problem I want to write about and what I hope to achieve with the article.

You could also write it at the end when you know exactly what the outcome of the article is. Sometimes the article goes a different direction than you were expecting so this might be a good idea. It's up to you!

These are my primary tips for writing it 👇

Keep it concise.

It doesn't need to be longer than a couple of paragraphs. If it has to be then maybe there is enough content for multiple articles and you should consider splitting things up.

Outline the main topic/problem

Give the reader a quick summary of the overall topic. This could be explaining what it means or why it is a thing/problem/amazing.

What you hope the reader will get from your article

Finally, explain briefly what the reader should know after reading through your piece.

4.) Start writing

Write/read/check and repeat ✍

I'm not going to get too deep into writing tips in this article but I will offer a few things to look out for.

Try to keep it concise with simple language. When I look back to my earlier articles I noticed I was not doing this. My sentences were long and I was using far too many breaks. It breaks the reading flow for the reader.

Another tip is to watch out for what you include in the article. Keep this in mind when your writing 👇.

Work through your headings from top to bottom and write about the things that will help you accomplish the tasks/problem/topic you outlined in the introduction.

If it doesn't help with this then leave it out or link to another article that goes into more depth.

5.) Proofread your work

From the heading to the last character 🧐

Great! Now you might think you're done? Guess again.

It's time to read back through the article from top to the bottom. Read every sentence from the heading to the final character. You'd be surprised to see all of the mistakes I've caught in the headings 😅.

By doing this you'll not only catch spelling mistakes but you'll spot sentences that don't make sense in the flow of the rest of the work.

Once you get in the flow of writing you become oblivious to spelling and grammar errors so this is a really important step (I make a lot of typing errors 😂).

But after reading through you can catch them before anyone finds out 😋.

6.) Publishing

Where to publish? 🤔

The final step is to publish your article. Congrats!! You're nearly there.

There are a couple of great platforms that I would recommend. Firstly here on Dev.to. It has a great community and your articles are almost guaranteed to be viewed by lots of people. It's where I started writing and I would be happy to recommend this platform to others.

Another great option is over on Hashnode. The great thing about Hashnode is that you can publish your articles to your own domain while still seeing the flow of traffic to your articles that you get from a community blogging site.

If you like to cross-post your articles to other sites then you should be careful. Don't forget to set the canonical link to the location it was first posted.

Create a custom article preview image 🙂

Adding a preview image to the top of your article can help it to stand out from the crowd. It's not too difficult to come up with something reasonable.

If you've read any of my other articles you will have noticed I created a template that I customize each time. Yours doesn't have to be like this but it might be good to create something that is unique to you.

As a developer you could create one yourself using CSS like I did or you could use a design tool like Figma. An attractive preview image can help attract readers to your content.

Share it 🤝

Now you have it deployed it's time to share the article! It's likely that you use social media so share it with friends and other like-minded developers.

Conclusion

I hope this look into my process is able to help or motivate you in some way. It is important to know that you don't have to be an expert to blog. It's given me so much in so little time since I started two months ago.

Just start and see where you end up!!

You can find me over @Kieran6dev so come and say hi! If you liked the article please leave some likes or consider following me for future articles.

Thanks!! 👋

1 year into coding 🎉. Here are the tips I would go back and give myself

Kieran Roberts — Fri, 23 Apr 2021 17:04:54 +0000

In March 2020 I began my coding journey which means I have now been learning about web-development for 1 full year 🎈! I've learned a lot along the way but there are a few things I would tell myself if I could travel back in time.

Let's not waste any more time 👏.

Content

Don't be afraid of joining developer communities
You can't learn everything so don't try
Take notes or better yet write a blog
Become comfortable with Git and command line basics early
You learn the most when building projects
Consistency is key
Have fun

1.) Don't be afraid of joining developer communities

This is probably my number 1 tip. It took me around 9 months before I had the confidence to branch out of my own bubble and connect with other developers. I was hesitant about putting myself out there. About putting my work into the open. Thinking I wasn't qualified to share ideas or that I didn't have enough knowledge to teach.

I was completely wrong😅

The developer community is extremely supportive and there are loads of aspiring developers openly sharing their progress with each other. Check out the #100DaysOfCode on Twitter for some examples.

Sharing and learning from other developers is a key part of your progression. It can also be a great source of inspiration for your future work or perhaps a source of networking for you. These are a few of the amazing benefits I can think of 👇.

You can learn from other devs in similar positions
You can learn from more experienced devs
It can be a great confidence builder
You can get feedback on your work
You can network with other devs
You could make some friends

and so much more. Just make the jump and I promise it is the best thing you can do for yourself as an aspiring developer.

2.) You can't learn everything so don't try

As a front-end developer I realized that there is always going to be some new shiny tech that becomes the thing. It is impossible to become a master of everything so don't try.

Do your best to focus on a few key technologies and try to master them. As a learning front-end developer I was jumping into different CSS frameworks, build tools and more. It really wasn't necessary for someone who is leaning front-end development early on.

If you get good at regular CSS then applying it to different CSS frameworks becomes easy when there is a good use-case for them. Once your comfortable by all means try out a framework but don't expect to become good with all of them.

Instead I would now tell myself to focus on the key tech and get good with them before moving on to the shiny stuff. For me as a front-end developer I would focus on the following 👇.

HTML
CSS
Vanilla JavaScript
1 JavaScript Framework
Git
Testing

3.) Take notes or better yet write a blog

I didn't really take many notes while I was learning over the past year. I wish I had now. Recently I found myself trying to explain simple topics out loud and found that I struggled to articulate answers.

Having some of my own notes to quickly reference would have been extremely useful 🙄.

Keeping notes as you learn has so many incredible benefits. Writing will help you reinforce the knowledge you gain and can give you a reference for the future. You could also take it a step further and turn your notes into a blog for others to read.

If you would like to know more about the benefits of blogging while learning web-development then check out my article Why it's awesome for new developers to blog as they learn.

4.) Become comfortable with Git & command line basics early

Even as a front-end developer the command line is something we use on a daily basis. It can be intimidating but even learning some basics can drastically improve your workflow. Things like folder navigation and running executables are valuable skills.

As well as this I would tell myself to not be intimidated by version control specifically using Git. As I prepare to start applying for my first web-development role I have been diving deeper into Git. It has made me realize how little I actually knew about it and what it can do.

The reality is that it is a very important skill to know if you plan on working as a developer in the industry. When you become comfortable with the code itself and you start building projects I highly recommend you practice with Git.

Treat it how you would CSS or JavaScript and you will definitely fell the benefits later on.

5.) You learn the most when building projects

Building projects is awesome. That feeling when you host a project you built on the web for others to see and use is hard to beat. I have found that is also the thing that will help you learn the most.

It is easy to follow tutorials and early on it is a great way to become comfortable with the basics. But at some point it is important to break away and attempt to build your own projects. Start small and if you get stuck then of course use all of the amazing resources we have online to help you.

Google is every developers best friend 😃.

The process of running into problems, googling for solutions and implementing fixes is the iteration that will see you solving your own problems. This is key to becoming a confident developer. Even if the project doesn't turn out how you hoped, it is better than not trying at all.

The important thing is that you try it yourself first. Look up some simple projects and try to personalize it in some way based on your likes or interests.

Get building!

6.) Consistency is key

Consistency is the key to becoming proficient at most things. If you work at it everyday then you are sure to see some progress. The same is true for coding.

Unfortunately not everyone can put all of their time into it. We all have commitments. But if you can dedicate a little time everyday then you are on the right track.

Try to have a specific topic in mind for the session and put all of your focus into it. Could be 30 minutes or it might be a couple of hours. As long as your focus is on the work for that time the consistency will be key to your development.

7.) Have fun

Sometimes coding can be frustrating. We've all been there. It's easy to get frustrated and feel downbeat when we run into problems. But try to remember why we became developers in the first place. For me at least it is because It's fun and I love it!

It's sometimes easy to lose sight of this. Now that I have a little more experience I'm getting better at controlling my code frustration and find that I can now walk away leaving it for later when I come up with a better solution. There was a time when I would stress over a problem for hours at a time.

I now realize that I would become frustrated because I'm passionate about coding and wanting to be as good as I possibly can. I love what I do and I try to keep this in mind which is easy to do most of the time 🙂.

Conclusion

Those were some of my the tips I would go back in time and tell myself and I think they are great tips for any developers learning their trade. I hope you are able to take something with you and if you did then please tell me about it.

You can do so @Kieran6dev where I'm always active or in the comments below.

If you could go back a year(or to the beginning) and give yourself a piece of advice, what would it be?

My most frequent React errors and how you fix them

Kieran Roberts — Thu, 15 Apr 2021 17:29:36 +0000

When using the popular JavaScript library React there are some errors/problems that seem to pop up time and time again. They can be easily avoided in most situations and I would like to share them with you so you can spend less time debugging and more time writing code.

So let's not waste any time and take a look at our problems and how we can solve them 👏.

Content

Forgetting to add keys with a list of elements
Not returning a list correctly
Not cleaning up certain useEffect side-effects
Not wrapping adjacent JSX elements

1) Forgetting to add keys with a list of elements

In React we often find ourselves with lists of data that we want to map into elements or components. This is often done using the Array.prototype.map function to pass data from each index of the array to the element or component through props.

When we do this without adding a key prop React will complain that each element is missing a key. Essentially it is just a special attribute to which we pass a string. It should be a unique string which will distinguish it from its siblings that we are also mapping.

React says:

Keys help React identify which items have changed, are added, or are removed. Keys should be given to the elements inside the array to give the elements a stable identity

Example Problem

Let's map some data before adding keys to our elements to see the problem in action. Here we will have a simple component that deconstructs foods from the prop object. foods is just an array of objects and it looks like this 👇

and our component 👇

and finally the warning from React 👇.

Solution

To fix this all we have to do is pass a unique key to the element we are returning. Often the data we are mapping comes from a fetch request and usually includes an id. Fortunately we have and id property we can use from our set of data. Let's add our key property.

If we didn't have a unique id we would need to have an alternative solution. Often people use the index of the array as the key but this is not recommended for any set of data where positions in the list may change. It can negatively affect the state of the component. See here for more information Reactjs - Reconciliation.

Instead we could create our key by combining the name property with the current date/time using the JavaScript Date object.

2) Not returning a list correctly

To return or not to return

In React as we have already seen we are often iterating over some data . Perhaps we are filtering a data set down to a specific sub-set or mapping to the DOM. Whatever it is there are a few pitfalls we need to watch out for when it comes to returning our data otherwise we might be left scratching our heads.

Example Problem

A frustrating example can be seen when we map a data set to some elements or components. We expect to see the or elements on screen with the data we map into them. However we see nothing.

No error, no warning no data 🤨. In this situation it is likely that you're not returning your result correctly.

For our example we will be mapping our array of foods to some elements so we can show it to the user. It should look like this:

Instead our data will appear to be missing 👇.

Let me show you some examples where we won't see the output that we were expecting. We are passing our array to our component and destructuring it from the prop object the same as before.

Can you spot the problem below.

Correct! Here we are not returning anything either implicitly or explicitly using the return keyword.

Let's take a look at another 👇.

This time we include the return keyword but what we are actually doing here is returning undefined. The code below the return statement never gets read.

There are other examples you might run into but let's take a look at the different solutions we can use.

Solution

Let's start with the explicit returns. If we move our article element in line with the return statement all is well.

See below 👇

We could also wrap the return elements with parenthesis like this:

Another option is to return the result implicitly which means we can forget the return statement and the function body curly braces. Check it out 👇.

or inline like this 👇.

The choice is up to you as long as you are aware of the possible pitfalls you encounter. If the data appears to be missing make sure you check your map function carefully and make sure you are actually returning correctly.

3) Not cleaning up certain `useEffect` side-effects

The useEffect hook allows us to perform side-effects inside functional components. Certain side-effects that we perform in this hook require cleanup. This means that when the component unmounts we can run a special function. Sometimes this is necessary otherwise we might see an error warning us of memory leaks in our apps.

Consider a useEffect that performs some kind of asynchronous api call before setting some component state to the response. If the response is slow and the component unmounts before we receive a response then we might be trying to update the state of a component that is not mounted.

Example Problem

Let's take a look at two different situations where we might add some cleanup to our useEffect.

The first is a situation is where we have an asynchronous fetch request inside our useEffect hook. The user of the application navigates to a different page before we receive the response from the fetch call. This is our component before we add a cleanup function to theuseEffect hook.

Here we are fetching some data after the component mounts and then using the result to set the components state. Finally we map the state to the DOM. Relatively straight forward 👍.

The second situation is where we add some eventListeners to some DOM elements. If the component unmounts we are going to want to remove these listeners.

Check it out before we clean it up 👇

The logic inside our useEffect is irrelevant for this simple example. All that matters is that we are adding an event listener and that will need to be cleaned up.

Solution

We begin by adding a cleanup function to our useEffect like this:

It is simply a function that we add to the bottom of our useEffect hook where we add our cleanup logic.

Now to cleanup our fetch request we can use the DOM api AbortController which is available in JavaScript. It allows us to abort web requests which we will use to abort out of the fetch request whenever the component unmounts. Let's see it in action 👇.

First we create a controller by using the constructor with new AbortController() and then we pass its property signal to the fetch request. This association of controller signal to the request allows us to abort the request by calling abort() inside the cleanup function.

Now we are ensuring that we don't have any requests coming back to a component that is not mounted.

The cleanup function for our eventListener example is simple which you might have already guessed. All we need to do is remove any listeners we create using removeEventListener in our cleanup function. Let's see it in action 👇.

Hopefully now like me you won't forget to clean up your effects 😉.

4) Not wrapping adjacent JSX elements

This one is simple to debug but I though I would include it because I sometimes forget to do it until React starts shouting at me 😅.

Adjacent JSX elements must be wrapped with an enclosing tag. There are a few different ways we can do this based on our requirements.

Example Problem

If we want the wrapper to be part of the DOM for structural purposes then go with some semantic element where possible (<article>, <section> etc.). I usually wouldn't recommend wrapping elements with a <div> although it is fine if you want the wrapper for styling purposes.

Often we do not want the wrapper to part of the DOM because it serves no purpose there. We would only be adding markup only to shut React up.

Let's see the problem in action.

and the error it throws 👇

It is likely that your code editor gave you a warning about this before the error pops up which is great.

Solution

Fortunately React provides us with a solution. We can use React.Fragment to wrap our adjacent JSX if we do not require the wrapper to be part of the DOM. Let's say this is the case for the following example.

First let's use React.Fragment before we see how we can simplify it further.

If we don't need any attributes or keys for our fragment we can shorten React.Fragment to this <> empty tag. Have a look below.

Finally if we are mapping some data to JSX as we have previously seen then we need to add keys to our wrapping element. If all we have is adjacent JSX then we can wrap our elements with React.Fragment and add a unique key to the fragment.

Conclusion

Thanks for getting this far! I hope you learned something from the article and now we can both make sure we avoid these problems in our future code.

If you enjoyed it feel free to drop a 👍 on the article. It inspires me to continue improving and make more awesome content.

If you would like to connect with me then come an say hi @Kieran6dev as I am always active in communicating with other devs over on Twitter.

Thanks!

I built a full stack serverless e-commerce site with Next.js. What I learned and how it might help you

Kieran Roberts — Mon, 05 Apr 2021 09:47:36 +0000

As part of building side projects to fill out my front-end portfolio I recently built a full stack serverless e-commerce site. I have always enjoyed building larger applications and I thought I would build my biggest project yet.

One of my first personal projects was a small site for a fictional brewery company. It had a home page, products page, contact page and a small product store. The products store was more of a to-do list than a real e-commerce store. You could add and remove items but there was no checkout process or payments.

Ever since then I was determined to build a full e-commerce site with all the bells and whistles. And so I did. This is the home screen of 'Kieran's Coffee Collection' in the light color theme 👇.

It is far from perfect which you might see if you look at the code 😅. But it is finished and working and I'm proud that I was able to get to the end. A lot of the points I will soon talk about are the struggles I encountered along the way because I think it is important to reflect on what we can improve on.

Here is the live version of the site 👉 Kieran's Coffee Collection

and here is the code 👉 Github repo

This is not a walkthrough of the project. You wont see any code but instead it is an overview of my experiences and failings so that it might help you.

I am open to writing about the technical side of the project including code and how I built the site. If that is something that interests you then let me know in the comments or alternatively check out the repo.

I learned a hell of a lot during this project so why not share it you. Let's go!

Content

So what is Kieran's Coffee Collection?
What I learned and how it might help you
- 😍 I love Next.js
- 😕 Caching is tricky
- 😃 The back-end setup of Hasura, Auth0 and GraphCMS was great
- 🤔 Take time out to think through problems
- 😮 It is easy to forget about testing but we shouldn't
- 😉 This is the type of project where a component library like Chakra UI is perfect
- 😌 I need to spend more time with TypeScript
Final thoughts

So what is Kieran's Coffee Collection?

First a quick overview of the project. Kieran's Coffee Collection is a serveless e-commerce website built primarily with the React framework Next.js. The rest of the front-end stack includes the component Library ChakraUI, TypeScript and Apollo Client.

Since I'm primarily a front-end developer I wanted to simplify the backend as much as possible. User authentication is handled by Auth0 as a tried and trusted authenticator while Hasura graphql handles the creation and maintenance of the users database. Finally I have GraphCMS as a graphql based headless CMS to handle products and everything related to them.

My store in dark theme 👇

and the cart page also in the dark theme 👇

The primary features of the app include the following:

e-commerce product store
product sorting / filtering
persistent cart / saved products
user authentication / accounts
checkout process
payments
user product reviews
pagination
theme toggle

The shipping page in the checkout process 👇.

Now let's straight into my main takeaways 👏.

What I learned and how it might help you

😍 I love Next.js

Next.js is great. I've now used it in a few different projects including my portfolio.

I love how it simplifies working with images, perfect for an e-commerce site where I'm working with a lot them.

I love how it makes routing and creating pages and dynamic routes so easy and fluid.

I love the TypeScript support which I'm starting to pick up.

I love the api routes that allow you to add some back-end functionality to your app which was perfect in my case. It meant I could easily integrate my authentication redirects, order webhooks and account details updates seamlessly.

If you have some experience with React and are looking for the next challenge I definitely recommend trying Next.js.

😕 Caching is tricky

This is the first project where I really had to manage a cache. I had seen a popular computer science quote by Phil Karlton that says

There are only two hard things in Computer Science: cache invalidation and naming things.

This was my first project using Apollo Client for data fetching. If you've never used it before all you need to know is that it allows you to store the results of queries in a cache. I wanted to try it in previous projects but decided to go with other lighter weight options due to the limited amount of fetching I was doing in those projects. This time I went for it!

I found it to be great for client-side data fetching but I struggled at first when it came to managing the cache. As soon as I started to implement graphql mutations where I was forced to update the cache manually I found it tricky.

This in combination with component state updates and I was having a hard time in understanding why a mutation for a product review was causing 5 new reviews to appear on screen 😂.

But the more I dug into the documentation and took time out to think about problems the easier it became. So I ended up with two main takeways here.

First is don't underestimate cache management. Secondly the documentation is there for a reason so just read it!

😃 The back-end setup of Hasura, Auth0 & GraphCMS was great

The inspiration for this setup was provided by this article series Hasura Fit - By Jesse Martin.

Having previously built projects with Next.js and GraphCMS I was looking for a back-end stack that I could implement successfully as a front-end developer while still giving me user accounts and authorization etc.

I wanted a serveless setup where I could deploy the front-end to a CDN provided by Vercel but I would still have a dynamic app that could update when necessary.

👉🙂 Handling Users

Hasura provides us with instant grahql api's and acts as our 'backend as a service'. In minutes you can have a free Postgres database hosted on Heroku with api's to interact with it and I found using it to be a very pleasant developer experience.

The combination of Hasura and Auth0 was perfect for user authentication and accounts. For user sign-in I could just redirect users using next.js api routes to Auth0 and let them do the heavy lifting. On completion they would be redirected back to my site and by setting up some rules in Auth0, Hasura then handles the creation and maintenance of user accounts.

☕ Handling Products

I liked the separation between users and products included in the article. Having previously used GraphCMS in two separate projects I knew it would be perfect for handling data related to products. Setting up schemas and content is a breeze and I could incorporate mutations and webhooks when required. Similarly to Hasura it also has a free plan available which is great!

🤔 Take time out to think through problems

This is more of a general problem but I thought I'd mention it quickly. Before this project I was prone to frustration. Sitting for hours on end staring at the same problem hopelessly trying solutions that were destined to fail.

Now I have learned that stepping away from problems is often the best solution. If your stuck on an issue move on to another task and you'll end up thinking of a solution to your problem that involves a fraction of the code you would otherwise write.

I had to step away several times because of issues I was having especially when I was dealing with the Apollo cache. I was able to think out different solutions clearly and many of them I realized wouldn't work.

But some of them did and this saved me a lot of time instead of writing out the solution first and then realizing its no good.

😮 It is easy to forget about testing but we shouldn't

I started off the project with the idea of testing as I go. Test Driven Development (TDD) is the process of starting by writing failing tests and then going about writing the code to satisfy the test and rinsing/repeating until satisfied.

It started off well but I soon got carried away with the building and testing was forgotten. If there is one takeaway that will stay with me into future projects it's that I'm going to try not to rush things and instead stick to the plan.

No one wants to be left writing tests after the project is done. It's not a great way of doing things and I'm going to be stricter with myself in the future.

😉 This is the type of project where a component library like Chakra UI is great

For a large project like this with a lot of moving parts and large components Chakra UI was a life saver! I could build large, complex and accessible components in minutes leaving me more time to work on other parts of the app. This sidebar is one such example 👇.

I could build a sidebar like this with a background modal in no time and they're still extremely customizable. There are so many other examples of this. I've never found it so simple to add a light/dark theme toggle. You can then customize individual elements based on the color theme. It's great 😃.

Another example are these tabs located on each individual project page 👇.

If your thinking about building a larger project where you might need a lot of interactive components such as menus, drawers, tooltips, modals and much more then consider giving Chakra UI a go.

😌 I need to spend more time with TypeScript

I have been learning TypeScript for the last couple of months. I though it would be a good skill to start learning now before I look for a job in the industry where I might need it. I'm comfortable with the basics but I found that I'm still unsure how to best use it when projects start to grow.

There are still too many times where I use the dreaded any 😮 type or others that were sub-optimal effectively nullifying the benefits of TypeScript. I was also unsure of where a lot of the types and interfaces should live.

I would like to spend a little time organizing shared types into their own directory because at the moment it is not organized and it can be a waste of time tracking the origin of the file where the type is.

One of my focuses for the next month is going to be diving into the TypeScript documentation and do some more reading. I recently did something similar with git and now I'm much more comfortable with the popular version control system.

Final thoughts

Although there are things I would have liked to have done differently I am very happy with the overall result. I accomplished my goal of building an online store for this fictional company where users can manage accounts, products and checkout out a cart with payments.

If you would like to see more about the technical side like how I integrated certain features than please let me know.

I'm always active over on twitter @Kieran6dev so come and say hi and if you liked the article please let me know. Thanks friends 👋.

An introduction to @testing-library: Part 2

Kieran Roberts — Wed, 31 Mar 2021 11:47:29 +0000

In An introduction to @testing-library: Part 1 we explored why we test, the benefits of using Testing Library as well as some of its features.

It's about time we started writing some tests so let's get straight into in 👏.

Content

Test setup
Our starter component
Testing
Async component update
Conclusion

Want to practice some queries - Testing Playground

1.) Test setup

For the following example I will be using Testing Library in combination with the testing framework Jest and we will be unit testing a simple stateful component in React. I will also be using Yarn as my preferred package manager.

I have begun by creating a new project with create-react-app. The great thing about this is that the packages that we need to get started with are automatically installed for us in the build.

If that wasn't enough create-react-app also comes with support for Jest out of the box meaning we can get straight into writing our component for testing 👏.

The following are the Testing Library packages that we will be using included with create-react-app👇.

@testing-library/jest-dom provides us some custom Jest matchers which we will soon see
@testing-library/react gives us api's so we can work with React components
@testing-library/user-event allows us to perform user related actions like firing events

If you spin up your own create-react-app you will see these packages in your dependencies as well as a setupTests.js file inside the src folder. Inside setupTests.js we import @testing-library/jest-dom. React will run this file before each of our test files meaning it is imported once here and we won't have to keep importing it into every test file.

I'm going to start by creating two folders to store our components (components) and our tests (__tests__). The reason we name the tests file with two underscores on each side is because Jest will recognize this file and run the tests inside for us when we run the script yarn test.

You could also store your tests in the same location as its component counterpart but for this example we'll keep them separate.

To see this in action I will delete the App.test.js file provided by React and create a new test file for our component named UserInput.test.js inside our __tests__ folder and run the test script again. You should see that Jest runs our new test file before giving us a FAIL.

We need a component to test. So let's build one!

2.) Our starter component

Next I'm going to show you the component we will be working with in our examples. All I have done is created the component and imported it into the default App component after removing the starting code that create-react-app provides.

It is a simple example so that we can focus on Testing Library core features and the flow of testing. This is how it looks 👇.

Let me break this down for you. We have a component that has a simple text input that allows users to enter a value into it. We then pass this input value above to a <h2> element.

Pointless I know but it makes for a good example 😅. We also have a reset button that will clear the value in the input field on a click.

We are using a controlled input and therefore we maintain the state of the input value with the useState hook. When the user types into the input we update our input state value using with event.target.value and finally pass this state as the value for our input. Here I am deconstructing target from the event object in the function properties.

We also have a prop called inputType that we pass from the <App /> component. I have given it the value of name so we can ask the user for their name or anything else if we chose to change it. I wanted to include some props for our component so that we can test it.

Below is the <App /> component where we import our component to be tested.

I have also added some simple styling just for you to help visualize our component. This is how it looks in browser 👇.

Here we type my name "Kieran" and you can see this is mirrored above in the <h2> element.

Let's start testing 🙌.

3.) Testing

So we want to avoid testing implementation details. This means we should test the results that our users will see and interact with and not necessarily how we do it in case we change how we do it in the future.

Test 1

Our component has a prop as a string and this prop is shown to the user. So let's make sure this is coming through as we expect. Here we go 👇.

To start we import screen for our queries and the render method to render our component. We will use userEvent a bit later.

Next up we create our describe block that will wrap our tests and then create our first test. This first test will check that the input is working as expected. The describe and test structure is just part of the Jest testing framework.

Next we render our component and we create a mock prop to pass in. When we render our components in unit tests we have to create our props ourselves. Here I pass in a prop called name because we are asking for the users name.

In order to assert that this prop is indeed visible to the user I need to query for it. I start by seeing if I can query it by role with getByRole as an accessible query which in this case is not possible. You can use this list of roles to help you MDN - Using ARIA: Roles, states, and properties.

Querying for elements is an important part of using Testing Library. If you would like some practice with this there is a great tool called Testing Playground where you can quickly write some elements and queries and receive feedback on whether there are more suitable queries available.

Here the prop is passed as text content to both the label and the clear button. We use the getByText query to check if an exact match for this is present in the DOM and it is in our label which is what we are looking for. If we tried to query for a substring like this 👇

screen.getByText(/name/i); which matches a substring with a case insensitive flag i

it would also return our clear button because it contains the word name. We want an exact match like this to find our label 👇.

screen.getByText("name"); which matches an exact string.

Secondly we query for the button by its accessible role and we use the @testing-library/jest-dom package and its toHaveTextContent() matcher. This matcher asserts that it has the text content clear name which partly comes from our prop. If we had more than one button we could query them using getAllByRole() instead. Now if we run the test it should PASS ✔!

This package has a lot of great matchers that let us assert different states of the DOM. Check it out here testing-library/jest-dom.

Next up we want to type into the input and check that it updates the UI with the value provided. Check it out 👇.

First we query for the input element and store it in a variable because we will reference it more than once. We query for the text associated with label which in this case is the value of our prop "name".
Then we query for our output which in our case is the heading element <h2>. We can query this using getByRole("heading").

Next we can start using some events. Here we use the type event to simulate our users typing into the input and we assert that the input value contains the value "Kieran" which we expect. I then use another type event to show you that it doesn't replace the previous event. Just like a real input field the string continues as we type and we end up with "KieranRoberts".

Finally we want to check that this is being outputted as we expect. First as the value of the input with toHaveValue() and secondly to the output heading as text with toHaveTextContent().

Great 👏. Now we have our input tested.

Test 2

Next we want to test that our reset button clears our input as the user expects.

For the purpose of this article I will split our component tests into multiple test blocks so it's easy to follow and there's clear separation with our component features.

Out second test block looks like this 👇.

We start very similarly to before by rendering our component and performing a type event into our input. This time we also have a click event that we trigger on our button. We query for the button using the accessible role button. Finally we assert that the value of the input and the text of the heading are empty string.

Great! All the tests pass ✔.

4.) Async component update

Next let's modify our component a little so that we have some async logic to see how we can successfully test this. I will also change up the markup a little so that we can play with some of the other query variations. Check it out 👇.

The first change we have made is to add a setTimeout function to our reset button click. This is to simulate an asynchronous submission which is often the case in a real application. Secondly I have included a conditional paragraph element <p> so we can see how we should query for elements we expect don't exist.

Updating our tests

If your familiar with Jest you will know we need to mock our setTimeout function for the testing environment. Let's start here 👇

We use to mock jest.useFakeTimers() inside a beforeEach() block which will run the mock before each of our tests. We then simply restore the timer function behavior using the afterEach() block. All of this is just part of the Jest framework.

In our case the first test for the user input remains the same. It's the second test for the input clear that we need to modify.

First of all we now have a conditional element so we want to first assert that this element does not exist in the DOM before we have some user input. We should do this using the queryBy... variation like this 👇.

When we want to query an element that we expect does not exist we use queryBy... because it returns null if it does not find a match instead of throwing an error like getBy... would. Our element will have the text "Input is not empty" if it present so we query for this substring with a case insensitive flag i.

To assert our element is not in the document we use the assertion toBeInTheDocument() from @testing-library/jest-dom combined with .not() provided by Jest.

Then we perform our type user event and this time we also assert that our conditional element is now in present.

And now we get to our async submission. Here it is 👇.

First we click our clear button. Next I make a quick check that our setTimeout mock is called after the click. Now we have to deal with the async part.

When we want to wait some period of time before we make the assertion we can use the waitFor function provided by Testing Library by importing it like this:

import { waitFor } from "testing-library/react";

To this function we pass a callback and we need to await the result of waitFor()because it returns a promise . The default timeout for this is 1000ms meaning our promise should resolve before this otherwise it will reject.

If we did not wrap our assertion this way it would fail because it would run immediately and we currently still have our input value until after 800ms. So instead we waitFor() our result because it calls our callback at different intervals until the promise is resolved. Other than that we still pass in our same assertions.

Let's take a look at the completed test file 👏.

Now when we run our tests we should be greeted by the sweet site of the green PASS ✔.

Waiting on elements

Another common situation that I wanted to mention is when we are waiting on an async event that causes an element to appear that did not previously exist in the DOM. This can be done using the findBy() query variation.

findBy() is a combination of the getBy() variation we have seen and the waitFor() function that we just implemented. It returns a promise that resolves after a default max timeout of 1000ms which means we should await the result.

Consider a situation where we have an async submission for a form and once submitted we add a heading <h2> element to the DOM that says 'Submitted' or maybe we want to store the element in a variable. We could use it like this 👇.

Now we seen some examples of testing some async code as well. Great!

5.) Conclusion

There is still a lot to discover so I encourage you to play around using Testing Library yourselves. I hope you at least learned something from this introduction and I appreciate you taking the time to read the article.

You can find me @Kieran6dev where I'm always active and if you enjoyed the article feel free to let me know. Thanks 👋.

An introduction to @testing-library: Part 1

Kieran Roberts — Wed, 24 Mar 2021 14:03:00 +0000

Testing our apps is a vital part of modern web-development that is often overlooked by new developers. I myself struggled with testing early on. It can be difficult to grasp and there are far fewer free resources available online for testing compared to other topics.

Why do we test our apps?

We want to write tests because they help certify the behavior of our app. You can think of your tests as the documentation for what your code does.

I thought I would introduce you to a set of libraries we can use to help test our apps called Testing Library.

For this introduction you will see me use the React package which is a wrapper on the core library. If you're not familiar with React don't worry. The core principles are the same across the other frameworks/libraries.

On top of the core library there are wrappers that allow us to use this set of testing utilities for multiple different JavaScript frameworks including React, Vue, Svelte and much more.

Content

In part one we will explore 👇

What is Testing Library?
What benefits does Testing Library provide?
What kind of tests can we write with Testing Library?
The flow of testing with Testing Library?
Queries
User Events
Looking ahead to part two!

1.) What is Testing Library?

Testing Library is a collection of utilities that allow us to test our apps in a similar way to how users interact with our site which is a good testing practice. One of the focuses of the library is to provide us with methods of querying for our DOM nodes that is representative of how users would find these nodes on a page.

The description provided by Testing Library on their site is as follows:

The core library, DOM Testing Library, is a light-weight solution for testing web pages by querying and interacting with DOM nodes (whether simulated with JSDOM/Jest or in the browser).

It is not however a testing framework or a test runner. This means we generally use this set of libraries in combination with a testing framework like Jest or Cypress. For the purpose of this introduction I will be running tests using arguably the most popular testing framework, Jest.

2.) What benefits does Testing Library provide?

Testing in a user focused manner gives us the confidence that the tests we write are a true reflection of the user experience.

When we write our tests we want to ensure that we leave out the implementation details of our app. By doing this we ensure our tests are maintainable because any refactoring of our app/components won't cause tests to suddenly fail.

What I mean by this is that we typically want to test the things that our users will interact with and see in our apps. Do you have some state that changes what the user will see on the page? If you do test it.

This article by the creator of Testing Library - Kent C. Dodds explains in detail why we want to avoid testing implementation details - Testing Implementation Details - Kent C. Dodds.

3.) What kind of tests can we write with Testing Library?

The great thing is we can write all kinds of tests using this set of libraries.

Unit Tests ✔
Integration Tests ✔
End-to-end Test ✔

4.) The flow of testing with Testing Library?

Personally I have been using Testing Library in combination with React. The idea is the same across other frameworks/libraries.

The general flow for our tests in React will be something like this 👇.

Render our component passing in some mock props if required
Query for our nodes in component with maybe some initial assertions.
Perform some user action like typing or a click
Assert some change that a user would see based on the user input

We can render our React components for testing using the render method which we can import from the main library like this:

import { render } from "@testing-library/react";

and in our test pass in our component to render it:

render(<SomeComponent />);

Next we'll take a look at how we query for elements 😃.

5.) Queries

An important part of Testing Library is being able to query for DOM nodes in a user focused manner. We do this using methods called Queries.

Queries allow us to find elements that might exist on the page. Knowing the correct query to use for a given situation is an important part of using the library. We need to query for elements so that we can perform some assertions or user events on them.

Then general syntax for querying with Testing Library is as follows 👇.

screen.getByRole("button");

screen is an object that has all the available queries bound to the document.body. We can import it from the main library of whatever context we are using (in this case React) like this 👇.

import { screen } from "@testing-library/react;

The query we used in this case is called getByRole which queries for a single node that has the role of button. Let's take a look at the different query variations we have available.

Query Variations

Queries allow us to find DOM nodes. We can query for single nodes or multiple nodes and queries can be put into three different categories.

getBy...

This query returns a single matching node or an error for no matching nodes. This is usually the go to variation when we are looking for a single node that we expect to be in the document.

queryBy...

This query returns a single matching node or null for no matching nodes. This variation is usually preferred when we want to assert that the node is not present in the document.

findBy...

This query returns a promise that resolves when the element is found. It will reject if no node is found before the 1000ms default timeout. We use this query variation when we expect to have to wait some time before our result is present to the user (e.g some asynchronous request).

These queries also have AllBy... variations that allow us to query for multiple DOM nodes returned as an arrays (e.g getAllByRole). Often our components will have multiple elements of the same role for example and we can group them all using this query.

It is also common to store the results of our queries into variables so that we can reference them in multiple places without having to re-perform the query like this 👇.

const button = screen.getByRole("button");

What can we query for?

Deciding how to query for an element is an important part of using this library. We can find elements in several different ways such as finding text in the document, element roles and label text. Despite this some query methods are preferred to others.

This is because we want to ensure that our tests are a good representation of how our users interact with the app. Certain queries are more accessible than others for example users that visit your site using assistive technology such as screen readers.

If we query an element by its role instead of its text content we can be sure that our elements can be found accessibly as our impaired users may find them.

Let's take a look at what we can query for. For the following queries I will stick to getBy but we can also use any of the other variants.

getByRole()

👆 This is usually the preferred method of query because we can query for roles accessibly by the name that screen readers will read out. There is a lot you can get with this query which I was initially unaware of but it should be the first choice.

You can find a list of ARIA roles here - MDN Web Docs - Using ARIA: Roles, states, and properties

getByText()

👆 Used to query for non interactive elements that have some text content like a <div>.

getByLabelText()

👆 This query will get the <input> element associated with the <label> text that we pass to it. It is usually the preferred method of querying our inputs.

getByPlaceholderText()

👆 Used to query for an element that has some placeholder text such as in an <input>. It is recommended to use getByLabelText over this for querying inputs.

getByDisplayValue()

👆 This will return the element that has a matching value. Can be used to find an <input>, <textarea> or <select> element.

getByAltText()

👆 Used to find the element that has a matching alt text to the value we pass it.

getByTitle()

👆 Query an element that has a matching title attribute value to the value we pass it.

getByTestId()

👆 We can pass a data attribute in the form data-testid="something" to an element and then query for it using getByTestId.

This query is generally not recommend because it is not friendly to accessibility and involves polluting our markup with attributes not relevant to the users.

Because using the right queries is important Testing Library provides us with a function that provides suggestions for which queries to use. We can import the configure() function from our primary library like this 👇.

import { configure } from "@testing-library/react";

and inside our tests we can call it and pass in the throwSuggestions option like this 👇.

configure({ throwSuggestions: true });

This will provide you with potentially better query options when you run your tests and can be helpful early on.

Many of these queries are also able to take optional second parameters for example 👇

screen.getByText("hello world", { exact: false });

meaning we don't have to match the string "hello world" exactly.

Or this 👇

screen.getByRole("button", { name: "reset" });

where we narrow down our button search to an element that also has the name "reset".

There is a lot we can do with our queries and it would beneficial to you to have a play around with trying out different queries. We will start implementing some of these queries in some tests in part two!

You can check out these query methods in more detail here - Testing Library - About Queries.

6.) User Events

Now that know how to query for elements let's see how can simulate some user actions.

Testing Library provides a companion library called user-event that allows us to perform these user-actions available though @testing-library/user-event. Using this library we can perform actions such as user click events, typing, tabbing, hovering and much more. Check out the Testing Library docs here for the full list with explanations - Testing Library - user-event.

First we import the userEvent object as a default export like this 👇.

import userEvent from "@testing-library/user-event";

Then we have a bunch of methods available on this object that allow us to simulate user events like this 👇.

userEvent.click(screen.getByRole("button"));

where we specify the event and the element we wish to execute the event on in the case of the click event.

Let's have a quick look at how queries and events are connected inside an example test file for a React component. The logic of the component or tests isn't important at this stage and we won't be making any assertions just yet.

Here we setup our test with our describe and test blocks which are part of the Jest testing framework. First we import our screen wrapper which allows us to access our queries. Next we import the render method which just allows us to render our react component to the DOM.

Then we render our component and perform our queries for elements we would expect in our component. We can store the result of the query inside constants which is good to do if we plan on referencing them often. Finally we execute some example user events on our elements.

The next step would be to start making some assertions which you will be familiar with if you've used a testing framework like Jest. Testing Library builds on these assertions which we will see in part 2.

7.) Looking ahead to part two!

Now we now why we need to test and how Testing Library can help us, the next step is to write some tests. Finally 😂.

But unfortunately not today otherwise it will end up being far too long.

If you're new to Testing Library I suggest playing around with rendering some component and practicing with the different queries available. We will see this in action in part 2 along with making assertions, dealing with asynchronous events and a look at different queries in action.

Thanks for reading! Feel free to say hello @Kieran6dev.

See you in part 2 👋.

Why it's awesome for new developers to blog as they learn

Kieran Roberts — Wed, 17 Mar 2021 13:35:47 +0000

Writing about what we learn provides us with lots of incredible benefits both ourselves and to our awesome community. Many of us write notes as we go so why not share it others as well?

Before I wrote my first post I honestly thought that I disliked writing but I wanted to give it a go. I used to think that I wasn't qualified to teach others. That I didn't know enough to write a full article about a certain topic.

I could not have been more wrong.

Not only did I enjoy writing about web-development but I learned so much in the process. I was wrong and now I want to encourage others who might think the same.

Let me explain how writing a blog can benefit everyone and why we need new developers to help teach others 🙂.

Why Blog

You will learn more from writing about it
You can explain topics how you would have liked them to be explained to you
You will help teach other developers
It looks great to future employers
You will meet a lot of awesome people
Your writing and communication will improve
It is a lot of fun if you make it so

1) You will learn more from writing about it

There are two main reasons why you will learn more. Firstly you can pick exactly what you want to write about. You might choose a technical topic that you're not familiar with and so you will have to do a lot of research in order to write about it well.

Or maybe you pick a topic that you think you know well. But when you try to explain it you realize that you don't know it as well as you think. It's happened to me on many occasions. And that's a great thing ✔.

You want to find out the things you don't know because that's how you improve. As developers the learning process never stops.

It's not about saying 'I've learned to code' but instead ask yourself 'What can I learn next?'.

2) You can explain topics how you would have liked them to be explained to you

There are a lot experienced and knowledgeable developers who write awesome blogs but we need developers of all levels to create content because they can sometimes simplify topics in a way which others might not.

Let's say I've just become comfortable with the basics of the JavaScript library React. I know why we have class components and functional components and the differences between them. There are others who might not be sure. They see some tutorials where components are written with classes and others written as functions without much of an explanation.

If I had also experienced similar confusion then I would be best placed to explain the history of classes and the introduction of hooks before just diving in to writing stateful components.

As writers we need to write content that is suited to our audience and sometimes those who have recently been though the struggles of a topic are the ones that are best placed to teach it 👍.

3) You will help teach other developers

There will always be new developers taking up coding that rely on community created tutorials and articles. As you progress there will be more and more developers further back in the learning process than you.

This means that even if you have just started out there will be others that would love to read the content you create.

If you start writing on one of the many amazing community blogging sites such as Hashnode or Dev.to your content is guaranteed to be seen. Start small with a focused article that tries to solve a particular issue and your content will be appreciated by others.

With consistency your posts will reach a larger audience and you will be helping to teach the next wave of developers and bloggers.

4) It looks great to future employers

Writing will help you to prove to employers that you know what you claim to know. Especially for those of us without a CS degree. You could link to your blog on LinkedIn to help enhance your profile and make it stand out.

If an employer asks you

'Tell me what you know about arrow functions'

then you can confidently say

'Of course! Arrow functions are.... I also wrote an article for my blog all about arrow functions that was well received if you would like to see it.

It might just help you stand out from the crowd 😎.

5) You will meet a lot of awesome people

The web-development community is by far the most amazing and supportive community I have been a part of. Without this I probably would never have started this blog.

The web-development community have welcomed me and made me feel at home especially over on Twitter. Since I started with my blog I have been able to meet a lot of cool people. They have also helped me along by providing ideas on what to write about.

My first post all about breaking down React State which became a featured article was recommended by someone over in our twitter community 👏.

Being consistent with your writing will lead to interactions with other developers where you can share information with each other. Everyone benefits from sharing valuable information with each other.

6) Your writing and communication will improve

As long as you're consistent and you want to get better, you will! I think one of the main reasons we are hesitant to blog is that we have a lack of confidence in our writing.

There are lots of very successful blog writers who aren't great with the language they write in. And that's OK! ✔ What better way is there to improve your writing than to tackle the problem head on.

Think back to your coding skills in the first month and how they compare to now. You've probably improved a lot. It doesn't matter how great your coding was in the beginning. It only matters that you made the commitment to start.

7) It is a lot of fun if you make it so

Write about topics you enjoy and you will see that it is a lot of fun. Don't write about things that you think will bring you views. If it doesn't go well you will be annoyed with the result and end giving up. It will show in your writing if you're heart isn't in it.

Instead write about things that will bring you enjoyment or allow you to learn something new in the process. And if you can bring out some of your personality into your writing that's even better 🙂.

Conclusion

Thanks for reading! Now get writing

I hope you enjoyed the article and are now inspired to take up a blog. Let me know if this has helped you make the jump. If you know anyone that is thinking of taking up a blog then feel free to share the article around.

I'm active over on twitter @Kieran6dev so come and say hi 👋. Thanks for reading! Until next time

React State: A simple and easy to follow breakdown

Kieran Roberts — Wed, 10 Mar 2021 12:58:12 +0000

Content

What is state?
What causes a component to re-render?
How do we use state in React?
Functional components and the useState() hook
Class components and setState()
State do's & don'ts
Lifting state
Conclusion

So you've just started learning and working with React. Great 😄! React is a fantastic JavaScript library that helps us in building interactive sites but it can difficult to grasp at first.

Coming from vanilla JavaScript into React you will be hit by all kinds of terminology such as props, state, lifecycle, components, hooks and much more. It can be overwhelming but it doesn't have to be.

State is a core concept of React. One that can be difficult to understand at first and especially difficult to master. So that is why I decided to write this article. I like React a lot and would like to help others who might be having difficulties. Let's get to it 👏.

What is state?

Let's consider some simple real world examples for a second. A door can either be open or closed hence in an open or closed state. It can be anything really. Think about a clock ticking over. Each time the second increases, the state of the clock changes.

In React we build our UI by creating re-usable components that we write using JavaScript(usually JSX which is a syntax extension of JavaScript). Components are able to manage their own state locally and they can be combined to form large and complex UI.

Consider a project written with vanilla JavaScript for a second. If we want to update an element normally we would have to query for the element and then do something to it to reflect the change of state. A common way to do this is by toggling certain classes that we have set up. Check it out 👇.

In this simple example we are creating a function to toggle the CSS class "open" every time we click on the button element. We could also say that we are toggling the state of the button which we show to the user through a change in style.

React comes into its own when we are dealing with a more complex application that has a lot of moving parts and requires a lot of state changes/management.

It is down in large part to React state in whether our components are dynamic or not. Values inside state can and often change over time as we require changes to our UI or data.

What causes a component to re-render?

React is very smart when it comes to updating the DOM(Document Object Model). It uses something called the Virtual DOM which is similar to the real DOM that we work with except it is a lightweight virtual representation of it.

Think about walking into your favorite fast food restaurant for second. You have the person working at the cash register that takes your money and we deal with this person every time we're hungry. But there's also that person in the back and this is the person making our food. The unsung hero and the one we know is there but never get to meet 🤣.

Each DOM object has a corresponding virtual DOM object and React uses this virtual DOM to check for updates so that it doesn't have to directly update all of the real DOM's objects if they show no changes. This would be otherwise very inefficient.

Whenever we render a JSX element in React, the whole virtual DOM is updated which happens incredibly quickly. Next up it compares the updated virtual DOM's objects against the real DOM. It will then only make changes to the objects in the real DOM that have changed and that is when we see the changes updated on the screen. This is the reason why React is so fast.

So how do we update the DOM in React other than the initial first render 🤔 ?

In React a component will undergo a re-render whenever its state changes. This can be done in two ways. Firstly through a direct change to the state using the state update functions provided by React which we will soon take a look at. Secondly through a change to the components props.

Now that we have an idea of what state is in the context of React and why we need it, let's see how we can use it in our apps.

How do we use State in React?

Functional components & Class components

Before we start with some example we first have to differentiate the two different methods we have of working with state. While writing or reading about React you may have come across examples of code where components are written as JavaScript classes Class Product extends React.Component {} or as functional components such as const Product = () => {}.

It used to be that when we required a component to be a stateful component(meaning we want create some local state for the component) we would use classes to construct the component. And when we required a stateless(no local state required) component we would create the component as a functional component.

The reason for this is that React did not provide a way for us to control a components state when we used functional components. If we wanted the the component to be stateful then we would have to use a class component and then create a state object with this.state = {...}; which we will soon see.

In February 2019 React released a way in which we could now use state with functional components known as React Hooks. They are essentially special functions that we can use and one of these hooks allows us to control a components state without having to use classes. This does not mean that you are forced to use hooks instead of classes and vice versa. The definition provided by React fro hooks is as follows.

What is a Hook? A Hook is a special function that lets you “hook into” React features. For example, useState is a Hook that lets you add React state to function components. We’ll learn other Hooks later.

It is however my preference to stick to functional components when working with React similar to many others who think that they are simpler to read and write and understand exactly what is going. In fact in the official React documentation in the section Introducing Hooks - React, there is a sub-heading that says:

Classes confuse both people and machines

If you are coming from another language where classes are the norm then don't worry, you are more than welcome to use classes in your React code. React have made clear that they have no plans to remove classes from the library. I think those of us whose first programming language is JavaScript tend to prefer functional programming.

In JavaScript we also have to deal with using the this keyword in classes which behaves differently to many other programming languages and this can lead to code that can be harder to read or follow.

To demonstrate this let's take a look at our first example of a simple stateful component. One will be written as a class and the other as a functional component so we can compare both methods but each component is otherwise the same. Don't worry to much if there's something in the code you are not sure about just yet. We'll cover the specifics about handling state very soon.

Functional Component with useState() hook 👇.

Here we have a simple Button component that requires us to use state so that we can conditionally show the the user whether it is in an "open" or "closed" state. Really contrived example but go with it 😃 just so we can make a quick comparison.

Class Component using setState() 👇.

Aside from there being less code to write in a functional component it is also for me at least easier to parse. Despite this it is important to be comfortable with both class and functional components. There are a lot of resources, code snippets and documentation for React that were written before the existence of React hooks. Therefore we want to be comfortable with both so now we'll have a look at them. Let's get into it 👇.

Functional components and the `useState()` hook

As we briefly saw in the previous comparison we can use state in a functional component with the useState() hook provided by React. To use this hook we call the useState() function inside the component and pass in one argument which will be the initial value for the state. This initial value can be anything and is not restricted to being an object such as setState() which we will see in the next section.

From calling the useState() function we get two things back from React and we use array destructuring to deconstruct them into two variables. If you need a refresher for JavaScript destructuring then check out MDN - Destructuring Assignment. The first is called the state variable and we can give it any name we want. I suggest giving it a name that represents what the state is(e.g products, name, isOpen etc.).

The second value we get back is a function that allows up to update the state and similarly we can choose an appropriate name for it although the convention is to give it the same name as the state value but prefixed with the word "set". For Example:

const [ numbers, setNumbers ] = useState([0, 1, 2, 3]);

We can also have multiple different calls to useState() to keep track of different values in state which may be required in a larger and more complex component. We could inlcude all of the following useState() calls within a single component if we really desired.

Now that we know how to create some state let's put it into action. We are going to create a simple component that will output an array of numbers. We will have a button and whenever we click the button we will increment the last number of the array by 1 and output the full list with our state updates.

Here is an example of it after we have clicked the button once and therefore added the number 4 to the initial list [0, 1, 2, 3] 👇.

We start by creating the functional component and calling the useState() function.

So now we have our state value numbers set initially to the array [0, 1, 2, 3] that we pass in to useState and we also have our function that will let us update the state value when something happens. So let's put it all into action.

Whenever we want to update the state we call the SetNumbers() function in our case. Let's write a simple function that holds the logic to find the next number to add to the list and then update the state as we have defined. This will cause a component re-render and the result can then be shown to the user.

Here we access the last number of the array with array[array.length - 1] and then we call the update state function. We pass in an array where we spread the values from the current numbers state value using the JavaScript spread syntax ... so that we can still keep them in state. Then to the end of the array we add current last value + 1.

The final step is to make sure we return something because all React component must return some kind of React element. In the case of a functional component we can do this with the return keyword. So let's finish our example and update the UI to show that our state is changing.

(note: In the map function below each <li> should contain a unique key property which is explained here React - Lists and Keys)

In order to trigger the function that add adds a number to the array I have rendered a button for the user with an onClick handler that will run our function after a click. Then we want to render our list of numbers to the page. We can do with with the JavaScript map() function which allows us to perform some action on each element of the array and return the result of each action into a new array.

This is a very common pattern in React where we have some data(e.g result of an external API call) and we have to map it in some form to the DOM. Here we map each number into a list element by passing each number into the <li>. Often we would have other custom components where we map the data at each index into the component.

And that's it! We have our stateful functional component that will update upon user interaction 👍. Let's take a look at how we would achieve the same result in a class component.

Class components and `setState()`

Before the introduction of React Hooks we were forced to write our stateful components using classes. React provided us with the setState() api which allows us to request some changes to our state. I use the word request because it is not guaranteed that React will update the state changes immediately. It is possible that React will delay the update for performance reasons so attempting to read the state value immediately after a change might lead to unexpected results.

Nevertheless calling this will always lead to a component re-render as we have previously explored. It takes two arguments shown here setState(updater, [ callback ]) where updater is a function that can take two parameters as state and props and returns the change of state (state, props) => stateChange. The callback parameter is an optional function that gets executed after the component has re-rendered with state changes. This callback is not often used and React suggests not to use it but instead provides LifeCycle Methods which we will not cover today.

We can also choose to just pass an object as the first parameter of setState() instead of the function and this will create a shallow merge of our new state into the state object. This just means that the values in our object will override any duplicate properties with our new values, leaving other properties unchanged and this is how we are going to update our state in our example. This is an example of the merging 👇.

Back to our example we start by creating our local state object in our class constructor like this 👇.

(Note: Don't forget to import React which is not shown in the following examples 😅).

We do this by setting this.state to an object where we can specify the properties we want to keep in state with their initial values. Similarly to a functional component we could use more state variables by adding more properties into our state object.

Next we can update our handleAddNumber function to be suitable for a class component.

The only changes we've made here is to use the this keyword when referencing our state value and update function so that we are referring to our Numbers Class and I have also stored the current state in a temporary variable for readability. It is also important to note that our handleAddNumber method is created using the arrow function syntax so that we don't have to bind our function to the correct this in the onClick handler. Arrow functions do not have their own this and therefore it will refer to enclosing execution context, in this case our class.

If you would like a refresher for understanding the this keyword in JavaScript then check it out here at JavaScript Info - Object methods, "this"

Here we refer to our current state with this.state.numbers and I have stored this in a constant for readability. In order to update the state we setState() provided by react and pass in our new state object. Finally let's return some React Element using the React built-in render() method.

(note: In the map function below each <li> should contain a unique key property which is explained here React - Lists and Keys)

Once again we have to add the this keyword to our handler function as explained and also to our state value this.state.numbers that we are mapping to the DOM.

State Do's & Don'ts

Now that we know how to create stateful components we should consider the things to avoid when we use state in React.

Firstly it is important to know that state changes in React is asynchronous. This means that we need to be careful when calling multiple state change functions in quick succession. We will end up running into problems where we call multiple state updates inside the same cycle.

Secondly it is important that we should never try to change the state value directly using this.state.numbers = ... but instead always use the setState() or useState() options function for classes or the update function provided by useState().

There are also rules for using React hooks such as the useState() hook we have previously used ourselves. React provides us with a few more very useful hooks(and some less useful) that give us our functional component alternatives to using React class lifecycle methods.

The first important rule is that we don't call our hooks anywhere other than the top level. Don't call them inside loops or conditional and try to call them before your functions might experience an early return.

This is because we have to ensure that our component hooks are executed in the same order every time our component renders otherwise we will run into errors with React. If the component only sometimes executes an if statement for example with some state update then there will be a difference in the order that the hooks were called. It is a common problem for React learners and one that will get easier to understand with time.

Secondly we cannot call out useState() (or other hooks) or subsequent state update function outside of React Functions(this means React components or custom hooks which are just themselves functions).

For now it is good to just be aware of the important rules and get playing with state. When you run into problems you will have a better understanding of why you are receiving the error 😃.

Lifting State

Lifting State is a term you may have come across during your learning and it describes a solution for the flow of data through react components. What happens when we have two different components and we would like them to react(pun intended 😅) to the changes in state of another component. Often we have multiple components and we want them to show some changes based on the state changes of another component.

In order to understand this further we need to know about the flow of data through our app. In React we have to pass props down the component tree from top to bottom. We cannot pass this data up from a child to a parent or from a child to a sibling. The data comes from ancestors downwards.

Consider the following example where the Child component originally has some local state but then we realize that the ChildSibling component also requires the same state. In React we want to limit the amount of stateful components as much as possible. The possibility of bugs increases when we work with more stateful components and if we keep re-writing the same code in different places then we are not writing efficient code.

So before we lift our state up we have this 👇.

Here we are just toggling the isOpen state variable with a button click using setIsOpen(!isOpen) which means not the current value of isOpen. A boolean can only ever be true or false so we just flip the value when the button is pressed.

In order for both child components to utilize this state we can 'lift' it to the closest common ancestor of both components. In our case it is the Parent component which we can see is returning both of the child components.

So what we can do is lift the state to the Parent component declaring it only once. Then we can pass the state value as a prop to each component so that it can render something conditionally. We will also move our button to the parent component.

So let's lift it up to the Parent and pass it down to each child.

Now you can see we define our state in the Parent component and pass it to our children via the props object which we deconstruct inside the parameters into the variable so we don't have to bother with writing props.isOpen. We still only have on stateful component which is great 😄.

It is important to not that our child components no longer have control over this state and we cannot modify the values passed down from the parent as props. They can however update in some way as a result of the parent modifying the state.

Conclusion

There is so much more to learn with regards to React and state. Try building some simple components that might be used on a website to practice with state.

Start small like a box that toggles its visibility with a button click. Maybe a clock that uses state to update itself with every second and eventually you will be building bigger and more complex examples.

When you are ready I suggest exploring the other react hooks we have available other than useState() or if you prefer classes then check out the React lifecycle methods.

I hope you enjoyed reading the article as much as I enjoyed writing it. For more React and front-end related content you can follow me @Kieran6dev. Until next time 👋.

A nice introduction to JavaScript variables

Kieran Roberts — Wed, 03 Mar 2021 18:28:05 +0000

Content

What is a programming variable?
How do we create a JavaScript variable?
var, let & const declarations
Scope, Hoisting & Shadowing
Which variable declaration keyword should I use?
How should we name our variables?
What can we store inside variables?
Conclusion

What is a programming variable?

One of the core features of any programming language are things called variables. We use variables to store data. Think of them as boxes that contain some entity and without them we lose the item that was stored inside.

Consider a bottle of beer for a second. Or juice depending on your age 🤔. If we empty out the liquid it no longer has a container and is doomed to be lost to the floor.

Variables are essential to programming languages because they allow us to store pieces of data that we might need later on.

To be able to focus on variables I will stick to using simple examples and assigning basic primitive data types as values to variables(e.g. numbers, strings and booleans). If you would like to check out more about JavaScript data types you can have a quick read of this article by MDN - JavaScript data types and data structures.

Ready? Let's go!

How do we create a JavaScript variable?

To begin with let's have a look at how we create a variable. The most common syntax is generally as follows where we declare our variable with a name and initialize it with a value 👇.

(variable declaration) (variable name) = (some value);

We also add a semi-colon ; after declaring the variable which is used to to separate expressions. It is also used across many other programming languages for this reason and in JavaScript although it is optional, it is highly recommended that we use them after each code instruction to avoid potential bugs that can arise as a result.

It is also possible to create certain variables that are not initialized with a value. In this case the syntax is as follows:

(variable declaration) (variable name);

Variables created by in this way are initialized by JavaScript at execution with a value of undefined and later we will see this in action.

In JavaScript there are three primary methods of creating variables each with their differences. We start by defining the keyword associated with creating the variable before usually assigning some value to it. Let's take a look at each method and the differences between them.

`var`, `let` & `const` declarations

const

The const declaration creates a read only reference to a value that we must be defined when we create the variable. Let's create some variables below 👇.

(The last example is useless I'll admit. There is no need to store a boolean value in a constant that can't be changed, we could just use the value false instead but I thought it was funny so it stays 😄).

When we define a variable using const what we are actually saying is that the variable identifier(name) cannot be reassigned to another value. See here:

When the const declaration we must also initialize the variable with a value. Not doing so will result in an error.

This does not mean that the value itself is immutable(can't be changed). Check out this article for a deeper dive to constant immutability with an object example (When to capitalize your JavaScript constants - {Brandon Wozniewicz})[https://www.freecodecamp.org/news/when-to-capitalize-your-javascript-constants-4fabc0a4a4c4/]

We can however create a new const variable that points at an exisiting const variable. In this situation the value stored in the existing variable is copied into the new variable.

let

The let declaration differs from const because the value stored within a let variable can be changed. We use the let declaration when we know that later on in the program the value is likely to be changed.

With let variables we are not forced to initialize it with an initial value. In this case the variable will be undefined but will not throw an error. Check it out.

var

Using the var declaration predates the previous two examples. It used to be the only way do declare variables until let and const were introduced to JavaScript with ES6 in 2015.

In modern code we have taken to using let and const instead of var because of a few problems that can arise which we will soon explore. It is advisable to stick with let and const although having an understanding of how var works is important to fully understanding JavaScript.

Perhaps you will come across this syntax in older codebases or maybe will be asked to solve JavaScript problems that use the var keyword.

Similarly to let it allows us create variables can either be initialized with a value or not initialized at all.

Unlike the let defined variable we can reassign a var variable to a different value like this

In order to properly understand the what the var syntax does, we need to know about a couple of core concepts which are key to mastering JavaScript. Those concepts are called Scope and Hoisting.

Scope and Hoisting

While I am not going to dive too far into each topic(this would probably take at least two more articles to fully explore 😃), it is important to grasp the idea so that we can explore the differences between var, let and const.

Scope is a concept that defines what variables are accessible at any point in a script. When we create a variable we are defining the scope variable and what has access to it without really knowing it. In JavaScript we have two types of scope when we define a variable. They are Block-scope and Function-scope.

When we create a variable with let or const we are defining the scope of the variable as Block-scope. This means that we can only access this variable from within the same block or further down in the scope tree. A block is defined between the curly braces {} syntax such as in an if statement, a function and more.

var on the other hand defines a variables scope as the current execution context. This is a fancy term that means it will either refer to the global scope(which is shown in the following examples) or the function that it lives in, also known as Function-scope.

In JavaScript a function is simply a piece of reusable code that we can write that allows us to run it whenever we like. When we create a function a new scope is defined for that function.

Using var to create variables can lead to more unpredictable code where access to the variable is possible outside of the current block scope. Consider the following situations 👇.

There the if statement has its own block scope defined by the curly braces and we define a variable using var. But this variable is function-scoped meaning it can be accessed from outside in the scope above(in this case the global scope). And this is not necessarily something we want to be able to do. If we try to do the same but instead create the variable using let then we will see a very different result.

let defines the scope of the variable as being block-scoped meaning we can only use it from within that block or any nested scope below this block. Here we will add an if check inside the original if therefore creating another nested scope such as this 👇.

Here you can see we are able to access the let variable from a nested scope of the scope in which it was created but not from outside. This is a key concept to be aware of as you start working with functions and you are only able to access certain variables in specific scopes.

The second key concept I mentioned was Hoisting. Hoisting is the JavaScript mechanism by which variables and functions are moved to the top of their own scope before the code is executed. When we declare a JavaScript variable it is hoisted. In the case of the var declaration if we try to access it before we declare it, we won't get an error and instead it will return the value undefined.

Opposed to this are let and const where JavaScript does not allow us to access theses variables before we declare them. They are still hoisted to the top of the block however instead of returning undefined and carrying on we will get an error for trying to access it before declaration.

It is always advised whenever possible to initialize your variable declarations with a value to avoid situations where you run into undefined instead of an error resulting in a difficult to debug problem.

Finally shadowing is a concept that we see when we define a variable in a nested scope that has the same name as a variable in its outer scope. Take a look 👇.

Even though we have already defined a const called name, JavaScript does not throw us an error. From the nested scope name will have the value "Bob" while on the outside it will be "Kieran".

Which variable declaration syntax should I use?

This decision has become tricky in recent years since let and const were introduced to JavaScript with ES6(EcmaScript 2015) especially to beginners who are unsure of the differences. In modern code you will often see let and const used exclusively, replacing the former declaration var. These newer methods of declaring variables are generally considered the better approach because they solve some of the problems that come with using var.

Using the var keyword can lead to some unpredictable results. var allows for multiple variables of the same name to be declared re-assigning it a new value. But this is not really something we want. We might accidentally overwrite an important piece of data and JavaScript would not give us an error leading to problems while debugging.

This type of silent failing can be largely eliminated if we stick to using let and const where block-scope is more predictable and easier to grasp for most developers. We will be provided with errors by JavaScript which means we can fix our bugs early before they become a pain in the backside.

Therefore if we need a constant variable where the value is not going to change we use const. If it's value is likely to change then go with let. Even if you are not sure it is not the end of the world. You can start by using const and if you later change the value stored in the variable, your code editor should warn you about the error and before you know it you'll know exactly which declaration to use.

How should we name our variables?

So we now know what variables are. We know how to create them and which versions of variable creation we should use based on the situation. One often overlooked aspect of creating variables is naming them. We should always try to give our variables names that correspond to the data that they hold and sometimes it is more difficult than it seems.

Assigning names in this way helps us because our code is then more readable and much easier to debug. Check out some examples of good and bad variable names 👇

and another

You can see in the example above we have a variable name called productName which contains multiple words with the second of which beginning with an uppercase letter. This naming convention is called "Camel case" or "camelCase" where we don't use any spaces to separate words but instead we capitalize any words that come after the first word.

My first Name would become myFirstName.

Camel case naming convention is the commonly accepted method of naming JavaScript variables and also functions with a few exceptions(class initializations, private class properties etc) which will not be covered in this article.

Another naming convention that you might come across relates to boolean values. To help us differentiate boolean variables from other variable types we prefix the variable name with a helper word such as "is" or "are".

You might also look at someone else's JavaScript code and see a const variable that is all uppercase letters. This is used to denote a constant variable that will point at the same primitive value throughout the lifetime of the script. These primitive values include string, number, boolean, symbol, undefined and BigInt but this convention is generally used when the value is a string or number.

There is really no use case for storing a boolean in a const (as I explained in the first example 😁) that you never intend to change while storing undefined in a variable is not recommended. Symbols and BigInt types are not used as often although they have their use-cases in other situations.

This is again a convention and not required although it does help us differentiate our variables so they are easier to spot and debug.

There are two rules when it comes to naming variables that JavaScript imposes on us. These are as follows:

The first character of the variable name cannot be a digit
Variable name can only contain letters, digits, or the symbols underscore(_) and dollar sign($).

To finish let's take a quick look at a few examples of names we cannot give to variables even if we really wanted to. Check it out 👇.

JavaScript also has a few keywords that are reserved and cannot be used to name variables. These can be found here at w3schools.com - JavaScript Reserved Words.

What can we store inside variables?

So far you have seen me store strings, booleans and numbers inside variables to introduce you to the basics but really we can use them to store much more. More advanced JavaScript data types such as arrays, objects and also functions which are themselves just objects can and are often stored inside variables so that we can reference the data they hold whenever we require. Below is an example of common types of data we store in variables.

Variables are key in allowing us to build all kinds of applications and there is so much we can do but this has been a nice introduction to JavaScript variables. We've only just scratched the surface.

Conclusion

Now that you have a basic understanding of JavaScript variables I hope you can go off and experiment yourself to see what else you can do with them.

Thanks for reading! If you would like to see more from me including my progress as a developer then come say hi on twitter @Kieran6dev.

Lesser known HTML attributes and what they can do for us

Kieran Roberts — Wed, 24 Feb 2021 14:57:49 +0000

There are many attributes that we use on a daily basis when writing HTML. Attributes such as src for <img> tags which allows us provide a source destination for where our image resides.

These are the kind of attributes that most of us are familiar with. Many of them are necessary for the particular element to function as intended. There are however many other attributes that like me, you might not have even known existed.

Recently I completed a HTML quiz and was surprised at how many attributes I had never seen before. So let's explore some of these attributes together including what they do, when to use them and what elements they suitable with.

1. Available globally

translate

translate is an enumerated attribute meaning we need to explicitly pass translate="yes" or translate="no" as opposed to just translate. It is used to instruct translation tools whether or not the text node of an element and its attribute values that are able to be translated, should be translated.

Think of a situation where your site is being translated to another language but you would prefer if your brand name was not translated. You can instruct these translation tools to not translate it by passing the attribute translate="no".

Furthermore this attribute is respected by major automatic translation technologies such as Google Translate although it is not currently supported by Firefox or Internet Explorer. It could also be picked up by a human's translator tool.

Setting this attribute to translate="yes" is unlikely to ever be required because a lack of any translate attributes on the page signals to the translation tool that everything is to be translated anyway. Although if you need to override this for a particular then maybe you should consider setting this attribute to translate="no".

<a href="/" translate="no">
  My Brand Name
</a>

dir

This attribute is used to change the direction of the elements text content and has three possible states. However it should not be used as a method of aligning text because using dir="rtl" with an dir="ltr" based font will mean your full stops will be in the incorrect position on the left side of the text.

ltr
Left-to-right text direction. This is the default value.
rtl
Right-to-left text-direction. Languages such as arabic, hebrew, and pashto are written in this direction.
auto
Allows the browser to decide the value based on an algorithm that checks for strong directionality in the elements text characters.

<header>
    <h1>
        dir attribute changes the direction of the elements text content
    </h1>
    <p dir="rtl">
        Text is in english but is aligned to the right without any influence from CSS although punctuation might be out of place.
    </p>
</header>

spellcheck

This attribute is used to determine whether or not an elements text content may be checked for spelling and grammar mistakes. It can be applied to any element that contains the contenteditable attribute which allows for its text to be edited by the user.

This however is not recommended especially for production code because. You can however use it on an <input> or <textarea> element as long as the <input> element is not of type password.

It is also an enumerated attribute which means you must explicitly pass spellcheck="true" or spellcheck="false".

<textarea contenteditable="true" spellcheck="true">
    spellcheck enabled with editable conten.
</textarea>
<textarea spellcheck="false">
    spellcheck disabl.
</textarea>

2. `<a>`

ping

The ping attribute is used on an <a> element and when clicked it sends a POST request with the body "ping" to the url or multiple urls specified which can also be written as a space seperated list of urls.

A use case for this attribute could be analytics where the owner of the site wants to keep a record of the number of clicks on the link.

<a href="https://something.com" ping="https://analytics.com">
  Checkout this content
</a>

download

We can use the download attribute on the <a> tag in combination with the href attribute that we use all the time. When the user clicks on the link the file attributed to the href tag will be downloaded. You can also set a custom filename for the download by assigning a value to the download such as download="my-burger-menu" or just download for the original filename provided by the href attribute.

<a href="my-burger-menu.pdf" download="brand-menu">
  Download our full menu here!
</a>

3. `<link>`

hreflang & rel

The hreflang attribute is used to instruct the browser as to which language the page is served with allowing its users to be provided with the correct version. It can then provide the site to users during browser searches if they are searching in that specific language. It could be included in either the sitemap, http header or the page markup and you can also target more than one country per page.

To use the hreflang attribute we can pass in the required two letter language code and the optional two letter country code for example for German it would be hreflang="de".

The rel attribute belongs to the link tag that we often use in the head of a HTML document to link things such as stylesheets, icon packages and so on. Its most common job is to inform the search engines about the relationships that exist between your sites pages. When this attribute is set to rel="alternate" in combination with hreflang="de" we are successfully indicating the intended audience of the page.

<link rel="alternate" hreflang="de" href="https://something.de">

4. `<ol>`

start

If for some reason you would like to start you ordered list from a specific number then we can set the start attribute to an integer.

<ol start="5">
  <li>Five</li>
  <li>Six</li>
  <li>Seven</li>
</ol>

reversed

The reversed attribute will reverse the order of list's item instead sorting the list from the highest to the lowest.

<ol start="5" reversed>
    <li>something</li>
    <li>something else</li>
    <li>something more</li>
</ol>

5. `<img>`

loading

Images are often the primary reason as to why your web page's initial load could be slow. Perhaps they are not optimized or maybe your page is trying to load all of the images on the page on the initial load. One way we can speed up this initial load speed is by only loading the images which the user will see after the page loads.

There is a native solution in HTML which can help use with this. We can add the loading="lazy" attribute on an <img> element which instructs the browser to defer loading the image until a certain calculated distance from the viewport is reached. The default option for this attribute is loading="eager" which will load the image immediately on page load.

If the user has JavaScript disabled in the browser this lazy loading method will no longer function as a deferred loading method which can be seen here MDN loading attribute

<img alt="a nice descriptive alt" loading="lazy" src="myimage.webp">

decoding

Another attribute for our images is the decoding attribute which allows us to specify how we would like our images decoded with page load. Specifically we can tell the browser whether we want it to decode the images synchronously or asynchronously. It takes three possible values:

auto
This is the default value where the browser will decide what it thinks is best for the decoding.
sync
Decode the image synchronously along with the other page content.
async
Decode the image asynchronously in parallel with other page content which may help speed up the rendering of the page's other content.

<img decoding="async" alt="a nice descriptive alt" src="myimage.webp">

6. `<form>`

enctype

The enctype atrribute is used on the element to specify how the data from your form submission should be encoded. There are three states that we can set for this attribute:

application/x-www-form-urlencoded
This is the default setting for the attribute and is suitable for most simple HTML forms. It encodes key-value pairs as tuples where a "&" separates each tuple and a "=" in between each key/ value.
multipart/form-data
This value should be specified if your form requires the user to upload a file through the submission process
text/plain
Finally this value sets the encoding to none at all and will just send the data as plain text which is not recommended.

<form enctype="application/x-www-form-urlencoded">
  <label for="country">
  <input id="country" name="country" type="text">

  <input name="submit" type="submit">
</form

novalidate

This is an interesting attribute that allows us to specify whether we would like the data from a form submission to be validated natively on submission. By default it is set as true even if we don't include it and therefore passing novalidate on the form will disable the native validation.

A good use case for setting novalidate on the <form> element is when you want to allow users to save their form progress so they can finish the submission at a later date. It will allow them to save their current form values without running into validation errors preventing them from saving.

<form novalidate>
  <label for="country" >
  <input id="country" name="country" type="text" />

  <input name="submit" type="submit" />
</form

7. `<input>`

autocomplete

We all despise filling out forms. Despite this there are ways in which we can make it easier for the users of our site to accomplish this quicker. One of them is the autocomplete attribute which tells the browser how it should populate a given form field if auto-completion is set based off the users history.

This attribute can be used with <input> or <form> elements with value differences. When using forms the name on the input element is used to dictate the kind of information that will be used for the auto-completion so make sure you choose an appropriate name for the input (e.g. name, email, city, state, postcode etc...). If used on the <form> element it can have the value of on or off;

A full list of autocomplete options for the <input> can be found here The HTML autocomplete attribute

There are few use cases for turning off this attribute on your forms. One of them might be that you implement your own custom autocomplete or perhaps you have a field which takes some custom data where you don't need to remember previous results. Even if you set it to off there may be cases the where the browser ignores it if it suspects it is a login form (see here MDN How to turn off form autocompletion

<form>
  <label for="country" >
  <input id="country" name="country" type="text" autocomplete="off" />

  <label for="postcode" >
  <input id="postcode" name="postcode" type="text" autocomplete="postal-code" />

  <input type="submit" />
</form

<form autocomplete="on" >
  <label for="country" >
  <input id="country" name="country" type="text">

  <label for="postcode" >
  <input id="postcode" name="postcode" type="text">

  <input name="submit" type="submit">
</form

max/min

The max and min attributes can be specified on an <input> element to limit the valid possible value of the element. The value should be less than or equal to the min and greater than or equal to the max. It can be applied to seven different input types which include:

number
range
time
date
month
week
datetime-local

<form>
  <label for="number">Number</label>
  <input id="number" max="30" min="-30" name="number" type="number">

  <input name="submit" type="submit">
</form>

maxlength

Another way to limit the value of an input field is through the maxlength attribute which we can assign to <input> or <textarea>. It will limit the number of characters that can be entered into the field and it must be an integer that is greater or equal to 0.

We can use this to limit the characters to a username for example although this method should not be relied upon as form validation. It is more a helpful tool to be accompanied by server-side validation of the input.

<form>
  <label for="username">Username</label>
  <input id="username" maxlength="30" name="username" type="text">

  <input name="submit" type="submit">
</form>

pattern

The pattern attribute when applied to an <input> element provides a regular expression(string of characters to define a pattern) that it can use check against the value of its input. It can be applied to the following input types:

text
tel
email
url
password
search

This functionality could be useful if you need some simple validation without needing to resort to JavaScript. The problem with this type of validation though is the ease at which regular expressions can introduce bugs due to its complexity if not understood or tested properly.

Once again relying on front-end validation for form submissions is not recommended and we should always include server-side validation. The example below validates that the input only contains letters or numbers.

<form>
  <label for="username">Username</label>
  <input id="username" name="username" pattern="[A-Za-z0-9]+" type="text">

  <input name="submit" type="submit">
</form>

readonly

Setting the readonly attribute on specific <input> elements check out which elements here, or the <textarea> element disables the ability for the user to edit the input value.

You might think that it sounds the same as the disabled attribute which is commonly used to achieve a similar effect but there a few differences. Unlike to the disabled attribute, when readonly is applied to an input it is still possible to copy the value of the input and users can also focus into the element.

<form>
  <textarea readonly>
    Users will not be able to edit this field but can copy or tab into it
  </textarea>

  <input name="submit" type="submit">
</form>

step

The step attribute specifies a numeric value that the input uses as the stepping interval whenever the user clicks on the increment or decrement buttons. It can be applied to <input> elements of type range, number and the time/date types.

<form>
  <label for="number">Number</label>
  <input id="number" step="5" name="number" type="number">

  <input name="submit" type="submit">
</form>

Conclusion

Thanks for getting this far! I hope you were able to learn something new about HTML to take with you in your web-development journey.

You can follow me @Kieran6dev for more helpful tips as well as my own progress through web development.

If you know of any other lesser-known HTML attributes which I did not include then let me know in the comments below. Thanks!

Ditch the dreaded
. Semantic HTML elements we should use instead

Kieran Roberts — Wed, 17 Feb 2021 15:20:00 +0000

Firstly we'll clear up the meaning of semantic HTML. The semantics of an entity describes what its purpose is. By using semantic HTML elements we are able to provide meaning to the structure of our code. If you think about the <div> tag for a second ask yourself this: If you had never heard of this element before what would you think its purpose was?

Difficult right? 🤔

Imagine trying to build a new desk from one of those sets you can buy at a furniture store. It includes everything you need to construct it as well as an informational booklet with all the information related to the desk.

Now imagine each page of the instruction booklet is missing a header. It makes finding the instruction page much more difficult as well as the list of contents in the box, the warranty policy, and so on. You can still find them but you have to look very closely.

The name <div> does not offer any information as to what role it might perform. Now think of the <h1> tag or any heading tag for that matter. The heading element has a role that describes the role it performs (as a heading). There should only ever be one <h1> element on the page.

There are three primary advantages to using semantic HTML elements to you and the users of your site:

Search Engine Optimization

This refers to the way in which search engines such as Google interpret the content of your site and it can affect where your site will appear in search results. This means that neglecting semantic HTML could have a negative effect on how many users will find and interact with the site.

Accessibility

Using elements that better describe the role they perform makes it easier for screen readers to inform users with disabilities about the content of your site.

Code readability and maintainability

Using semantic HTML elements can help you with the maintaining and debugging of your code making it clear which part of the code you are looking at. This is especially important if you are working with other developers in the same codebase.

There are many semantic elements we can use that in principle do the same thing but offer the benefits outlined above. Now that we understand what a semantic element is and why they are important, let me show you some semantic elements that we can use to replace the <div> that you might still be using a little too often.

Throughout the article I will include quote definitions for each element using MDN Web Docs before explaining them in simpler terms.

Let's begin 👏.

`<article>`

Definition by MDN:

The HTML <article> element represents a self-contained composition in a document, page, application, or site, which is intended to be independently distributable or reusable (e.g., in syndication). Examples include: a forum post, a magazine or newspaper article, or a blog entry, a product card, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.

This element is often used to wrap pieces of content where your codebase might contain multiples of them. An example of this is a blog post preview card or the post itself but really you could use it whenever you have a piece of content that includes a heading to describe it and the content representative of the heading. You can also nest <article> elements inside each other.

Example 👇

<article class="product">
  <h2>
    Coffee
  </h2>
  <article class="product-info>
    <h3>
      Product information
    </h3>
    <p>
      Very delicious coffee!
    </p>
  </article>
</article>

`<header>`

Definition by MDN:

The HTML <header> element represents introductory content, typically a group of introductory or navigational aids. It may contain some heading elements but also a logo, a search form, an author name, and other elements.

This element is typically useful for grouping elements that represent the header of an article or post together where at least one of the elements includes a heading element such as <h2>. I have also used it in the hero of a landing page of a site that includes the main heading element <h1> and possibly some images, text, links or other introductory content that support the heading.

Although called a header element it is not necessary to use this element at the top of the page and can used in other sectional elements such as <article> and <section>.

Examples 👇

<header class="header">
  <h1>
    Hero header
  </h1>
  <img src="heroimage.webp" alt="a nice descriptive alt text">
</header>

<article>
  <header>
    <h2>
      Article header
    </h2>
    <a href="/blog-article">
      Link
    </a>
  </header>
  ...
</article>

`<section>`

Definition by MDN:

The HTML <section> element represents a generic standalone section of a document, which doesn't have a more specific semantic element to represent it. Sections should always have a heading, with very few exceptions.

Similar to the <div> there is often a better choice than the <section> element. Even so it is an improvement on the <div> when you need to section-off a piece of content that would not be suitable for a <nav> or <article> or similar elements (as long as it is not used for styling purposes).

If you require an element wrapper for styling purposes it is better to stick to the <div> element.

Example 👇

<section id="blog-articles">
  <h2>
    Section header
  </h2>
  ...any other content related to the section
</section>

`<nav>`

Definition by MDN:

The HTML <nav> element represents a section of a page whose purpose is to provide navigation links, either within the current document or to other documents. Common examples of navigation sections are menus, tables of contents, and indexes.

Use it to wrap the primary sets of links that are used to navigate around your page indicating clearly to your screen reader users exactly where the main navigational links of your site are based.

Example 👇

<nav id="main-nav">
  <ul>
    <li>
      <a href="/">
        Home
      </a>
    </li>
    <li>
      <a href="/blog">
        Blog
      </a>
    </li>
  </ul>
</nav>

`<main>`

Definition by MDN:

The HTML <main> element represents the dominant content of the <body> of a document. The main content area consists of content that is directly related to or expands upon the central topic of a document, or the central functionality of an application.

You will only ever have one <main> element per page of a site that indicates to the user where the primary content of the page exists. This is the content that is left when you ignore secondary content that is repeated across other pages of the site such as the content enclosed in the <nav>, <footer>, <aside> and similar additional elements. These are sometimes called layout components/elements.

It also has an important role for users requiring a screen reader to navigate your site because they are able to instruct their browser to skip straight to the <main> element and the content it includes.

Example 👇

<nav id="main-nav">
  <ul>
    ...navigational links
  </ul>
</nav>
<header id="landing">
  <h1>
    Some descriptive page header
  <h1>
  <p>
    ...explanation
  </p>
  <a href="/blog">
    call to action for user
  </a>
</header>
<main>
  <h2>
    Welcome to the main content of the page
  </h2>
  <article>
    <h3>
      Article title
    </h3>
    ...
  </article>
</main>
<footer>
  ...
</footer

`<aside>`

Definition by MDN:

The HTML <aside> element represents a portion of a document whose content is only indirectly related to the document's main content. Asides are frequently presented as sidebars or call-out boxes.

The <aside> element is to provide some content that is secondary to whatever content it relates to. This means that wherever the element is in the document, it should only contain content that the user does not explicitly require to understand the primary content.

An example is in an article to provide a definition for something or a further explanation the relates to the content. Maybe some links to other articles that expand on a definition further.

Example 👇

<article>
  <h2>
    Article header
  </h2>
  <p>
    I really enjoy writing JavaScript.
  </p>
  <aside>
    JavaScript is a high-level dynamically typed programming language. You can find more information here ...
  </aside>
  <p>
    I also really like semantic HTML.
  </p>
</article>

`<details> & <summary>`

Definition by MDN:

The HTML Details Element (<details>) creates a disclosure widget in which information is visible only when the widget is toggled into an "open" state. A summary or label can be provided using the <summary> element.

These two elements are really useful when you require a widget that can be toggled to an 'open' or 'close' state that reveals or hides some content. A typical use case for this is an faq (frequently asked questions) section of a website that allows the user to click on a question to reveal the answer.

It uses no JavaScript meaning it will continue to function properly for your uses even if they have set their browser to ignore it, making your site more accessible. The <summary> tag contains the text that is always visible to the user while the <details> tag holds the information to display when the widget is in the 'open' state.

Example 👇

<details>
  <summary>
    Do you offer tours of the brewery?
  </summary>
     Unfortunately at this time we do not offer tours of the brewery. We are currently building our taproom so stay tuned.
</details>
<details>
  <summary>
    Are your beers gluten-free?
  </summary>
     All of our beers are gluten-free and vegan-friendly!
</details>

`<figure> & <figcaption>`

Definition by MDN:

The HTML <figure> (Figure With Optional Caption) element represents self-contained content, potentially with an optional caption, which is specified using the (<figcaption>) element. The figure, its caption, and its contents are referenced as a single unit.

Generally the <figure> element encloses an image (although it is not required) and is usually accompanied by a <figcaption> element that provides the description for the element. You could also include other elements such as the <p> tag that is relevant to the figure.

In my experience it is useful to include the <figure> element when you include a piece of content such as an image, diagram, or piece of code that relates to the content you are writing within some article or post.

Example 👇

<article>
  <h2>
    Article header
  </h2>
  <p>
    ...some introductory text
  </p>
  <figure>
    <img src="post.webp" alt="a nice descriptive alt text" />
    <figcaption>
      Photo taken by Kieran Roberts
    </figcaption>
  </figure>
  <p>
    ..rest of the article
  </p>
</article>

`<blockquote>`

Definition by MDN:

The HTML <blockquote> Element (or HTML Block Quotation Element) indicates that the enclosed text is an extended quotation. Usually, this is rendered visually by indentation (see Notes for how to change it). A URL for the source of the quotation may be given using the cite attribute, while a text representation of the source can be given using the <cite> element.

Use the <blockquote> when you want to include text in your site that comes from another source. The cite attribute on the <blockquote> element should be used to provide original source of the content.

Example 👇

<blockquote cite="link to the souce">
  <p>
    This is an inspirational quote from another source
  </p>
  <footer>
    Source author, <cite>content of the citation</cite>
  <footer>
</blockquote>

`<abbr>...</abbr>`

Definition by MDN:

The HTML Abbreviation element (<abbr>) represents an abbreviation or acronym; the optional title attribute can provide an expansion or description for the abbreviation. If present, the title must contain this full description and nothing else.

This element is nice for providing a simple but effective tooltip effect to acronyms you might have on your site. I have included this attribute myself in my portfolio for things like JavaScript(js). The title attribute provides the full description of the acronym when the users hover over it.

Example 👇

<p>
  I really enjoy working with<abbr title="JavaScript"> js </abbr>and I am now learning <abbr title="TypeScript"> ts </abbr>.
</p>

`<footer>...</footer>`

Definition by MDN:

The HTML <footer> element represents a footer for its nearest sectioning content or sectioning root element. A footer typically contains information about the author of the section, copyright data, or links to related documents.

Typically people include one <footer> at the bottom of the document but we can also include a <footer> for each <article> or <section> element as long as it does not have another <footer> or <header> element as a descendant. Inside the <footer> you can include any kind of text, images, or links related to the placement of the element.

Examples 👇

<footer>
  <p>
    This is the end of the site
  </p>
</footer>

<article>
  <h2>
    Article header
  </h2>
  <p>
    Article content
  </p>
  <footer>
    <p>
      Article footer
    </p>
  <footer>
</article>

Conclusion

I hope you have learned something about semantic HTML that you can take with you into future projects to make your markup more accessible for everyone that interacts with your site!

You can follow me @Kieran6dev where I'm always active and happy to connect with you!

Thanks for reading 👋

DEV Community: Kieran Roberts

cvrsnap.com: Blog post cover image creator to help you publish quicker

Why did I build this tool?

Who is the tool for?

The live site

CvrSnap example covers

Requirements

Tech Stack

Build Specifics

React Router v7 & the rendering approach

The persistent editor: Zustand + IndexedDB

IndexedDB

Dom to image handling

MantineUI

Infrastructure

What went well

Product: Editor

Personal: Learning

What can be improved

Mobile UX

Customisation options

Landing page

React router: Library or Framework

Summary

My process for writing blog articles with actionable steps you can follow

My Blogging Steps

1) Pick a Topic

2.) Plan the main points

3.) Write the introduction

4.) Start writing

5.) Proofread your work

6.) Publishing

Conclusion

1 year into coding 🎉. Here are the tips I would go back and give myself

Content

1.) Don't be afraid of joining developer communities

2.) You can't learn everything so don't try

3.) Take notes or better yet write a blog

4.) Become comfortable with Git & command line basics early

5.) You learn the most when building projects

6.) Consistency is key

7.) Have fun

Conclusion

My most frequent React errors and how you fix them

Content

1) Forgetting to add keys with a list of elements

Example Problem

Solution

2) Not returning a list correctly

Example Problem

Solution

3) Not cleaning up certain useEffect side-effects

Example Problem

Solution

4) Not wrapping adjacent JSX elements

Example Problem

Solution

Conclusion

I built a full stack serverless e-commerce site with Next.js. What I learned and how it might help you

Content

So what is Kieran's Coffee Collection?

What I learned and how it might help you

😍 I love Next.js

😕 Caching is tricky

😃 The back-end setup of Hasura, Auth0 & GraphCMS was great

🤔 Take time out to think through problems

😮 It is easy to forget about testing but we shouldn't

😉 This is the type of project where a component library like Chakra UI is great

😌 I need to spend more time with TypeScript

Final thoughts

An introduction to @testing-library: Part 2

Content

1.) Test setup

2.) Our starter component

3.) Testing

Test 1

Test 2

4.) Async component update

Updating our tests

Waiting on elements

3) Not cleaning up certain `useEffect` side-effects

Functional components and the `useState()` hook

Class components and `setState()`

`var`, `let` & `const` declarations

2. `<a>`

3. `<link>`

4. `<ol>`

5. `<img>`

6. `<form>`

7. `<input>`