DEV Community: Halil Durak

getComputedStyle: The good, the bad and the ugly parts

Halil Durak — Sat, 27 Jul 2024 15:27:23 +0000

getComputedStyle is one of a kind. It does couple of interesting things in the background and has it's own unique way of using. In this post I'll be sharing my experience and thoughts on this bittersweet API.

I expect myself to edit this post since I interact with this function a lot nowadays. I also think there can be loads of niche cases for it too. By the way I'll put some links that helped me on my journey at the end of the post.

What is getComputedStyle?

Directly from MDN:

The Window.getComputedStyle() method returns an object containing the values of all CSS properties of an element, after applying active stylesheets and resolving any basic computation those values may contain.

Individual CSS property values are accessed through APIs provided by the object, or by indexing with CSS property names.

Usage example in plain JavaScript:

const element = document.getElementById("box");

// Get the computed styles of an element
const styles = getComputedStyle(element);

Simply put it returns styles for the given element. Interesting bit here is resolving computations. Say you have given width property in CSS with calc():

#box {
  width: calc(100px - 80px);
}

It'll give you 20px as a result. Meaning you can actually access results of CSS calculations from JavaScript. It even calculates viewport and percentage units (100vh, 50% etc.) and gives the result in pixels. Awesome!

GOTCHA: Computed value is dependent on properties and it's not static. Meaning you can't expect it to calculate something like this:

#box {
  --box-width: calc(100px - 80px);
  width: var(--box-width);
}

// boxWidth variable will be set to string `calc(100px - 80px)`
// Not `20px`
const boxWidth = getComputedStyle(element)["--box-width"];

This totally makes sense since it'd be impossible to calculate the result of a CSS variable statically. It depends on environment and the property aspects (Think percentages for example).

However you'll have 20 pixels if you try to access the width property. It'd end up calculating width for the specific element:

// 20px
const { width } = getComputedStyle(element);

That's cool and all but what are the actual use cases?

Transitioning an element from 0px to auto

If you're reading this post after calc-size() is widely available on modern browsers, stop and go use it. It'll likely outperform our solution here. If you're stuck in a reality where we can't transition to auto, keep going!

In your journey of web development, you might've encountered with animating to/from auto couple of times. An animation library might suit here well but what if I tell you there's no need for it at all?

Let's say there's a box that we can toggle on/off which has some text content. The text content will be dynamic so we can't give it a max-height beforehand. Oh the designer also want an animation there, it must transit from 0px to auto height slowly.

The following will be our HTML and CSS:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="/vite.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  </head>
  <style>
    #box {
      position: relative;
      display: block;
      width: fit-content;
      height: 0px;
      overflow: hidden;
      background-color: rebeccapurple;
      color: whitesmoke;
      transition: 1s;
    }
  </style>
  <body>
    <button type="button" id="toggle">toggle</button>
    <div id="box"></div>

    <script type="module" src="/src/main.ts" defer></script>
  </body>
</html>

In scripting side, we won't be doing much for the start. We just need to keep a simple state to put or remove the text content. (Whether or not using TS is up to you):

// get the wrapper div
const box = document.getElementById("box") as HTMLDivElement;
// get the trigger button
const button = document.getElementById("toggle") as HTMLButtonElement;
// state that keeps track
let toggle = false;

function changeBoxContent() {
  if (toggle) {
    box.innerText = `Lorem ipsum dolor sit, 
    amet consectetur adipisicing elit.
    Minima culpa ipsum quibusdam quia
    dolorum excepturi sequi non optio,
    ad eaque? Temporibus natus eveniet
    provident sit cum harum,
    praesentium et esse?`;
  } else {
    box.innerText = "";
  }
}

button.addEventListener("click", () => {
  // flip the toggle
  toggle = !toggle;
  // update the content
  changeBoxContent();

  // ...
});

The code here simply sets box's innerText to some psudo string or reverts it back to an empty string.

If you click the button now, you'll see nothing has changed. That's because we set box's height to 0 pixels and hide it's overflow.

In order to know how much space we need for the text, we can set box's height to auto and call getComputedStyle on our box. The idea here is to let the element enlarge as much as it need via auto and getComputedStyle here will fetch us that size in pixels.

button.addEventListener("click", () => {
  // flip the toggle
  toggle = !toggle;
  // update the content
  changeBoxContent();

  // set the element's height to `auto`, this enlarges the element to fit it's content
  box.style.height = "auto";

  // we got our desired height property!
  const height = getComputedStyle(box).height;

  console.log(height);
});

You should see the box had as much height as it needed when you click the button. We can also see the height in pixels in console:

That's cool but we're not transitioning for sure.

Since we know the height we need, maybe we can set box's height back to where it was. Within a call to requestAnimationFrame, we can set it to height we had from getComputedStyle. Let's try it!

button.addEventListener("click", () => {
  // flip the toggle
  toggle = !toggle;
  // update the content
  changeBoxContent();

  // set the element's height to `auto`, this enlarges the element to fit it's content
  box.style.height = "auto";

  // we got our desired height property!
  const height = getComputedStyle(box).height;

  // set the height back to where it was (0px)
  box.style.height = "";

  // set the final height in next animation frame
  requestAnimationFrame(() => {
    box.style.height = height;
  });
});

Now that we've set the height to 0px and changing it in the next animation frame, we should see it animating, right?

Well, not exactly. If you're running this in Chrome in a high end PC, you should observe the transition animation BUT in lower end PCs or in some browsers (like Firefox), you can see nothing has changed.

Comparison of Firefox and Chrome on my computer:

The reason why this is happening is because the calculation for layout happens after the styles. We can't guarantee our layout calculation will happen before the style calculation. Also browsers have different implementations of requestAnimationFrame too, it seems. (You can learn more about it here)

Don't get into despair though! We have multiple solutions for this. We can:

Force the browser to run layout calculations immediately before styles
Use intertwined requestAnimationFrames to make sure the animation will be run on the next tick (also known as double rAF())

Let's try forcing the browser to calculate styles first. Remember getComputedStyle? I'm sure you do. It'll come to our rescue here too!

Right after we set height back to 0px, we'll force to recalculate the layout:

button.addEventListener("click", () => {
  // flip the toggle
  toggle = !toggle;
  // update the content
  changeBoxContent();

  // set the element's height to `auto`, this enlarges the element to fit it's content
  box.style.height = "auto";

  // we got our desired height property!
  const height = getComputedStyle(box).height;

  // set the height back to where it was (reset)
  box.style.height = "";

  // we're synchronously forcing the browser to recalculate the height of the element
  getComputedStyle(box).height;

  // set the final height in next animation frame
  requestAnimationFrame(() => {
    box.style.height = height;
  });
});

GOTCHA: You might be thinking why we're accessing height property but not assigning it to anything. Well that's because getComputedStyle computes a property on access. It's actually to make it more optimized, it'll only run layout calculations on access to top, left, bottom, right, width and height. Its not documented but good to keep in mind. Try changing it to getComputedStyle(box), you'll see nothing has changed.

So that was one way to solve it and honestly I like this way much better. It's good to know double rAF() trick too, though.

For that we simply need to wrap our requestAnimationFrame with another requestAnimationFrame:

button.addEventListener("click", () => {
  // flip the toggle
  toggle = !toggle;
  // update the content
  changeBoxContent();

  // set the element's height to `auto`, this enlarges the element to fit it's content
  box.style.height = "auto";

  // we got our desired height property!
  const height = getComputedStyle(box).height;

  // set the height back to where it was (reset)
  box.style.height = "";

  // set the final height in next animation frame
  requestAnimationFrame(() => {
    requestAnimationFrame(() => {
      box.style.height = height;
    });
  });
});

Think of it like in the next frame, we've queued an animation that'll run on the next frame. I know it sounds weird but that used to solve lots of problems since it has a bug in Chrome too.

That's the wrap! As you can see in a modern world where we have WAAPI, transitions and getComputedStyle still have their use! It's a bit nasty to understand at start but it has it's own way of doing things, what can I say!

Sources:
Transition to Height Auto With Vue.js by Markus Oberlehner
Need cheap paint? Use getComputedStyle().opacity by Webventures

Simple & Elegant State-Management with Zustand

Halil Durak — Wed, 06 Mar 2024 17:39:24 +0000

Have you ever wanted to learn state-management but it felt so overwhelming to get started with Redux? Or maybe you're already using Redux but don't want to take the burden anymore? If so, you might want to take a shot at Zustand! Its an amazing state management library that's easy to get started and maintain in a long run. In this post, we'll dive into creating & sharing stores with this tiny Redux alternative.

Why Zustand?

Small & Performant
Beginner friendly
Rapidly adopted by Frontend devs

In this tutorial, we'll see usage of Zustand directly on React (via Vite). I'll likely add another chapter for using it with Next.js too.

Setup

Fire up your favorite code editor and let's get started! We'll first need to create a fresh project and install the library. I'll be using Node.js as runtime and Bun as package manager throughout the tutorial. You can use whatever suits to you!

$ bun create vite
✔ Project name: … zustand-episode-1
✔ Select a framework: › React
✔ Select a variant: › TypeScript + SWC

Scaffolding project in zustand-episode-1...

Done. Now run:

  cd zustand-episode-1
  bun install
  bun run dev

After you've installed the dependencies, install the Zustand as the following:

bun add zustand

Cool! I've also removed everything inside App.css, index.css and App component:

function App() {
  return <></>;
}

export default App;

Creating a Store

What we need first is a store. Store is where we put our states and methods. Its possible to keep primitives, objects and functions in them. Import create from Zustand and create your own:

import { create } from "zustand";

const useCountStore = create(() => ({ count: 0 }));

function App() {
  const count = useCountStore((state) => state.count);

  return <>{count}</>;
}

export default App;

Notice that create takes a callback that returns an object (It is () => ({}) not () => {}). The object we return is our store. create function also gives back a hook that we can use to access our store. Inside the App component, we have used the hook to retrieve the count.

That's cool but surely we'd like to mutate the count.

Store Actions

The callback we've passed to create can optionally take set argument which is a function that we can use to mutate our state. Modify the useCountStore hook as the following:

const useCountStore = create((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
  decrement: () => set((state) => ({ count: state.count - 1 })),
}));

Let's run it down;

increment is a function that calls set,
set takes state as an argument which is the current state (similar to set function we get from useState) and returns a new object where the it takes state.count and increments by 1,
same applies to decrement but instead it decrements the count by 1.

Now that we've created our actions, let's use them in our component to mutate the count. We can access to our actions like this:

function App() {
  const count = useCountStore((state) => state.count);
  const increment = useCountStore((state) => state.increment);
  const decrement = useCountStore((state) => state.decrement);

  ...

Or, we can take advantage of destructive assignment:

function App() {
  const { count, increment, decrement } = useCountStore();

  ...

Much cleaner! I've also created a barebones interface to play around:

function App() {
  const { count, increment, decrement } = useCountStore();

  return (
    <>
      {/* Count value */}
      <span>{count}</span>
      <br />
      {/* Button that increments the count value */}
      <button type="button" onClick={increment}>
        increase
      </button>
      {/* Button that decrements the count value */}
      <button type="button" onClick={decrement}>
        decrease
      </button>
    </>
  );
}

You should be able to see the current count value and increment/decrement it.

Accesing the Store from Another Component

If we're persisting a store outside of our component, we most likely want to access it from some other component. This is also one of the great things about using a state manager, it avoids prop drilling.

Right now our store lives inside App.tsx. Let's start by moving it to somewhere else. How about a stores folder inside src? That sounds like a good idea. Or, we could approach it just like an hook and move it to hooks folder. I'll go with the former but like I said earlier, whatever suits. My folder structure looks like this now:

node_modules/
public/
src/
  stores/
    count-store.ts
  App.tsx
  main.tsx
  ...

In stores/count-store.ts, I've took the code for our store and pasted it there. Then I've added export keyword right before useCountStore declaration.

stores/count-store.ts

import { create } from "zustand";

export const useCountStore = create((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
  decrement: () => set((state) => ({ count: state.count - 1 })),
}));

While at it, we can also add some typing to make our code more understandable:

stores/count-store.ts

import { create } from "zustand";

// States are typed here
interface CountState {
  count: number;
}

// Actions (or functions) are typed here
interface CountActions {
  increment: () => void;
  decrement: () => void;
}

// We create a unified type from them
type CountStore = CountState & CountActions;

// Indicate the type here
export const useCountStore = create<CountStore>((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
  decrement: () => set((state) => ({ count: state.count - 1 })),
}));

This is self-explanatory. If you didn't know, & in TypeScript merges the types.

Let's also create a new component in src named Counter.tsx and fill it in with the following:

src/Counter.tsx

import { useCountStore } from "./stores/count-store";

export default function Counter() {
  const count = useCountStore((state) => state.count);

  return <span>{count}</span>;
}

Sole purpose of this component is to show count value, I'm aware that we're already doing it in App but the idea here is to show that we can access the same store from some other component.

In App.tsx, import our Counter component and render it alongside our buttons:

import Counter from "./Counter";
import { useCountStore } from "./stores/count-store";

function App() {
  const { increment, decrement } = useCountStore();

  return (
    <>
      {/* Count value */}
      <Counter />
      <br />
      {/* Button that increments the count value */}
      <button type="button" onClick={increment}>
        increase
      </button>
      {/* Button that decrements the count value */}
      <button type="button" onClick={decrement}>
        decrease
      </button>
    </>
  );
}

export default App;

Notice that we're only mutating the count in App.tsx. The rendering of count is moved to Counter.tsx and it still works perfectly! If our tree would be deeply nested, it still won't be a problem for us to access our store and read/mutate the state.

That's it for part 1. I hope you got the hang of Zustand and liked it! In the follow-up, we'll be trying to integrate React Context API to this and I'll also show you how you can use Zustand in your Next.js apps. Take care!