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. It’s 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 it’s 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 there’s 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 don’t have a current template designed (somewhere like Figma) for me to re-use across my posts and I don’t 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 wouldn’t 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 don’t 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 don’t 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

1. A very simple landing page

2. Editing interface

3. Minimum set of customisation options to start with.

   1. Text placement, size, font, etc.

   2. Background colors, templates, images etc.

4. 1 click image download in PNG format that accurately resembles the preview.

5. An editor that would persist the selected design options.

6. Different download size options.

7. Light/dark theme toggle.

Tech Stack

• React Router v7

• TypeScript

• html-to-image

• MantineUI

• SST

  • Amazon CloudFront

  • Amazon S3

  • Amazon Route 53

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 API’s 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 don’t believe it’s 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 there’s work that can be done to better explain this product now it’s 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. I’m 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.

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

CvrSnap does not have user authentication, and doesn’t 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:

1. 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.

2. IndexedDB allows structured data which I would would be working with (objects) without requiring it to be serialised.

3. 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.

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 it’s 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. There’s 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 wasn’t 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. It’s open source, TypeScript based, and adaptable to various modern Frameworks. The component list of it’s 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 that’s 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. It’s 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.

I’m 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 you’ll find plenty of articles if you’re 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 didn’t 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 shouldn’t 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 I’m happy that you can make covers that don’t all look completely identical. I’m 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 I’m 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 it’s not ideal. I don’t 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 don’t add design fatigue to the user since that would defeat the purpose of the app. I’m 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 that’s 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 I’d be happy to read/share.

This article will share some tips and good practises that I employ to help make my code more maintainable, reusable, organised, and performant within a React project. Some of the tips are applicable outside of a React codebase as well. I love to learn so please share any tips you have also in the comments. Let me know if you have a better/different approach to something that’s mentioned.

Here are 5 tips/good practises to consider implementing in your React codebases.

1. Use ‘dumb’ components

A dumb component is simply a component who’s purpose is to be presentational (UI). It separates presentation from logic. It might accept some props, and render some UI. Some of the benefits are:

• Better reusability

• Better predictability

• Better separation of concerns

• Simpler to maintain

Any smart logic (state etc.) can be moved to a wrapping container and any data the dumb component requires can be accepted through props.

Before ‘dumb’ components

// ❌ Avoid tying a simple presentational element to complex logic

interface BlogCardProps {
  title: string;
}

export const BlogCard = ({ title }: BlogCardProps) => {
  // Here we are tying the useUser hook to an otherwise simple presentational card
  const { user } = useUser();

  return (
    <article>
      <h2>{title}</h2>
      <span>{user.name}</span>
    </article>
  )
};

Perhaps we will want to reuse BlogCard later but we might not interested in the user name for that instance. Depending on what useUser is doing, you may be making an API call you don’t need, or running some logic that adds unnecessary performance overhead. Rudimentary example I know but the idea is there.

After ‘dumb’ components

// ✅ Dumb Component (Better):

interface BlogCardProps {
  title: string;
  userName: string;
}

const BlogCard = ({ title, userName }: BlogCardProps) => (
  <article>
    <h2>{blog.title}</h2>
    <span>{userName}</span>
  </article>
);

// Blog Section becomes the smart container with complex logic
const BlogSection = ({ blog }: { blog: Blog }) => {
  const { user } = useUser();
  const { posts } = useBlogs();

  return (
    <div>
      <section>
       {posts.map((post) => {
         return (
           <BlogCard 
             key={post.id}
             blogTitle={blog.title}
             userName={user?.name ?? 'Unknown'}
           />
          )
        })}
      </section>
      ...
    </div>
  )
};

A better approach is to designate a container component to handle the complex logic, and pass down the data to any presentational components that need it.

Dumb components are some my favourite components and I recommend you keep this in mind the next time you are composing some UI. It makes reusing and testing so much easier.

2. useState isn’t always the solution

The useState hook is often overused. Many times we can perform the desired action with an alternative solution that improves the user experience.

A common case where useState is sometimes seen but not ideal is a component that does sorting/filtering.

Before with useState

// ❌ Non ideal approach with useState:

import { useState } from 'react';

const sortTypes = {
  popular: 'popular',
  newest: 'newest'
} as const;

type SortType = (typeof sortTypes)[keyof typeof sortTypes];

export const BlogList = () => {
  const [sortType, setSortType] = useState<SortType>(sortTypes.popular);

  return (
    <div>
      <select value={sortType} onChange={(e) => setSortType(e.target.value as SortType)}>
        <option value={sortTypes.popular}>{sortTypes.popular}</option>
        <option value={sortTypes.newest}>{sortTypes.newest}</option>
      </select>
    </div>
  );
};

The UX of this example is poor for a few different reasons:

1. If we refresh, we lose our current sort and the default sort is restored. This can be frustrating to users who want to continue from where they previously were.

2. We are unable to share a link that includes a specific sort type.

We can implement a much more user friendly approach by utilising the URL as state.

After using the URL as our ‘state’

// ✅ Better approach using the URL:

import { useSearchParams } from 'react-router';

const sortTypes = {
  popular: 'popular',
  newest: 'newest'
} as const;

export const BlogList = () => {
  const [searchParams, setSearchParams] = useSearchParams();

  const sortParam = searchParams.get('sortType');

  const sortType =
    sortParam && sortParam in sortTypes ? sortTypes[sortParam as keyof typeof sortTypes] : sortTypes.popular;

  const onSortTypeChange = (e: React.ChangeEvent<HTMLSelectElement>) => {
    setSearchParams((params) => {
      params.set('sortType', e.target.value);
      return params;
    });
  };

  return (
    <div>
      <select value={sortType} onChange={onSortTypeChange}>
        <option value={sortTypes.popular}>{sortTypes.popular}</option>
        <option value={sortTypes.newest}>{sortTypes.newest}</option>
      </select>
    </div>
  );
};

Now our selected state is saved by the url, even after refresh. The user can save/share/bookmark the url and keep the current sort. We fallback to a default sort type popular if the url is not what we expect so the app works as expected. This also now incorporates the browser history allowing users to flick between sorts.

More features that can often make use of the URL as state is

• Filtering/sorting

• Pagination

• Tab interfaces

• Search functionality

• Multi stage forms

Keep this in mind the next time your writing your next useState hook.

3. Think about how you organisation/structure your code repository

This one isn’t strictly React focused, but it applies nonetheless. Repository structure and good organisation is something we all was unsure of at some point. It’s not really something that’s taught akin to learning your chosen coding language. But as you see when you start working in real projects, the structure of the code has real affects on working within it successfully. This is mostly aimed at projects that start to grow beyond the simple few files. Most real React projects will have several components/pages/hooks/utils from early stages.

As your projects grow, you’ll want a structure that is:

• Scalable

• Maintainable

• Adheres to some good patterns

Ensuring these points are taken care of makes everything easier for you and any collaborators working on the project. Testing, debugging, working in parallel, you name it.

There is no ‘correct’ way of structuring your repository. Projects have different requirements and complexity.

Recently I have been enjoying implementing a ‘Feature-Based Architecture’ for my personal projects. As you may guess, it suggests structuring code by features e.g. editor, preview. I like the scoping here. Each feature directory may have it’s own hooks, utils etc. directories with code only that feature requires. A shared directory is used to include code that is shared across features.

Example of a feature-based hierarchy

src/
│
├── features/                   
│   ├── editor/                   # Editor feature
│   │   ├── components/
│   │   │   ├── Drawer.tsx
│   │   │   ├── TextSettings.tsx
│   │   │   └── BackgroundSettings.tsx
│   │   ├── hooks/
│   │   │   └── useEditorData.ts
│   │   ├── styles/
│   │   │   └── Drawer.module.css
│   │   └── index.ts
│   ├── preview/                 # Preview feature
│   │   ├── components/
│   │   │   ├── CoverImage.tsx
│   │   │   ├── CoverImageControls.tsx
│   │   ├── hooks/
│   │   │   └── usePreviewData.ts
│   │   ├── styles/
│   │   │   └── CoverImage.module.css
│   │   │   └── CoverImageControls.module.css
│   │   ├── consts/
│   │   │   └── index.ts
│   │   └── index.ts
│   │
│   └── ... (other features)
│
├── shared/                       # Shared/common code
│   ├── components/               # Reusable components
│   │   ├── Button.tsx
│   │   ├── Modal.tsx
│   ├── hooks/                    # Shared custom hooks
│   │   └── useImageDownload.ts
│   ├── styles/                   # Global or shared styles
│   │   └── global.css
│   ├── layouts/                  # Shared layouts
│   │   └── navbar.tsx
│   ├── utils/                    # General-purpose utilities
│   │   └── logger.ts
├── pages/                        # However you app handles pages etc.
│   ├── index.tsx

There’s a nice encapsulation about this structure that I find appealing. Despite some of the code being a bit more ‘spread out’ that it would in some structures, I know exactly where everything should be when I create something new and I’m never second guessing or wasting time thinking about it. I hate not knowing where I should place a component/value etc, and this way I have clear pattern.

I have built many projects that started out with a flat/technology based approach. When starting out this way you still need to make decisions about how you are going to organise sub-directories like components. Do you group by location, feature, or something else. You certainly have to group in some way or end up with a directory that’s impossible to navigate nicely. You could group by feature within components for example, but let’s say you want to re-work a feature, or add some upgrades. Now you have to traverse throughout all the parent directories to find what you need like components, hooks, utils, stores and whatever else the feature uses to make your changes. Of course you can make searching the repo easier by keyword searching, but still.

Instead, with the feature based approach I can navigate to my feature and get started. Maybe I have to look in shared but it will be easier to navigate this directory now that most of the logic is encapsulated within the feature directory.

Example of the flat/technology based hierarchy

src/
├── components/         
│   ├── Drawer.tsx
│   ├── TextSettings.tsx
│   ├── BackgroundSettings.tsx
│   ├── CoverImage.tsx
│   ├── CoverImageControls.tsx
├── layouts/            # Layout components
│   ├── Header.tsx
├── hooks/              # Custom React hooks
│   ├── useImageDownload.ts
├── styles/             # Global or modular styles
│   └── global.css
├── utils/              # General-purpose utilities and helpers
│   └── logger.ts
├── pages/              # However you app handles pages etc.
│   ├── index.ts/

Another type of organisational design system you may come across, especially in a React project is ‘Atomic Design’. This usually involves grouping code into categories named something like atoms, molecules, organisms, templates etc. atoms being the smallest elements like a base Button component, and scaling up from there. This structure can work well specifically for React UI components grouping in a project with a lot of components.

And as you may see, it is possible to combine ideas from these repository organisational structures. There are many patterns out there to read about. The idea being that you should read up on the pros/cons of them and implement what you think fits well for your use case.

4. Use common shared consts for your non-changing values

Let’s say we have some content that can be one of several different types. One of these types we identify as posts. It’s a string and will always be posts. You might use it like this:

return (
  <Select defaultValue="posts" onChange={onItemChange}>
    ...
  </Select>
  <PostsSection hidden={value !== "posts"} />
)

Here we refer to a string posts more than once. Every time we use the string posts we increase the possibility of misspelling it and causing errors. This is easily avoidable if you use TypeScript, but there is another issue.

Let’s say we get a directive that we now have to change this to the string articles, for whatever reason. Now we have to change every instance where it’s in use. That becomes a major pain if it’s used across multiple files and directories without being referred to by a common const.

Instead we should refer to the string using a const variable like this e.g:

// consts/index.ts

// Common practice is use snake_case naming convertion with capitals
export const POSTS_KEY = "posts";

import { POSTS_KEY } from '@consts/index';

return (
  <Select defaultValue={POSTS_KEY} onChange={onItemChange}>
    ...
  </Select>
  <SomeOtherComponent hidden={value !== POSTS_KEY}>
)

Now you have one source of truth. It is common practice to have a directory called consts or constants where you store values that need to be shared across files. If the const is only ever going to be required in one file, it is fine to define it only where it is needed, then move it to a central location later when re-use is needed.

5. Passing primitives as props beats whole objects

Let’s say we have an object blog and this object has several key-value pairs. We have a dumb component that needs access to some of this data. Instead of passing the whole object as one React component prop blog={blog}, it is good to instead prefer passing the individual values required by the dumb component:

What I wouldn’t recommend

// ❌ What I wouldn’t recommend:

type Blog = {
  title: string;
  coverImage: string | null;
};

// BlogCard doesn't even use blog.coverImage
const BlogCard = ({ blog }: { blog: Blog }) => (
  <article>
    <h2>{blog.title}</h2>
  </article>
);

There are a few key reasons this approach is not usually preferred:

1. It has access to data it doesn’t need.

2. BlogCard could mutate the original blog object causing side effects. Recently while diving into my AWS learnings, I learned about the ‘Principle of least privilege’ and it applies here. Essentially we don’t allow the inner component the chance to do more than it should be able to.

3. Can lead to more unpredictable rendering behaviour due to React’s shallow comparison of props: https://react.dev/reference/react/memo#troubleshooting

4. Is less declarative in general.

5. Might make testing more difficult because there’s more data than required.

Better approach passing only the required props

// ✅ Better Approach:

type Blog = {
  title: string;
  coverImage: string | null;
};

const BlogCard = ({ title }: { title: BlogCard['title'] }) => (
  <article>
    <h2>{blog.title}</h2>
  </article>
);

Now the component is more declarative, we can see exactly what data it accepts. It doesn’t have access to the original blog object and if we wanted to memoize the component, we could skip re-rendering the BlogCard successfully when other fields other than title of the blog object change.

I would prefer this approach almost always even if I needed to pass several different fields. If you see the number of props your component needs is growing, it could be a sign you need to refactor your component into several different different components. Each with less responsibilities than before.

Summary

This article shares five key tips for improving the maintainability, reusability, organisation, and performance of your React codebases. It covers the benefits of using 'dumb' components as they’re simpler to maintain and re-use, optimising state management beyond useState, and suggests exploring effective code repository structures. It also encourages the use of shared constants for consistency and maintainability, and finally favouring the passing of primitive values over whole objects in component props.

There is a ton of things I didn’t cover in this article that could have been in, I might write another article on the topic. Let me know if you have any interesting tips or best practises that you like to employ in your React codebases. I’d love to hear them.

Until next time!

I’ve had my eye on Astro for a while, knowing it would be a perfect fit for a simple content-focused site like this. Leveraging TailwindCSS, TypeScript, and Hashnode API’s for the remaining work, here is a look behind the curtain of my new portfolio and how it was put together.

The ‘final’ product

I’m hesitant to say ‘final’ since it will be iterated on further, but we can say the initial MVP is done:

kieranroberts.dev

The problem

This a list of notes/requirements I kept in mind before beginning the project:

1. I will be a simple content focused site and minimal dynamic elements.

2. Start out as a simple one-pager.

3. Fast.

4. Accessible.

5. Be search engine optimised.

6. Clean/simple design style to not get bogged down in design hell.

7. Light/dark theme.

8. Free hosting.

Site content

The page would have the following sections at a minimum:

1. Landing page hero.

2. Career & experience (relevant stuff only with CV download).

3. Blog (recent articles only and a link to the blog).

4. Testimonials

5. Personal projects.

6. Additional achievements.

With that mind, it was time to pick the right tools for the job.

Tech stack

The approach

There weren’t any technical challenges with this project so the primary focus was on the UI/UX and delivering a fast and accessible experience.

How was the Astro experience

This was my first project building with Astro. Overall it was a pleasant experience. The docs are great and adapting to Astro was straightforward. At first I was experimenting using React alongside Astro which is viable with the help of Astro client directives. But I quickly realised React is overkill here. I wanted to take advantage of astro components .astro as they render to static HTML without client-side runtime, and so I converted any straggling React into Astro files and removed the React dependencies altogether.

An example of this was a light/dark theme toggle. Initially I wrote this in React but it was simply wasn’t needed and therefore I refactored to plain TypeScript:

// ThemeToggle.astro
---
import { Icon } from 'astro-icon/components';
---

<script>
    import { Themes, THEME_STORAGE_KEY } from '../consts/index';
    import type { Theme } from '../env';

    const button = document.getElementById('theme-toggle');

    const theme = (() => {
        if (typeof localStorage !== 'undefined' && localStorage.getItem(THEME_STORAGE_KEY)) {
            return (localStorage.getItem(THEME_STORAGE_KEY) as Theme) || Themes.light;
        }
        return window.matchMedia('(prefers-color-scheme: dark)').matches ? Themes.dark : Themes.light;
    })();

    const reflectThemePreference = (theme: Theme) => {
        document.documentElement.className = '';
        document.documentElement.classList.add(theme);
        button?.setAttribute('aria-label', `${theme} theme`);
    };

    reflectThemePreference(theme);
    window.localStorage.setItem(THEME_STORAGE_KEY, theme);

    const handleToggleClick = () => {
        const element = document.documentElement;
        const newTheme = element.classList.contains('dark') ? Themes.light : Themes.dark;
        reflectThemePreference(newTheme);
        localStorage.setItem(THEME_STORAGE_KEY, newTheme);
    };

    button?.addEventListener('click', handleToggleClick);
</script>

<button
    id="theme-toggle"
    title="Toggles light & dark theme"
    class="group flex items-center justify-center rounded-full p-1.5"
>
    <span
        class="duration-400 block text-zinc-900 transition-transform ease-in-out group-hover:-rotate-90 dark:text-zinc-50"
    >
        <Icon name="sun" class="block dark:hidden" width="24" height="24" />
        <Icon name="moon" class="hidden dark:block" width="24" height="24" />
    </span>
</button>

Removing the React code and dependencies helped reduce the bundle size and ensured I was taking advantage of what Astro offers.

I’m sure as the project grows there will opportunities to explore some of the latest Astro features like Astro Server Islands architecture.

Design overview

Design is usually the tricky part for me. It’s easy to start experimenting too early and lose time to ideas that didn’t work out. This time I was determined to keep things simple at first and then slowly add extra layers over time.

Because I was not attempting complex design from the start, I decided to skip pre-designing the page in Figma. This is something I have done in the past for small side projects and it helped. But on this occasion I wanted to get my ideas into code as soon as possible.

Every site needs a button

One of the earliest things I did was create a simple button component with a couple variants. To add some polish I utilised CSS transitions and icon slots. The button is one of the first things you notice on a site, and usually what you click first so I wanted to design a nice version.

Navbar UX

Recently I wrote an article on a specific type of UX for a main site navigation and I decided to opt for this behavior on my portfolio. You can find a tutorial on this with more information here:

Color scheme

It’s easy to find a good color scheme. There are countless free tools to help you pick a pre-defined theme. I wanted my primary theme colors to be simple white/dark/gray to keep a clean and modern look. On top of that I added some accent colors to the tailwind config that added a bit more life to the site. They would help bring some ‘pop’ to elements in areas such as focus styling, icons, and background sections.

    'accent-darkest': '#6F61C0',
    'accent-dark': '#A084E8',
    'accent-bright': '#8BE8E5',
    'accent-brightest': '#D5FFE4',

Icons

As far as Icons go, I opted to keep a local copy of icons I would use in the repo using /src/icons, saving each icon as a .svg. There is a package called astro-icon that helps simplify working with icons in Astro projects, this handles embedding the icon.

As far as the icons themselves I opted for icons from the open source project iconoir. Largely because of the simple one click copy of the svg code and the large free set of icons available.

If I ever decide to update icons in the future, changing one icon at a time can be easily done.

Once those design decisions were made, most of the blockers to writing up core code was done and I could proceed with the build.

Outcome

What went well

Overall I am happy with the outcome. The site feels fast thanks to the lack of JavaScript and server first approach of Astro. It scores well across Lighthouse scores which admittedly should be the minimum standard for a site like this.

There was some trial and error with the design but I didn’t get stuck iterating on anything for too long. There’s always room for iteration and improvement. I am not a designer but I was able to harness some inspiration and tips from my experience working with a talented design team. An example is that I paid closer attention to text colors/weights than I would have previously, layering in different shades & weights where appropriate.

What would I do differently next time

I would have avoided beginning the project with React and Astro, and just started with Astro. I had written some components in React initially but soon realised it wasn’t necessary. Likely that since I had been working with React for so long, it was strange to separate initially.

What can be improved

There are further minor improvements I intend to make to various sections as well.

Summary

I recently built a new personal developer portfolio for myself using Astro, TailwindCSS, and TypeScript ensuring a fast, accessible site with great SEO. The project focused on simplicity, speed, and clean design and the case study helped me contextualise the project and seek ways to improve. It was a lot of fun to build and I’m excited about all the things I can add and improve upon in the future.

Thanks for reading!

In this tutorial we will build a sticky navbar that hides as you scroll down using translation and reappears when you scroll up, based on scroll position calculations. It can provide quite a pleasant navigation experience as it maximizes screen space while keeping important links readily accessible. We will ensure it is accessible, as performant as possible, and leverage React hooks.

Let’s go.

TLDR

Here’s how the final version functions:

Here’s the final code:

// hooks/useStickyHeader.ts

interface UseStickyHeaderProps {
  elRef: React.RefObject<HTMLElement>;
}

const TRANSLATE_BUFFER = 30; // in pixels
const QUERY_NAME = "(prefers-reduced-motion: no-preference)";

export const useStickyHeader = ({ elRef }: UseStickyScrollProps) => {
  const [prefersReducedMotion, setPrefersReducedMotion] = useState(true);

  const scrollRef = useRef<{ prevScrollTop: number; animation?: number }>({
    prevScrollTop: 0,
    animation: undefined
  });

  const getScrollDistance = ({ scrollY }: { scrollY: number }) => {
    const { prevScrollTop } = scrollRef.current;
    return scrollY - prevScrollTop;
  };

  const getHeaderTopValue = () => {
    const headerPosition = elRef.current?.getBoundingClientRect();
    return headerPosition?.top ?? 0;
  };

  const calculateTranslateValue = ({
     headerTop,
     scrollDistance,
   }: {
     headerTop: number;
     scrollDistance: number;
   }) => {
     const navHeight = (elRef.current?.offsetHeight || 0) + TRANSLATE_BUFFER;
     return Math.max(
       Math.min(
         headerTop +
           (scrollDistance < 0
             ? Math.abs(scrollDistance)
             : -Math.abs(scrollDistance)),
          0,
        ),
      -navHeight,
    );
  };

  const onTranslate = () => {
    scrollRef.current.animation = requestAnimationFrame(() => {
      const curScrollTop = window.scrollY;
      const scrollDistance = getScrollDistance({ scrollY: curScrollTop });
      const headerTop = getHeaderTopValue();
      const translateAmount = calculateTranslateValue({
        headerTop,
        scrollDistance,
      });

      if (elRef.current) {
        elRef.current.style.transform = `translateY(${amount}px)`;
      }

      scrollRef.current.prevScrollTop = curScrollTop;
    });
  };

  useEffect(() => {
    if (prefersReducedMotion) {
      return;
    }
    window.addEventListener("scroll", onTranslate);

    return () => {
      window.removeEventListener("scroll", onTranslate);

      if (scrollRef.current.animation)
        cancelAnimationFrame(scrollRef.current.animation);
    };
  }, [prefersReducedMotion]);

  useEffect(() => {
    const mediaQueryList = window.matchMedia(QUERY_NAME);

    setPrefersReducedMotion(!mediaQueryList.matches);

    const updateMotionSettings = (event: MediaQueryListEvent) => {
      setPrefersReducedMotion(!event.matches);
    };

    mediaQueryList.addEventListener("change", updateMotionSettings);

    return () => {
      mediaQueryList.removeEventListener("change", updateMotionSettings);
    };
  }, []);
};

// Navbar.tsx

import { useRef } from 'react';
import { useStickyHeader } from './hooks/useStickyHeader.ts';

export const Navbar = () => {
  const headerRef = React.useRef<HTMLElement>(null);
  useStickyHeader({ elRef: headerRef });

  return (
    <header
      ref={headerRef}
      className="z-[9999] sticky top-0"
    >
      ...
    </header>
  )
};

Here are key features:

1. When scrolling down it should gradually disappear above the fold as you would expect with any static positioned element that disappears with viewport scroll.

2. But as soon as you scroll up the slightest bit, it should start to reveal itself again until it’s fully visible in it’s normal sticky state.

3. The movement of the navbar will be handled by translating it up and down, we will need to do some calculations based on scroll positions for this.

Setting Up Basic Navbar Requirements

The first step is to build your desired navbar. If you already have a working navbar on your site, that will work just fine. There are only a couple of things we must ensure for the UX to match what we have in the demo.

For the purpose of the tutorial, I am using Tailwind for styling and also TypeScript, but neither are required.

Our navbar will use sticky positioning. MDN defines sticky positioning as the following:

The element is positioned according to the normal flow of the document, and then offset relative to its nearest scrolling ancestor and containing block (nearest block-level ancestor), including table-related elements, based on the values of top, right, bottom, and left. The offset does not affect the position of any other elements.

We will vertically position the navbar at the top of the viewport using top: 0px.

Finally we’ll need to track the navbar element for later use when the core logic of the sticky nav is written. We’ll do that by adding a ref to the top level element of the navbar component. A high z-index value has also been added so the navbar is stacked on top of all other content.

export const Navbar = () => {
  const headerRef = React.useRef<HTMLElement>(null);

  return (
    <header
      ref={headerRef}
      className="z-[9999] sticky top-0"
    >
      ...
    </header>
  )
};

Those are essential parts your navbar element should replicate. Next up we need to write the core logic for our desired UX. This will be done by writing a custom React hook. The core logic can be adapted to your requirements.

useStickyHeader React Hook

Staying in the Navbar component for a second, will use our hook as follows:

import { useRef } from 'react';
import { useStickyHeader } from './hooks/useStickyHeader.ts';

export const Navbar = () => {
  const headerRef = React.useRef<HTMLElement>(null);

  useStickyHeader({ elRef: headerRef });

  return (
    <header
      ref={headerRef}
      className="z-[9999] sticky top-0"
    >
      ...
    </header>
  )
};

Now we need to create the hook. Create a file called useStickyHeader.ts and define the basic outline of the hook:

interface UseStickyScrollProps {
  elRef: React.RefObject<HTMLElement>;
}

export const useStickyHeader = ({ elRef }: UseStickyScrollProps) => {};

How Will The Animation Work?

When scrolling down, we are going to translate the navbar upwards to a maximum translation distance of when it’s fully hidden (+ small offset). The navbar is hiding just above the top of the visible viewport so that when you start scrolling up, it immediately starts coming back into view. In that case we translate the navbar down again.

To help illustrate this, in the image below, consider the thick black line to be the top of the visible viewport. Meaning you can’t see anything above that line. This is where the navbar will be positioned when we have scrolled down and hidden the navbar from view. It’s just above the fold and ready to come right back into view.

Implementing Scroll Based Logic

To do this precisely requires some calculations taking into account the distance that has been scrolled since the last check. Therefore we’ll make use of a scroll event listener. Let’s add this to our hook.

interface UseStickyHeaderProps {
  elRef: React.RefObject<HTMLElement>;
}

export const useStickyHeader = ({ elRef }: UseStickyScrollProps) => {
  const onTranslate = () => {};

  useEffect(() => {
   window.addEventListener('scroll', onTranslate);

   return () => {
     window.removeEventListener('scroll', onTranslate);
   };
 }, []);
};

The scroll event listener was added inside a useEffect that will run on mount. Make sure to cleanup the event listener when unmounting, that’s what the return statement of a useEffect is for. An empty onTranslate function has also been created for use as the callback for the listener. Logic will be added there shortly.

Next up we need to write out translating code. For that we need to do some calculations. We need to know the number of pixels the document is currently scrolled vertically. This is given by window.scrollY.

Next we calculate how far we have scrolled since the last time the onTranslate function ran. It’s important to note that the scroll listener is not going to fire the onTranslate callback for every 1px scrolled. The distance scrolled can be variable.

By tracking the window.scrollY value, we have access to the previous state when calculating the new translation value. A positive value means the user is scrolling down, a negative value means the user is scrolling up.

Let’s put this logic into action. Inside the hook we will write another function getScrollDistance:

// Define a ref in the hook to keep track of previous scroll top value
const scrollRef = useRef<{ prevScrollTop: number; }>({
  prevScrollTop: 0,
});

// Calculate the distance change from previous check
const getScrollDistance = ({ scrollY }: { scrollY: number }) => {
  const { prevScrollTop } = scrollRef.current;
  return scrollY - prevScrollTop;
};

and then call this function as part of onTranslate:

const onTranslate = () => {
  const curScrollTop = window.scrollY;
  const scrollDistance = getScrollDistance({ scrollY: curScrollTop }); // We will use this in a moment

  scrollRef.current.prevScrollTop = curScrollTop; // Track our scroll top value
};

Another required value is the current vertical position of the navbar relative to the viewport. Create a function called getHeaderTopValue for this:

const getHeaderTopValue = () => {
  const headerPosition = elRef.current?.getBoundingClientRect();
  return headerPosition?.top ?? 0; // ?? 0 is just a fallback in case the ref was not found
};

Calculation Pseudocode

With that, all the information is ready to calculate the exact translation value. Before the calculation is written in code, let’s see it in pseudocode to understand what is happening:

Given:
- headerTop: current position of header from top of viewport
- scrollDistance: how far user has scrolled (positive = down, negative = up)
- navHeight: height of navigation + buffer

Step 1: Calculate scroll adjustment

IF scrollDistance is negative (scrolling up)
    adjustment = +|scrollDistance|    // Move header downward
ELSE (scrolling down)
    adjustment = -|scrollDistance|    // Move header upward

Step 2: Calculate new position

newPosition = headerTop + adjustment

Step 3: Clamp the value

maxValue = 0                         // Header can't go above viewport
minValue = -navHeight               // Header can't hide more than its height
finalPosition = CLAMP(newPosition, minValue, maxValue)

Calculate Translate Value

Implementing the pseudocode, we end our with our translation value:

const TRANSLATE_BUFFER = 30; // in pixels

const calculateTranslateValue = ({
    headerTop,
    scrollDistance,
  }: {
    headerTop: number;
    scrollDistance: number;
  }) => {
    const navHeight = (elRef.current?.offsetHeight || 0) + TRANSLATE_BUFFER;
    return Math.max(
      Math.min(
        headerTop +
          (scrollDistance < 0
            ? Math.abs(scrollDistance)
            : -Math.abs(scrollDistance)),
        0,
      ),
      -navHeight,
    );
  };

The TRANSLATE_BUFFER is not essential but I think it helps with the smoothness of the UX. It adds a small offset so the navbar is an extra 30px above the visible viewport. You can experiment with that value.

Implementing the translation calculation in onTranslate:

const onTranslate = () => {
  const curScrollTop = window.scrollY;
  const scrollDistance = getScrollDistance({ scrollY: curScrollTop });
  const headerTop = getHeaderTopValue();
  const translateAmount = calculateTranslateValue({
    headerTop,
    scrollDistance,
  });

  scrollRef.current.prevScrollTop = curScrollTop;
};

The final step important is to actually perform the css translation with our calculated value. All we have to do is to use the navbar ref we defined earlier and update its style.transform property:

const onTranslate = () => {
  requestAnimationFrame(() => {
    const curScrollTop = window.scrollY;
    const scrollDistance = getScrollDistance({ scrollY: curScrollTop });
    const headerTop = getHeaderTopValue();
    const translateAmount = calculateTranslateValue({
      headerTop,
      scrollDistance,
    });

    if (elRef.current) {
      // Move the navbar up or down in pixels
      elRef.current.style.transform = `translateY(${amount}px)`;
    }

    scrollRef.current.prevScrollTop = curScrollTop;
  });
};

Notice we wrap the entire function with the window.requestAnimationFrame method which tells the browser you wish to perform an animation. It requests the browser to call a user-supplied callback function before the next repaint.

This performance optimization helps prevents multiple unnecessary calculations within the same frame. Scroll events can fire at a very high rate so we need to optimise the performance. For example, if a user scrolls quickly triggering 100 or more scroll events in a timeframe of say 20ms, requestAnimationFrame will consolidate these into a single frame update. We can ensure our animations remain smooth at the optimal frame rate the device used by the user.

Let’s also expand the scroll ref to eventually allow animation cancelling:

const scrollRef = useRef<{ prevScrollTop: number; animation?: number }>({
  prevScrollTop: 0,
  animation: undefined
});

and then set a reference for our requestAnimationFrame callback using scrollRef.current.animation:

const onTranslate = () => {
  scrollRef.current.animation = requestAnimationFrame(() => {
    const curScrollTop = window.scrollY;
    const scrollDistance = getScrollDistance({ scrollY: curScrollTop });
    const headerTop = getHeaderTopValue();
    const translateAmount = calculateTranslateValue({
      headerTop,
      scrollDistance,
    });

    if (elRef.current) {
      // Move the navbar up or down in pixels
      elRef.current.style.transform = `translateY(${amount}px)`;
    }

    scrollRef.current.prevScrollTop = curScrollTop;
  });
};

This now allows clean animation cancelling in useEffect cleanup:

useEffect(() => {
   window.addEventListener('scroll', onTranslate);

   return () => {
     window.removeEventListener('scroll', onTranslate);
     if (scrollRef.current.animation) {
       cancelAnimationFrame(scrollRef.current.animation);
     }
   };
 }, []);

Cancelling the animation frame is necessary because if the component unmounts while an animation frame is pending, you might end up trying to run onTranslate on an unmounted component which will probably lead to errors on memory leaks.

Considering prefers-reduced-motion CSS Media Feature

An improvement we can make to the hook is to consider users to prefer to reduce animations when visiting sites. prefers-reduced-motion is a CSS media feature in this vein and here is how it described as per MDN:

The prefers-reduced-motion CSS media feature is used to detect if a user has enabled a setting on their device to minimize the amount of non-essential motion. The setting is used to convey to the browser on the device that the user prefers an interface that removes, reduces, or replaces motion-based animations.

The transitioning being performed on the navbar may be unwanted by users who prefer to be without animations. We can make use of this media query in the hook and prevent the translate from happening if they have this set on their device. Instead the header will just remain in a regular sticky state.

Here’s the additional logic for checking the user’s preference:

const QUERY_NAME = "(prefers-reduced-motion: no-preference)";

// Default to true
const [prefersReducedMotion, setPrefersReducedMotion] = useState(true);

useEffect(() => {
  const mediaQueryList = window.matchMedia(QUERY_NAME);

  setPrefersReducedMotion(!mediaQueryList.matches);

  const updateMotionSettings = (event: MediaQueryListEvent) => {
    setPrefersReducedMotion(!event.matches);
  };

  mediaQueryList.addEventListener("change", updateMotionSettings);

  return () => {
    mediaQueryList.removeEventListener("change", updateMotionSettings);
  };
}, []);

Here the user’s system setting is checked with window.matchMedia("(prefers-reduced-motion: no-preference)"). Specifically checking if they don’t have a preference with prefers-reduced-motion: no-preference and if it doesn’t match, we know they prefer to have reduced motion, hence we keep setPrefersReducedMotion to true.

Now all we have to do is prevent the scroll listeners from doing their magic in the case where the user wants to prevent animations.

useEffect(() => {
  if (prefersReducedMotion) {
    return;
  }
  window.addEventListener('scroll', onTranslate);

  return () => {
    window.removeEventListener('scroll', onTranslate);

    if (scrollRef.current.animation) {
      cancelAnimationFrame(scrollRef.current.animation);
    }
  };
}, [prefersReducedMotion]);

Note we also need to add prefersReducedMotion to the dependency array so that changes to the value re-trigger the effect.

And that’s all! Now you should have an accessible, optimized, scroll-positioned navbar with a smooth transition.

You could also extract the media query logic into a separate hook for use elsewhere, or open up our hook for use with other components. Feel free to experiment!

Final Implementation

Here is the full implementation:

// hooks/useStickyHeader.ts

interface UseStickyHeaderProps {
  elRef: React.RefObject<HTMLElement>;
}

const TRANSLATE_BUFFER = 30; // in pixels
const QUERY_NAME = "(prefers-reduced-motion: no-preference)";

export const useStickyHeader = ({ elRef }: UseStickyScrollProps) => {
  const [prefersReducedMotion, setPrefersReducedMotion] = useState(true);

  const scrollRef = useRef<{ prevScrollTop: number; animation?: number }>({
    prevScrollTop: 0,
    animation: undefined
  });

  const getScrollDistance = ({ scrollY }: { scrollY: number }) => {
    const { prevScrollTop } = scrollRef.current;
    return scrollY - prevScrollTop;
  };

  const getHeaderTopValue = () => {
    const headerPosition = elRef.current?.getBoundingClientRect();
    return headerPosition?.top ?? 0;
  };

  const calculateTranslateValue = ({
     headerTop,
     scrollDistance,
   }: {
     headerTop: number;
     scrollDistance: number;
   }) => {
     const navHeight = (elRef.current?.offsetHeight || 0) + TRANSLATE_BUFFER;
     return Math.max(
       Math.min(
         headerTop +
           (scrollDistance < 0
             ? Math.abs(scrollDistance)
             : -Math.abs(scrollDistance)),
          0,
        ),
      -navHeight,
    );
  };

  const onTranslate = () => {
    scrollRef.current.animation = requestAnimationFrame(() => {
      const curScrollTop = window.scrollY;
      const scrollDistance = getScrollDistance({ scrollY: curScrollTop });
      const headerTop = getHeaderTopValue();
      const translateAmount = calculateTranslateValue({
        headerTop,
        scrollDistance,
      });

      if (elRef.current) {
        elRef.current.style.transform = `translateY(${amount}px)`;
      }

      scrollRef.current.prevScrollTop = curScrollTop;
    });
  };

  useEffect(() => {
    if (prefersReducedMotion) {
      return;
    }
    window.addEventListener("scroll", onTranslate);

    return () => {
      window.removeEventListener("scroll", onTranslate);

      if (scrollRef.current.animation)
        cancelAnimationFrame(scrollRef.current.animation);
    };
  }, [prefersReducedMotion]);

  useEffect(() => {
    const mediaQueryList = window.matchMedia(QUERY_NAME);

    setPrefersReducedMotion(!mediaQueryList.matches);

    const updateMotionSettings = (event: MediaQueryListEvent) => {
      setPrefersReducedMotion(!event.matches);
    };

    mediaQueryList.addEventListener("change", updateMotionSettings);

    return () => {
      mediaQueryList.removeEventListener("change", updateMotionSettings);
    };
  }, []);
};

// Navbar.tsx

import { useRef } from 'react';
import { useStickyHeader } from './hooks/useStickyHeader.ts';

export const Navbar = () => {
  const headerRef = React.useRef<HTMLElement>(null);
  useStickyHeader({ elRef: headerRef });

  return (
    <header
      ref={headerRef}
      className="z-[9999] sticky top-0"
    >
      ...
    </header>
  )
};

Summary

In conclusion, implementing a scroll-translated, dynamic sticky navbar in React can bring a nice touch to your website. By leveraging React hooks and considering user preferences for reduced motion, developers can create a smooth, responsive, and accessible navigation experience.

Feel free to share the article if it was helpful.

This month on Hashnode we have been running the #DebuggingFeb Writeathon. As a software developer at Hashnode, I wanted to join in. Of course, I won't be eligible for any prizes of course but it's a great opportunity to share knowledge with the wider developer community here on Hashnode and beyond.

Introduction

Did you know it is possible to make persistent-through-reload CSS style changes using the in-browser dev tools? This method can also be used for other needs as well as what I'm going to show, so it's a really useful tool to have in your debugging arsenal.

Recently I came across a UI bug that was only visible in our staging environment, and not in my localhost environment. Persisting style changes this way was something I needed to help solve the bug efficiently and cleanly. It's not something you'll likely need very often but is an awesome tool to have in your debugging arsenal.

TLDR

Make style changes persist through a reload using the in-browser dev tools.

• Open Chrome dev tools

• Visit Sources tab -> Overrides sub-tab -> Select folder for overrides -> Click Allow -> Select Enable Local Overrides -> Use Sources/Page tab to select files -> Right click Save for Overrides -> Make your style changes

• User the Sources tab for style changes if the source of the styles (CSS) is coming from an HTML file.

• Profit!

What bug was I facing?

The bug itself was not so interesting, I'll be honest. But the conditions around the bug made it a more challenging fix to solve efficiently.

We often make use of staging environments as a midpoint between local development and production. This is currently the case for our Hashnode-powered blogs. I'm sure you've noticed some significant changes to your blog recently after we released a multitude of awesome UI and UX enhancements. We have seen a lot of positive feedback for these changes which is awesome to hear.

While the team and I were testing some of these updates in staging, it was reported to me that there was a layout shift during a page load for our new navbar which I was responsible for.

If you look closely, you'll notice the size of the top navbar changes once the newsletter and dashboard links come into view. Layout shifts can be super jarring in many situations and should be avoided where possible.

Although the bug itself would likely be adding/removing a style or two, knowing exactly which style needed to be added or removed was problematic without visualisation of any changes. I couldn't see this in my localhost development.

Our staging environment is pretty fast these days, much closer to production than the development environment which helps us catch issues like this before we ship them. I set out to investigate and since I couldn't replicate using localhost, I would have to debug the issue using the staging environment.

The problem was that I didn't want to push changes to the staging branch that I thought might fix the problem, I wanted to know that it was sure to fix the problem. Better to avoid pushing commits and possibly having to revert them, or end up with a cluttered history of commits with descriptions like this:

fix: pls fix layout shift for main nav 🙃

Solution: Using the Chrome browser dev tools

Like many of you, I often use the in-browser dev tools as an efficient method of trying out different style changes at speed. It's a great way of making a multitude of quick changes without touching the codebase. If you don't use it often, give it a go.

Any changes you make to styles this way will disappear when you reload the page. That's a problem when you need those style changes to persist after the reload. I needed to see that the change I would make was fixing the layout shift. That's where the Chrome browser dev tools came to my rescue.

Chrome Dev Tools 'Sources' Tab

We can preserve style changes through reload using the Sources tab of the Chrome Dev tools. This feature was released a few years back but having just come across this myself, some of you might also be seeing it for the first time.

I'll be using the Chrome dev tools for this tutorial.

• Open up the dev tools through a right click -> Inspect

• Navigate first to Sources, then the Overrides sub-tab.

  Here we can select a directory on our filesystem that will save style changes we make on whatever domain you need.

• Then click on Select folder for overrides. Feel free to create a new directory for your changes. You can see all this below.

• After selecting a file you'll see a warning. Click on Allow and don't expose sensitive information as it warns.

• After clicking you'll see the directory under the Overrides sub-tab. Ensure the checkbox named Enable Local Overrides is selected.

• Next up you need to select the sources you'd like to save for overrides. Navigate to the Page sub-tab. Right-click on the source where you'd like to make changes and click Save for overrides.

Now you're finally ready to make some styling changes.

The way you make these changes has some conditions If you make style changes in the Elements tab using the DOM (Document Object Model) tree, changes will not be saved and you should use the Sources tab instead. Find your file there and make edits.

Secondly, when editing CSS in the Styles pane, if the source of the CSS is an HTML file then any changes made won't be saved by DevTools. It's better to edit the HTML file in the Sources panel to ensure any changes are saved.

Here's a quick video of style changes persisting through reload:

When an override is in effect you'll notice a little purple circle on top of the file icon and filename.

What else can you use this for?

We can use local overrides for things other than style changes as well. Some of the use cases that come to mind are:

• Testing potential performance improvements

  • Using different fonts

  • Changing script load orders

• Trying out changes or debugging potential issues in external libraries

It's likely not something you'll need to use very often but will come in very handy in some of these specific use cases.

Note: It's a good idea to remove your overrides after you are done.

Conclusion

Using this method I was able to run through some minor style changes very quickly and find/fix the culprit. It ended up being a highly time-efficient solution to a potentially frustrating problem.

It allowed me to cut the effort in debugging -> shipping by a considerable amount. I hope you find it useful in the future too.

See you next time 👋

I am a self taught developer who began learning to code in March 2020, before landing a Full Stack Developer role here at Hashnode in May the following year.

This is my first year as a Software Developer reviewed in 30 questions.

Overall, do you think it was successful?

Yes, absolutely.

I had my ups and downs, without doubt. There were moments I doubted myself, even moments I thought I was letting others down.

Despite this, I know that I was able to deliver in the end. I feel like I contributed some really cool additions to the product. Specifically on the features side which we pushed hard the last year.

Now I know that I belong in my role, and for my first year, that was always going to be enough for me to be happy that it was successful. My job now is kick on and push things further.

How did you end up in your role at Hashnode?

Sandeep (Co-Founder of Hashnode) reached out to me on Twitter and offered an interview for the role of Full Stack Developer as he suggested I could be a fit for the team. Fortunately for me, those interviews went pretty well and I was hired soon after.

• I didn't end up applying for any roles before landing the job.
• I didn't need to build a portfolio, my Hashnode blog was more effective and time-efficient than any portfolio I could have ever spent time building.
• Being a regular user of the product was essential.
• Connecting with tech related people through Twitter is a great way of finding opportunities. Help recruiters find you first. This is especially helpful when trying to break into the field.
• There were no algorithm tests in the hiring process.
• I had a take home challenge to complete over the weekend which was very much related to things you might end up doing on the job.
• You can do it too! - Hashnode Careers Page

What features and other things did you work on?

• Table of Contents
• Article scheduling
• Unsplash integration for cover images
• Recover deleted articles
• 2021 End-of-year awards and review
• Several team publication updates
• Editor updates and bug fixes
• End-to-end testing setup and CI integration
• Blogs migration contribution

As well as several more bug fixes, tech debt, and documentation work.

Which feature are you most proud of?

I think it would be the Table of Contents feature.

It was a lot of fun to build, offered an interesting challenge in trying to generate the headings in the correct structure, and was one of my earliest significant contributions. You never forget your first.

We still see some really great feedback for this feature as well. Our users are responsible for driving many of the features we build. Without that I would be building for myself and there's not as much fun to be had in that case.

What kind of struggles did you experience?

Where do I start.

I struggled a little with communication at times. It's easy to feel as though you don't want to bother someone with your 'stupid' questions despite people stressing otherwise. Or maybe you feel like you can figure it out yourself and before you know it, 3 hours have passed and you're still in the same spot. It can often be the case that 5 lines of code take 50,000 lines of thought and it's easy to get lost in it all.

You soon learn that over-communicating is key and I was encouraged to do so. We're fortunate to have a culture of open communication at Hashnode where sharing discussions, problems, and any general questions are encouraged and everyone is extremely helpful.

I would sometimes also make simple mistakes when trying to deliver within a tight timeframe. I learned the hard way that the smallest of changes can have effects that can't be anticipated. Any change has to be verified thoroughly, even if you think it can't possibly affect things.

Surely I'm not the only one who has shipped 'fixes' only to later find out that it ended up breaking something else, or not working exactly as I had thought it was. That has probably been the most demoralising thing I've done.

But we all make mistakes, it's our job to learn from then so we can make less mistakes moving forward.

Do you enjoy working from home?

I love it, most of the time.

It's my first experience working from home outside of school or university and I'm not sure I ever want to go back. It's the little things for me.

• Jumping in the shower on a lunch break.
• Cooking lunch fresh.
• Always being home for deliveries.
• Not wasting time travelling to and from work.

There is a part of me that sometimes misses the jokes and general banter you can have in person, but the benefits definitely outweigh the alternative, for me at least.

Can you share one tip you've learned while working remotely?

Work to a schedule that works for you within the boundaries you're given, and don't feel bad about having a cutoff point.

Just because you work from home, does not mean you're always on call (unless you are actually on-call of course). It's easier to separate yourself from work when your in-office but it's more difficult to switch off while working from home.

It's ok to close your laptop at the end of the day and get back to something on your schedule. Try leaving the office at the end of the day to create that separation. I like spending the end of the day outside if the weather permits.

Keep your mind fresh and excited for the times when you should be working. At least for me, spending time on my other interests outside of work hours helps keep me fresh and motivated for work. I know the feeling of burnout and trust me, you don't want it.

How was the onboarding process?

Extremely fun, but difficult at times.

When I joined, the team was a lot smaller than it is now. Up to that point, I think there hadn't been the need to have a fleshed out onboarding process. It was a smaller early stage startup after all, so of course that's understandable.

There were also few processes in place at the time for things like work tracking, code review, and so on. Documentation was lacking too but despite this, everyone on the team was extremely helpful and were also open to any questions or struggles I was facing.

We have now seen many new members join in various roles over the last 9 months and so the team have made a big effort to get the proper processes and documentation in place. Onboarding now would have been a smoother process for sure.

What's one superpower you've noticed from your co-workers?

Knowing the right questions to ask.

It sounds strange to say that I often didn't feel like I knew what questions I should have been asking. Experienced developers are really good at asking the right questions. If you know, you know.

Do I think it's important to spend non-work related time with your fellow remote workers?

Absolutely

I love joining our team fun calls where we usually end up chatting about all sorts of stuff. Sometimes over pizza, and occasionally we will end up in a game of Scribble.

Vamsi is the resident Hashnode Scribble champ. I'm a very competitive person so that pains me to admit. I did win once though and I'll cling onto that forever. Never forget.

We can often feel isolated as remote workers and sometimes it does the world of good to talk face-to-face with your team about non-work related stuff. Especially great at the end of a tough day.

What was your scariest moment?

I could say my first day on the job, but that's obvious so I'll choose something else.

Personally deploying to production for the first time.

Earlier on my code would often be deployed to production by the reviewer, but we have since moved on to a different review and deployment process that helps us move faster as a team.

My first deployment didn't have any user facing changes. I was just merging some test related code but it didn't stop me worrying I would somehow break something. It didn't help that Sentry suffered some downtime while I was merging which caused the initial preview build to fail.

This gave me a small panic attack, but all went well in the end.

What tool or service do you enjoy using the most?

Notion

Not because there's anything specific I like about Notion, but because I enjoy the act of writing documentation. We currently use Notion for our in-house documentation. It's a nice change of pace from writing code and combines technical skills with writing and teaching which I think suits my strengths.

What tool or service do you enjoy using the least?

Jira

I appreciate it's a much needed tool for software teams and I don't dislike using it anymore, but I had to choose something.

What was the most memorable bug fixing experience?

The editor scroll jump bug, definitely.

There was a bug that caused the editor to do an instant scroll when hitting the enter key, scrolling to a position where the cursor would now be at the top of the textbox. It was as random an act as is seemingly possible in our field. Sometimes it would jump and sometimes not, with little consistency to be able to find a pattern.

Eventually I noticed similar behaviour on other sites. I had an 'ahaa!' moment when I was opening a GitHub pull request and noticed a similar event.

It was browser specific issue that affected textboxes and required a workaround fix in our current situation. I'll never forget the pain this bug caused me trying to understand why it was happening.

I'm thinking of writing an article about this in the future so I won't give it all away just yet.

How can you contribute more to Hashnode in the future?

Get back into writing and social sharing.

Decide on my next learning path.

This is a question I have been asking myself recently. Now I feel settled in my role, I want to take the next steps forward. For me, and for the product.

Writing took a backseat this year. I focused on trying to become a valued member of the development team. Code and processes were my first priority. Recently I published my first article to the Hashnode Engineering blog and I'm excited to contribute more often.

I also want to focus on some learning path. I'm interested in cloud computing and have started exploring this more with AWS recently. Here at Hashnode, they are extremely helpful with supporting team members in advancing their skills and I look forward to taking advantage of this in the next year so I can put what I learn into practice.

What was your worst period of the year and why?

Oct 2021 - Jan 2022

This three month period at the end of 2021 saw me moving from the UK to Ireland. It was a stressful period where my girlfriend and I were moving around temporary accommodation often while looking for something permanent. It was a difficult time to be in need of accommodation with high competition and low availability, all while continuing to work.

This definitely put a strain on me and my mood and I think it affected my work too. Thankfully, all of this is now behind me.

What is it like working in a small team startup?

• Extremely exciting.
• Always changing and progressing forward.
• Very rewarding with large variation of work.
• Fast moving.

Did you experience Imposter Syndrome?

Of course, I think we all do.

There were days I didn't think I would get to the end of. My biggest bug-bear is feeling like a burden on others. I tried my best to alleviate that problem the most because I knew it had have the biggest affect on my mind.

Early on I would work the odd Saturday or Sunday, not because someone asked me but out of my own determination to keep up. I didn't want to fall behind on something that might affect others. It was my way of coping because I definitely wasn't going to let myself sink.

Another thing that helped me was the code review process. The more code review I took part in on both review and reviewee sides, the more I realised that I belong where I am. Taking part in reviews with different people helps you see many different perspectives and learn from others. It also allows you to share what you know and it was a great confidence boost when you can teach something.

What does your daily work routine look like?

It looks something like this 👇.

Around 30 mins before the first focus time is my chance to catch up on messages, emails, threads, and check if I have code reviews to do for the day. Lunch break usually takes place in-between focus times and some more casual tasks are reserved for the end of the day, after my final focus time.

How did the job affect your need to code outside of work?

I'd be lying if I said my desire to code outside of work hours wasn't affected. I was so focused on getting up to speed as a team member that I often didn't have the mental energy to want to write code in my spare time.

It's a normal thing to want to step away from the things you do everyday at work when you're off the clock, despite what Twitter might have you believe.

Slowly this has been coming back to me though. I have some project ideas in the brain backlog but I'm more inclined to focus on learning instead of building at the moment.

What do you think is the most important skill to have in a remote async team?

Communication

As I have come to learn, over-communicating is a necessity for async teams. I have been guilty of forgetting this at times in the last year.

It's super easy to get into a rut of single-minded focus on something, but a little update will go a long way. If something is taking longer than expected, that's fine. Communicate this and keep the person in the loop. You might even get some help as a result of the update/discussion.

Based on your experience, share one thing that helped you produce better code?

Embrace code reviews.

Code reviews are an essential part of team development. Having regular constructive code reviews from different people is extremely helpful. We each bring something different to reviews and we can all learn something from each other.

Ask questions, be respectful, don't be overly nitpicky, and you'll be making forward strides in no time.

How much time do you spend in meetings?

Google calendar is telling me I have an average of 1.7 hours per week.

The benefits of an async work culture mean you spend less time in meetings, and end up enjoying every minute of those meetings far more because it's a rarer occurrence.

What do you see yourself moving towards?

I'm looking to get more experience with the cloud and serverless computing.

This approach is something we often employ at Hashnode for various purposes and I would like to get exposure on this front moving forward. I'm now testing the waters with AWS starting with the free resources related to the Cloud Practitioner certification. Looking forward to getting hands-on here in the future.

Do you think a fully remote role is suitable for an early career developer?

Yes, with a few caveats.

I was a little unsure how it would turn out having a fully remote role in my first job. I worried that I might not get the direction I needed, or that getting help would be difficult because I knew I'd need it.

I think the following are important if you're going to make the most of it:

• You should be a responsible person and capable of managing your time and effort without a direct push from someone.
• Get to know your teammates quickly, this will help you feel comfortable asking for help.

A good idea is to have quick 1 on 1 calls with your team members (or at least those you'll be working closest with if you're working in a larger team/company) to get to know everyone individually. I didn't do this personally because I didn't know it was a common practice back then, but I would now if I was starting out again.

Can you share some work related terms/phrases you didn't know before you started your role?

Many of these are related to working in a team environment which like me, you likely won't know much about before you start working in industry.

• Sprints
• Scrum framework & Agile methodology
• Burndown & velocity charts
• Stories, Epics, Bugs & Initiatives
• Standup

If any of these are unfamiliar to you, look them up and get a basic understanding of each. Having knowledge of this is useful and some of it might even come in handy in an interview situation.

What is one selfish thing I want to see from Hashnode?

Hashnode hat swag 🧢🙏

Based on your experience, can you share one piece of advice to help other developers find their first role?

Start writing.

In my opinion (and many others), you make yourself a far more attractive prospect to potential employers if you maintain a consistently good blog. You can get started with this very easily here on Hashnode. If you didn't already know, this blog is a Hashnode blog. You can setup your very own blog/portfolio in minutes here.

Self built portfolio sites usually aren't that interesting and are often very similar from one to the next. We've all seen them a hundred times. I'll admit, they can be fun to build. It gives you your own corner of the internet where you can do what you want. But it's not really a learning exercise in most cases. I would say the time it would take to build your own portfolio can be better spent.

Consider writing about your personal projects in blog form as an alternative to just including links to the live site. Treat each project as a case study and share:

• Why you used certain tech over alternatives.
• What you struggled with.
• What you would do differently next time.

Take this personal project I built as an example of how you can share your projects in a little more detail:

Also write about related topics that interest you and show everyone you know what you're talking about. If you're self-taught like I am, It's your responsibility to prove you can do the job because you won't have the certificate to prove otherwise.

Ok, so where did your articles go this year?

Feels rich of me to suggest writing to you when I've lost my way a bit on that front. I found it difficult to motivate myself to keep writing if I'm honest. My aim was to put my all my focus at getting up to speed as an engineer with code, processes and everything else as I previously mentioned.

Instead of writing, I'd spend time reading about something that would directly help me with work related stuff. I needed to do all this for myself and I've accepted that now.

It didn't help that I was also going through a stressful move as well. Now that I'm back in a good place, I would love to continue writing again. This is a good place to start.

Finally, if you could give yourself of 1 year ago some advice, what would it be?

Keep things in perspective by appreciating the small wins.

At times, our industry can be stressful and feel like it's moving at lightning speed, especially for early career developers. You feel like you're going nowhere. Maybe feel like you don't know what you're doing or if you belong where you are.

But keep things in perspective and take small steps.

• Did you avoid making a mistake you recently made?
• Did you ask for help with something you struggled with?
• Are you proud of something you built?

Each positive small step you take should be valued and moves you closer to where you want to be. It won't happen over night, even over a year. Keep things in perspective and move forward!

The End

That's all 30 questions covered. I can't believe I've already made it through the first year and I think it went about as well as I could have hoped for.

If you have any questions for me that I didn't cover already, leave them in the comments and I'll answer them.

Until next time 👋

If you haven't already noticed, I missed last month's edition so I'm bundling it into this one. Without further delays, let's see how things went for me in months 2 and 3!

Content

1. Becoming more proactive
2. Making code gains
3. What kind of things did I work on?
4. My tip for the month
5. Did I achieve what I set out to?

Perks of the job!

👊 Becoming more proactive

I'm not ashamed to say that in my first month, I was very much working reactively as opposed to being proactive. What I mean by this is that I was generally being given for tasks as opposed to picking things up myself. Of course, I was new in my first role and very much trying to find my feet. I didn't want to go and do things I maybe shouldn't.

I was also in the process of becoming comfortable in the multiple codebases we have but there was also a definite lack of confidence on my part. I guess I didn't feel like I should at that point.

In June I felt this started to change.

A week focused on bug fixing forced me into having to pick up tasks myself and carry them through to completion. I'm grateful for this because it broke me out of my shell and I was now feeling like less of a burden on my teammates which I really didn't like.

Now I'm much happier taking on tasks that I don't feel comfortable with. That is the nature of the job after all, especially early on especially at Hashnode where we have to tackle a variety of problems from beginning to end, frontend and backend. This is an awesome thing because I'm able to pick up a lot of things as I go across many different aspects of web development.

I make a note of every bug or problem I come across so that if I ever encounter them again, I'll know what to do.

💪 Making code gains

I know I still have a long way to go but I feel as though I made some big strides in these couple of months. Just getting to spend more time in the codebase, reading my coworker's code, writing more code myself. This kind of experience is invaluable.

Of course I still have a long way to go and I'm excited about it. When I first started this job, I looked back at some of the projects I had built previously. Even then I was starting to think that some of that code could be much improved. Just goes to show how much progress you're making when you can realize this and know how you might update it or do things differently.

💻 What kind of things did I work on?

Now that it's not a secret anymore, I can tell you that I was helping out the team on Hashnode's migration to Vercel which you can (and should) read about here 👇

Powerful and superfast Hashnode Blogs, now powered by Next.js 11 and Vercel

I joined Hashnode shortly after work on the migration had begun and so this was the start of my career in software development. It was of course, my first experience of migrating an existing codebase and in some way I think this helped me get settled. Allowing me to ease me into things since I was mostly migrating and updating existing code instead of writing new code.

It allowed me to fully explore the codebases and find my feet. Things become so much easier in a large codebase when you start figuring out where things are and how things are currently working.

Once the main development work was done on the migration I got to move into some other tasks as well including 👇

• Unit testing with Jest and end-to-end testing with Cypress.
• Implement the new blogs mobile navigation
• Several small bug fixes

Practical learning (learning by doing) is what usually works for me. I had never touched Cypress before I was tasked with it so it's a case of opening the docs and taking it step-by-step. It's awesome to have the opportunity to learn something new and contribute to the project at the same time.

I'm looking forward to picking up new skills in the coming months.

💡 My tip for the month

Take notes!

Whether you're like me and love to write handwritten notes, or you favor something like Notion (which I also like). If you're working on a project, learning a topic, or whatever else it may be, write down things of note.

Anything you think you might want to refer back to in the future should be included. Some examples of things I tend to write down 👇

• Daily tasks
• Known bugs/solutions, or bugs I fixed
• Steps required to finish a task
• Any codebase specific details

An extra benefit is that many of my blog posts originate from the notes. They are an endless source of learning and ideas (as long as I keep writing them). My notes were vital for me this month!

Did I achieve what I set out to?

In the previous article of this series, I noted a bunch of things that I wanted to improve upon in the future. What things you might be asking, and how did I do?

One of the points involved my working day structure and how I felt I could be better at scheduling my general daily tasks around work and just get used to remote working in general. Now I feel like I'm getting the hang of it. My day is a little more structured which works for me, including when I take my breaks and start/finish work.

I didn't really manage to keep up the consistency with my articles and Twitter content but honestly, this didn't end up as a priority for me this time around. I took a little time away from writing articles and I felt like I needed that break. It gave me time to focus on my work and come up with ideas for future content.

As someone who has managed to break into development from a community-taught background, I think I'm in a good position to help others make the same jump. I'll be sharing more content over on Twitter related to this topic while the blog will continue to focus on a mix of technical articles and this monthly series.

The End

Thank you all for stopping by and reading my article. I hope you enjoyed. If you did feel free to check out some of my other articles. You can reach me @Kieran6dev.

See you very soon (hopefully with just August's review this time 😅)!

In this article, I will introduce HTTP headers including various different security headers that you might want to use. I will also show you how to implement them in a Next.js application.

Let's go!

Content

1. What is a security header
2. Examples of security headers
3. Adding headers to a Next.js app
4. The end!

What is a security header

First, we need to ask the following question.

What is an HTTP header?

An HTTP (HyperText Transfer Protocol) header is simply something that we use to pass some extra information with HTTP requests and responses. Think of them as notes that give more context to the main document. Each header is simply a key-value pair separated by a colon.

When you visit a website, the server receives a request from the browser. This is a request for more information about the site you are visiting which is exchanged from the HTTP request headers. The server then responds and the response will include HTTP response headers.

An example of an HTTP header is the 'Authorization' header. It simply authenticates the user agent (software that acts on behalf of the user) with a server.

Authorization: Bearer <Some token>

So what is an HTTP security header?

We use security headers to help describe our sites specifically to protect against various potential attacks. When a user navigates to the site the server will respond with response headers that provide the browser with information on how to handle things.

By adding security headers to the response of our pages, we can minimize the possibility of the following attacks happening to our application.

• Cross-Site Scripting (XXS)
• Clickjacking
• Code injection

Examples of security headers

Let's take a look at some of the important security headers that you may want to implement.

If you're already familiar with security headers, skip ahead to setting them up in Next.js here - Adding security headers to a Next.js app

Content Security Policy

The Content Security Policy header allows you to set a policy for which domains are approved for executable scripts. It's like setting a policy for children in a video streaming service. You can specify what they can and cannot watch and it's the same idea here.

Sometimes your site will need to execute scripts that come from origins other than your own application. With this header, we can fine-tune exactly which domains should be considered safe or 'whitelisted' and which should not.

We can also control the kind of resources we load into the site in more detail. For example, we could restrict loading scripts to our own domain but allow fonts or images to be loaded from a specific outside source.

Let's take a look at a few examples.

To allow content from any domain as if the policy was not set 👇

Content-Security-Policy: default-src *

Or set the own origin as the only trusted domain 👇

Content-Security-Policy: default-src 'self'

You can also specify any other domain other than your own trusted domain 👇

Content-Security-Policy: default-src 'https://someotherdomain.com'

We can fine-tune our content security policy to set separate policies for resources like images, fonts, styles, media, scripts, and more like this 👇

Content-Security-Policy: default-src 'self'; font-src 'self' 'https://fonts.googleapis.com'; image-src *.somewhere.com; script-src 'self'

In the above policy, we set the following

1. We set a default source for the content as our site's origin so this will be used for all resources unless otherwise specified.
2. We allow fonts to be loaded from our own site or from google fonts
3. Images can be trusted from anywhere that ends in .somewhere.com
4. Scripts are only trusted from our own site

Permissions Policy (Previously 'Feature Policy')

The recently renamed Permissions Policy security header allows you to control which browser APIs are allowed to be used within your site document or any iframes located in the document.

Things like geolocation, camera, microphone, and many more can all be disabled if you know your site does not require them and hence can reduce the possibility of attacks coming through these avenues as a result.

Permissions-Policy: camera=(); battery=(self); geolocation=(); microphone=('https://somewhere.com')

In the above example, we set the policies of several browser features.

1. Camera is empty which means we deny the use of video input devices.
2. Battery status API is allowed within your own domain
3. Geolocation is empty which means we deny its use
4. Audio input devices are allowed for the origin stated

X-Frame-Options

The X-Frame-Options header controls whether or not your site can be loaded within a frame. Allowing this can be dangerous because you leave yourself open to clickjacking attacks.

Clickjacking is an attack that involves tricking the user into clicking something that they believe to be something else. Attackers may disguise elements and the user is unable to see what they are actually clicking on.

We can help protect ourselves against this attack by preventing our site from being loaded within frames.

There are two options for this header

X-Frame-Options: deny

The recommended option is to deny your site being loaded within frames which is shown above using the 'deny' option.

X-Frame-Options: SAMEORIGIN

The 'SAMEORIGIN' option allows the site to be loaded within a frame while serving the site is the same as the one in the frame.

X-Content-Type-Options

The X-Content-Type-Option header ensures that MIME (Multipurpose Internet Mail Extensions) types specified in Content-Type are adhered to and we avoid what is known as 'MIME type sniffing'. Browsers might try and determine the MIME type based on the response content instead of what is specified in the Content-Type header.

It only has one option and it prevents the browser from trying to change the Content-Type away from what was declared.

X-Content-Type-Options: nosniff

Referrer policy

With this header, we can control what information is sent when a user navigates from one origin to another. Consider a user that clicks a link on what we will call the original site. This link takes the user to a different domain. When this happens, some information is sent to the new domain. Information about where the user came from.

There are several different options we can set with this header.

Referrer-Policy: origin-when-cross-origin

The 'origin-when-cross-origin' option sends the path, origin, and query string with a same-origin request from equal protocol levels. An example of an equal protocol level would be from HTTPS to HTTPS.

If the request is cross-origin, only the origin is sent.

Referrer-Policy: strict-origin-when-cross-origin

The 'strict-origin-when-cross-origin' option is similar to the previous option. The path, origin, and query string are included with same-origin requests regardless of protocol level.

When making cross-origin requests, only the origin is sent as long as the protocol level is the same and omits the header otherwise.

Referrer-Policy: strict-origin

With 'strict-origin', only the origin is sent when the protocol level is equal and otherwise omits the header.

Referrer-Policy: no-referrer

The 'no-referrer' setting will omit the referrer header.

There are further options which you can check out here

Strict Transport Security

With the Strict Transport Security header, you can specify that your site should only be accessed using the HTTPS protocol. Here we can specify the time in seconds that the browser will remember this protocol.

Strict-Transport-Security: max-age=31536000;

You can also extend the instruction to all subdomains with an optional setting

Strict-Transport-Security: max-age=31536000; includeSubDomains

You may think that setting up a redirect from 'http://' to 'https://' is enough but attackers could still seize sensitive information. Setting up a strict transport security setting will make this attack far more difficult.

Adding security headers to a Next.js app

Now that we've had a look at some security headers, let's quickly implement them in a Next.js app. Also, feel free to explore some of the other security headers available.

In Next.js we can set security headers from a next.config.js file located at the root of your project.

// next.config.js
module.exports = {
  async headers() {
    return [

    ]
  },
};

We return an array of headers that we specify inside JavaScript objects. You can choose to apply headers that will be sent with every route request or on a route-by-route basis. Let's set some of the headers that we previously explored.

// next.config.js
module.exports = {
  async headers() {
    return [
        {
          source: '/(.*)',
          headers: [
            {
              key: 'Content-Security-Policy',
              value:
                "default-src 'self'; font-src 'self' 'https://fonts.googleapis.com'; img-src 'self' *.somewhere.com; script-src 'self'",
            },
            {
              key: 'X-Frame-Options',
              value: 'DENY',
            },
            {
              key: 'X-Content-Type-Options',
              value: 'nosniff',
            },
            {
              key: 'Referrer-Policy',
              value: 'origin-when-cross-origin',
            },
            {
              key: 'Permissions-Policy',
              value: "camera=(); battery=(self); geolocation=(); microphone=('https://somewhere.com')",
            },
          ],
        },
      ];
  },
};

In the above example, we set our security headers for all routes in our site indicated by the source /(.*). You could also set security headers on a page-by-page basis like this 👇

// next.config.js
module.exports = {
  async headers() {
    return [
        {
          source: '/profile',
          headers: [
            {
              key: 'Content-Security-Policy',
              value:
                "default-src 'self'; font-src 'self' 'https://fonts.googleapis.com'; img-src 'self' *.somewhere.com; script-src 'self'",
            }
          ]
        },
       {
          source: '/blog',
          headers: [
            {
              key: 'Content-Security-Policy',
              value:
                "default-src 'self'",
            }
          ]
        },
      ];
  },
};

Now spin up a development server in your Next.js application and navigate to the route after setting your security headers. You should be able to the headers you set in the network tab of the developer console.

Congratulations, your site is now more secure than it was before! Customize the security headers to suit your application as each site has its own specific requirements.

The end!

That was a look at HTTP security headers and how we can implement them in a Next.js application. I hope you managed to learn something new.

You can follow me @Kieran6dev and if you liked the article, please let me know about it.

Until next time everyone!

Well, you've come to the right place!

What does it mean to conform?

Let's first ask the question, what does it mean to conform to something?

The simple answer is that it means we behave or comply with a set of rules or standards hopefully for the benefit of all involved.

So even before we take a look at Conformance in Next.js, we have this idea of what it might involve.

Conformance in Next.js

Conformance isn't necessarily a feature in itself, but a system. An overriding system of best practices that sets out to solve a particular problem. Those problems are defined below 👇

Conformance is a system that provides carefully crafted solutions and rules to support optimal loading and Core Web Vitals, with further additions coming to support other quality aspects like security and accessibility

https://nextjs.org/blog/next-11

Conformance aims to help developers achieve a strong base standard for these vital website factors without needing to be an expert in everything and keep up with all of the latest standards. This is done by adding solutions directly into the frameworks responsible for building the sites. This means we can spend more time focusing on features and less time on the rest of it without sacrificing anything.

Conformance in Next.js actually comes from the team at Google Web Platforms and Next.js is the first of the framework ecosystem to see a lot of the current optimizations available. If you would like to find out more about the larger effort which Conformance attempts to solve, check out this article web.dev - Introducing Aurora.

You may be reading this article and thinking something like this 👇

Where does conformance stand in relation to a tool like ESLint? How do they differ?

I was when I was first reading about Conformance.

Simply put, ESLint is one of the tools identified to be an important part of Conformance in frameworks.

ESLint is a tool that statically analyzes your code based on a set of defined rules which helps you maintain certain standards and consistencies across a project. It's a great tool that we should all be using in order to help maintain consistent code quality and best practices.

This is why there is out-of-the-box support for ESLint in Next.js as of this update. You can start a new project with ESLint ready to go or easily add it to an existing project. Let's check it out!

Next.js 11 - ESLint

ESLint can now easily be added to any new or existing Next.js project so let's do it. I'll create a new project with 👇

npx create-next-app next11-conformance

I'll draw your attention to two things. First of all, you will see a .eslintrc file at the root of the project with the base configuration. This is where we configure ESLint for our project. The second point is a new "lint": "next lint" script in the package.json file. This is how we can lint our projects and make sure the code is up to standard.

If your existing project does not currently make use of ESlint, add this script and run it. You will be guided on which packages you need to install to get things up and running.

ESLint will also lint your project whenever you run the script next build and errors in the linting process will stop the build.

I won't be diving into a complete set of ESLint rules for a Next.js project in this article, but I am going to explore the new Next.js specific rules that we now have available.

eslint-plugin-next

Our ESLint configuration will include a set of new rules specific to Next.js which are provided by the plugin eslint-plugin-next included in your project when you run create-next-app. Let's see it in action.

I will be working inside pages/index.js for the purpose of the following examples.

Firstly, delete everything inside the return statement of the home page and add the following 👇.

// pages/index.js
export default function Home() {
  return (
    <div>
      <a href="/">
        Home
      </a>
    </div>
  )
}

Here we are using a regular anchor tag that links to the home page. Next.js provides a built-in <Link /> component that we should utilize whenever we are routing within our own site. This is one of the things that the new ESLint configuration will catch.

Run the lint command

yarn lint

and you should see the following inside the terminal.

./pages/index.js
6:7  Error: Do not use the HTML <a> tag to navigate to /. Use Link from 'next/link' instead. See: https://nextjs.org/docs/messages/no-html-link-for-pages.  @next/next/no-html-link-for-pages

Need to disable some ESLint rules? Learn more here: https://nextjs.org/docs/basic-features/eslint#disabling-rules

error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Let's make the change it suggests and use the <Link /> component instead.

import Link from 'next/link';

export default function Home() {
  return (
    <div>
      <Link href="/">
        Home
      </Link>
    </div>
  )
}

Now the errors have gone and we are building an app that adheres to certain standards for the benefit of our site and the users that visit it.

✔ No ESLint warnings or errors

Let's take a look at one more again using the <Link /> component. When we are using this component and wrapping a child component which includes an <a> tag, and that makes use of the href property, we must pass the property passHref to `. Before we do, let's see the problem in action 👇.

import Link from 'next/link';

const Component = React.forwardRef(({ href }, ref) => {
  return (
    <div>
      <p>This is my link with some text</p>
      <a href={href} ref={ref}>This is the link</a>
    </div>
  )
})

export default function Home() {
  return (
    <div>
      <Link href="/">
        <Component />
      </Link>
    </div>
  )
}

If we don't use passHref on our link then our <a> tag will not receive it. In this case, we should also wrap the component in React.forwardRef because this child component of <Link /> is a functional component. The following is the error we receive by not including it.

./pages/index.js
4:19  Error: Component definition is missing display name  react/display-name
16:7  Warning: passHref is missing. See https://nextjs.org/docs/messages/link-passhref  @next/next/link-passhref

Need to disable some ESLint rules? Learn more here: https://nextjs.org/docs/basic-features/eslint#disabling-rules

error Command failed with exit code 1.

And if we now add passHref to our <Link />, everything is great again!

import Link from 'next/link';

// eslint-disable-next-line react/display-name
const Component = React.forwardRef(({ href }, ref) => {
  return (
    <div>
      <p>This is my link with some text</p>
      <a href={href} ref={ref}>This is the link</a>
    </div>
  )
})

export default function Home() {
  return (
    <div>
      <Link href="/" passHref>
        <Component />
      </Link>
    </div>
  )
}

All is well again 👏.

✔ No ESLint warnings or errors

Next.js specific rules

You may be wondering 👇

What are the full set of current rules pertaining to Next.js?

Here they are with a helpful overview of each rule.

As is the case with ESLint rules, you can turn any of these in your ESLint config rules like this 👇.

// .eslintrc
{
  "extends": ["next", "next/core-web-vitals"],
  "rules": {
    "@next/next/font-google-display": "off",
    "@next/next/no-page-custom-font": "off"
  }
}

If you're just getting started with Next.js I would recommend not turning these rules off until you understand why each rule is important and you run into a case where it is not suited to your situation. They are there to help you out.

Is there more to Conformance?

Yes there is.

ESLint is not the only tool that is considered a part of Conformance for Next.js. TypeScript is another which adds static type definitions to JavaScript and can help highlight conformance rules to the developer. If you've used TypeScript with Next.js I'm sure you will have noticed integrated type checking on built-in Next.js components. Like when you forget to add the href property to the <Link /> component. You will be warned of the problem allowing you to quickly get rid of problems before they even exist.

Conformance is very much still evolving and I'm sure it will all become clearer in time once its ideas are implemented into other frameworks, and tools and features adapt.

To further explore Conformance I suggest checking out this article web.dev - Conformance for Frameworks by Shubhie Panicker & Houssein Djirdeh.

Conclusion

That was Conformance in its current state and how it is implemented into Next.js. I think it's an interesting topic that warranted a look at now because we are sure to hear more about it in the future. I hope you were able to learn something new!

You can reach me @Kieran6dev with any questions or concerns.

Thanks for being here and I'll see you next time 👋

If that sounds good to you then please keep on reading!

Series preface

I wanted to start writing a series of articles talking about my experiences as a developer taking on his first full-time developer role. To give you a little background on me, I started learning to code as many others did around March 2020. I put thousands of hours into learning and last month in May I secured my first full-time role in the industry.

Many others have picked up programming during this time and are now also looking to make a similar breakthrough, or have recently done so themselves. I thought it would great to start a series focusing on my experience and especially the things I struggle with so that it might help others in similar situations.

Last month I became a Full Stack Developer here at Hashnode 😄. It became my preferred place to blog in March and quickly became something I was passionate about. It's awesome to be working to help build the future of Hashnode.

This was the moment I shared my news with everyone 👇.

My role with Hashnode is fully remote. It's not only my first full-time web development role but also the first time that I'm working remotely so I think there's a lot I could share as I take on this brand new challenge.

Now that's over, let's get into my first month!

🙂 New is the flavour of the month

1. My first month as an employed software developer
2. My first month as a fully remote worker
3. New codebases
4. New teammates
5. New challenges

My first week was very exciting despite also being a little intimidating purely because it was all new to me. Everyone on the team was super welcoming which helped to settle my nerves and I soon began to dig into the codebase. I've worked many jobs in several different industries over the course of my travels so I know how much easier things become when you have a supportive team.

Jumping into someone else's established codebase for the first time kind of feels like what I imagine being pushed off the side of the cliff into a cold pool of water is like. It's shocking at first, then hopefully your instincts kick in and you start to swim to stop yourself from going under 😄.

Fortunately, I felt comfortable with some of the main players in the tech stack that includes Next.js so that helped ease me in. As I worked my way through reading each and every file on the first day I quickly realized that it would be impossible to pick things up straight away and understand the exact significance of each line, file, and function. It takes time for this stuff to come.

🐾 Small steps

A good place to start is to work your way through each file to get accustomed to the structure of the project. I use a pen and paper to make regular notes of things I can refer back to and I would be lost without it. Think of it as getting used to a new city after you've just moved in. Walk around and take in the highlights. When you need something in the future, you'll at least know where to look!

I can honestly say that working in a codebase that was not written by me has been a complete eye-opener and something I suggest everyone do as soon as possible.

🙏 It's OK to be nervous

For the first couple of weeks, I definitely felt some nerves which I think is normal. This was the first time I was working in a shared codebase that was rapidly evolving. More than anything I was afraid of making silly mistakes.

My mind would go blank when I had to perform the simplest of actions with Git for example. I didn't want to cause problems that would negatively affect others and so I would second guess everything I was doing. There were a couple of days where I genuinely couldn't remember how to do simple fetching, merging, and branching because I was second-guessing myself. Even though this was stuff I knew how to do.

By week 2 or 3, I started to calm down and I tried to remember that I did know what I was doing and I was here for a reason. I'm sure this a very common occurrence among new developers and feel free to share it if you have experienced something similar.

🎥 Getting used to remote working

My current temporary setup, not so fancy but it's mine 👇

I've never worked remotely before and I found this to be a surprisingly difficult thing to get accustomed to. All of a sudden you have to think about things like when to take breaks, what work schedule works well for you, and handling regular video calls.

I think it's important to define your own working day structure with some kind of plan. I didn't do this so well for the first two weeks. Some mornings I would forget to eat breakfast until it was almost lunch and I wasn't consistent with taking breaks when I needed them. Weeks 3 & 4 were a little better and I'm starting to see what times work well for those short breaks.

It's all trial and error

I still struggle with remembering to get up and move around. From what I've found, it's easier to feel a little too comfortable in your chair when you're at home which means you forget to get up and take a quick refresher. There was a day last week where I must have been glued to my chair because I completely forgot to move for most of the day 😄. Big mistake!

For the next month, I'm going to dedicate a little break time each day to a small walk or exercise of some kind to help keep me active. I'll share how I get on with this next month.

The other important part of remote working is video calls. I've never been someone who is completely comfortable talking over the phone or over video. Often one of those people who would avoid phone calls at all costs and would much prefer speaking in person. Having now finished my first month I can say that it's getting a little easier but I've still got some ways to go to become one with the camera!

🤗 I get to work on a platform I use daily!

It is a really exciting thing to be able to contribute to a product you know and love and I'm extremely fortunate to be in this position. Every time you see one of your pull requests get merged to the big boy branches it feels awesome knowing you were responsible for something, no matter how big or small 😅.

It meant that it often didn't feel like work at all. I was a regular user of Hashnode before I joined the team and it's really interesting to see the inner workings of how it all comes together and where it's headed in the future.

I honestly don't know where that first month went because I loved every second of it, even in my struggles. Blink and you miss it!

Hashnode swag that I was sent this month 👆

📝 Maintaining consistent content outside of work is tough

Starting a new full-time job definitely contributed to a drop in my own content which is to be expected. My tweets were way down and my articles were not as consistent as they were. It's been difficult trying to balance the two things. Some days you don't feel like posting and it's on days like this where having a plan is needed which I was lacking.

For the coming month, I will try and be a little more organized by planning ahead with content a little better so that I don't end up with as many blank days. I love interacting with the community and I feel disappointed in myself when I can't manage it how I would like to.

💁‍♂️ My tip for the month

Every month I will try and offer up a tip of some kind based on my experiences for the month. This month's tip relates to finding your ideal role 👇.

Build personal projects that represent the field or tech you are really interested in.

Let's say you are passionate about e-commerce and you would love to work on e-commerce projects in the future. Then build some of your own e-commerce projects and get them out in the open. This can go a long way especially if you are looking to break into the field for the first time.

Doing this will provide the opportunity for employers to contact you first. Share your projects in developer communities and on social platforms and write about them too. Your projects can act as another recruiter for you and you can use them to back up your own claims and knowledge when you get to the interview stage.

✌️ The month ahead

Overall I'm really happy with how my first month as a software developer turned out despite the article focusing on a lot of the things I struggled with. It's just how my brain works, to keep finding things I could get better at. I know there's only one way to go for me and that's ⬆.

Although touches of imposter syndrome crept in at times, I was able to cope with it and I now know that I am able to do this.

Please let me know if you enjoyed reading this article. You can do so in the comments below or @Kieran6dev where I'm always available.

Here's to the month ahead! 👋

Let's explore how we can integrate user authentication in a serverless Next.js app using Auth0 in a really simple way. We will be using a package called @auth0/nextjs-auth0 which was built to support user authentication in Next.js using Auth0 and will get us up and running in no time.

One of my recent side projects was building a full-stack serverless Next.js e-commerce site. This site included user authentication and you may be thinking

How does user authentication work in a serverless Next.js app?

Good question! Let's answer this by building a simple app that allows users to login/logout and visualize their profile data as a result 👏.

Content

1. What is the authentication flow?

2. Finished app demo

3. Building our app!

• Initialize the project

• Auth0 setup

• Auth API route

• Auth Provider _app.js

• Home page

• useUser() hook

• Nav component

• AuthLink component

• Profile page

• Custom auth helpers

4. Conclusion

What is the authentication flow?

Before we start writing any code I think it's important to understand what exactly we are trying to do and how authentication will work.

This article below will give you a fantastic overview of the approaches you can take to implement Auth0 authentication in a Next.js app.

Auth0 - The Ultimate Guide to Next.js Authentication with Auth0

We are going to take the approach of a serverless application where we instead opt to use functions in our Next.js app that provide us with functionality like authentication when it's needed. We can use our serverless functions on a need-to-use basis as opposed to having a server that is constantly running.

Our application login flow will look something like this 👇

When the unauthenticated user clicks the login button they are redirected to the login form provided by Auth0. Then the user proceeds to login and when successful, is redirected back to our app at a destination of our choosing.

It is important to note that I will not be implementing any kind of persistent storage for users in this tutorial. We have no need for a database in a simple app like this and the authentication works nonetheless. Let me know if you want to see an article on integrating a database into the app 😀.

Finished app demo

I thought it would be a good idea to include a quick demo of the finished app before we start so you can visualize what we are going to be building.

The basic features of the app include:

• Home page that instructs the unauthenticated user to login

• Protected profile page populated with some of the authenticated user's data

• Profile page is a dynamic route /profile/username

• If an unauthenticated user visits profile page, they will be redirected to login page

• Offer logout option for authenticated users

If you want to check out the full repo for this project you can do so here 👇

kieran6roberts/Blog-Next-Auth0

Building our app!

To handle our app's authentication we are going to use a package called @auth0/nextjs-auth0. This package was built to facilitate user authentication with Auth0 in a Next.js app. To use it you must satisfy the following conditions.

• Node.js version ^10.13.0 || >=12.0.0

• Next.js version >=10

Initialize the project

We'll start this project from scratch so you can see exactly what it takes from start to finish. Start by initializing a Next.js app.

npx create-next-app next-auth0

Now install the necessary packages for our app

yarn add @auth0/nextjs-auth0 @emotion/react

• @auth0/nextjs-auth0 - SDK for handling authentication in our app

• @emotion/react - Emotion CSS in JS react package for styling

I'll be using Emotion for styling in this app but you can use whatever you want, it's not important, is easily substituted, and there won't be much styling anyway.

Auth0 setup

Before continuing with the code, we first need to set up a new application with Auth0 on their site. You can do so here Sign Up - Auth0 or simply login if you already have an account.

Then we are going to set up a new application in the Auth0 dashboard. Once you've logged in, navigate to the 'Applications' tab.

Click the 'Create Application' button and give the app a name. Here I name mine 'my-next-auth0'. Then select the 'Regular Web Application' option.

When prompted select 'Next.js' as the technology for the application. Auth0 recently had an update to their site and now offer some very helpful documentation on how to get started with Next.js and Auth0 authentication. This information is available in the 'Quick Start' tab of your application if you ever need any help.

The next step is to configure some settings in our Auth0 application. Click on the 'Settings' tab and here we need to set two options.

1. Allowed Callback URLs - http://localhost:3000/api/auth/callback

2. Allowed Logout URLs - http://localhost:3000/

You might choose to configure more settings depending on your app but this is enough for us. If you end up deploying the app then you would also want to come back in here and add your new URLs.

When we as a user have entered our login details successfully, Auth0 will need a destination to send the user. This is why we specify our API callback route so that our auth package can handle the redirect.

When the user hits the logout button, we also specify the url's that are valid for auth0 to redirect to for the logout case. Here it is http://localhost:3000/.

The package @auth0/nextjs-auth0 also requires the following settings within the Auth0 app dashboard so make sure to check they are correct.

1. Json Web Token Signature Algorithm - RS256

2. OIDC Conformant - True

You can find those settings in your applications 'Advanced Settings - OAuth'.

Now that we have our settings in place we are going to need some constants in our Next.js app which we will store in environment variables. Create a .env.local file at the root of your app:

// at the project root
touch .env.local

and add the following but replace the examples with your settings 👇

AUTH0_BASE_URL={{Base URL of your site, probably http://localhost:3000 in development}}
AUTH0_ISSUER_BASE_URL={{https://your auth app domain found in dashboard}}
AUTH0_SECRET={{Some secret used to encrypt the session cookie}}
AUTH0_DOMAIN={{https://your auth app domain found in dashboard}}
AUTH0_CLIENT_ID={{Auth0 app client id found in dashboard}}
AUTH0_CLIENT_SECRET={{Auth0 app client secret in dashboard}}
AUTH0_SCOPE={{The scopes we want to give to our authorized users, here I will use 'openid profile'}}

Our auth package will pull the following information from your.env.local file so make sure you don't miss these out and that you also name them like this 👆.

It's up to you to locate the missing information from your dashboard and add it to the .env.local file and I've added a description for each variable to help you along. These settings should be secret to your app so don't go sharing them with anyone 😉.

For the AUTH0_SECRET variable you can generate a secure secret from the command line using:

openssl rand -hex 32

Auth API route

Now our application is created and our variables are setup we can start working on the authentication flow in our Next.js app.

To do this we are going to make use of Next.js API routes. If you need a quick introduction to these routes, check out my article here Getting started with Next.js API routes.

We will need one API route to handle user authentication. Create the file pages/api/auth/[...auth0].js.

// project root
touch pages/api/auth/[...auth0].js

Using this dynamic route will match all paths prefaced by /api/auth/ meaning it will run whenever we hit one of our auth routes. The handleAuth() function which you are about to see will create the following routes for us seemingly by magic 🪄.

• /api/auth/login

• /api/auth/callback

• /api/auth/logout

• /api/auth/me

import { handleAuth } from '@auth0/nextjs-auth0';

export default handleAuth();

We will explore how we can add some custom functionality to this later but for now that's all you need.

Auth Provider_app.js

We can access the user on the client or on the server. To access the user on the client we must wrap our app in the UserProvider component provided by @auth0/nextjs-auth0.

In our app we are going to be accessing the user on the server. Despite this, I will add the provider to the app in case something changes and we need access to the user on the client.

Inside the _app.js page you should wrap the returned content with the provider.

// _app.js
import { Global, css } from '@emotion/react';
import { UserProvider } from '@auth0/nextjs-auth0';

function MyApp({ Component, pageProps }) {
  return (
    <UserProvider>
      <Global styles={css`
        *, *::after, *::before {
          box-sizing: border-box;
          font-family: 'Gill Sans', 'Gill Sans MT', Calibri, 'Trebuchet MS', sans-serif;
          padding: 0;
          margin: 0;
        }

        a {
          text-decoration: none;
        }

        ul {
          list-style: none;
        }
      `}
      />
      <Component {...pageProps} />
    </UserProvider>
  )
}

export default MyApp

I have also added some basic global style resets which you are more than welcome to expand upon.

That is the simple setup complete for handling our user authentication. I promise that is not a joke. That's all you need! Soon we will see what else we can do but for now, our user authentication is functional!

The next step is to build out our application UI so we can show the user a login or logout link depending on whether the user is authenticated or not. We will also add some of the user's dynamic data when they are authenticated and work with protected routes.

Home page

Let's start with the home page. For an unauthenticated user it will look like this👇

For an authenticated user it will look like this 👇

So let's write the code for it.

/** @jsxRuntime classic /
/** @jsx jsx */
import { css, jsx } from '@emotion/react';
import { getSession } from '@auth0/nextjs-auth0';

import AuthLink from '../components/AuthLink';
import Nav from '../components/Nav';

export default function Home({ user }) {
  return (
    <div css={css`
      align-items: center;
      background: #ff00cc;
      background: -webkit-linear-gradient(to right, #333399, #ff00cc);
      background: linear-gradient(to right, #333399, #ff00cc);
      display: flex;
      height: 100vh;
      justify-content: center;
    `}
    >
      <div css={css`
        background-color: #fff;
        border-radius: 1rem;
        padding: 4rem 8rem;
        text-align: center;
        `}
      >
        <Nav user={user} />
        <h2 css={css`
          margin: 2rem 0;
        `}
        >
          {user?.name ?? 'Welcome User'}
        </h2 >
        <p css={css`
          margin-top: 2rem;
          margin-bottom: 3rem;
        `}
        >
          {user ? `It's great to have you here${user.given_name ? ` ${user.given_name}!!` : '!!'}` : 'I bet you would like to sign in to our app right? Click the Sign in button below'}
        </p>
        <div>
          {user ?
            <AuthLink path="/api/auth/logout">Sign Out</AuthLink>
          :
            <AuthLink path="/api/auth/login">Sign In</AuthLink>
          }
        </div>
      </div>
    </div>
  )
}

export async function getServerSideProps(ctx) {
  const { req, res } = ctx;
  const session = getSession(req, res);

  return {
    props: { user: session?.user ?? null }
  }
}

As you can see it is a fairly straightforward page, but I will draw your attention to the main points.

First of all, we are pre-rendering our page on the server using getServerSideProps(). We use the helper function getSession() which takes the request and response objects as parameters and retrieves the user's current session if it exists and otherwise null. This session will contain the user data as a property on the session object.

The main reason I am server-rendering this page is to know for sure whether we have a user before rendering the page. Our user profile route which we will soon implement will be a dynamic route that will look like /profile/username. We need the user object to create this route so we pre-fetch this user on the server.

You'll also notice that I'm importing two components Nav and AuthLink in our home page. This is because we will also need the same markup for our soon-to-be Profile page so I broke it down into the reusable components that we will soon see.

useUser() hook

Another method of fetching the user with this package is through the useUser() hook. This is the method you would use if you wanted access to the user on the client and would be possible for us to implement this in our app since we previously set up the UserProvider component.

It lets us hook into the user so that the client is aware of whether or not we have an authenticated user. We can make use of loading, data, and error states to conditionally render data based on the outcomes. This is how you would implement the hook 👇.

import { useUser } from '@auth0/nextjs-auth0';

// Inside your component
const { user, error, loading } = useUser();

This does not mean authentication takes place on the client. Our authentication would still take place on the server and no sensitive information is exposed.

Nav component

This is our Nav component which is just a simple set of links with some styling 👇

/** @jsxRuntime classic /
/** @jsx jsx */
import { css, jsx } from '@emotion/react';

const linkItem = css`margin: 0 2rem;`;
const link = css`color: #ff00cc; padding: 0.5rem 1rem;`;

const Nav = ({ user }) => {
  return (
    <nav>
      <ul css={css`
        display: flex;
        justify-content: center;
        margin-bottom: 1rem;
      `}
      >
        <li css={linkItem}>
          <a css={link}
          href="/"
          >
            Home
          </a>
        </li>
        <li css={linkItem}>
          <a css={link}
          href={`/profile/${user?.nickname ?? '_'}`}
          >
            Profile
          </a>
        </li>
      </ul>
    </nav>
  )
}

export default Nav;

The component takes the user object as a prop. If the user exists, we set the route of the profile link to /profile/${user?.nickname ?? '_'}. If the user exists we have a dynamic route with the nickname of the user included. Otherwise, we set it to /profile/_ because we still have to set something otherwise we will end up on a 404 route because /profile/ does not exist. We will set up a protected route for the profile page.

AuthLink component

Our Auth Link component is the main call-to-action link for signing users in and out of our app.

/** @jsxRuntime classic /
/** @jsx jsx */
import { css, jsx } from '@emotion/react';

const AuthLinkStyles = css`
  background-color: #ff00cc;
  border: 1px solid #ff00cc;
  border-radius: 0.5rem;
  color: #fff;
  display: block;
  margin: auto;
  padding: 1rem 2rem;
  width: max-content;
`;

const AuthLink = ({ children, path }) => (
  <a css={AuthLinkStyles} href={path}>{children}</a>
);

export default AuthLink;

We can pass a dynamic path to the component props based on whether the user is authenticated.

Profile page

Now I'm going to create another page at a dynamic route /profile/[profile].js and this should only be accessible to users that are logged in. If an unauthenticated user tries to access this page, they should be redirected to login instead.

Let's remind ourselves of what it looks like 👇

We can implement protected routes using a helper function provided by this package called withPageAuthRequired(). You wrap getServerSideProps() using this function to check whether we have an authenticated user, and if not they will be redirected. If the user exists, there will be an added user object inside the page props object.

Start by creating our profile page file.

// project root
touch pages/profile/[profile].js

Then add the following code 👇

/** @jsxRuntime classic /
/** @jsx jsx */
import { css, jsx } from '@emotion/react';
import { getSession, withPageAuthRequired } from "@auth0/nextjs-auth0";

import AuthLink from '../../components/AuthLink';
import Nav from '../../components/Nav';

const profileItem = css`margin: 2rem 0`;

export default function Profile({ user }) {
  return (
     <div css={css`
      align-items: center;
      background: #40E0D0;
      background: -webkit-linear-gradient(to right, #FF0080, #FF8C00, #40E0D0);
      background: linear-gradient(to right, #FF0080, #FF8C00, #40E0D0);

      display: flex;
      height: 100vh;
      justify-content: center;
    `}
    >
      <div css={css`
      background-color: #fff;
      border-radius: 1rem;
      padding: 4rem 8rem;
      text-align: center;
      `}
      >
        <Nav user={user} />
        <h2 css={css`margin: 2rem 0`}>Welcome to your profile {user.name}</h2>
        {user &&
          <img
          alt="user avatar"
          css={css`
          border-radius: 0.5rem
          `}
          src={user.picture}
          />
        }
        <ul css={css`margin-bottom: 2rem`}>
        {user.given_name ? <li css={profileItem}>First name: {user.given_name}</li> : null}
        {user.family_name ? <li css={profileItem}>Family name: {user.family_name}</li> : null}
        {user.nickname ? <li css={profileItem}>Nickname: {user.nickname}</li> : null}
        {user.favoriteFood ? <li css={profileItem}>Favorite Food: {user.favoriteFood}</li> : null}
        </ul>
        <AuthLink path="/api/auth/logout">Sign Out</AuthLink>
      </div>
    </div>
  )
}

export const getServerSideProps = withPageAuthRequired({
  async getServerSideProps(ctx) {
    const { req, res, query } = ctx;
    const { profile } = query;
    const session = getSession(req, res);

    if (profile !== session.user.nickname) {
      return {
        redirect: {
          destination: `/profile/${session.user.nickname}`,
          permanent: true
        }
      }
    }

    return {
      props: {}
    };
  }
});

We start with our server-side rendered page that we wrap in our protected route wrapper. We again access the user's session but this time we want to see whether or not the user is trying to access their own profile. In our app want to restrict users to their own profile only.

To do this we check if the session nickname of the user is the same as the nickname query accessed from the context query. If they don't match we will redirect the user back to their own page.

Note 👇

I recognize that this is not a very robust check and if you are implementing a real-world app where profile privacy is essential. If we had a database then we could ensure every user has a unique identifier to compare against but I'm not going to make this article longer than it already is 😂.

End of note

As you can see we access the user object through our page props which will be provided automatically by withPageAuthRequired().

Custom auth helpers

Remember how we earlier had only two lines of code in our API auth route? We can do a lot more in here with helpers provided by our auth package. It provides a set of handlers for each state of the authentication process. They are the following 👇

• handleCallback

• handleLogin

• handleLogout

• handleProfile

Now I'm going to add them into our API auth route so you can see how to implement them yourself. I will also use the afterCallback function to add a custom property to our user object once authenticated.

import {
  handleAuth,
  handleCallback,
  handleLogin,
  handleLogout,
  handleProfile
} from '@auth0/nextjs-auth0';

const afterCallback = (req, res, session, state) => {
  // user is located in session
  session.user.favoriteFood = 'pizza';
  return session;
};

//Use this to store additional state for the user before they visit the Identity Provider to login.
const getLoginState = (req, loginOptions) => {
  console.log(loginOptions.authorizationParams.scope); // access scope
  return {}; // custom state value must be an object
};

// Use this to add or remove claims on session updates
const afterRefetch = (req, res, session) => {};

export default handleAuth({
  async callback(req, res) {
    try {
      await handleCallback(req, res, { afterCallback });
    } catch (err) {
        res.status(err.status ?? 500).end(err.message)
    }
  },
  async logout(req, res) {
    try {
      await handleLogout(req, res);
    } catch (err) {
        res.status(err.status ?? 500).end(err.message)
    }
  },
  async login(req, res) {
    try {
      await handleLogin(req, res, { getLoginState });
    } catch (err) {
        res.status(err.status ?? 500).end(err.message)
    }
  },
  async me(req, res) {
    try {
      await handleProfile(req, res, { afterRefetch });
    } catch (err) {
        res.status(err.status ?? 500).end(err.message)
    }
  }
});

We can call these four asynchronous functions inside our handleAuth object and in each we use our handler functions wrapped in a try/catch block. Each of the handlers has a custom set of handlers so consult the documentation if you need help.

I wanted to show that it is possible to add custom functionality to each step based on your requirements. Each time we login, we redirect to our callback function which runs our afterCallback function. In here we add a custom property called favoriteFood on our user object which is accessed through the session object.

Now you should see an extra list item with my favorite food being pizza on the profile page that we previously set up. The app should now resemble the finished app from the video earlier on. Well done 👏.

Conclusion

That brings us to the end of this demonstration of how we can add user authentication to a Next.js app using Auth0. I think you'll agree that it was a reasonably easy thing to set up. The next step might be to set up a database so you can persist users with custom accounts suited to your app.

You have any questions then contact me @Kieran6dev where I'd be more than happy to answer you.

If you made it this far congrats 🎉. Until next time friends 👋

You will also probably need a portfolio if you're looking to start freelancing so that you can show potential clients that you're up to the task. This article won't be focusing on a freelancer's portfolio because it's not my area of knowledge but there is plenty of overlap of useful tips so please keep reading 😄.

Building your own portfolio is not an easy task. There is a lot of different ways you can go about the task and I thought it would be useful to write an article that answers some of the questions I had when I was building mine.

Here are my portfolio do's & don'ts 👏

Sections

1. 📞 Contact Details
   • Do - Make your contact details obvious
   • Don't - Add social links to accounts that you don't actually use
2. 🖥 Projects
   • Do - Consider adding project case studies
   • Do - Make it easy to jump to the projects
   • Don't - Include the portfolio itself as a project if you have enough other projects to show
   • Do - If you're going to include tutorial projects, customize them in some way
3. 😃 About Me
   • Don't - Include your life story
   • Don't - Include skill bars
4. ✅ Tech stack doesn't matter, performance & accessibility does
   • Do - Ensure the site is performant
   • Do - Ensure your site is accessible
5. Summary

📞 1. Contact Details

Do - Make your contact details obvious

Not making your contact details obvious to the hiring employee/potential client is probably the worst thing you can do. Why go to all the trouble of showing off what you can if you don't make it easy for them to contact you afterward?

Consider adding multiple communication options on your site. This could be through email, Twitter, Linkedin, Github, and anything else you actually use and have a presence on. When your site loads, the user should be able to click one button and be taken to a contact option.

You could do this using a call-to-action on your hero that says something like 'contact me' taking the user to a contact form on your page. Maybe you could add links to your accounts using icons and add them to the hero so the when the page loads they're right there on the screen.

Whatever it is, make sure it's obvious and simple for the person to find and contact you. You don't want to miss out on an opportunity because you made it difficult for them to reach out. Employers are not going to spend very long on your page and they will just move on if they find it difficult.

Don't - Add social links to accounts that you don't actually use

I remember when I was building my portfolio for the first time. I searched for what contact links are common for someone to add to a portfolio. Common options include:

• Email
• Github
• Twitter
• Linkedin
• Youtube
• Blogging profiles

As a developer you should already have a Github profile which can be added along with your email but the rest are usually optional.

When I was making my portfolio I had a bare Twitter account which I had created a few months prior and an almost empty Linkedin profile. If these are not sites you actually intend on using, don't bother including them in your portfolio. What's the use of showing an employer your Twitter account when you don't post there or contribute anything related to web development and the jobs you may be applying for.

My suggestion would be to start using some of them and begin branching out. The word 'networking' made me nervous when I started but it's really not that difficult to start making connections with like-minded people. Then you can add these profiles to your portfolio and start building a more well-rounded portfolio.

🖥 2. Projects

Do - Consider adding project case studies

There are plenty of great portfolios that don't include case studies of their projects but I think it can help you stand out. You don't need to write thousands of words for each study but adding a little more background to each project can be very insightful.

Tailor each case study to the real world and how your potential employer would look at a project. Consider adding the following elements to the study 👇

• Project objectives
• Why the stack choice was optimal for achieving the objective
• Some of the problems you faced and how you overcame them
• What you might do differently next time

Showing potential employers that you considered the trade-offs between alternative solutions and tech, based on the needs of the client (or you for a personal project) will go a long way.

Instead of saying

The front-end of this project was built with the JavaScript library React.

Expand on it by saying why this decision was taken with something like this 👇

I decided to go with React for this project because there is a lot of state management required which would be much more difficult to maintain without the JavaScript library. By choosing React I could get the live site up and running faster meaning the client could start trading as early as possible. It would also provide a more maintainable codebase for the future...

Do - Make it easy to jump to the projects

Your portfolio is essentially a house to show off your projects right. Almost like when you want to buy a car. You go to the showroom or garage and the employee walks you around to see some of the cars on show. You're not really interested in anything else but cars. If you like what you see you input your contact details and make a purchase.

The same goes for the portfolio. Make it easy for the user to find the projects so they can see what you can do and then contact you if applicable. How you do this is up to you and there is no obvious best approach.

My approach was first to avoid adding a hamburger toggle to my site and instead just include the link names. I only have three links so there is really no reason to make the user click an extra button to find what they're looking for. On the home page, I also kept the introduction section relatively small with limited text before introducing my projects. After the projects I include a little 'about me' section with a little more info about me which really didn't need to come before the projects.

Try not to leave the user with a mountain of introductory/personal content to scroll through before getting to the projects.

Don't - Include the portfolio itself as a project if you have enough other projects to show

This is something I deliberated at first and so I asked my friends over on Twitter what they thought about it. The general consensus was to avoid including the portfolio itself as one of the projects. This is especially true if you have plenty of other projects to highlight. Instead consider just adding a link to the Github repo somewhere. I like the idea of including it in the footer but it's up to you.

Do - If you're going to include tutorial projects, customize them in some way

It's fairly common to see projects on someone's portfolio that clearly came from a tutorial. We have all taken tutorials at some point and these projects can be a very useful learning curve. But if you want to add it to the portfolio, then customize it in some way that will make it a more personalized project.

For tutorial projects I would recommend not adding to the portfolio and instead just link your Github repo where the code lives. However if you're at the stage where you don't have many projects, it can be a temporary solution. Try changing the design of the tutorial project and some of your own features to it as well.

Personalize your projects to help you stand out!

😃 3. About Me

Don't - Include your life story

I have seen plenty of portfolios that include a massive life story of the creator. It takes endless scrolling to get through before seeing the projects. I'm not saying you shouldn't include it, but I am saying you can probably reduce the size of it. Nobody needs to know what we had for breakfast or where we went to school 😄.

Give a few highlights instead that will quickly give a better picture of you as a person. Keep it short and concise or move it after the projects on the home page. You could also have a dedicated 'About me' page with more information there and have a quick snapshot of it on the homepage.

As long as you don't have a massive personal section ahead of your projects that require scrolling to get through it, you should be good!

Don't - Include skill bars

This is a personal preference of mine that you may disagree with. You have probably seen those skill bars where the developer gives themselves a 9/10 for JavaScript as an example. In my opinion, this is not very useful information to be giving a potential employer. The employer will find out exactly how good you are when it comes to your interviews.

You could be overestimating your skills giving the employer the opportunity to question you on it which may trip you up. Or perhaps you're underestimating your skills and they deem you not to be worthy of the interview in the first place.

I just think that they don't provide any actual value to your portfolio. You can include the tech you are comfortable with but I wouldn't add a rating for what you think your skill level is. Use your projects to highlight your skills and what you could do better instead.

✅ 4. Tech Stack doesn't matter, performance & accessibility does

Do - Ensure the site is performant

The content and design are often the main focus for new developers when it comes to building the first portfolio. But good performance and accessible content are two incredibly important factors of any website that you need to get right. You could have all of the best projects in the world on your portfolio, but if it takes 5 seconds for the page to paint and render then what's the point?

No potential employer is going to consider you if they visit your site and it takes forever for it to load. They will think that you don't know how to optimize a site which will set off some red flags. At the end of the day, the stack you use to build the site is irrelevant. But it should always be performant and accessible. General tips for making it performant are as follows 👇

• Load the content you need for the visible screen and defer the rest when possible
• Optimize any images you may have
  • Use modern formats like WebP with a fallback option
  • Use a compressor tool like Compressor.io
  • Use the correct image size for the device size
  • Lazy load images
• Bundle and minimize your files

Use a tool like Lighthouse to audit your site and give you potential improvements to make for performance as well as accessibility.

Do - Ensure your site is accessible

Make sure you use colors that contrast with each other so that users with deficiencies in viewing colors are catered for. You can use a tool like WebAIM: Contrast Checker to help you with this.

Make sure you always add alternative text to all of your images so that users using assistive technology can still understand your images. Also, try tabbing through your site as an impaired user may do. Ask yourself this 👇

Is the tabbing order logical?

and

Can I still operate the site as any other user would?

If the answer to these questions is no, you definitely want to correct this. Firefox has some great features in its developer tools for helping you view this information.

Navigate to the Accessibility tab in its developer tools and click the button 'Show Tabbing Order' to highlight all of the tabbable elements on the page. There is also a lot more information related to accessibility here like element roles so have a look around and see what improvements you can make.

Summary

Let's quickly summarize the main points. Make your projects stand out as the highlight of the portfolio and ensure your contact information is easy to access. You can include information about yourself but don't make it detract from your projects. Finally, ensure the site is fast and accessible.

If you can manage all of this with some good projects on there as well, you're on the way to becoming a software developer. This is not to say that will be guaranteed to find a job. But it will help you get your foot in the door and perhaps receive more interview opportunities. It's then up to you to back up the stuff you claim to know from your portfolio.

I hoped this will help you in some way because making a portfolio can be a difficult thing to get right. Looking back at mine now, there are many things I would change and I'm sure I will be building a much-improved version sometime in the future for a bit of fun. But everything I have mentioned in the article stands true for me at least.

Reach out to me @Kieran6dev for any questions or concerns.

Until next time 👋

Before I started the challenge I had no social media presence as a developer. No followers and no developer friends and I had been self-learning for about 10 months. Knowing that I would soon be looking for my first professional role, I thought it was important to have a social media presence and that it would significantly increase my chances of finding the right job.

But I didn't really know where to start or what I should be posting about? Then I found the #100DaysOfCode challenge where people of all stages in their learning were posting about what they were learning. This would be perfect I thought. I could post about my progress and meet others in the same position as me.

This challenge was absolutely the kick-start I needed and led to me meeting lots of amazing people I otherwise wouldn't have. This catalyst also led to me becoming a Full Stack Developer here at Hashnode.

Let me explain why this challenge was the catalyst for me getting to where I am today and why you might consider taking it on 👏.

Content

1. 📱 Provided content for my account
2. 📈 Helped my social media growth
3. 👩🏻‍🤝‍🧑🏽 Connected me with like-minded people
4. 🙂 Kept me accountable
5. 📝 It is a record of my progress
6. 🤔 Is it for you?

This was my first-day tweet 👇

📱 1. Provided content for my account

Having a good social media presence as a developer can be hugely beneficial. If you're like me and start the challenge with no presence at all it might be difficult to know what you want to post about and where to start.

I didn't feel comfortable posting in my first few weeks but this challenge forced me to keep doing it. The more you do something, the easier it gets. Similar to when I started blogging, thinking of suitable content is difficult and so a great way of overcoming this is to write about yourself.

The challenge requires you to post a tweet each day about what you've been learning. It pushes you to write about yourself and I continued this trend into my articles. By tweeting out your progress you start to build a collection of tweets that may be important to have if people are going to feel as though they want to follow you. People are usually less likely to follow a person if they have none of their own tweets on their timeline because it tells them they are probably less likely to engage in general.

The 100-day coding challenge gave me a starting point to begin adding value to my feed which I probably would have been stuck on otherwise. I found it refreshing to be able to share with others the stuff that went well, as well as the stuff that didn't. It meant I would have at least one post on my feed every single day. If you commit all the way to the end of the challenge you will have more than three months' worth of consistent tweets just from the challenge alone!

It will help get you off the ground and into the habit of posting consistently. You will need this consistency if you aim to build a social media presence and use it to help you search for employment or freelancing opportunities.

📈 2. Helped my social media growth

When I started the challenge I think I had less than 5 followers and I didn't even have a Linkedin account. If your aim is to grow your social media presence to help you find opportunities I think we can both agree that this will not work out.

I hadn't posted a single tweet on my account before this challenge. Most of it was down to anxiety and putting myself out there. I would say I'm an introvert at heart who has learned to become socially extroverted when required. It's just a fact that I was afraid of posting 😥.

Knowing that I was going to be applying for my first full-time role in the near future, I wanted to change this but I didn't really know how to do it. I would see some popular accounts tweeting tips and think I had come up with a super-secret amazing tip every time that has never been seen before. That's not the case of course and I soon found my way that started with what I was learning.

I soon connected with lots of other developers also taking part in the challenge. This gave me the confidence to start posting some of my own content including starting to write a blog which was supported by lots of the friends I have made. It's like the snowball effect where it keeps getting bigger as it rolls ⛄.

Before you know it I became comfortable with the content I was providing and started sharing things about myself as well that I never would have considered before. Showing others you are a person and not just an account will go a long way to helping you connect with others. Today I'm proud to say I have made a lot of awesome friends and I never would have thought I'd be ending the challenge with close to 1k meaningful connections. Many of which I communicate with regularly.

#100DaysOfCode is a very popular hashtag that will be seen by many people and can help extend the reach of your progress tweets early on when it's possible you don't have many connections. If you combine this with adding value to other' tweets you are sure to see some growth and start making connections that could help your future in one way or another.

👩🏻‍🤝‍🧑🏽 3. Connected me with like-minded people

This is great for a multitude of reasons. Probably the best part of the challenge was meeting lots of like-minded people who were going through the same struggles as me. For the previous year I had been working alone without anyone in the same field to really share things with.

I soon met lots of awesome people through the challenge who were openly sharing and encouraging each other. It was awesome to see what everyone was building from week to week. You can clearly see how much progress your friends are making and this should help drive you on to do the same.

The absolute biggest benefit for me so far in my progress as a developer has come from connecting with others. There is always something to learn from another developer whether they're behind you in the process or far more experienced than you. Everyone has something to share. This is the phrase I used to push myself to start writing.

This openness to share and help others was new to me and I loved it. Not only will you learn so much from each other, but you might connect with people who can help you look for opportunities whether it's direct or through sharing that you're looking for a job. You might be surprised to hear how many job and freelance opportunities can be found on places like Twitter.

🙂 4. Kept me accountable

Staying consistent is the most important factor when learning to write code. It will help you if you can include others in your attempts to be consistent. This usually comes from sharing with others like the opportunity provided by this challenge.

Posting your progress every day will open you up to others and suddenly your not the only one interested in how you're getting on. I never felt pressured to continue in any way. I just wanted to. If you want to grow your social media presence and learn to code, you're going to want to be consistent or it's going to take you twice as long to get where you want to be.

I made a lot of progress on the coding side of things during this challenge. Partly down to the push given by the challenge and it culminated in me finding my first role in the industry.

📝 5. It is a record of my progress

Making notes and keeping track of your development is a great way of seeing how far you've come and where you might want to go in the future. Every day you post a tweet talking about what you worked on for the day like you would if you were writing a diary. The good and the bad.

Having recently completed the challenge, it was interesting for me to look back through some of the days to see what I accomplished and also the things I struggled with. Below is a quick list of some of the things I worked on during the challenge.

• Built a full stack next.js serverless e-commerce website
• Designed and built a modern landing page
• Started my blog
• Worked on many different topics like 👇
  • Git
  • React
  • Data structures
  • TypeScript
  • Design with Figma
  • Testing
  • Several different styling libraries/frameworks

and so much more. Some of this I might not have started with. Or perhaps it might not have gone as well as it did without the push from the challenge. Things like my landing page design/build project and this blog your reading right now were inspired by the people I met and the quality of work they were producing.

🤔 6. Is it for you?

I would definitely recommend you to take on the challenge if you fall into one of two categories. Maybe like me, you want to join communities of other developers but you're not sure where to start or what content you want to be posting about. Or perhaps you're still new to web development and you want to challenge yourself and learn to code by staying consistent. If you fall into a different category and would like to take on the challenge, then by all means go ahead. Only you will know whether it's right for you.

Whatever it is there are obvious benefits to it which is why it is a very popular challenge over on Twitter. I can't say for sure that I would have put myself out there like I have since without it and I could have missed out on all the awesome things that have happened since.

Starting the challenge is the moment I can pinpoint as the catalyst for a lot of the amazing opportunities I've experienced since. This doesn't mean that starting the challenge is guaranteed to lead to great things. It's up to you to put in the hard work yourself. What it did do was open my eyes and push me to where I am today and I am very grateful for this.

Conclusion

Things would be different now for me if I hadn't started the challenge when I did. If you're currently taking on the challenge then let me about it!

If you would like to connect with me then you can find me @Kieran6dev. Feel free to send me a message anytime if you think I can help you with something.

Want another read 👉 I took part in #5amCoders! These are the benefits I saw from being productive earlier in the day

See you soon 👋

Routes can simply be created by adding a file into the /pages folder that is created for you when you bootstrap an app with create-next-app. Inside of here there is another folder called api. When you create a file inside of api it will be accessible at the route /api/.... But you won't be served with a page this time.

This is an API endpoint belonging to the server-side of your app and is intended to return data, not pages. Here we can write backend code using Node.js if we desire. You might be a bit hesitant about this especially if you come from the position of a front-end developer. This transition between one minute writing Node.js code on the server and the next minute writing react code in the client is a feature of Next.js. and it's awesome when you get going.

I'm here to introduce you to these API routes. Let's go 👏.

Content

1. Why should we use the /api routes

2. Our first API route

3. Request and Response

4. Dynamic Routes

5. What else might we use an API route for?

6. Typing API routes with TypeScript

7. API route configuration

You can check out the Next.js documentation yourself here 👉 Next.js

1. Why should we use the /api routes

A nice way of thinking about a Next.js API route is as a middle-man for your app. Time for an analogy! 😃

Consider a person called John who wants to send a letter to his friend Jane. Once Jane receives the letter she will send a reply back to John. But how do the letters get from one place to another? The Postman/Postwoman of course!

The Postman/Postwoman acts as the middleman. This person handles the logic of transporting the letters where they need to be and this is kind of what we do with Next.js API routes. Often we make a request to an API route with some data. This is like posting your mail into the letterbox.

Then behind the scenes, the post will go through things like sorting and manipulation before being sent to the other end (like an external API). When the person receives and replies to the letter, eventually the original sender will open the reply (response).

So if our API routes are sometimes also sending requests, you might ask something like this 👇

Why should I make a request to /api/posts and then from there make another request?

There are a few reasons why you might want to do this.

• You can access your environment variables safely with process.env on the server-side

• You can hide your interaction with some external provider by keeping it out of the client

• Maybe you have cookies you want to handle on the server

Instead of making a request to https://externalsite.com from the client we instead make the request to our API route api/... with a body of data if required. These routes can act as the go-between for our app to safely communicate between our client and our serverless requirements.

It should be noted that access to Next.js API routes is only accessible from the same origin unless configured otherwise with middleware such as CORS.

2. Our first API route

I'll start by setting up our project directory called next-api-routes with Next.js using the following command

npx create-next-app next-api-routes

Our first example will be a simple request for some data related to blog posts. I will hardcode the data inside a JSON file. Create a file called posts.json and place it at the root of your project alongside package.json and the rest. My data looks like this 👇

// posts.json
[
  {
    "id": "1",
    "title": "Ditch the dreaded <div />. Semantic HTML elements we should use instead"
  },
  {
    "id": "2",
    "title": "Monday motivation - How I got into code"
  },
  {
    "id": "3",
    "title": "How to setup path aliases for development with Next.js & Jest"
  }
]

Now create a file called posts in the api folder so we can hit this route with a request to /api/posts. You can delete the current hello.js file or remove its content and rename it. Inside the /api/posts file we have the following code 👇.

// pages/api/posts.js
import posts from "../../posts.json";

export default (req, res) => {
  res.status(200).json(posts);
}

Essentially our API routes are just functions. We have one default exported function per API route. Here we are also importing our hardcoded posts. The function receives two parameters req and res which are defined as the following.

• req - The request object based on the incoming HTTP message

• res - The response object based on the HTTP response of the server

We will explore the req and res objects in detail in the next section. You'll be familiar this these if you've worked with Node.js and Express before. Here we send back a response code of 200 indicating it was successful and we can chain this status with .json() response method to send back a JSON response of our posts. Since our list is hardcoded and imported we know it is going to be successful hence the 200 status code.

You can navigate in the browser to the route /api/posts and you should see a response like this 👇

and this is in JSON format. Of course this is just data, not a page. To use the data in our app we would need to send a request for it.

Now we have the route setup we are going to hit it from our app and access the data. We'll work out of the pages/index.js file for the purpose of these examples. The cool thing about Next.js is that we can choose exactly when we need access to this data. We can fetch in on the server using getServerSideProps() or getStaticProps(). We can alternatively fetch in on the client after the page loads. It depends on what the data is and what you want to do with it.

I'll show examples of both because it's very similar. Again you can remove the default markup of this file inside the return method.

First up we'll fetch it client-side on a button click like this 👇

// pages/index.js
import * as React from "react";

export default function Home() {

  const [ posts, setPosts ] = React.useState([]);

  const handleFetchPosts = async () => {
      const postsResponse = await fetch("/api/posts");
      const postsData = await postsResponse.json();
      setPosts(postsData);
  };

  return (
    <>
    <button onClick={handleFetchPosts}>Fetch Posts</button>
    <ul>
      {posts.map(({ id, title }) => (
        <li key={id}>{title}</li>
      ))}
    </ul>
    </>
  )
}

Or you could pre-render the page server-side like this 👇

// pages/index.js
import * as React from "react";

export default function Home({ posts }) {
  return (
    <ul>
      {posts.map(({ id, title }) => (
        <li key={id}>{title}</li>
      ))}
    </ul>
  )
}

export async function getServerSideProps() {
  const postsResponse = await fetch(process.env.BASE_URL + '/api/posts');
  const postsData = await postsResponse.json();

  return {
    props: {
      posts: postsData
    }
  }
}

These examples don't include error handling due to the fact we know the data exists. A few things to note in the server-side example. Here if you pass the same URL to the fetch function as the previous example you'll see this error 👇

To fix this we need to change it to an absolute path. Because we're on the server-side we can access our environment variables using proccess.env and I create a variable called BASE_URL. This variable holds the value http://localhost:3000 for now. If you were building an application to be deployed you would want this to be configurable based on the environment.

Once we have the data we return it through the props object and access it through the props of our home page. This time I removed the button and instead decide to pre-render the page with our data.

Checkout the Next.js documentation on getServerSideProps() if you need more information Next.js - getServerSideProps (Server-Side Rendering)

3. Request and Response

Next.js provides us with middleware built into API routes to parse the request.

• req.body - The request body where we send some data to our route

• req.cookies - Cookie object sent with the request

• req.query - URL query string object of the request

Let's take a look at some of the things we can access from the request. The following code is in our pages/index.js file and it will send a request to a route called user.js at /api/user with some data.

// pages/index.js
export default function Home() {

  const handleSubmission = async () => {
    const info = {
      name: "Kieran",
      age: 26
    }

    const res = await fetch("/api/user", {
      method: "POST",
      headers: {
        "Content-Type": "application/json"
      },
      body: JSON.stringify(info)
    });

    const data = await res.json();
    console.log(data) // { message: "success" }
  }

  return (
    <div>
      <button onClick={handleSubmission}>
        Hit Route
      </button>
    </div>
  )
}

All we are doing here is sending our request with our info object in the request body in JSON format. To do this we send a POST request with our data when we click the button.

Next up let's see what data we can access on the request. I have added a new API route at /api/user.js with the following code 👇

// pages/api/user.js
export default async function user(req, res) {
    console.log(req.body); // {"name":"Kieran","age":26}
    console.log(req.query) // {} in our example

    console.log(req.method); // POST
    console.log(req.headers.host); // localhost:3000
    console.log(req.url); // /api/user

    res.status(200).json({ message: "success" })
}

Don't forget to send a response back from your API routes like we do here with res.json(), otherwise you'll see this 👇

API resolved without sending a response for /api/user, this may result in stalled requests.

Above you'll see some of the things we can access on the request and the result of each in our example. If you log the request object to the console you will see a large amount of data returned. Don't forget that because this is running on the server, you won't be able to see this logged in the browser. You'll find it in your terminal instead.

Now let's take a look at the response. As we've previously explored, our API routes often act like middleware for our app between our client and external services. The general flow is like this 👇

1. Send a request to the API route

2. Do something with the request

3. Finish by returning a response

If you're familiar with Node.js and Express then the following will be familiar to you. Next.js provides methods on the res object that let us control how we return a response. Let's check them out 👇

1. res.status(statusCode) - Return a status code in the response headers

• 200's- Success

• 300's - Redirect

• 400's - Client errors

• 500's - Server errors

2. res.json(json) - Return a JSON response object

3. res.redirect([ status ], path) - Return a redirect with a status code

4. res.send(body) - Return the response body as a an object, string or buffer

As you've seen in previous examples we can chain these together to return a status code with some data such as res.status(500).json({ message: "Bad request" }); allowing us to better control our responses.

4. Dynamic Routes

In Next.js we can also create dynamic routes that match different queries.

Using our posts example from earlier, let's see an example of dynamic API routes. Create a directory called posts inside the api folder. Then create a file called [postId].js inside the posts directory.

We use the square bracket syntax for dynamic routes and pass in a parameter name of your choice You should end up with /api/posts/[postId].js. We have the following code inside this file 👇.

import posts from "../../../posts.json";

export default async (req, res) => {
    const post = posts.find(({ id }) => id === req.query.postId);

    if (post) {
        res.status(200).json({ message: "success", post });
    } else {
        res.status(400).json({ message: "post not found" });
    }
}

You can test this out in the browser by navigating to http://localhost:3000/api/posts/1. We can access the query using the middleware req.query as we've previously seen. Then we can use this to see if the article exists in our hardcoded posts based on the id we pass to the query.

If it is present, we send back a success response with the post. Otherwise we send back a not found status with a generic error message.

Here you can see the successful response in the browser 👇

and the fallback response 👇

5. What else might we use an API route for?

I wanted to share some real examples where you might use Next.js API routes. Recently I built a full-stack serverless e-commerce site using Next.js and these routes allowed me to create a dynamic site using these serverless functions.

I have an article focused on that site here - I built a full-stack serverless e-commerce site with Next.js. Here's an honest review of what I learned and how it might help you

The API routes served as the middle-man for my app's authentication, in this case using auth0. I created routes for handling login, logout, session, and more all without the need of a server.

I also have serverless functions for creating a checkout session using the payment platform Stripe and handling the creation of orders based on successful payments. The possibilities are endless!

6. Typing API routes with TypeScript

Recently I have been learning TypeScript so I wanted to quickly share an example of how you can type the request and response of an API route function. Using our previous posts example we can type it like this 👇

// pages/api/posts/[postId].js
import posts from "../../../posts.json";
import type { NextApiRequest, NextApiResponse } from "next";

type ResponseSuccessMessage = "success";
type ResponseFallbackMessage = "post not found";
interface Post {
    id: string;
    title: string;
}

interface PostSuccessResponse {
    message: ResponseSuccessMessage;
    post: Post;
}

interface PostFallbackResponse {
    message: ResponseFallbackMessage;
}

export default async (req: NextApiRequest, res: NextApiResponse<PostSuccessResponse | PostFallbackResponse>) => {
    const post = posts.find(({ id }) => id === req.query.postId);

    if (post) {
        res.status(200).json({ message: "success", post });
    } else {
        res.status(400).json({ message: "post not found" });
    }
}

7. API route configuration

Next.js also allows us to customize the configuration of the route in a couple of different ways. We do this by exporting a config object from the route like this 👇.

import posts from "../../posts.json";

export default (req: NextApiRequest, res: NextApiResponse) => {
  res.status(200).json(posts);
}

export const config = {
  api: {
    bodyParser: false, // set to true by default which parses request bodies
    externalResolver: true // sets whether the route is handled by something like Express 
  }
}

In most cases, this won't be necessary but it's useful to know it's there. One thing to note is that the default config is as follows 👇

export const config = {
  api: {
    bodyParser: {
      sizeLimit: "1mb",
    }
  }
}

This means bodyParser is enabled by default meaning that even if you don't include the Content-Type header in your request, the request body will still be parsed using the default config. If you set bodyParser to false you have to make sure to send the correct headers but I recommend leaving this set to true.

Conclusion

That is my introduction to Next.js API routes. I hope you enjoyed and if you did let me know about it here on Hashnode or @Kieran6dev where I'm always available.

I would love to write an article in the future where we build a small app using Next.js API routes including something like authentication or payments. Let me know if that interests you!

![](https://img.buymeacoffee.com/button-api/?text=Buy me a beer&emoji=🍺&slug=kieran6roberts&button_colour=FFDD00&font_colour=000000&font_family=Cookie&outline_colour=000000&coffee_colour=ffffff align="left")

Until next time 👋

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 👏.

Semantic Elements

1. <article>
2. <header>
3. <section>
4. <nav>
5. <main>
6. <aside>
7. <details> & <summary>
8. <figure> & <figcaption>
9. <blockquote>
10. <abbr>
11. <footer>

1. <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>

2. <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>

or

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

3. <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>

4. <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>

5. <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

6. <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>

7. <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>

8. <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>

9. <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>

10. <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>

11. <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>

or

<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 👋

I took this challenge very literally as a lot us did 😃.

Defining the target as being productive at 5am was a way for me to hold myself accountable. I had a specific target and I was going to stick to it from Monday to Friday. Every morning I set my alarms between 4:45am and 5:00am and managed to get up and be productive in my own way.

Now that the week is over I want to share my experiences with you. I saw a lot of benefits from the challenge to myself that goes beyond the code.

Don't forget you can join the early risers yourself if you would like to. Check out @nitecoda1 and @andresuriegas on Twitter as the guys that inspired me to take part!

Also go and check out this awesome article by another participant in last week's #5amCoders What I learned from waking up at 5AM - [Nicole Analise Cox]

So let's find out what I learned from the challenge and how it could be helpful to you 👏.

What I learned

1. The guilt from doing stuff non-code related was gone
2. You have more free time
3. Routine is important
4. The community support is awesome!
5. You have to get over the hump
6. Waking up is not the problem. Going to sleep at the right time is!
7. It is not for everyone
8. Will I stick to it?

1. The guilt from doing stuff non-code related was gone

You might have felt this one yourself. Since learning to code I have been determined to learn as much as I can in the shortest possible time. The downside of this is that when I'm not coding I almost feel guilty about it. My thoughts would something like this 👇

Instead of watching this movie I could finish a certain part of my project.

And this is not a healthy way to live. This was the first and best thing I learned during this challenge. By waking up early and tackling the most difficult tasks first, I have all of my required work finished before I even eat breakfast 😃.

Between 5am and 8am I would finish my intensive coding tasks and for the rest of the day I would feel completely free to do whatever I pleased. It's and incredible feeling!

2. You have more free time

Because my required tasks were finished by breakfast I suddenly had a lot more free time on my hands. This allowed me to get back to some of my other hobbies and interests.

I have been learning to play guitar on and off for the last couple of years and this week I found myself playing more than I have been doing recently. On Wednesday I also spent the whole day outside hiking which I loved.

I could happily spend time doing other things I love thinking I had earned it.

It was also beneficial to my health. This challenge helped me get back into exercising after months of procrastination. The release I get from exercising helps keep my mental and physical health in a good place and it's likely I wouldn't have got back into it without the push from #5amCoders.

3. Routine is important

For a lot of people a routine is essential. It helps you stay consistent with your task which is massively important. #5amCoders gave me a clear and defined routine that I could hold myself accountable to. Mine looked something like this 👇

• 5am to 8am - Intensive code related tasks
• 8am to 10am - Workout & breakfast
• 10am onwards - Anything I wanted

I should note that I'm currently spending time at home with the family after returning home from travel. I'm not employed in a full time role otherwise this routine might look a little different 😅.

Check out this article that explains my story from the last two years and how I got into code - Monday motivation - How I got into code.

I could spend the rest of the day doing whatever I liked which included everything from relaxing with family and my girlfriend to writing for you and me here!

4. The community support is awesome!

Just check out this post here which includes a lot of the people taking part in #5amCoders last week 👇

It was awesome having so many in the same situation supporting each other. Sometimes we all need a little help from friends.

The major benefit of this is the sense of community accountability. By putting it out there for others to see you are reducing the possibility of changing your mind. If you're the only person you let in on the challenge it is really easy to talk yourself out of it.

If you share the fact you want to take part with others then you will might feel obliged to go further with it and the community will help you get there 🙂.

5. You have to get over the hump

My hump was on Wednesday. What I mean by this is that it was my most difficult day trying to wake up and be productive. It was the final hill I had to climb. This was the only day where I struggled to get out of bed. I have three alarms and on this day I woke up a minute before 5am on the very last alarm.

I must have turned the first two off 😅.

For that morning I struggled to get much work done because I found it hard to concentrate. Though after this day I definitely noticed a change. I was also not the only person who struggled on this day so I believe there is a turning point that you need to push through.

The next two mornings I was far less tired in the early part of the morning and my energy would last further into the day. I managed to be quite productive on both Thursday and Friday.

6. Waking up is not the problem. Going to sleep at the right time is!

For me the difficult part of the challenge is not waking up so early. I could set a few alarms and usually jump straight out of bed. However making sure you go to bed at the right time was the challenge because that affects how you will feel in the morning.

We have many distractions in modern day life. Everything from our mobile phones, laptops, computers and televisions. They all contribute to making your sleep more difficult than it otherwise would be. I found this out on Wednesday morning when I stayed up a little too long staring at screens the night before. This may have contributed to my hump day but I think it would have happened regardless.

By staying up to late you can still get yourself out of bed if you really want to but you'll feel terrible because of it. Concentration will be difficult and it makes the whole process less valuable to you.

For the most part I tried to tire myself out during the day mostly through exercise so that by 7pm I was already tired and by 9pm I was asleep 😴. I think it definitely helped me.

7. It is not for everyone

I'll admit that it is not suited to everyone. We are all different and what works for one might not work for another. It is up to you as an individual to try things out and make up your own mind.

I've seen many developers say they like coding at night. Some do it because their commitments leave them with no other choice. But if you are a morning person or would like to become one then consider giving it a go because it will do wonders for you and your productivity ✌.

8. Will I stick to it?

The magic question ✨

Because of all the benefits I've listed above it would be strange if I reverted back to my old ways right? For the last couple of months I have been waking up much later and usually don't get started with my work until the end of the morning.

I am definitely going to be sticking to an early routine that allows me to complete my intensive tasks early. However this week I'm going to try out a slightly later time so I can see how my body reacts.

This week I am going to be waking up for 6am which still allows me plenty of time to get work done early. Maybe I'll realize that I actually prefer the 5am start.

There's only one way to find out!

Conclusion

If you are interested in trying out the early morning routine with others then check out @nitecoda1 on Twitter or search for #5amCoders. You don't have to do it alone!

I hope you enjoyed the article. If you did consider leaving some likes ❤ or let me know about it in the comments 💬. You can also connect with me @Kieran6dev where I'm always active.

See you soon 👋

SEO stands for Search Engine Optimization, which is the practice of increasing the quantity and quality of traffic to your website through organic search engine results. - Moz.com

In order to tackle the topic head on I used my portfolio as a project to apply what I was learning into practice. I had already built the portfolio in its current state around two months prior with only minor fixes since. You can check it out below if you'd like.

My live web-developer portfolio - kieranroberts.dev

The first step would be to test the site in its current state. I started by running it through various free SEO checkers accessible through a simple search and found that there were a lot of issues I was largely unaware of. This is a good representation of my initial score from one of the tests 👇

After various changes and improvements that were mostly simple fixes I was very happy with my results. Below you can one of the tests carried out after making improvement 👇

and one more

I still have some improvements to make but it's a step in the right direction ✔.

Before we begin I should clarify this is not a detailed tutorial on SEO topics because I am no expert and I'm still very much learning myself. Rather it is an overlook of some of the things I did to improve my project that you will be able to explore yourself when you've finished with the article.

Let's get into how I did it, what I learned and some useful resources to help you do the same 👏.

Content

1. Testing using basic free SEO tests
2. On-page SEO improvements
   • 301 Redirects
   • Page Content
   • Sitemap & Robots
   • Meta Tags & Keywords
3. Conclusion

Testing using basic free SEO tests

The first step was to test out the current state of the site SEO so I could see what needed improvement. You can do this using many of the free SEO checkers available with a simple search. If you type 'seo test' or 'seo checker' into google you'll find a bunch of them 👏. All you need to do is to pass your domain into the input provided and sit back while it does the checking for you.

Each of them seemed to suggest different factors to improve so I recommend you use more than one to cover all the bases. I'll list some of the ones I tried out below which gave me actionable feedback to work on.

• Seobility - SEO Checker
• SEO Site Checkup
• SEOptimer
• IONOS - SEO Check

On-page SEO improvements

At this stage I was receiving pretty poor results as you saw above. Around an average of about 65/100 between the different tests. Before we get into the changes I made let's quickly clear up the difference between on-page SEO and off-page SEO.

On-page SEO

Things you can do to help your site's SEO directly on your website to help search engine robots understand and interpret your page. We will focus on this type of SEO in this article!

Off-page SEO

This refers to things you can do to help your site's SEO away from your site such as increasing the quantity of quality backlinks to your site. Check out this for more information Moz - Off-Page SEO.

Now we know i was working on the on-page SEO let's find out what changes I made 👏.

301 Redirects

These redirects were something I had never considered before. So what's the problem 🤔? Let me show you an example.

Consider my domain available at https://kieranroberts.dev. What would happen if someone searched for the subdomains https://www.kieranroberts.dev or www.kieranroberts.dev which users might do and we didn't set up a redirect for this?

Well your potential users will be left high and dry potentially on a domain that does not exist or perhaps on a page that contains content that has expired!

I want to prefer the domain https://kieranroberts because this and www.kieranroberts.dev are different domains.

So how do we correct this?

✔Changes I made

I had not setup these redirects at all and it was the first thing I tackled.

Before we get started it is important to note that my site is hosted with Vercel and the domain is registered with Namecheap.

By logging in with Namecheap and clicking on on the manage button of your domain, navigate into Advanced DNS settings. Here you can manage you domain's host records.

I began by setting up the subdomain for the www. variant as you can see below 👇

I pass in the value cname.vercel-dns.com provided by Vercel which you can find more information on here Vercel - Custom Domains.

Next up I need to go into my Vercel project dashboard and setup our new sub-domain. Here you can add domains to your project and I add my recently created www. subdomain. Vercel allows you to specify a main domain and any redirects to setup from one to another.

To find this setting navigate from your dashboard into the project. Then click settings - domains and you will see this list for your project.

Here you can see kieranroberts.dev specified as the main domain and any searches prefaced by www. will now be redirected to this main domain. Now we should satisfy this simple redirect 👇.

and our users will be happy 😃.

Page Content

Another major contributor to your on-page SEO relates to the quality of your page content. OK but what is page content? This considers multiple factors based on the content on your page many of which I did not consider when building my site.

Some of the factors include 👇

• Content relevance
• Descriptive image alts included
• Suitable headings
• Suitable number of internal & external links
• Use of keywords
• Mobile Optimization
• Word count and sentence length

and much more. If you run a site through the tests you will see these factors recommended to you with improvements.

✔Changes I made

Overall the page content of the site was in reasonable shape and there were not many changes I had to make. The quantity of my external and internal links was acceptable and there was enough relevant content using keywords when suitable.

One major issue I did find however was down to missing alt text on my logo images. I have some logo images on my site representing the stack choice for my projects which looks like this 👇.

The SEO check spotted the fact I had an error with the alt text for these logos and I have a lot of them on the home page. This is a big problem because alt text for images is extremely important for your site accessibility. If missing it will negatively impact the SEO of your site. Fortunately is was a simple fix 👏.

Sitemap & Robots

This is not some crime fighting duo as the title suggests 😂 .

They are two important parts of giving more information to the browsers in relation to your site. By adding a robots.txt file to the root of our project we can instruct the browser crawlers to which parts of our site we want them to index.

Check out this article for more information Yoast - The ultimate guide to robots.txt.

The sitemap is a file also placed at the root that includes information about the pages/files of your site. This file helps the search engine crawl your site which may be difficult if your working with a very large site and so could very important.

Check out Google Search Central for detailed information on sitemaps.

✔Changes I made

My portfolio only includes 6 pages and so the search engines could probably index the site by following the links but I wanted to include basic versions of each mostly as a learning exercise. Initially I was missing both of these files. Since I am still in the process of learning many of these topics, I searched for information on sitemaps and found that there are free online sitemap generators which will create a basic sitemap for you.

This is the one I used xml - sitemaps.com which again is just a case of passing in your domain and letting it do the work. In order to make the sitemap available to the search engine you can place it somewhere in the robots.txt file like this 👇

Sitemap: https://kieranroberts.dev/sitemap.xml

After creating a robots.txt file this is exactly what I did. Similarly to the sitemap it is possible that the robots.txt file is not required for a site like this. I don't have any pages that I would want to block from being indexed such as a login page for example. Even so I wanted to learn and create these files now in case the site ever grows into something larger.

I'm not going to include these here because I'm still unsure of the optimal setup for the robots file. For now it is allowing the search engine crawlers access to all pages as is the default.

The last thing I want is to share a potentially problematic setup that cause major problems so you can use the links provided to do some research you like 🙂.

This is another useful article about the robots.txt file backlinko - Technical SEO - Robots.txt

Meta Tags & Keywords

It's likely that you've used plenty of meta tags before. Meta tags describe the content of your site in many different possible ways. As well as meta tags we also have the title element and in combination with the <meta name="description" content="..." /> tag they provide the information you see when you search for something in the search engine like this 👇

Other important tags include the the open graph meta tags (og) which allow you to control the content when you share the site in places like Twitter and Facebook. Twitter also has it own tags such as twitter:title but it will use the og tags instead if they are not present.

There is a very useful site available here metatags.io that allows you to preview your site's meta tags, edit them and generate new ones.

✔Changes I made

First of all I was able to spot an issue with my social sharing image which was not displaying correctly. This was because I did not place the image in the correct directory. After moving it to the root of the project all was good!

Next up I wanted to improve the quality of my title and description tags for each individual page after suggestions from a few of the tests that included 👇

• Adding site keywords to title and description
• Descriptive title which accurately represents what is on the page
• Title and description have optimal character lengths

After changes I saw some score improvements although I could still add certain keywords which are currently not used. Finding the right balance of including enough keywords without overdoing it seems tricky

Take a look at this for in depth analysis on the title and description tags Wordtracker - Titles and descriptions in SEO

Here is the current state of some of my meta tags 👇

Note: this is in React with Next.js using a custom head component where the title and description is passed in as props for the different pages.

Conclusion

I'm still in the process of learning about SEO so if you have any pointers feel free to share them. There are still improvements I know I can make and I look forward it.

I hope you were able to learn something and if you enjoyed please let me know about it.

You can find me @Kieran6dev on twitter and if you would like another read check out this article about my personal story of how I got into code below.

Next read - Monday motivation. How I got into code

Until next time 👋

I'll keep it short and sweet because otherwise there would be a lot to tell and I could on for days 😄.

Here's my personal story of how I got into coding!

My Short Story

1. Life before code

2. I had tried and failed with coding before

3. Making progress

4. The end of my travels

5. And to today

Life before code

I was an engineering graduate with a lost passion for the subject. In wasn't until my final masters year that I admitted this to myself but I persevered and graduated well. I no longer wanted to be an engineer so I took some time out to travel and have some fun 🤞.

In April 2019 I left the UK to go to New Zealand on a working holiday visa. I packed my things and went alone. It was the best time of my life and I was fortunate to make so many awesome memories and a few less fortunate ones 😅.

Some of the highlights include:

• Almost leaving behind my phone & wallet in Changi Airport security

• Tried surfing and ended up in the doctor's office getting stitches in my head

• Hiked up as many peaks as possible

• Worked many cool jobs including:

  1. Hostel Receptionist 👨‍💼

  2. Waiter 💁‍♂️

  3. Maitre d' 🤵

  4. Pine tree orchard worker 🌲

  5. Tomato glasshouse worker 🍅

  6. Kiwifruit picking 🥝

I had been working/traveling there for almost a full year when Covid hit. Just before this I started to think about what I wanted to do when I returned. I didn't want to be an electronic engineer anymore. That much I knew.

I'm not sure exactly how it happened but I stumbled on a list of common jobs done by remote workers. In there was web-development which from what I remember was talking about Wordpress.

After a little more digging I thought it looked interesting and decided to try out front-end development for myself. At this point I didn't think it was a realistic goal to be honest. Started with some HTML and I got hooked 😄.

I had tried and failed with coding before

At university our engineering department was a joint department along with computer science. They gave us 2 computer science modules in our first year. Java basics in semester one and C++ basics in semester two.

❌I failed the C++ module and narrowly passed Java

I hated it at the time and it showed in my results. This failure was a big motivation for me this time around and I hope if helps you to know that it's OK to fail.

Just try again! ✔

Making progress

Fortunately I had taken my laptop with me on my travels and so three weeks before New Zealand went into lockdown I started with HTML. I loved it and didn't stop for the next 2 months.

I lived through lockdown in a hostel learning to code for what seemed like 6-8 hours a day. I saw an opportunity to use my time productively so I just went for it. I was thinking 👇

I'm not going to get a better chance to make this change and give it all my time so let's go!

My girlfriend who I met on my travels 8 months prior was incredibly supportive as I made my way from HTML to CSS to JavaScript and I felt like I managed to cover a lot during this time. After lockdown was up we moved on to look for more full-time work which was needed since it was almost 5 months since the last paycheck.

For the next almost 4 months I was working full time from 8 in the morning to 5 in the afternoon on weekdays and part time for an hour or two afterwards on hostel reception. I didn't have much time to code and so I did what I could 🙂.

I would wake up at 5am every weekday to get two hours of code in before I left because I was afraid that if I stopped that I wouldn't come back. I'm so happy I did this because it meant I was able to keep some consistency and managed to retain a lot of the things I learned up to that point.

Some form of consistency is crucial if you're going to be successful.

During this time I also experienced some problems with my laptop and through my own stupid fault I lost all of my practice projects and code from the first 4 months of learning. I didn't back things up and I hadn't started using Github yet. My laptop went down for around three months until I could get it fixed and my girlfriend was kind enough to let me use hers.

Despite the problems I kept on going!

The end of my travels

At the end of September our visa extensions were up and we were forced to say goodbye to New Zealand. If it was our choice we would have loved to continue our travels for a bit longer and see other countries. But it wasn't to be!

We headed back home in what felt like an apocalyptic movie. Transiting through Brisbane Airport I have never experienced such a strange and eerily quiet atmosphere. I went to stay with my girlfriends family for a few months and this is when my coding started to take off 🚀. Now I was beginning to understand things in greater depth.

I got a far better understanding of JavaScript and started learning React, Next.js and several other tools and libraries. I was on fire for these four months. It was my mission to build my own projects including a portfolio so I would have the option of applying for roles.

It was like my own personal 4 month bootcamp 😄.

Unfortunately we also somehow caught Covid and tested positive three days before our flight back to the UK meaning I was forced to overstay my allowed time in Croatia. Fortunately the only damage was to our bank accounts and all else was well.

A few weeks later I made it home safe and healthy two years after leaving and now with a new career path and a love for coding!

And to today

Now over a year since I started coding and I still haven't had a desk to work at 😂. I've learned largely on my travels usually from the comfort of a bed or a couch with my laptop. All because I love what I do.

I'm currently spending some time at home with the family and after this I'll be applying for my first web-development role. I was fortunate to have so much free time to put all my efforts into it and I'm inspired by others who are learning while maintaining full time work and other commitments. You're the real hero 😉.

Now you know a little more about me feel free to introduce yourself below or share something about you. I'd love to get to know you all a little better.

If you would like another read check out my article where I explain in steps how I go about writing articles for my blog My process for writing blog articles with actionable steps you can follow.

![](https://img.buymeacoffee.com/button-api/?text=Buy me a beer&emoji=🍺&slug=kieran6roberts&button_colour=BD5FFF&font_colour=ffffff&font_family=Poppins&outline_colour=000000&coffee_colour=FFDD00 align="left")

Thanks for reading!! 👋

Next.js

Configure the baseUrl in the tsconfig/jsconfig along with your desired paths:

// tsconfig/jsconfig.json
{
  "compilerOptions": {
    "@/*": ["./src/*"]
  }
}

Jest

Install jest and jest-environment-jsdom:

pnpm install -D jest jest-environment-jsdom

Generate a Jest configuration:

pnpm create jest@latest

Update the jest config file to use next/jest:

import type { Config } from 'jest'
import nextJest from 'next/jest.js'

const createJestConfig = nextJest({
  dir: './',
})

const config: Config = {
  coverageProvider: 'v8',
  testEnvironment: 'jsdom',
}

export default createJestConfig(config)

Finally match the paths option from your tsconfig/jsconfig to the Jest moduleNameMapper:

import type { Config } from 'jest'
import nextJest from 'next/jest.js'

const createJestConfig = nextJest({
  dir: './',
})

const config: Config = {
  coverageProvider: 'v8',
  testEnvironment: 'jsdom',
  moduleNameMapper: {
    // Your desired paths
    "^@/src(.*)$": "<rootDir>/src/$1",
  },
}

export default createJestConfig(config)

Original article

I wanted to share how you can setup path aliases for your imports. Sometimes you end up with various levels of file nesting and this can get messy fast.

Fortunately for us both Next.js and Jest support adding path aliases so we don't end up with something like this 👇

import Component from "../../../Component/Component";

For any medium to large react project you will have realized that due to the component nature of the library we end up doing a lot of importing. Let's find out how we can change the above into this 👇

import Component from "@/Component/Component";

for both development in Next.js and for our tests using the test Framework Jest.

Next.js

Step 1 - Create a Next app

I'll start with a brand new project so you can see all the steps. For this I will create a new Next application using create-next-app so we can get up and running quickly. Start by running npx create-next-app. This is the basic file structure that comes with create-next-app 👇.

Step 2 - Create some files to import

Next I'm going to create a src folder which is where I normally store the apps components, hooks etc. Let's add some files to our src folder to simulate how a real project might look 👇 .

Here I have created the following files

• Header.js and Button.js components inside a components folder

• __tests__ folder with our component test files

• useStorage.js hook inside a hooks folder

• config.js inside a lib folder

The contents of the files is not important. As long as you export something from your components which I will show you in a second.

Step 3 - Specify our path aliases

First we need to create a jsconfig.json file (or tsconfig.json if you're using TypeScript) and setup our path aliases. My setup looks like this 👇.

Here we can specify a base url that we start our import from. Commonly you will see the root . specified.

Next we can specify path aliases for our paths to the different folder locations. paths is an object where we start with our path alias and assign it an array of paths. A common syntax of alias is in the format "@/fileName/" but you can use anything you'd like.

Let's take our components alias as an example. We are saying we want to match the alias "@/components/" to the path src/components/ folder.

Step 4 - Checking that our aliases work

Now let's add some basic code to our components:

and the header is the same except it exports a <h2 /> tag 🙂. We can import them into other pages/components using the path aliases like this 👇.

And to show you everything is working as expected in the browser.

If we had code in our other files that we created inside our hooks and lib files we could import them like this:

Of course we don't have anything in there but I wanted to show this is how you would import from those places.

Jest

Step 1 - Install and configure the necessary files

I wanted to add this extra step for two reasons

1. You should be testing your apps

2. It's good to keep your imports consistent across development code and tests

First let's download the packages we need to work with Jest. I will install the following packages:

• jest

• babel-jest

jest if the primary package we need to install in order to use the Jest testing framework. While babel-jestwill help transform our code so we can include things like ES modules import syntax in our test files.

We also have to configure a .babelrc file with the following setup 👇

What we are doing here is telling babel to use the custom preset for Next.js.

Next I'll add a test script to the package.json file so we can run our test suites like this 👇

Step 2 - Add our jest.config.js

Finally we can now get on to our aliases in Jest 👏. We first need to create a jest.config.js file. There are a couple of options we will pass in here and it looks something like this 👇.

The first thing we do is use the testPathIgonrePattern which is defined as an array of strings that specify which paths we would like to skip when testing. Here we include the node_modules directory and the .next directory which contains our build files.

We don't want Jest looking in these directories for tests and we specify these paths starting at the root <rootDir>.

Next comes our path aliases. We need to use the moduleNameMapper property to map our aliases. It is a map of regular expressions and in this case we setup our three current aliases of @/components @/hooks and @/lib.

You can do this for any path you are likely to be importing regularly. If you wanted to move on to integration tests and import you pages into tests you could do the same for example @/page.

The order in which you setup these aliases could matter however. These patterns are checked by Jest from top to bottom therefore you have more specific rules you should include them first.

For more information check out the Jest - Configuring Jest.

Now if we add an empty test block to one of our files and attempt the import with the alias we won't receive any errors after running out test script. Our imports are now working as expected in Jest ✔.

Conclusion

Set up path aliases for cleaner imports in Next.js and Jest by configuring the baseUrl and paths in your tsconfig/jsconfig.json. For Jest, install necessary packages, configure Babel, and set up a jest.config.js file with moduleNameMapper to map aliases for consistent imports across development and tests.

I thought 'time for a change!' 👏.

I have always been interested in art & design and I loved it at school. So I thought I could apply this using Figma. First I would design a desktop landing page for a fictional Software As A Service (SaaS) product with Figma and then build it with code.

I'm not saying you need to go out and put all of your focus on web-design as a developer. However a little knowledge will make you a better developer. If you start working in the industry it is possible you'll end up working with a web designer.

This means you'll start developing to satisfy some design right? 🙂

All of this got me thinking about the benefits of learning a little design for a developer. Let's explore these benefits and the project that inspired them.

My Figma landing page project

First let me share the deployed project. This is the hero page at desktop size 👇

and part of the featured services section 👇.

I wanted to keep the stack simple. No need for any complicated frameworks here. It is built with 👇

• Figma for design

• HTML

• SCSS

• Vanilla JS (Not required. Site functions the same without it)

• Snowpack

Live site is available here 👉kieran-sass-landing.netlify.app

Code is available here 👉 github repo

And the lighthouse scores 👇.

I still have a few improvements to make. These include:

• Reducing font sizes

• Altering the hero content

• Filling some of the whitespace in the features section after hero

• Maybe some subtle animations

Let me explain why the benefits you will see with a little design knowledge and how working from design improved my development efficiency 👏.

Content

1. You'll shorten your development time by using a design tool

2. Your project will look much better from the first version

3. You get practice for when you work with designers

4. Your eye for detail will improve

5. You start learning a new skill

6. Maybe your a better designer than developer

1.) You'll shorten your development time by using a design tool

If you're at least a little familiar with the basics of your design tool you should be able to speed up your development time. It took me a couple of hours to get accustomed to Figma before I started on the project.

I'm definitely no expert with design or Figma but I was quickly able to throw things on the page and piece something together. I was surprised at how fast I was able to do this and that it actually looked pretty good 😃. This couple of hours I spent designing the landing page saved me so much more time in development.

It is much easier to build when you have a full design to reference. I was able to visualize the different components I had meaning I could group common styles together in advance.

You will completely avoid situations where you decide to revert changes and lose potentially hours worth of work. I found it to be much more effective having my design side-by-side with the code and I don't ever think I can go back for any significant project 👏.

2.) Your project will look better from the first version

Leading on from the previous point your project UI will be much improved from the start. Trying out more complex designs is much quicker inside Figma. You can create all kinds of different shapes in seconds and move things around at will.

In previous projects the first versions of my UI design were pretty poor. I can't tell you how many times I've changed things around in my portfolio. Much of this could have been avoided if I started with a design in mind.

Be honest, how many times have you changed around your portfolio design? 😄

And your UI is vitally important especially if you expect to retain users on your site. Bad UI is one of my biggest turn offs for a website and spending a little time working out your design first will pay off later 😃.

3.) You get practice for when you work with designers

It is likely that at some point you will end up working with a web-designer. Having a little design knowledge will help you provide meaningful feedback and suggest changes etc.

Sometimes things that seem good in design doesn't translate well into code. Maybe it's inefficient or negatively affects other parts of the site. Whatever it is being able to recognize this is a useful skill to have to avoid losing hours of progress.

4.) Your eye for detail will improve

I found that creating a design from scratch focused my eye for detail. You are forced to ensure that every item is aligned as it should be and you'll start noticing when things are not. Because you don't have to write the code immediately there are less distractions and you can focus on one element at a time.

I realized I would focus in on factors like colors, typography and spacing making sure everything was exactly as I wanted and although not perfect it is a hell of a lot better that it otherwise would have been.

5.) You start learning a new skill

As developers we thrive on learning new skills. For me it's one of the biggest motivations because I love learning new things. Web-design is a skill that ties in closely with development. They complement each other 🤝.

If you think about it every time you build a project that includes a front-end you will be working with design whether you use a design tool or work in the browser.

It is very possible that one day you might be working on a solo project. Maybe it's some service that you intend to run as business. If this is the case you'll want to make sure your design is as good as it can possibly be because a bad UI will not get you anywhere.

6.) Maybe your a better designer than developer

This one is a stretch but you never know 😉. Maybe you realize you prefer design. It takes very little time to at least try it out and it will definitely make you are more well rounded developer.

Conclusion

I really loved this project! Creating the design was a lot of fun and actually a lot faster than I imagined. It's not perfect nor near the level of a designer but it's something I'm proud of 😄.

I will absolutely be using a design tool from now on going into personal projects after seeing the benefits to my work.

If you enjoyed the article please leave a like or let me know about it @Kieran6dev. I really love hearing your thoughts and comments.

Until next time 👋.

![](https://img.buymeacoffee.com/button-api/?text=Buy me a beer&emoji=🍺&slug=kieran6roberts&button_colour=BD5FFF&font_colour=ffffff&font_family=Poppins&outline_colour=000000&coffee_colour=FFDD00 align="left")