DEV Community: Will Holmes

Migrating to NextJs 13

Will Holmes — Tue, 08 Nov 2022 12:42:26 +0000

Introduction

With all the buzz around NextJS 13 recently, I decided to take the opportunity to upgrade my personal website from 12 to 13.

The current setup is that I have a NextJS 12 app which serves a single page. It makes use of getServerSideProps to fetch data relating to my latest blog posts and my latest packages that I have published. It's pretty simple really and does the job for what I need right now.

The Migration Process

As part of this upgrade I wanted to give a shot at moving to the new app directory structure.

Firstly you have to run some updates to your package versions:

npm i next@latest react@latest react-dom@latest eslint-config-next@latest
# or
yarn upgrade next react react-dom eslint-config-next --latest
# or
pnpm up next react react-dom eslint-config-next --latest

The above is taken from Vercel's upgrade page.

Secondly you need to adjust your next.config.js to include the following code block to enable app structure routing:

const nextConfig = {
  experimental: {
    appDir: true,
  },
};

Once this has been done you then need to start migrating the different parts affected by the major bump. You can view them here at Vercel's hidden beta upgrade page which is frustratingly hard to find.

The most major parts to the upgrade that I found were:

Components are now react-server-components by default unless you specify use client at the top of your file. This can cause breakages in existing code. Previous hooks such as useRouter() have been replaced and the new ones are only available in client components.
The folder structure for routing. See a comparison below.

NextJS 12

project
│   
└───/pages
   │   index.tsx
   │   projects.tsx
   └───/api
       │   hello-world.ts

vs

NextJS 13

project
│   
└───/app
    │   page.tsx (represents '/' route)
    └───/projects
        │   page.tsx (represents '/projects' route)
└───/pages
   └───/api (api routes are still in a pages folder)
       │   hello-world.ts

Layouts have changed. You can share layouts between routes really easily or just have your normal layout at root. Layouts now just take a children prop typed as React.ReactNode. No typings of component and page props.
You do not need a <head> section inside of your layout. This is done via a head.tsx file which contains all the declarations of your head tags etc.
Caching requests with fetch inside of pages is so easy and code looks a lot cleaner than the old getServerSideProps().

fetch(url, { next: { revalidate 60 } }); // 60 second cache

If you run into unhelpful errors then you will most likely struggle to find answers to your issues via Google. But that's due to the nature of new technology!
<Image /> tag has been upgraded - but you can revert to the old version by changing your import to something like this import Image from 'next/legacy/image';. I had to due to some errors that I ran into during my upgrade.
<Link /> tag now renders an <a> tag by default. So you no longer need to wrap an a tag inside of a Link tag.
No changes to api routes. They stay inside of the pages directory. Which I was surprised at, I hope this changes soon!

Deploying to Netlify

This was... painful to say the least.

Documentation isn't well presented and easily accessible. If you wish to use the new NextJS app structure, it is currently part of an extended version of their plugin to enable it for deployments.

Ensure you upgrade @netlify/plugin-nextjs to this:

"@netlify/plugin-nextjs": "^4.28.4-appdir.0",

Your existing .toml setup should be fine as it is.

I also found that running the build locally and then serving it and testing the build was absolutely fine. But when deployed to netlify I got a 500. Turns out the issue was because there was an import of next/head which isn't used anymore and doesn't play nicely when running inside of netlify.

To help others with this in the future, below is a link of references that I found helpful when migrating my app:

https://nextjs.org/docs/upgrading - Vercels snapshot update of upgrading.
https://beta.nextjs.org/docs/upgrade-guide - Vercels in-depth (kinda) guide upgrading.
https://www.netlify.com/blog/deploy-nextjs-13/ - Netlify's blog post around migrating to NextJS 13.

Overall

I spent a great deal of time migrating due to little gotcha's here and there. I'm happy it's done and I can test the new features it provides. But if my experience is anything to go by, I would allow a fair amount of time to do this with due care and attention. But maybe it was my late night coding brain that caused me to be so slow at upgrading.

Thanks for reading!👋

Multi Nested Dynamic Routes in NextJs

Will Holmes — Wed, 20 Jul 2022 20:40:27 +0000

Recently i've been working on a web app that im building in NextJs along side a lot of other technologies (via create-t3-app). However, I came across a problem that I could not easily solve with some googling in the space of 15/20 minutes. So I thought that I would share my problem and solution, which will hopefully help others not go through the endless browsing of stackoverflow results as I did.

The Problem:

I want to have multiple nested dynamic routes in my NextJs app.
So that I can build routes like:

'/product-catalog/123/product/1'

Now before I carry on with my solution, i'd like to add that basic dynamic routing is so easy.

All you have to do is have a folder structure like so:

- pages/
-- product-catalog/
--- [productcatalogid].tsx

This would produce the route:

/product-catalog/123
(123 being the productcatalogid parameter)

However, moving to multiple nested routes isn't available using the same principle. I.e. a folder structure like so:

- pages/
-- product-catalog/
--- [productcatalogid].tsx
---- product/
----- [productid].tsx

The above will simply result in a 404 everytime you go to request the page.

The solution:

Simply implementing a folder structure like so:

- pages/
-- product-catalog/
--- index.tsx
---- product/
----- [productid].tsx

Seems to do the job nicely when dealing with multiple dynamic routes.

I hope this helped! For more information see the video that I found the solution on: https://www.youtube.com/watch?v=nfAxNTmme64

A UseDarkMode react hook for everyone!

Will Holmes — Mon, 23 May 2022 09:13:26 +0000

So a while ago I came across an issue whilst developing.

I was creating a solution in nextjs with typescript and using tailwind to help with my css.

Tailwind out of the box provides dark mode support for different styling really easily by doing the following:

<div class='bg-white dark:bg-black'>Hello World </div>

However, I needed to know when the user was in dark mode within my react application to change other parts to the system. So I began looking through npm for another solution, but with little luck I decided to take how tailwind looks for dark mode and put it into a react hook.

This is where useDarkMode comes into play. Initially I created this inside of the repository that I was working on at the time but after proving that it works, I realized it would soon be something that could help a lot of other developers.

The package also comes with types so for those using typescript you can ensure type safety and, those who aren't well... that's fine too!

So I created a new repository and published it to npm: https://www.npmjs.com/package/use-dark-mode-ts.

It's really easy and simple to use, below is a code snippet:

import { useDarkMode } from 'use-dark-mode-ts';

const ExampleComponent = () => {
    const isDarkMode = useDarkMode();

    return (
        <>
            {
                isDarkMode
                ? (<div>I am in dark mode </div>)
                : (<div>I am not in dark mode </div>)
            }
        </>
    )
}

Now by no means is it perfect and those with more experience in this area might be able to help contribute to make it even slicker. But for now, this is where I have got to and at the time of writing it has exploded with 4.2k weekly downloads.

I hope it helps as many of you as possible!

Feature Flags in Next.JS

Will Holmes — Fri, 25 Mar 2022 12:57:51 +0000

Feature flags are great, they are also even better when the developer experience of integrating and using them is easy.

With lots of choice available today on the market I wanted to find a solution that worked well for developers who build projects on the side and specifically in Next.JS.

So that lead me to search for a tool which ticked the following boxes:

It has a gracious free tier
Easy integration into my project
Is small in size (don't want to be bloating projects).

This is where I discovered a tool which ticked all of them.

Introducing... HappyKit

I did some research on this tool and implemented it into my main pet project that I am working on right now and I have been blown away.

Firstly, it's npm package is both easy to use and small in size.

Less than 5kb in size.

How to integrate

npm i @happykit/flags

OR

yarn add @happykit/flags

Then create a flags.config.ts file at root with the following contents:

import { configure } from "@happykit/flags/config";

configure({
  envKey: process.env.NEXT_PUBLIC_FLAGS_ENVIRONMENT_KEY
});

Then import this into your _app.tsx:

import '../flags.config'

Lastly, add the following to your .env.local:

NEXT_PUBLIC_FLAGS_ENVIRONMENT_KEY=flags_pub_development_xxxxxxxxxx

To find the value for your environment variable:

Go to the portal happykit.dev
Go to settings
Go to keys and pick which environment you want to target (i'd advise development in local building).

They also support a preview environment and a production environment out of the box. Which is a nice feature for free.

The library fully supports SSR and I can demonstrate this with the below code snippet:

import type { NextPage, NextPageContext } from "next";
import { useFlags } from "@happykit/flags/client";
import { getFlags } from "@happykit/flags/server";
import {
  ErrorInitialFlagState,
  Flags,
  SuccessInitialFlagState,
} from "@happykit/flags/dist/declarations/src/types";

export const getServerSideProps = async (context: NextPageContext) => {
  const { initialFlagState } = await getFlags({ context });
  return { props: { initialFlagState } };
};

interface IHomePageProps {
  initialFlagState: SuccessInitialFlagState<Flags> | ErrorInitialFlagState;
}

const Home: NextPage<IHomePageProps> = (props) => {
  const { flags } = useFlags({ initialState: props.initialFlagState });

return (
   <div>Hello {flags.exampleFlag ? 'World' : 'Not turned on'}</div>
  );
};

export default Home;

The above is really neat because this now means that we get the initial flag values on the server when a client requests the page and we pass it to them. Rather than having the client make that extra initial call to get the values for our flags.

Secondly, the portal is very easy to use.

It guides you through creating feature flags and is full of code samples on how to get started. It's very intuitive to use and i've had absolutely no problem with navigating my way through it which is always a reassuring sign when picking a tool to aid your development of projects.

Thirdly, the free tier is good.

When developing pet projects we want the world for nothing. HappyKit gives you a free tier consisting of:

AB testing of feature flags
Up to 100,000 requests a month
5 feature flags on the go at once.

This is good, but I leave it at good. There are other competitors that offer more feature flags in their free tier and I would hope that this changes in the future for HappyKit. But given the fact that it offers all the other things mentioned so far in this article. It's still a winner for me.

Closing thoughts

Feature flags are an important tool in todays development ecosystem. Testing features before releasing to the masses, and not being dependent on stale feature branches from master is an important thing to avoid. Therefore finding a good tool for the job is high on the priority list. I personally like how HappyKit is laid out and I intend to keep using it. A key theme for me has been Developer Experience and how that affects my decision making when using tools. Which is why I like this tool in particular. Just like the reason for why I love using tailwind for my UI's. It's DX is amazing.

Let me know in the comments below what tools you use to manage feature flags in Next.JS 👇

Links:

HappyKit

You don't need to know it all

Will Holmes — Wed, 09 Feb 2022 12:17:22 +0000

As I continue to keep developing and building in different, new technologies this realization of not needing to know it all as a developer has become quite an important part to fighting off imposter syndrome for me.

Being a fullstack developer, it can be so overwhelming to try and be on top of every new dotnet version, node version, react version etc etc. You get the message...

But something that I have come to the realization in myself whilst working on new builds recently is that:

It's okay not to know everything.

You will come across specialists in areas that know the complex, and make it simple. That's fine! They have chosen to be an absolute master at that specific area of development. Don't compare yourself, you'll never win. Trust me.

But what can you do to make sure that you keep up to date whilst not falling behind?

Build in your own time with new technologies.

This to me has been so beneficial throughout my career as a developer so far. Never stop building. I find that when I want to use a new technology, I will build a new app with it. Specifically a copy of an existing application that you can use to experiment with technologies and integrations.

For example:

I want to play with react native and brush up on my styling as I feel I am so behind on the trends.

Brilliant! Go build a copy of Instagram in react native, this will cover building in a new technology and experimenting with styles.

Take exams from technology providers.

This has been a great way for me to learn new things and squash that feeling of being an imposter. This is because the gratification of being certified by a provider allows you to know that the hard work you put in is recognized officially. Rather than relying upon yourself to validate this.

For example:

I want to learn more about Azure as a developer so that I don't feel I am behind with the trend when developing in their cloud.

Brilliant! Go take an exam such as Azure Developer Associate to learn more and validate your knowledge.

These are two great things that you can do to bolster your knowledge and have helped me. They may or may not work for you but take the personal time to figure this out. I understand life can be difficult and things get in the way and that's fine. As GaryVee well says:

Macro patience, micro speed.

Aim for the long term, becoming the best developer you possibly can be. Unrealistic timelines and expectations are going to set you up for disappointment. But make sure you push yourself :)

Why I think Jest is better than Mocha & Chai

Will Holmes — Wed, 20 Jan 2021 00:07:25 +0000

So recently i've been working on building services in NodeJS with Typescript, and one of the big challenges i've had is picking a test framework that suits my purpose.

Coming from a .NET Developer backend world and stepping into the NodeJS/Typescript backend world, has been on a journey on its own, and one that I will look to document soon in an upcoming blog post.

However, with my experience on the frontend and using jest to test components and logic, etc. I naturally drifted towards it, but I thought instead I would give Mocha & Chai a shot instead.

What is Jest or Mocha!?

Jest and Mocha are both examples of testing frameworks that have their pros and cons, but in essence, do the same thing. Just one simpler than the other... 🙄

"Jest is a JavaScript testing framework maintained by Facebook, Inc. designed and built by Christoph Nakazawa with a focus on simplicity and support for large web applications. It works with projects using Babel, TypeScript, Node.js, React, Angular, Vue.js and Svelte"

"Mocha is a JavaScript test framework for Node.js programs, featuring browser support, asynchronous testing, test coverage reports, and use of any assertion library."

Why would I want to use either of these?

When building applications using modern javascript libraries or frameworks such as Node or React, you need to be able to test your codebase. Both of these tools enable you to do that, but exposing different API's in order to execute your tests.

Typically Mocha pairs with Chai:

"Chai is a BDD / TDD assertion library for node and the browser that can be delightfully paired with any javascript testing framework."

However, when using Jest you will not need to rely explicitly on a third-party assertion library. Let's see some live examples so we can see how the underlying API's differ between the two.

Implementation Comparisons

Scenario 1:

I want to unit test my login service on the action of checking the user has a valid userId.

Mocha

import { expect, should } from 'chai';
import loginService from './loginService';

describe('loginService', () => {
    it('should return true if valid user id', () => {
        expect(loginService.isValidUserId('abc123')).to.be.true;
    });
};

Jest

import loginService from './loginService';

describe('loginService', () => {
    it('should return true if valid user id', () => {
        expect(loginService.isValidUserId('abc123')).toBeTruthy();
    });
};

As you can see from the basic scenario that has been given there isn't a whole lot of difference in the approaches here. It's more a question of personal preference on their assertion APIs in my opinion.

Scenario 2:

I want to unit test my user service on the action of getting their profile.

Mocha

Side note: For us to be able to mock out external modules in Mocha, we are going to need to install another package called 'sinon'. This will allow us to set spies on certain functions and also replace functions with mock ones.

import { expect, should } from 'chai';
import sinon from 'sinon';
import loginService from './loginService';
import userRepository from '../repositories/user';

describe('loginService', () => {
    it('should fetch a user profile given a user id', () => {
        const expectedReturnObject = {
            id: 'abc123',
            username: 'joebloggs97'
        };
        const getStub = sinon.stub(userRepository, 'get');
        getStub.returns(expectedReturnObject);

        const response = loginService.getUserProfile(expectedReturnObject.id);
        expect(response).to.equal(expectedReturnObject);
        expect(getStub.calledOnce).to.be.true;
    });
};

Jest

import loginService from './loginService';
import userRepository from '../repositories/user';

const mockGet = jest.fn(() => {
    return {
            id: 'abc123',
            username: 'joebloggs97'
        };
});

jest.mock('../repositories/user', () => {
    return {
      get: mockGet
    };
});

describe('loginService', () => {
    it('should fetch a user profile given a user id', () => {
        const expectedReturnObject = {
            id: 'abc123',
            username: 'joebloggs97'
        };

        const response = loginService.getUserProfile(expectedReturnObject.id);
        expect(response).toEqual(expectedReturnObject);
        expect(mockGet).toHaveBeenCalledOnce();
    });
};

As you can see here in the first example with mocha we are fairly reliant on 3 libraries to achieve what Jest can do itself. Also, I feel the APIs of Sinon combined with chai really do make for much more difficult reading as opposed to jest. From a quick glance, it's obvious what Jest is asserting, whereas in the Mocha sample. To me, it takes a lot more from a glance to understand what assertions are taking place.

So now we know what the options are, how they are used, what is their documentation like?

Well quite honestly having used both Jest was a lot easier to navigate and find answers to. Just like their API's, everything is fluent and a breeze working with Jest. It seems like as well the community is a lot larger and a lot more problems have been solved around the web. Making it easier to google issues. Compared to the 3 different libraries with their own documentation in the Mocha implementation. It can be a bit tricky to know which one to look at and how to use google with them.

Closing Thoughts

Overall both of these solutions achieve the same goal, just they approach the problem differently. Personally, I have used Jest a lot longer than the Mocha alternative and for me, the simplicity of setting up and implementing Jest is a lot easier than Mocha.

Helpful Links:

Jest: https://jestjs.io/en/

Mocha: https://mochajs.org/

Chai: https://www.chaijs.com/

SinonJs: https://sinonjs.org/

Let me know in the comments below your thoughts and experiences! 👇

Why Netlify has mastered CI/CD

Will Holmes — Mon, 11 Jan 2021 22:29:56 +0000

Introduction

In a world where we want access to everything 24/7 and want it instantly. Technology has to progress with it. Even though I am only just coming up to 6 years of experience as a developer. I feel the landscape of CI/CD has changed MASSIVELY. Since I set out on my journey.

I remember that years ago I was deploying .NET solutions via either a dedicated server or a virtual machine, simply by publishing the output then using FileZilla take that output and put it on the server. That was what worked (kind-of). .NET back then was in its framework ages, .NET Core was not much more than a glimmer.

Fast forward to today, you can literally get a free CI/CD pipeline based on your git commits integrated into your repository. In a few clicks. With hosting so freely / widely accessible, it's truly amazing how easy it is these days to get world-class CI/CD without an expense being paid on your behalf.

What is Netlify?

Netlify is a web development platform that will allow you to link up to your git repositories and have a domain, environment, ci/cd pipeline all setup and configured from its UI (As well as a ton of other stuff). It essentially encapsulates all the things that typically you would need to be an expert in DevOps to do, but made simple.

Netlify essentially takes the process of deploying a web application (react, angular, vue, etc) and makes it so simple. You can take advantage of their CLI or opt for their intuitive UI. Their UI takes 4 clicks in total to get a git repository and deploy it on their servers with a subdomain. It's that simple. You can view your builds in progress with logs, trigger new builds, and more.

It has solved a problem that is so needed given how much is required of developers to know to get a web app, service, website out onto the internet. It's hard enough keeping up to date with the latest Javascript framework for example!

What would I use Netlify for?

If you want:

Continuous Integration
Continuous Deployment
A new environment created with a domain for each pull request
Domain management
Analytics
A/B Testing on branches
Environment specific behavior
Custom config files for your environments

For free, then you should definitely look into Netlify 😉

Honestly, you get all of that for free. Meaning you do not need to even start with picking a cloud provider and figuring out what resources to provision. You just use their service through a few buttons and you're up and running.

But that is only for frontend projects...?

True, but that is where other providers such as Heroku come into play. Heroku for example has near-exact functionality that Netlify does (CI/CD) but can support your NodeJs services and many more types of languages. This means that regardless of what your need is for hosting (backend service, frontend app) there is a provider that can suit your needs. I currently use both, Netlify for my frontend solutions and Heroku for my backend solutions.

But what about Github pages?

Again, that is a good point because as Github becomes even more enhanced in it's CI/CD actions it might be simpler for you to plug into Github pages. But again this is where it depends on your requirements. You won't get out the box monitoring and analytics from Github, however, for a small fee you can get things like Analytics from Netlify seamlessly. I also think the domain management is outstanding from Netlify. I've managed to manage my domains with ease and set up email domains etc all from the panel. Something that as a PAAS offering Netlify offers, whereas Github won't. Again, it all depends on your requirements.

My Netlify workflow

So with my Netlify site all hooked up to my Github repository as soon as I commit to my main branch, it will go and deploy to production. However, if I open a pull request it behaves a little differently. See below 👇

As you can see above it outlines the process of my main branch at the top and my pull requests below it. It's really sophisticated and I'm actually really grateful that I have access to this type of infrastructure, free and easy to access.

Closing thoughts...

My opinion on Netlify as an offering is that it has really mastered and spotted the gap in the market for developers to build apps without worrying how they would host it, integrate it, monitor it and most of all maintain it. Like I mentioned earlier it's hard enough to keep up with the latest Javascript framework let alone cloud-based DevOps. If you want to dig a bit deeper on Netlify I will leave some links below.

Useful resources

Netlify Docs: https://docs.netlify.com/

Heroku Docs: https://devcenter.heroku.com/start

What are your thoughts on the likes of Netlify and Heroku? What do you use yourself? Let me know in the comments below! 👇

TailwindCSS vs Styled-Components in ReactJs

Will Holmes — Sun, 10 Jan 2021 17:01:58 +0000

A few days ago I posted a new blog post in which I detailed my experience with styled-components, and how it was a nice way of incorporating dynamic styling into the js domain staying away from CSS files. I later found out about yet another way to incorporate styling into your applications... that was TailwindCSS.

I had seen some conversation around this before as well as a lot of videos and posts mentioning TailwindCSS but thought nothing more of it. So seeing as I had been told of it again and also wanted to try it out so I could compare my experiences. I decided to build a website utilizing Tailwind for styling.

What should I know as basics?

To get you started and to understand this read it's important to know that:

TailwindCSS is a package full of pre-built classes to style your components however, they are so flexible that you can do anything with them!
You do not need to know CSS to use TailwindCSS.
TailwindCSS uses a lot of abbreviations i.e. (pb is padding-bottom), so it's important that you read the documentation and use its search function if you are ever unsure.

Tailwind... more like bootstrap!?

I have to say my initial impressions of Tailwind are positive. It takes a lot of the semantics of bootstrap and has almost extended them so much that you never have to use media queries in direct CSS to toggle differences in styling. Instead, you would do something like the below:


<div class="pb-10 sm:pb-12 md:pb-8 lg:pb-4">
    Hello world
</div>

To those who have used styling frameworks before such as Material UI, Bootstrap, etc. You will understand the usages of these different media breakpoints (sm, md, lg, etc.). These are essentially saying 'When my device size is lower than small apply a padding-bottom of 10. When my device size is small (sm) or greater apply a padding-bottom of 12. When my device size is medium (md) or greater apply a padding-bottom of 8. When my device size is large (lg) or greater apply a padding-bottom of 4'. I must say, it took me a while to really understand the technique of saying there is no 'xs' breakpoint which is what you would typically find in bootstrap for example. Simply that any device which is lower than sm inherits tailwind classes without a media breakpoint like the above 'pb-10'.

But hang on... that looks like a lot of classes?

That's true and it's something that did put a bit of a dampener on my view of the framework. With having so many utility classes being added on to each element it's very easy to end up with huge class property values. This can easily cause things like useless classes remaining on elements that aren't necessarily needed etc. A good package to use is the classNames package that will combine class names together. Allowing you to format your elements a little cleaner.

How does TailwindCSS compare to styled-components?

Something I really liked about styled-components, was how simple it made your components look. Being able to create a styled div and reference it like:

const Wrapper = styled.div`
padding-bottom: 10px;
@media (min-width: 768px) {
    padding-bottom: 20px;
}
`;

const TestComponent = () => (
    <Wrapper>
        Hello world!
    </Wrapper>
);

This to me, keeps component code so clean and concise allowing the components to focus on logic and not looks. You could even go one step further, and abstract your stylings out to a separate js file within your component domain. However, let's see what this looks like in TailwindCSS:

const TestComponent = () => (
    <div className="pb-10 md:pb-20">
        Hello World!
    </div>
);

As you can see here, TailwindCSS actually reduces the number of lines of code we have to write to achieve the same goal. This is its whole intention with the utility class approach. It really does simplify writing styled elements. However, this is all well and good for our elements with only a few styles. Let's take a look at the comparisons of more heavily styled components:

styled-components

const Button = styled.button`
    font-size: 1rem;
    margin: 1rem;
    padding: 1rem 1rem;
    @media (min-width: 768px) {
        padding: 2rem 2rem;
    }
    border-radius: 0.25rem;
    border: 2px solid blue;
    background-color: blue;
    color: white;
`;

const TestComponent = () => (
    <>
        <Button>
            Hello world!
        </Button>
    </>
);

TailwindCSS

const TestComponent = () => (
    <div className="text-base mg-1 pt-1 pr-1 md:pt-2 md:pr-2 rounded border-solid border-2 border-light-blue-500 bg-blue-500 text-white-500">
        Hello World!
    </div>
);

As you can see from the above comparisons, styled-components really does take the lead now as our component has grown in styling rules. Tailwind's implementation is so verbose in classNames and without using a package like classNames it really makes our lines a lot longer than they should be. This is one of the biggest downfalls for Tailwind in my opinion.

Especially if you are working on a project with multiple developers, the styled-components approach allows you to easily read what stylings the Button component has. In comparison to the Tailwind approach, you would most likely have to lookup in the docs some of those util classes to understand precise values.

Compare this example to the first example. Tailwind just screamed simplicity. This follow up example just consists of complexity and a high risk of spaghetti code. It only takes multiple developers to be working on a few components at the same time for styles to be easily ruined/disrupted and then spending time removing certain util classes to find out the root cause. In comparison to the styled-components way of doing things where we still rely on our raw CSS changes it is a lot easier to manage change in my opinion.

So, who takes home the trophy?

Well... to be honest, I wouldn't say either of these two trumps each other. Both have their benefits and disadvantages which have been demonstrated in this article. I'd say if you are looking for a quick way to style a website or single pager with not much complexity; then TailwindCSS might be best for you. Mainly due to the amount of utility you get out of the box to style your classes. However, if you are looking for a longer-term project that can be more easily maintained. I would advise styled-components due to their more 'robust' feel to it when maintaining styles in my opinion. However, I am not an expert in either of them, I have simply just been building in both of these technologies and these are my initial thoughts.

Useful Resources:

TailwindCSS:

https://tailwindcss.com/

https://www.tailwindtoolbox.com/

https://tailwindcomponents.com/

Styled-Components

https://styled-components.com/

Thank you for reading, let me know in the comments below if you have used either of these or maybe both and how you found using them! 👇

Material UI Theme for JetBrains Rider

Will Holmes — Tue, 05 Jan 2021 18:41:29 +0000

From the evolution of the dark theme, developers now have a wide choice of color themes in most modern development IDE's that go beyond Light and Dark.

Ever since the release of Visual Studio Code, I have become a sucker for a nice color theme in my IDE's. To a point where I change my mind every other day. When using other IDE's such as Visual Studio 2020 you don't have to use it long to realize that the ecosystem of themes is pretty outdated.

However, I have been using JetBrains Rider for some time and have accepted their default themes as ones that are nice to develop in. But I've been wondering recently as to whether there are more advanced and customized themes out there.

Custom theming discovered...

After doing some digging around I realized that there is actually a huge ecosystem of themes out there for JetBrains Rider. With it being in parity to JetBrains IntelliJ a lot of similarities persist which has enabled theme building.

Material UI Theme

Having used Material UI in other IDE's such as Visual Studio Code I was amazed that we also have a port of this for JetBrains Rider. Meaning that my development in C# can be done in an IDE that now looks even more visually pleasing! You can download and install it via the plugins menu in Rider or read more here: https://www.material-theme.com/ .

Above you can see what this theme looks like in practice. It's a beautiful implementation of the Material theme into the Rider IDE. Syntax highlighting isn't off and the icon pack is really minimalistic.

Just like for many developers, a setup that consists of a mechanical keyboard that suits them is very important. Selecting the right theme for your development IDE that you will go to battle with every day is just as important.

Thanks for reading, let me know in the comments below which theme's you like to use in your IDE 👇

An intro to styled components in your react project

Will Holmes — Sun, 03 Jan 2021 20:51:37 +0000

CSS as a means of styling your web apps / websites is confusing, complex and can soon spiral out of control if you do not enforce a strict way of styling throughout your project.

This is mostly down to the fact that the semantics of it are odd and can be quite restrictive. For example, no for loops or functions. However, you do get the luxury of targeting elementIds, classes and others.

Tried but didn't achieve greatness...

There have been attempts to try and solve these problems with the likes of CSS pre-processors. These allow you to create styles in their own format which get transpiled down to CSS some popular examples might be SASS, LESS, SCSS etc. However, these come with their own problems. Such as they all can end up with the same issue of overcrowding of stylesheets like in CSS.

So what are styled components?

We are starting to live in a world whereby a large proportion of web apps are being developed in react. With this in mind styled components has been developed to be used alongside react when developing your websites / web apps. It takes the fundamentals of CSS and applies them to be closely integrated with our components. The main point is that we are no longer styling elements based on their type, elementId or className. We are now styling them as their own 'components' that are 'styled'.

Let's break this down in an example:

React + CSS

hello.css

.helloWorld {
    color: blue;
}

hello.js

const HelloWorld = () => (
    <div className="helloWorld">Hello World!</div>
)

The above demonstrates the way we are used to with a HTML / CSS world. This allows us to have a file to determine how elements should look and feel (hello.css). Alongside a file that allows us to construct our elements in a way that creates an experience (hello.js).

React + Styled Components

hello.js

import styled from 'styled-components';

const HelloHeader = styled.div`
color: blue;
`;

const HelloWorld = () => (
    <HelloHeader>Hello World!</HelloHeader>
);

Now from a glance this may look like a trivial change that has simply moved the CSS away from the individual file, into the component file. However, that is exactly the point. The styles now sit within the component where they are being used. This means that we are no longer relying on CSS classes or elementIds to style our components.

One of the main goals of styled-components is that it 'wants to remove the mapping between styles and components'. By incorporating our styles into our react code as 'components' we are now bridging that gap and allowing for more readable code from the outset. Gone are the days where a div has been styled by a stylesheet sitting tens of folders deep within a big codebase.

My thoughts?

Whilst styled-components is still a fairly new kid on the block it's definitley something I am going to keep playing with and seeing its potential. Since working on my personal website I have discovered it's benefits and how it fits into a project. I'm sure there are some points it falls behind on but with every new piece of disruptive tech, that's to be expected. As i progress further with styled-components I will be sure to blog again with my more advanced thoughts.

Helpful Links:

Styled Components: https://styled-components.com/

Let me know below in the comments if you have used styled-components in your react projects. If so, how did you find it? 👇

Building a portfolio site in GatsbyJS

Will Holmes — Fri, 01 Jan 2021 16:40:10 +0000

Why do I want a portfolio site?

I wanted to build a portfolio site so that I can experiment with new technologies and also showcase what I have been working on recently. In addition to this, it also allows me to keep refining my skills and testing out new ways of building things without the fear of breaking changes with brand new tech.

What Is Gatsby?

I'd heard a lot of buzz about Gatsby but never fully understood what it was. Turns out it's pretty powerful and really simple to use. If you've ever had the pleasure of working with NextJS then it's a fairly similar concept.

Gatsby is a static site generator that allows you to build websites and progressive web apps using modern javascript tools / utils / frameworks such as:

ReactJS
Webpack
GraphQL

Why Gatsby?

As I wanted to build a portfolio website I want to optimise load times for my users. So having a traditional React web app to serve this up didn't make sense. But I also wanted the benefits of developing in the React ecosystem which meant a traditional html / css / js route wasn't favorable. With Gatsby compiling our React app into static assets it also means that load times will be a lot faster than without using it. A key selling factor for me.

So how did it go?

After reading a few articles and the documentation for Gatsby it was pretty clear to see how neat it is. I love how dev friendly the CLI is for Gatsby. To get started you need to run the following command:

npm i -g gatsby --save

Once you have installed Gatsby you can then run the following to get started with a brand new project:

gatsby new my-brand-new-website

Then once it's finished installing and configuring you can run the following:

cd my-brand-new-website
npm run develop

Then you should be greeted to a template website that has been created for you with navigation all setup and examples of how to build in Gatsby, setting you up for success!

What stood out to me was how nice the functionality they provide out the box is. An SEO component is created for you which you simply implement into all of your pages and is very extensible. This sort of helping hand when onboarding developers onto your framework is what sets aside the competition.

Plugins are what Gatsby's ecosystem really relies on. There is pretty much a plugin to do anything needed for your website in the Gatsby world. For example, I wanted to optimise how I load content into my website. So I wanted to be able to add markdown files as part of my 'content' folder and read them in my components without having my content sitting hard coded in my components or pages. To do this all I had to do was install a plugin called gatsby-transformer-remark. Then add a little configuration to my Gatsby setup:

plugins: [
  {
    resolve: `gatsby-transformer-remark`,
    options: {
      // CommonMark mode (default: true)
      commonmark: true,
      // Footnotes mode (default: true)
      footnotes: true,
      // Pedantic mode (default: true)
      pedantic: true,
      // GitHub Flavored Markdown mode (default: true)
      gfm: true,
      // Plugins configs
      plugins: [],
    },
  },
],

Now I can call my markdown files from GraphQL queries inside my components or pages meaning the content sits in a content directory and my components and pages are in their own worlds too.

Once I understood this concept of doing things, I realised the power of Gatsby.

Closing thoughts...

Overall I really enjoyed using Gatsby to build my portfolio site. I will definitely be upgrading and getting more involved with it overtime as it is a fun and powerful tool to use. I didn't experience anything that put me off of using it. So for me it's full steam ahead!

Have you used Gatsby before? If so how did you find using it?

Let me know in the comments below! 👇

Docker 101 - For Beginners

Will Holmes — Sun, 13 Dec 2020 23:34:20 +0000

What is it?

Docker is a containerization platform that bundles your applications and all their dependencies into something called a 'Docker container' so that your application can run agnostic of what environment it is in. This also ensures that your application can run quickly and reliably from each environment.

Credit: https://www.docker.com/resources/what-container 👆

When should I use it?

When you want to ship your app across multiple environments and get the same expected behavior consistently on them.
When you want to minimise the risk of 'it works on my machine' development.
When you want to enable CI/CD within your development teams. Using docker containers means that your build pipelines can all use the same set of instructions to validate new code changes to your applications.
When you want to enable application development for developers who might not all use the same operating system but experience the same application performance.

When should I not use it?

If building a backend API could you split the API into a collection of serverless functions (AWS Lambda's, Azure functions, etc...). This would be much more cost-efficient and speedy than Docker. Due to it's set up but also because Docker will need to run on a dedicated piece of computing power all the time. Whereas serverless only uses compute power when it is needed.
If you require persistent volumes for data storage, this can be challenging to maintain with Docker.
An added layer of complexity to host your applications will mean that you need to put more pressure on your hosting machine.

How is it used?

Firstly for your application, you are going to need to write a 'Dockerfile' at the root of your project. This will contain a set of instructions to tell the Docker agent how to build your container.

See the example below:

We pull from 'alpine' which is a lightweight linux image to base our container from.

Then we run a bash command to echo the words 'Hello world!'

FROM alpine
CMD ["echo", "Hello world!"]

Save the above file as 'Dockerfile'

Then run:

docker build -t hello .
docker run --rm hello

This will build the Docker image firstly and give it a tag name of 'hello' and scope the Dockerfile to the root of the directory as we specified the '.' character.

Then it will run the container and kill it after.

Which should output:

Hello world!

🎉 Congratulations! 🎉 You've just built your first Docker container.

Conclusion

To summarise, Docker is a great way of bundling your applications up for development across multiple environments and enabling multiple developers to work on active app development. It will enable a lot more sophistication in your CI/CD process going forward but, at the cost of a more heavyweight solution (compute required and time spent getting setup). It's important to think about serverless and if it can fit your needs as opposed to containerization. But hopefully this has given you a brief enough insight into Docker that you can start making informed decisions going forward.

Download and Install Docker from here: https://docs.docker.com/get-docker/

Documentation: https://docs.docker.com/engine/reference/commandline/docker/