DEV Community: Stef

Chakra UI is still great in 2024

Stef — Sat, 17 Feb 2024 21:30:08 +0000

I was working at a startup in 2021 (not my current role) and the company was going through a pivot which meant all of our existing code was being scrapped and we were starting again from scratch.

The main project we'd developed up until that point was a React Native app used on tablets for managing stock and orders. The changes to the business model meant we were about to start work on an online B2B SaaS platform instead.

Most of the dev team (including myself) had never worked on a SaaS application before. We had a mixture of web and native experience, a mixture of Java, Kotlin and JS/TS experience, and we had about six weeks to try to ship something.

So why did we choose to use Chakra UI:

We didn't want an extra build step for CSS, because we couldn't afford to spend time debugging build issues and we had limited CSS experience
We wanted something that felt like React Native from a code perspective, because that's what we were used to
We needed to create something presentable and usable, without design expertise, in a short amount of time, without creating a big mess of tech debt - Chakra UI was 'batteries included' and had a bunch of useful components
Some of us had used Material UI in the past and had a bad experience with it - it's too complicated and full of gotchas, and it looks a bit dated

The honeymoon period

Chakra UI was amazingly simple to install and start using. Everything worked first time.

The Chakra UI theme and layout components such as Stack and Center made it easy to build presentable layouts without design expertise. The layout code was simple enough that we could quickly try out different page layouts, so we didn't need to wireframe anything. It was really easy to throw together some basic forms with nice validation states using Form components. I loved using the Skeleton component to make nice loading states. I'd never done anything like this before (I mostly worked on static content sites) so this was really fun.

Something else caught my attention, which I hadn't realised at first. Chakra's theme system (which is based on Styled System Theme Spec) is very powerful. I was surprised that it wasn't a lot more opinionated about styling considering the other benefits the library was offering, but the styling can be completely overridden using a custom theme which can also be extended for styling custom components. I had tried to do a similar thing on a previous project using Styled Components to create white-label components that can be wrapped with different brand themes - Chakra UI is light-years ahead of that approach and I wish it had been around a few years earlier so we could've used it then.

Back to the earlier story - we managed to ship something in time without creating a big mess, which was great. Unfortunately the business itself didn't work out, as is known to happen from time to time with startups.

Chakra UI's theming system was, however, a significant factor in the decision to adopt Chakra UI at the company I've since been working at, and we've used it for all of our projects over the last couple of years.

The last couple of years

We've been using Chakra UI in production for a couple of years now. How has it been so far?

I think it's mostly been great. All of the things that were initially great about Chakra UI are still great about Chakra UI.

I've put together some thoughts below on some of the specific highlights and lowlights I wanted to call out.

The theming system has helped a lot with design/dev alignment and handoff

The Figma kit has provided a good foundation for our internal library file. The theme system in Chakra UI itself is flexible and extensible enough that we haven't been concerned about deviating from the initial defaults. (You can see what our main application looks like on its product page - other companies have demonstrated this to an even greater degree, such as the Figma Conf' 23 site which also uses Chakra UI.)

Chakra UI has worked great for devs at all experience levels and backgrounds

I think Chakra UI is really easy to use, but the real proof of this has been seeing the success that junior/mid and backend engineers have been able to have with it.

I've found that it's been easy to maintain a good standard of code quality compared to the other approaches I've used in the past (CSS, Sass, and Styled Components), which is maybe because the Style Props syntax in Chakra UI is just normal React code - this reduces the cognitive overhead of learning and writing Chakra UI code compared to the alternatives, especially for developers who are new to React and JS/TS.

New patch/minor releases sometimes broke our builds

We've found that occasionally new releases of Chakra UI would cause breakages in our CI/CD builds due to breaking changes creeping into patch/minor releases. These are often fairly small things such as an ARIA role changing on an element causing our tests to fail. Sometimes they are harder to fix or it's unclear whether it's a bug or intended behaviour.

The source code seems overly complex and a bit too spooky for me

I've jumped into the Chakra UI source code a few times to try and fix bugs. I find it scary how much stuff is going on in there. I feel like I can't trust it to not contain weird bugs due to the complexity of the codebase and the number of 3rd-party dependencies. (I think we've come across a few of these bugs, which is why I was looking at the source code to begin with!)

I don't understand how all of the components work, such as the Toast component - it seems like some of this stuff like Standalone Toasts is breaking the rules of React by introducing global state. We've occasionally run into some issues with Chakra UI when writing unit tests (with React Testing Library) and I suspect some of those issues are a result of Chakra UI doing stuff it probably shouldn't be doing under the hood.

Overall, I wish it was more 'basic React' and had less going on. I think this would also help to avoid breaking changes creeping into new minor/patch releases by mistake.

Conclusions

I still love Chakra UI despite its flaws.

I love how accessible it is from a development perspective: it definitely levels the playing field and enables more people to build stuff with confidence and see immediate results from the start, regardless of whether your background is in web, native, backend or whatever. If you can learn to write React code then you can make stuff with Chakra UI.

I'm wondering now what will happen with the project. The maintainers have mostly been working on new projects: Zag, Ark UI and Panda CSS. There were a couple of posts written by Sage explaining the plan with these:

I think Panda CSS looks great, especially for when you really care about page performance and you want to make extensive use of Server Components - I'd actually really like to try it if I can find a project that demands it. On the other hand, it's an additional CLI tool that has to run both locally and in CI, and I like not having to think about Cascade Layers. The syntax also seems less friendly to me, but I need to try using it in practice.

I still appreciate that Chakra UI doesn't require an extra build step for styling. It's one less thing that can go wrong, and that's saved us time in the long run. For our use case, I also don't really mind that it's not as optimal for end-user performance as some of the other approaches to styling (it uses Emotion under the hood) - this is a worthwhile trade-off for what we gain in developer friendliness.

I think integrating Ark UI into the Chakra UI codebase (as is planned, and I really hope will happen!) could reduce the complexity of the code as well as fixing some of the pain points we ran into, so I'm still holding out for this over the next couple of major releases.

That's all for now!

Understanding React as a system

Stef — Tue, 31 Aug 2021 07:49:13 +0000

Note: since I started writing this series, the React team has published a new docs website. The new React Docs have put to bed pretty much all of the things which motivated me to write this, and they've done a much better job of explaining React for beginners than I've done here, so I recommend reading those docs instead.

I want to write about React to try and enable developers from various backgrounds to understand how it works, why it is good, and what it is good for.

This is perhaps a rather lofty ambition. A lot of people have written about React already, so why do I feel the need to write this now?

What I've found is that most of the writing about React is aimed specifically at front-end developers who are experienced in developing websites and other kinds of user interface code. I think maybe this is because the adoption of React in many teams has hinged on convincing the front-end developers in the team that it's something that they should be using.

React is very popular now in teams of various sizes, which is great! What this means though is that developers from various different schools of thought are now developing products with React, many of whom might not have chosen to use it otherwise.

My aim in writing this now is to try and help you to make the most of React even if, like me, you don't necessarily see yourself as a front-end developer.

I am also hoping that in the process of writing this I might be able to clarify my own mental model of React. So if you are experienced with React then hopefully this will still be interesting to read and you will learn something.

“Building user interfaces”

The official React website says this: “React is a JavaScript library for building user interfaces”.

I think this is a good sentence. 👍

Let's just talk about user interfaces for a moment.

User interfaces are how human beings interact with our computer code.

We have some choices when we are creating an interface for humans to use: we can try to create an interface that is intuitive and easy to use straight away, but this will require us to account for a lot of potential outcomes because we did not tell the user what we expect them to do ahead of time.

Alternatively, we can create a very streamlined interface that works in a very specific way, but this will require the user to learn exactly how to use it before they can achieve anything.

These are both valid choices and it depends who we have in mind as our user.

Humans can be quite messy and unpredictable, so if we do decide to make an intuitive user interface - one that does not require learning ahead of time - then it's often necessary for us to grapple with a large amount of complexity; an intuitive user interface will need to be able to react appropriately on the fly to our users doing things we did not expect or want them to do.

And perhaps, as we learn more about our users, we will need to find new ways in which to accomodate them and so the complexity of interface will increase over time.

In short, user interfaces are often necessarily complex. Our goal then is not to make them simple, but to find ways to manage that complexity.

React helps us to manage complexity

When we're writing code, it is generally hard to manage large amounts of complexity.

We may not be able to avoid complexity when we're building a user interface, but we can try to break it down and make it more manageable.

I think one of the core aims of React is to allow developers to build a complex user interface system without needing to think about it all at once.

I like this article called Why Rust's Unsafe Works by @jam1garner and it talks about the idea of locality and encapsulation. The article is unrelated to what we're talking about, but it says this about the Rust programming language which I think is relevant:

One of the greatest features of Rust is its increased design focus on locality, which is to say, it's easier to reason about a function without looking outside the function.

The Rust language is designed in such a way that functions are able to maintain locality; you can normally understand what a function does, and confidently make changes to it, without needing to read other parts of the code as well. You can also know with certainty whether or not a change you make to a function might break other parts of the code based purely on its return type and the type of its parameters.

React does something similar for us, by allowing us to write our user interface code in such a way that the component parts can maintain locality - i.e. we should be able to make changes to one specific part of our user interface in the confidence that it will either not affect other parts at all, or that we can fully understand how it might affect other parts.

React allows us to define a React component as a single JavaScript function or class (we will focus on the function kind here). A component encapsulates all of the appearance and behaviour that makes up some part of a user interface. By using React components, we can reason about the behaviour of some part of a user interface by looking only within the scope of a single JavaScript function.

Here's an example of a React function component:

function MyUserInterface () {
    function handleButtonClick () {
        window.alert("Howdy ma'am");
    }
    return (
        <button onClick={handleButtonClick}>
            Hello dear
        </button>
    );
}

This code defines a component which I've decided to call MyUserInterface.

The component will render an HTML <button> tag which contains the text "Hello dear".

When the user clicks on the button, an alert will be shown in their browser window which says "Howdy ma'am".

Sidenote: You might have noticed in the above code example that the syntax <button> is not valid JavaScript syntax.

React uses a JavaScript language extension called JSX which compiles to vanilla JavaScript. Anywhere you see some JSX code like <a href="/">Home</a> this can be transformed into normal JavaScript code like React.createElement('a', {href: '/'}, 'Home') by a compiler such as babel, esbuild or swc.

Since JSX compiles to normal JavaScript, we can use our React components, for example, to make up part of a web page. Here's a code example that shows how to do this in a single .html file which you can download and open in your favourite web browser: https://raw.githubusercontent.com/stefee/reactjs.org/main/static/html/single-file-example.html (this code is taken from the official React website).

You can also use React without JSX if you like!

Here's a second example which has two components - but the rendered output will be the same as in the previous example:

function AlertButton (props) {
    function handleButtonClick () {
        window.alert(props.alertText);
    }
    return (
        <button onClick={handleButtonClick}>
            {props.children}
        </button>
    );
}

function MyUserInterface () {
    return (
        <AlertButton alertText="Howdy ma'am">
            Hello dear
        </AlertButton>
    );
}

Here I have defined a new component and called it AlertButton.

This component looks similar to the previous example, but the text values are passed in as parameters. The parameters passed into a React component are called properties, or props for short.

Now our MyUserInterface component will render the AlertButton component and pass the text values as props.

The end result is identical to the previous example.

However, by changing the text values to be passed in as parameters, we have created an abstraction which will allow us to re-use this part of our user interface.

Here's an example where we render two different instances of AlertButton in our user interface:

function AlertButton (props) {
    function handleButtonClick () {
        window.alert(props.alertText);
    }
    return (
        <button onClick={handleButtonClick}>
            {props.children}
        </button>
    );
}

function MyUserInterface () {
    return (
        <div>
            <AlertButton alertText="Howdy ma'am">
                Hello dear
            </AlertButton>
            <AlertButton alertText="Okeydokey">
                Goodbye
            </AlertButton>
        </div>
    );
}

With this interface, the "Hello dear" button works the same as before, but now if the user clicks the "Goodbye" button instead, they will see a different alert which says "Okeydokey".

This example shows how we are able to abstract some user interface behaviour into a component, and re-use components to do different things.

This is good stuff! 👌

Sidenote: I should explain the children prop which we used in AlertButton before continuing.

The children prop is a special prop which takes on the value of whatever appears between the open and close tags in our JSX code (<AlertButton> and </AlertButton>) and it is used to describe a component hierarchy.

The component hierarchy is what makes React components composable; components can be assembled in different combinations to satisfy different needs.

We've got one more key concept to cover which is state.

So far what we have seen is that a React component is able to describe how some part of a user interface should appear to the user.

As well as describing how some part of our user interface is rendered, a React components is also able to manage the state of that part of the interface, that is to say it can describe how it will change over time in response to events that may happen outside of its control.

Here's an example of a component that manages some state:

function MyCounterButton () {
    const [counter, setCounter] = React.useState(0);
    function handleButtonClick() {
        setCounter(counter + 1);
    }
    return (
        <button onClick={handleButtonClick}>
            counter is {counter}
        </button>
    );
}

In this code example I've defined a new component which renders a button.

At first this button will say "counter is 0".

When the user clicks on the button, an event is triggered and the text will change to say "counter is 1". If the user clicks again it will say "counter is 2" and so on, and so forth.

What this example demonstrates is that a React component is able to persist some state in memory (in this case, the value of counter) between renders; when our component is rendered, React must store the value of counter somewhere so that it can be modified by our event handler and the value will be remembered for subsequent renders.

If you've not used React before then you might have a lot of questions at this point. This seems a bit magical, doesn't it?

I want to try and explain this fully, so we're going to talk a lot more in detail about exactly how state works in part 2 of this series.

First though, let's imagine we were to create a similar user interface to our previous example using just JavaScript.

Without React, we have to describe imperatively (step-by-step) how the elements are to be constructed and related to one another when our code gets executed - e.g. first we create a div node and then we create a button node and then we attach an event handler to the button and then we append the button to the div and so on, and so forth.

In contrast to this, React components are declarative; our div element has children which has the type of “button” and has a click event handler.

Our components do not need to describe how to construct our user interface, they only need to describe what is to be shown to the user at any given point in time.

What this means is, since the elements that make up our user interface do not come into existence until we render the component hierarchy, we can know for sure that, unless it is passed explicitly via props, it is impossible for one component to access an element which is created by another component and modify it's behaviour in some way - this is how React components enable us to fully encapsulate the behaviour of some part of our user interface and isolate it from the rest.

This is also what enables us to maintain locality in our user interface code.

When we look at the code in the MyCounterButton example, I can say with confidence that this component will always render a button which says "counter", clicking the button will always increment the number shown on the button, and there will never be any other hidden behaviours attached to the button by other components that we need to be concerned about when editing this code.

We can make these assertions simply because the MyCounterButton function does not have parameters, and so we know that running the function will always produce the same result, and the result will be defined only by the code inside the scope of the function.

In general, we can say that the appearance and behaviour of some user interface element rendered by a React component will only change if the props received from its parent change, or as a result of some state defined internally, and that the way in which some part of our user interface changes over time will only be decided by its associated React component, and not any other parts of the system.

This is how React enables us to break down a complex problem and reduce coupling between the component parts of our interface.

It ultimately means that we can continue to introduce more complexity into our user interface over time, and as long as we are able to understand how each individual component works in isolation, we can have confidence in the system as a whole.

End of part 1

I think we've touched on all of the things I want to cover in this introduction.

This was originally going to be a post about how React.useRef works - which I haven't even mentioned once. I still think it's a good idea to talk about this as a way of building a robust mental model of React as a runtime system, so that will be the primary focus of part 2.

Thanks for taking the time to read this! <3

Please let me know what you think of it. You can contact me by email at stef@sril.email.

Also, thank you Sam Greenhalgh for reading my first draft. What a nice man.

References:

Is React Functional Programming? - Eric Normandhttps://lispcast.com/is-react-functional-programming/
Composition: Every Layout - Heydon Pickering & Andy Bellhttps://every-layout.dev/rudiments/composition/
Why Rust's Unsafe Works - jam1garnerhttps://jam1.re/blog/why-rusts-unsafe-works

Speedy builds with Docker Layer Caching

Stef — Sat, 05 Sep 2020 10:32:10 +0000

I found Docker to be one of the most intimidating and confusing things about my work. Hopefully I can share some of what I’ve learned in a way that is accessible and somewhat less intimidating.

What is Docker?

Docker is an application for “containerising” software in an (almost) virtual machine. Docker containers can be used to:

Isolate your application code from the rest of your computer.
Allow you to control what resources an application has access to (e.g. networking).
Run your code on a virtual operating system, allowing you to run it on different computers and have greater confidence that it will behave the same way (e.g. during development and in production).

How it works

Here’s how a Docker container gets made:

You write a Dockerfile and add it alongside your source code.
You give your Dockerfile to the Docker build command.
Docker builds up an image of a container by running the instructions from your Dockerfile.
You give that image to the Docker create command.
Docker creates a container from the image.

So first off, Docker builds an image based on the instructions in your Dockerfile.

Here’s what that might look like:

FROM node:12.14.1-slim
USER node
COPY package.json /home/node/
WORKDIR /home/node
RUN npm install
RUN npm run build

Each line in the Dockerfile is an instruction for how Docker should build the image.

For example, the copy instruction copies a file from the Docker context (e.g. your source code) into the container. (A container has its own file system!)

Docker executes your instructions one after the other, then creates a snapshot of the result and stores this as an image.

You can then create a container from the image, start the container, and execute commands inside it.

Here’s how I would build and run my Node.js app using the above Dockerfile:

docker build --tag my_app .
docker run my_app npm start

(Docker run is like a combination of create, start and execute in a single command).

But wait, that’s not the full picture of what’s happening. Let’s talk about layers.

How layers work

Docker doesn’t just create a snapshot at the end of building an image. In fact, Docker creates a snapshot from the result of every instruction during a build.

These snapshots are called layers, and each layer is a recording of what changed as a result of executing an instruction.

Because a layer only stores what changed since running the previous instruction, each layer is dependant on the previous layer (aka. its parent layer). A layer without its parent is invalid, because it only makes sense in the context of its parent layers.

So, a layer consists of:

An instruction
A recording of what changed during the instruction
A unique ID
The ID of its parent

(Sidenote: Docker layers look a lot like Git commits!)

Docker stores all of the layers during a build in the outputted image.

When you ask Docker to create a container from an image, Docker re-plays the changes from each of the layers, one on top of the other (that’s why they’re called layers).

How layer caching works

When you run docker build you can give Docker an image to use as its layer cache by adding the --cache-from command-line argument.

Before running each instruction, Docker will check if there’s a layer in its cache which matches the instruction it’s going to run, and if it finds one, it will use that layer rather than building a new one. Nice one, Docker!

Importantly though, Docker also checks that the previous layer’s ID matches the cached layer’s parent ID. If the previous layer doesn’t match, then the cached layer can’t be used.

The effect of this is that as soon as Docker fails to find a match in its layer cache for one instruction, the layer for that instruction and all of the child layers will have to be re-built – invalidating one cached layer effectively invalidates all of its children as well.

To demonstrate how this works in practice, let’s go back to our example Dockerfile, which looks like this:

FROM node:12.14.1-slim
USER node
COPY package.json /home/node/
WORKDIR /home/node
RUN npm install
RUN npm run build

Let’s run docker build, and add the --cache-from argument like so:

docker build --tag “my_app” --cache-from=”my_app” .

Here’s our log output:

Step 1/6 : FROM node:12.14.1-slim
    ---> 918c7b4d1cc5
Step 2/6 : USER node
    ---> Using cache
    ---> d897eea3d14a
Step 3/6 : COPY package.json /home/node/
    ---> Using cache
    ---> 6211fc2535b1
Step 4/6 : WORKDIR /home/node
    ---> Using cache
    ---> 8b7fbfbc367f
Step 5/6 : RUN npm install
    ---> Using cache
    ---> 530d5f1f8e6d
Step 6/6 : RUN npm run build
    ---> Using cache
    ---> ae5267476d3d
Successfully built ae5267476d3d
Successfully tagged my_app

After each instruction, Docker logs Using cache, followed by the ID of the layer it’s caching from.

Now, if I change my Dockerfile to say RUN npm install --only=prod instead of RUN npm install and re-run the build, here’s what we get:

Step 1/6 : FROM node:12.14.1-slim
    ---> 918c7b4d1cc5
Step 2/6 : USER node
    ---> Using cache
    ---> d897eea3d14a
Step 3/6 : COPY package.json /home/node/
    ---> Using cache
    ---> 6211fc2535b1
Step 4/6 : WORKDIR /home/node
    ---> Using cache
    ---> 8b7fbfbc367f
Step 5/6 : RUN npm install --only=prod
    ---> Running in a168555b7db9
Removing intermediate container a168555b7db9
    ---> 44ab41899c52
Step 6/6 : RUN npm run build
    ---> Running in 1230a3e778aa
Removing intermediate container 1230a3e778aa
    ---> 8d3dca829a17
Successfully built 8d3dca829a17
Successfully tagged my_app

You can’t tell from the log output, but this build ran a lot slower than the last one! Let’s figure out why.

The first few lines here are the same as before, but now when we get to the instruction we changed, instead of:

Step 5/6 : RUN npm install
    ---> Using cache
    ---> 530d5f1f8e6d

Now we get:

Step 5/6 : RUN npm install --only=prod
    ---> Running in a168555b7db9
Removing intermediate container a168555b7db9
    ---> 44ab41899c52

Aha, so rather than using cache for this step, it has executed the instruction because the instruction has changed! This is a good thing of course, because we changed the instruction so we want Docker to do something different. If Docker used the cached layer, it would have the wrong result.

But the key thing here is that the ID of the layer has changed as well (from 530d5f1f8e6d to 44ab41899c52). This means from this point on, when Docker looks in its layer cache, it won’t find a layer that matches, because the IDs of the layers are all different to before — and remember, it caches layers based on the ID of the parent layer as well as the instruction.

All of the layers will have to be re-built for the instructions following the one we changed. And you can see in the log output that this is exactly what happened. There are no more Using cache lines once the cache gets invalidated.

So the reason why our build took longer was because we had to re-run both the npm install and npm run build steps in full.

It’s worth noting here that this is not a problem with Docker, it’s an important feature! The result of npm run build could change depending on whether we ran npm install or npm install --only=prod before-hand. Changing the npm install line in our Dockerfile means we will almost certainly want Docker to re-run our npm run build as well. This is cache invalidation working just as intended.

And of course, if we were to re-run this command again without making any changes, we would now get a fully cached build, since we are overwriting the same image tag each time.

Why this matters

It’s important to understand how Docker layer caching works when writing your Dockerfile.

Let’s use this Dockerfile snippet as an example:

COPY src /home/node/src
COPY package.json /home/node/
WORKDIR /home/node
RUN npm install
RUN npm run build

Here we have placed our COPY src instruction before our npm install instruction. This means npm install will have to execute again every time we make a change to the files in the src directory, because a change to the src files will invalidate the layer cache during the COPY src line. (Note: during a COPY, Docker will treat file changes as if the instruction has changed and this will invalidate the cache).

In the case of my Node.js app, I’m confident that the result of npm install will not be affected by what’s in my src folder, so I‘d like to be able to make changes to src without having to wait for npm install every time.

So let’s change the order of our Dockerfile and move COPY src to happen after npm install:

COPY package.json /home/node/
WORKDIR /home/node
RUN npm install
COPY src /home/node/src
RUN npm run build

Now if I change the contents of src but I haven’t touched package.json, Docker can take the first few layers straight from the cache, and it only has to re-run npm run build. And that’s exactly what we want, since the output from npm install doesn’t change depending on the content of src, but the output from npm run build does.

This will speed up my build when I’m not changing package.json, because it means Docker doesn’t re-run npm install. 🎉

In conclusion…

It’s important to be aware of dependencies between instructions in your Dockerfile to maximise the benefits from Docker layer caching. Try to group dependent instructions together.

You can also think about which things you change often and which things you don’t, and try to put the things which you think will change most often towards the bottom of your Dockerfile.

❤