A short guide explaining how to build a modern, cross-browser extension with web development tools like TypeScript, Tailwind, and Vite.

Building modern browser extensions with Vite and Tailwind CSS

Browser extensions have become an integral part of our lives. We use extensions to customize browsers to our liking, whether we need to add a missing functionality or tweak their looks.

Essentially, extensions are just autonomous web pages browsers render in popup windows. Using all the goodies from traditional web development like TypeScript, Tailwind, or Vite should be easy, right? Well, yes, but it might be tricky to set up, especially when building a cross-browser extension or you want to use specific features such as [HMR](https://webpack.js.org/concepts/hot-module-replacement/).

Thankfully you're just one of many struggling with this, and already existing solutions make this process much more manageable. This article will give you insight into a straightforward way of building cross-browser extensions using the latest frontend tech stack.

## Setting up the browser extension

I recommend setting up the development environment with the Vite plugin [`@samrum/vite-plugin-web-extension`](https://github.com/samrum/vite-plugin-web-extension). This plugin solves compatibility issues you would typically have to deal with yourself. To be precise, the plugin allows you to:

* Quickly bootstrap Manifest V2 and V3 browser extensions.
* Build the extension with ES modules.
* Import and use static assets as you would in a regular Vite application.
* Use HMR and Fast Refresh.

The plugin also has an `init` command, which will let you choose the Manifest version, whether or not you want to use TypeScript and the framework of your choice (React, Preact, Vue, Svelte, or no framework at all).

```
npm init @samrum/vite-plugin-web-extension@latest
```

What Manifest version you should choose depends mainly on your requirements.

Manifest V2 is tried and tested and has looser limitations than newer Manifest V3. However, the Manifest V2 is approaching its end of life, although the day when the Chrome Web Store will stop accepting Manifest V2 extensions has been postponed, and no new date has been set yet.

On the other hand, Manifest V3 has [significantly changed](https://developer.chrome.com/docs/extensions/mv3/intro/) what and how extensions can behave. The support on Chromium-based browsers is quite good already, but other browser families support Manifest V3 only partially or not at all. Firefox, for example, [publicly states](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Build_a_cross_browser_extension) the work is still in progress and subject to change.

## Adding useful dependencies

Depending on whether you are building a cross-browser extension, I recommend installing the `webextension-polyfill` package. This package will let you use the exported `browser` API, which follows the standards set by the W3 Browser Extensions group. Theoretically, this will allow you to use one API that works on Chrome, Firefox, and possibly other browser families. However, be aware it's not a 1:1 replacement for the [`chrome` API](https://developer.chrome.com/docs/extensions/reference/) as it lacks support for some APIs only available on Chrome.

```
npm i webextension-polyfill
```

If you don't need cross-browser support and have chosen to use TypeScript, I recommend installing the `@types/chrome` package, which will provide you with types for the `chrome` API.

```
npm i --save-dev @types/chrome
```

The last helpful dependency I'd like to recommend, although a bit more specialized, is the `user-agent-data-types`. It extends the `navigator` interface type with a new `navigator.userAgentData` API, which lets you query information about the user-agent (browser, platform).

```
npm i --save-dev user-agent-data-types
```

## Adding Tailwind CSS

To add Tailwind, follow their [installation guide](https://tailwindcss.com/docs/installation/using-postcss). I recommend using PostCSS as the experience felt the most seamless to me. Once you are done with the installation, you must import the stylesheets to the popup and/or options views. You can either import it in the JS main JS file or directly in HTML. For example, this is how you could import it in the popup UI's `App.tsx`.

```
import PageContent from '~/components/PageContent';
import '../../styles.css'; // 👈 A CSS file containing `@tailwind` directives

function App() {
  return (
    <main>
      <PageContent>Popup</PageContent>
    </main>
  );
}

export default App;
```

## Conclusion

The experience of developing a web application is much less cumbersome than it used to be 5 or 10 years ago. We've grown used to modern JavaScript frameworks like React or Vue, build tools like Vite, or CSS frameworks like Tailwind. Although the environment of browser extensions is somewhat special, there are existing tools that allow us to use all these tools to build modern browser extensions quickly.

A complete example built around `vite-plugin-web-extension` with React, Taiwind CSS, and other before-mentioned packages is available at [https://github.com/jozefhruska/browser-extension-example](https://github.com/jozefhruska/browser-extension-example).

A big shoutout and thanks go to Ruben Medina ([@samrum](https://github.com/samrum)) and all the contributors for making this possible!

Take a look at how git history can be improved by rebasing interactively. Join us in learning about this powerful feature and how to properly use it.

Saying goodbye to messy git history: Git Interactive Rebase

Hey, have you heard about Git interactive rebase? If you haven't, let's dive into it together. It's a true game-changer! You can use it to clean up your commit history and make it easier to understand at a glance. You also get more control over your commits, which means you can fix mistakes in your commit messages or break up big, complicated commits into smaller, bite-sized chunks.

It's like being a wizard who can shape the history however you want. Don't get me wrong, merging is cool and perfectly okay, but if you really want to take your Git history to the next level, you gotta try out Git interactive rebase.

## What is rebasing, and how does it differ from traditional merging?
So, when you merge branches in Git, you take all the changes from one branch and apply them to another. This creates a new "merge commit" that combines the changes from both branches. The downside is that your commit history can get cluttered with a bunch of these merge commits, which can make it harder to follow the evolution of your code.

Rebasing, on the other hand, lets you apply the changes from one branch onto another, as if they had been developed in sequence. This makes it look like the changes were always part of that branch from the beginning. Rebasing is great for cleaning up your commit history, because it can help you avoid creating a bunch of unnecessary merge commits. Plus, it can make it easier to keep track of the changes in your code over time.

So, while merging can be useful for bringing changes together, rebasing can help you keep your commit history cleaner and more organized. Both have their place in the Git world, but if you want to make your commits more coherent and easier to understand, rebasing might just be your new best friend!

![](https://images.prismic.io/webscopeio/fa931c64-0cc5-44ed-94f3-19b67e343c78_merge-vs-rebase.png?auto=compress,format)

## Interactive rebase: The hidden superweapon
Now that you have a concept of how traditional rebasing works, it's time to introduce a new champion into the arena: Interactive Rebase. Interactive rebasing allows selectively editing, reordering, combining, or deleting commits, providing more control over the Git history, while using the traditional rebasing under the hood to make it all possible.

The way it works is that it gets rid of the past commits and mimics them with the changes that you ordered when making new ones. And all while doing that, it rebases all the changes on the branch of your choosing. It's a perfect way to modify your own git history while staying up-to-date with the underlying base branch. Perfect!

Let's look at how a PR's commit history can look when using the merge strategy for keeping it up to date. Also, if we don't use interactive rebase, once a commit is pushed onto the remote, it's there - forever. There's no going back once it's whooshed up there.

![Example of dirty commit history](https://images.prismic.io/webscopeio/3633fcab-5d40-4094-8c26-993678c8149f_dirty-commit-history.png?auto=compress,format)

There's a lot of commits, small one-liner fixes that I've found when developing other things, and merge commits that keep the branch up to date with the base branch. Yuck. While you can see how I proceeded with my work, the history is really cluttered and if all of those commits were pasted onto the master branch without squashing the commits, I bet it would confuse the soul out of my colleagues.

## Now let's build a PR with Interactive rebasing in mind
I'll be using the Fork git client to better illustrate what I'm doing with the commits. Here's how I created the commits. This isn't something that I'd like my colleagues or clients to see! Let's interactively rebase this branch on “master”, to get the ability to edit our existing commits, while pulling the latest changes from master to stay up-to-date.

![Git Interactive Rebase process - step 1](https://images.prismic.io/webscopeio/85f06acf-24b2-4295-93dd-22810288ed6e_gir-1.png?auto=compress,format)

So, how do we make this mess look beautiful? Take a look at the dropdown menu with the green indicator and “Pick” word on it.

![Git Interactive Rebase process - step 2](https://images.prismic.io/webscopeio/db4f8362-9270-4615-bfa8-04a1ef4f1206_gir-2.png?auto=compress,format)

All of these options indicate a transformation for the commit that will happen during the rebasing process. If we were to rebase this branch straight-away, all of our commits will be “Picked”, meaning that nothing will change. Fork nicely explains how each of the actions transform the commit.

This is what we will do with this particular branch, to simplify things a little bit:

![Git Interactive Rebase process - step 3](https://images.prismic.io/webscopeio/6bd4af83-fe8b-47be-b8e0-479e040d9aba_gir-3.png?auto=compress,format)

We used the “Fixup” action to meld our commits one-by-one into the first one. When that was done, we had only one commit, but with an out-of-date (and quite ugly) commit message. So we reworded it into a nicely formatted, simple commit message. Yay! Now we can push the branch and create a PR. This is how the commit history looks now:

![Example of clean commit history](https://images.prismic.io/webscopeio/82d01984-66e9-48f9-bcac-df85dacfd0c6_clean-commit-history.png?auto=compress,format)

It feels good to have absolute control over your commits, doesn't it? If you find something to fix in retrospect, you absolutely can do it properly and add the fixing change into the former commit. 

If you want, you can have more commits in your PR's, for example one for your components, second for your type definitions, and a third for a helper function that you've just implemented. Or you can have it all at once in one bigger commit, that will be self-explanatory when merged onto the master branch. It's your call - you have all the freedom and tools to do it.

## Handle with care!
As powerful as Git interactive rebase is, it's sadly not all-mighty. There's definitely some borders to stay in when you're going ham on your git history. 

> The most important thing to remember is that you can only edit your local commits.

You can feel free to do whatever you want with commits that aren't yet on the origin, but once they're pushed onto the origin, you should take great care when manipulating them. If you really need to overwrite git history that's already pushed on the origin, you'll have to pull the branch, overwrite your commits locally with the interactive rebase, and then do a force push back onto the branch.


Solely the fact that you have to force push is an exclamation mark by itself, but let me emphasise on this once again: 

> In this case you'll be overwriting history that someone else could've based their work on.

Be sure to double check with the rest of your team that it's ok to overwrite the section you're working on, and that it won't cause any headaches for someone.

## Commit away!
Now that you know about Interactive rebasing and what it can do, there's nothing stopping you from making your git history clear and purposeful. Your mates will love to do code reviews on your branch because of the clarity, trust me on that. I was surprised how such a powerful feature is not so widely known among developers. It certainly changed my approach to commits, and I hope to have brought you fresh new information, so you can perhaps change yours.


Server rendering or Server components? What about both in parallel? Let's compare these two technologies and discuss the do's, don's and how each really works.

Server Components vs. SSR in Next.js

# Foreword

I recently published [an article](https://blog.jankoritak.com/so-why-server-components), in which I discuss the core ideas behind React@18's Server Components. I'd say the article is one of the chunkier ones. It discusses the limitations of React's Client Components and how the Server Components help us mitigate these limitations.

Overall, Server Components are an exciting shift to the React (and Next.js) ecosystem. A next step, that'll enable us - the engineers - to benefit from a new concept with only a slight pivot to the APIs we're used to. Although, the other important question is how severe a mindset shift will the concept require?

Server Components are one more weapon in the already stacked arsenal of today's front-end engineers. Next.js already exposes SSR (Server-side rendering), SSG (Static-site generation), and ISR (Incremental static regeneration). Let's discuss, how RSC (React Server Components) fit into this arsenal and how they work together with the rest of the technologies.

![](https://images.prismic.io/webscopeio/5a04bcac-ff19-4723-8f8b-72c8566ec828_next-js-tech.png?auto=compress,format)

Let's jump right into it, shall we?

# SSR vs. RSC

The names and the abbreviations look similar. However, the idea behind both differs significantly. Moreover, you can even leverage both concepts in parallel!

Let's compare the two concepts for these aspects:

* **When to use** them?
* **What is the output** of each?
* **When is the output built?**
* **What's the granularity?**
* **How to use** them in Next.js?

## When to use them?

Should we use server-side rendering or a set of server components? Well, what about using both?

### SSR

Let's start with SSR. A side note: Next.js uses the term "Dynamic pre-rendering" in place of SSR.

To describe SSR in layman's terms:

> The purpose of SSR is to give the user something to look at before JS is executed.

SSR splits the rendering process into two parts:

1. (Pre)rendering HTML. (server-side)
2. Hydrating the HTML with JS to achieve interactivity. (client-side)
    

The HTML is dynamically pre-rendered on the server and then sent to the client along with JS bundle(s) and other assets.

This way, we can present the user with at least a non-interactive website (that usually looks pretty close to the final product) for that couple (hundred) milliseconds, that it takes the browser to load, parse and execute JS.

The motivation behind SSR should be obvious. It's always better to show the user something "tangible" rather than a blank screen. Or do you prefer this?

![Spinner example](https://images.prismic.io/webscopeio/540c8f47-2c98-47ee-9842-01f817249971_spinner.gif?auto=compress,format)

There are also other classes of benefits, such as better SEO. Not all of today's search engines execute JavaScript when generating page scores, right?

### RSC

On the other hand, RSC (React Server Components) is a concept that allows us to decide per component, what to render on the server, and what to render on a client. There is no direct relationship between SSR and RSC. [Taking words from the RFC](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md#does-this-replace-ssr), these two are **not supposed to be antagonists, but rather complementary**. Meaning, you can even use both simultaneously!

As for the usage, the rule of thumb is to use Server Components by default, over Client Components and use Clients Components only for:

* Encapsulating interactive behavior
* Interacting with browser APIs

If you're interested in why is it better to render your components on the server by default, you can read my [other article](https://blog.jankoritak.com/so-why-server-components) or take a look at [Next.js docs](https://beta.nextjs.org/docs/rendering/server-and-client-components#server-components).

## What is the output?

Server-side rending is an established pattern in the front-end world. The Server Components are still quite new and as for implementation quite interesting. Let's look into why!

### SSR

This is quite intuitive. **The output of SSR is HTML**, which is generated on the server side. The markup does not have to be static, it can depend on the dynamic data available at the time of the request!

This allows us to transfer leaner chunks of data to the client and build more responsive pages on slower devices, resp. connections.

![SSR chart](https://images.prismic.io/webscopeio/4d17f66e-f391-4151-86f2-1442e03a9f93_ssr-chart.png?auto=compress,format)

### RSC

Here comes something new!

The intuitive train of thought here could be that since a React Server Component is just a component, that is rendered on the server, the output could be markup (the same as for server-side rendering), but just a smaller chunk, right? This is a perfectly reasonable train of thought and could as well work, however, this is not how server components work.

The reality is, that instead of a markup-type notation, the React team decided to go with a custom implementation for the RSC serialization format. The result is a custom JSON-like notation that is supposedly simpler to work with (internally) and suited better for transferring components over the network barrier.

Here's an example of a serialized server component.

```json
M1:{"id":"./src/SearchField.client.js","chunks":["client5"],"name":""}
M2:{"id":"./src/EditButton.client.js","chunks":["client1"],"name":""}
S3:"react.suspense"
J0:["$","div",null,{"className":"main","children":[["$","section",null,{"className":"col sidebar","children":[["$","section",null,{"className":"sidebar-header","children":[["$","img",null,{"className":"logo","src":"logo.svg","width":"22px","height":"20px","alt":"","role":"presentation"}],["$","strong",null,{"children":"React Notes"}]]}],["$","section",null,{"className":"sidebar-menu","role":"menubar","children":[["$","@1",null,{}],["$","@2",null,{"noteId":null,"children":"New"}]]}],["$","nav",null,{"children":["$","$3",null,{"fallback":["$","div",null,{"children":["$","ul",null,{"className":"notes-list skeleton-container","children":[["$","li",null,{"className":"v-stack","children":["$","div",null,{"className":"sidebar-note-list-item skeleton","style":{"height":"5em"}}]}],["$","li",null,{"className":"v-stack","children":["$","div",null,{"className":"sidebar-note-list-item skeleton","style":{"height":"5em"}}]}],["$","li",null,{"className":"v-stack","children":["$","div",null,{"className":"sidebar-note-list-item skeleton","style":{"height":"5em"}}]}]]}]}],"children":"@4"}]}]]}],["$","section","null",{"className":"col note-viewer","children":["$","$3",null,{"fallback":["$","div",null,{"className":"note skeleton-container","role":"progressbar","aria-busy":"true","children":[["$","div",null,{"className":"note-header","children":[["$","div",null,{"className":"note-title skeleton","style":{"height":"3rem","width":"65%","marginInline":"12px 1em"}}],["$","div",null,{"className":"skeleton skeleton--button","style":{"width":"8em","height":"2.5em"}}]]}],["$","div",null,{"className":"note-preview","children":[["$","div",null,{"className":"skeleton v-stack","style":{"height":"1.5em"}}],["$","div",null,{"className":"skeleton v-stack","style":{"height":"1.5em"}}],["$","div",null,{"className":"skeleton v-stack","style":{"height":"1.5em"}}],["$","div",null,{"className":"skeleton v-stack","style":{"height":"1.5em"}}],["$","div",null,{"className":"skeleton v-stack","style":{"height":"1.5em"}}]]}]]}],"children":["$","div",null,{"className":"note--empty-state","children":["$","span",null,{"className":"note-text--empty-state","children":"Click a note on the left to view something! 🥺"}]}]}]}]]}]
M5:{"id":"./src/SidebarNote.client.js","chunks":["client6"],"name":""}
J4:["$","ul",null,{"className":"notes-list","children":[["$","li","1",{"children":["$","@5",null,{"id":1,"title":"Meeting Notes","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"This is an example note. It contains Markdown!"}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"Meeting Notes"}],["$","small",null,{"children":"12/30/20"}]]}]}]}],["$","li","2",{"children":["$","@5",null,{"id":2,"title":"A note with a very long title because sometimes you need more words","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"You can write all kinds of amazing notes in this app! These note live on the server in the notes..."}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"A note with a very long title because sometimes you need more words"}],["$","small",null,{"children":"12/30/20"}]]}]}]}],["$","li","3",{"children":["$","@5",null,{"id":3,"title":"I wrote this note today","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"It was an excellent note."}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"I wrote this note today"}],["$","small",null,{"children":"12/30/20"}]]}]}]}],["$","li","4",{"children":["$","@5",null,{"id":4,"title":"Make a thing","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"It's very easy to make some words bold and other words italic with Markdown. You can even link to React's..."}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"Make a thing"}],["$","small",null,{"children":"12/30/20"}]]}]}]}],["$","li","6",{"children":["$","@5",null,{"id":6,"title":"Test Noteeeeeeeasd","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"Test note's text"}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"Test Noteeeeeeeasd"}],["$","small",null,{"children":"11/29/22"}]]}]}]}],["$","li","7",{"children":["$","@5",null,{"id":7,"title":"asdasdasd","expandedChildren":["$","p",null,{"className":"sidebar-note-excerpt","children":"asdasdasd"}],"children":["$","header",null,{"className":"sidebar-note-header","children":[["$","strong",null,{"children":"asdasdasd"}],["$","small",null,{"children":"11/29/22"}]]}]}]}]]}]
```

To some extent, the format is quite readable, we can see that our component consists of:

* Two atoms - a `div` and an `ul`. **These are Server Components, pre-rendered on the server!**
    
* A suspense boundary. Not so interesting in this context.
    
* Two pointers to a Client Component (`SearchField` and `EditButton`). **These will be rendered on the client.**
    

Here's how could update the diagram from above to reflect the server component architecture. Notice that Server Components can be streamed to the client in parts.

![RSC chart](https://images.prismic.io/webscopeio/cb07acc1-49ff-4201-945e-700077248d54_rsc-chart.png?auto=compress,format)

## When is the output built?

We discussed what the output looks like. We now know that SSR returns markup, but RSC interestingly enough returns a custom JSON-like notation! Both are obviously built on the server, but each one of them is built in a different part of the flow.

### SSR

If you paid attention, we already touched on this topic in the previous paragraphs. The SSR-produced markup is **produced at the requested time**. This is the reason, why SSR is also called "dynamic pre-rendering", as opposed to "static pre-rendering" (aka. SSG), which produces the markup statically, **at build-time**.

The flow goes:

1. The client requests a page from the server.
2. The **server pre-renders HTML** and bundles JS.
3. The assets are passed to the client.
4. The static markup is rendered.
5. The static markup is hydrated with JS.

![SSR time chart](https://images.prismic.io/webscopeio/dcdc39ab-0148-4c18-8889-2ef3a9e80d5b_ssr-time-chart.png?auto=compress,format)

### RSC

The server components are more asynchronous and streamable. By design, they are also more granular (we'll touch on this more in the upcoming paragraph), so when there is an UI interaction, that requires a component on the server side, the component is requested by the client, build dynamically on the server and streamed back to the client as an atomic chunk.

If we combine the flow with server-side rendering, we end up with:
1. The client requests the output from the server.
2. The server pre-renders HTML and bundles JS.
3. The assets are passed to the client.
4. The static markup is rendered.
5. The static markup is hydrated with JS (state and event handlers attached to the DOM).
6. ✨ *An UI interaction happens.* ✨
7. **Client requests the relevant RSCs to from the server.**
8. **RSCs rendered and serialized on the server and passed to the client.**
9. **RSCs are hydrated into the current web page.**

![RSC time chart](https://images.prismic.io/webscopeio/841052b7-c9e8-4244-a721-41cfbe6ddd45_rsc-time-chart.png?auto=compress,format)

Note: The initial chunk can also contain server components. I chose to demonstrate this on an example, where the components are rendered as a result of an user interaction with the page.

## **What's the granularity**?

How granular are the SSR and RSC outputs? This is a straightforward one.

### SSR

We can say that the granularity of SSR is 1. By this, we mean that for 1 page, there is only 1 request/response pair that returns the initial server-rendered markup.

After the initial portion of markup is rendered, the SSR served its purpose and is no longer needed.

![SSR has granularity of 1](https://images.prismic.io/webscopeio/94927789-d662-41b4-bc5c-f4793b3fb4b9_ssr-granularity.png?auto=compress,format)

### RSC

Oppositely to SSR, the granularity of RSC &gt;= N, where N is the number of server components used on the page. I'm including the `>=` operator, as one component may be rendered multiple times. Hopefully, it's cached.

The RSCs allow us to render little pieces of the page on the server and stream them to the client in small chunks, which brings [many benefits.](https://blog.jankoritak.com/so-why-server-components) The more chunks we decide to defer to the server, the more granularity we introduce. The point is, there is no upper limit to this.

![SSR has granularity of >=N](https://images.prismic.io/webscopeio/d4d44c1e-898b-491c-8ccc-a0d7b522f615_rsc-granularity.png?auto=compress,format)

## How to use them in Next.js?

Let's talk practice. How do you even trigger SSR or render a Server Component in Next.js? At the time of writing this article, no other frameworks support Server Components out of the box. Of course, you can still configure your server to handle them!

### SSR

Next.js is quite an advanced framework, that pre-renders every page by default. Moreover, it lets you choose, whether you want to pre-render statically (during build time) or dynamically (during request time).

* Use `getStaticProps` and `getStaticPaths` for SSG (default)
* Use `getServerSideProps` for SSR

![Example of getServerSideProps from Next.js docs](https://images.prismic.io/webscopeio/f3902c0e-10b5-466f-b4b4-9fc75d07fb60_ssr-code.png?auto=compress,format)

### RSC

As mentioned before, Next.js takes a stance of treating every component as a Server Component by default. If you want to use a Client Component, you'll need to annotate the file with `use client;` [directive](https://github.com/reactjs/rfcs/pull/227) at the top of the component file.

Also, don't forget that the concept is only available in Next.js@13 `app` directory. You cannot leverage it inside the good old `pages` directory.

![Example of a client component takes from Next.js docs](https://images.prismic.io/webscopeio/b018937b-7b05-42cb-b347-1257313f4f4a_rcc-code.png?auto=compress,format)

# Conclusion

Opposed to my [previous article](https://blog.jankoritak.com/so-why-server-components) which attempts to discuss the benefits of server components in-depth, the idea of this article was to provide answers to quite basic questions that may pop up to a developer who is new to the concept.

Hopefully, I hit the nail on the head at least partially and the article did help you grasp the concept a bit better.

If you'd like to catch up with me, [I'm active daily on Twitter.](https://twitter.com/JanKoritak)

React applications are built from components. Generally, components are built using Hooks, whether they are built-in or custom.

Building React Hooks - Copy to Clipboard

How many times have you seen out there in the wild the need to copy to the clipboard? Whether it's a piece of code (no shame if it's from StackOverflow 💁🏻‍♂️ *cough cough*), a URL you want to share 💅🏻, or a simple text you need to refer elsewhere 🤓. 

The easiest way to reduce friction in having something copied to the clipboard is by enabling buttons, and we all know that "Copy to clipboard" buttons are literally everywhere. So today we'll design a *React Hook* that enables our application to interact with the user's clipboard. Why hooks? 🤷🏻‍♂️

> React applications are built from components. Generally, components are built using Hooks, whether they are built-in or custom.

A quick refresher on what you need to know about React Hooks:
* All your Hooks should be written in `camelCase` and starting with `use`, such as `useState`. If your [linter is configured for React](https://react.dev/learn/editor-setup#linting), it should help you with this.
* Hooks can only be called at the top level (before any returns). They shouldn't be called inside loops, conditions, or nested functions.
* Only Hooks and components can call other Hooks! Therefore, functions that don’t _call_ Hooks don’t need to _be_ Hooks. You don't need hooks for everything.

## Why Custom React Hooks?

Integrating custom React hooks that can be incredibly useful in different use cases. Here are a few examples:
* `useLocalStorage`: This hook provides an easy way to store and retrieve data in the browser's localStorage. This can be useful for persisting data across sessions or keeping track of user preferences.
* `useMedia`: This hook allows you to query the media query string and return a boolean indicating whether it matches or not. This can be useful for implementing responsive design, hiding or showing elements based on screen size, or dynamically changing styles.
* `usePrevious`: This hook allows you to keep track of the previous value of a state variable. This can be useful when you need to compare the current and previous values and trigger a side effect based on the difference.
* `useAsync`: This hook allows you to easily manage asynchronous operations with error handling, loading and data states. This can be useful for making API calls or handling long-running operations.
* `useDebounce`: This hook lets you debounce the execution of a function by a specified delay. This is useful when you have an input field that triggers a search query, but you don't want to make the API call on every keystroke.

There are many other custom hooks available that can help you simplify your code and make it more reusable. The best hooks to use will depend on your specific use case and requirements.

## How to use `Clipboard.writeText()`

The [`Clipboard`](https://developer.mozilla.org/en-US/docs/Web/API/Clipboard) interface's **`writeText()`** property writes the specified text string to the system clipboard.

```js
navigator.clipboard
  .writeText("Text to copy")
  .then(()=> /* Clipboard successfully set */)
  .catch((err) => /* Clipboard write failed */);
```

If we go ahead and integrate this directly into a button, it could look something like this:

```tsx
import React from "react";
import { CopyIcon, ErrorIcon, SuccessIcon } from "@/components/icons";

export const CopyButton = ({ 
    textToCopy, 
    children 
  }: { 
    textToCopy: string, 
    children?: React.ReactNode 
  }) => {
  const [clipboardState, setClipboardState] = React.useState<boolean | Error>(false);
  return (
    <button
      onClick={() => {
        navigator.clipboard
          .writeText(code)
          .then(() => setClipboardState(true))
          .catch((e) => setClipboardState(e));
      }}
    >
      {children}
      {clipboardState ? (
        clipboardState instanceof Error ? <ErrorIcon /> : <SuccessIcon />
      ) : (
        <CopyIcon />
      )}
    </button>
  );
};
```

We could call it a day, but we can do better. At a simple glance, here's what we would need:
* ⛔️ Check for support on `navigator.clipboard`. Even if we abstract this logic into a handler function our component would start to get messy.
* ⛔️ We aren't resetting our UI after the operation. Setting a timeout would come in handy but this would require even more code.
* ⛔️ The more this functionality is required in our codebase, the harder it'll get to adopt and maintain.

## Creating a Custom Hook

> Custom Hooks should abstract as much logic as possible from the component that interacts with build-in React Hooks. We should only expose exactly what the UI needs to call the operation and provide the right feedback to the user.

Here is what our custom hook will do:
* ✅ `navigator.clipboard` support check before executing operations;
* ✅ Handle automatic resets after interacting with the clipboard;
* ✅ Keep a simple and straight-forward hook to consume anywhere in our codebase.

```ts
import React from "react";
type CopyState = "READY" | "SUCCESS" | Error;

export const useClipboard = ({ delay = 2500 } = {}) => {
  const [state, setState] = React.useState<CopyState>("READY");
  const [copyTimeout, setCopyTimeout] =
    React.useState<ReturnType<typeof setTimeout>>();

  function handleCopyResult(result: CopyState) {
    setState(result);
    clearTimeout(copyTimeout);
    setCopyTimeout(setTimeout(() => setState("READY"), delay));
  }

  function copy(valueToCopy: string) {
    if ("clipboard" in navigator) {
      navigator.clipboard
        .writeText(valueToCopy)
        .then(() => handleCopyResult("SUCCESS"))
        .catch((error) => error instanceof Error && handleCopyResult(error));
    } else {
      handleCopyResult(
        new Error("`useClipboard`: Navigation Clipboard is not supported")
      );
    }
  }

  return { copy, state };
};
```

## Is there a one-size-fits-all design approach?

> Following patterns/conventions helps your consumer to understand what your hook does and where state, Effects, and other React features might be “hidden”. However, React Hooks may return arbitrary values.

Notice we aren't returning a traditional tuple `[value, setValue]`. Although, depending on the use case, it may be favorable to follow this design. Additionally, we could expose other methods/values in our hook depending on our application's needs. 

Here are other options you can choose to build in and provide to your consumers:
* `isClipboardSupported` to indicate whether or not the component can use the clipboard;
* `copiedText` to provide feedback on what's in the clipboard by using `clipboard.readText()`;
* `reset()` method to reset failed operations.

As-is, with this abstraction in place, this is how all components that require clipboard interaction would look like with `clipboard.copy` and `clipboard.state`.

```tsx
import React from "react";
import { CopyIcon, ErrorIcon, SuccessIcon } from "@/components/icons";
import { useClipboard } from "@/hooks";

export const CopyButton = ({ 
    textToCopy, 
    children 
  }: { 
    textToCopy: string, 
    children?: React.ReactNode 
  }) => {
  /* ⬇️ Methods are now available to copy and check the hook's state */
  const clipboard = useClipboard();
  return (
    <button onClick={() => clipboard.copy(textToCopy)}>
      {children}
      /* ⬇️ Type autocompletion will make it easy to structure your UI */
      {clipboard.state === "READY" && <CopyIcon />}
      {clipboard.state === "SUCCESS" && <SuccessIcon />}
      {clipboard.state === "ERROR" && <ErrorIcon />}
    </button>
  );
};
```

## Bonus Hook - Set and Clear Timeouts

Yes, you don't need hooks for everything, but there is still an additional level of abstraction we could achieve here. Notice how `useClipboard` clears and calls a timeout every single time the button is used. Executing a function after a specified delay is also a very common use case in React applications. So let's take it a step further and design a bonus hook: `useTimeout`.

Let's jot down what would we want from a `useTimeout` hook:
* ✅ Methods to call and cancel a given timeout;
* ✅ Control between timeouts; 
* ✅ Avoid triggering unnecessary re-renders.

This is a perfect use case to write a hook that interacts with `useRef`. Why? (a) Unlike state, refs are mutable and (b) Refs are not required for and don't trigger re-renders.

>Normally, writing or reading `ref.current` during render is not allowed. However, it’s fine in the case below because the result is always the same, and the condition only executes during initialization so it’s fully predictable.

```ts
import React from "react";

export const useTimeout = (callback: Function, delay: number) => {
  const callbackRef = React.useRef<Function | null>(null);
  const timeoutIdRef = React.useRef<number | null>(null);

  /* ⬇️ Only executed during initialization */
  if (!callbackRef.current) {
    callbackRef.current = callback;
  }

  const call = React.useCallback(() => {
    if (!timeoutIdRef.current) {
      timeoutIdRef.current = window.setTimeout(() => {
        callbackRef.current && callbackRef.current();
        timeoutIdRef.current = null;
      }, delay);
    }
  }, [delay]);

  const cancel = React.useCallback(() => {
    if (timeoutIdRef.current) {
      window.clearTimeout(timeoutIdRef.current);
      timeoutIdRef.current = null;
    }
  }, []);

  return { call, cancel };
};
```

This hook could be improved as well. For instance, we could choose to provide our consumers with the option to `autoInvoke` the hook without having to call it. As-is though, our `useClipboard` and codebase can benefit from this abstraction. Here's how to use this one:

```ts
import React from "react";
import { useTimeout } from "@/hooks";

type CopyState = "READY" | "SUCCESS" | Error;

export const useClipboard = ({ delay = 2000 } = {}) => {
  const [state, setState] = React.useState<CopyState>("READY");
  /* ⬇️ We consume our hook passing the needed params */
  const timeout = useTimeout(() => setState("READY"), delay);

  function handleCopyResult(result: CopyState) {
    setState(result);
    /* ⬇️ We call the timer and leave the rest to the hook */
    timeout.call();
  }

  function copy(valueToCopy: string) {
    if ("clipboard" in navigator) {
      navigator.clipboard
        .writeText(valueToCopy)
        .then(() => handleCopyResult("SUCCESS"))
        .catch((error) => error instanceof Error && handleCopyResult(error));
    } else {
      handleCopyResult(
        new Error("`useClipboard`: Navigation Clipboard is not supported")
      );
    }
  }

  return { copy, state };
};
```

## Wrapping up

Learning how to write a custom React Hook can give you several benefits:

* **Reusability**: extract and reuse common logic in your application. By creating a custom hook, you can encapsulate complex functionality into a reusable unit that can be easily shared across different components and projects.
* **Abstraction**: keep implementation details and focus on the high-level behavior of your component. This can help you write more declarative code and make your components easier to understand and maintain.
* **Composition**: enable the possibility to combine multiple hooks together to create more complex functionality. This can give you the advantage of composition patterns to build more powerful and flexible components.
* **Better performance**: reduce the amount of redundant code and avoid unnecessary re-renders.
* **Improved code organization**: organize your code more effectively by separating concerns and promoting a more modular architecture. Create a clear separation of concerns between your components and hooks, which can make your code easier to reason about and maintain over time.

> The main takeaway here is that learning how to write custom React Hooks can help you write cleaner, more modular, and more reusable code, which can save you time and effort in the long run.

Check out the code for this implementation on [hectorsosa.me/hooks](https://hectorsosa.me/hooks). How would you design this hook? Is there anything we've missed? Let us know at [@_ekqt](https://twitter.com/_ekqt).

For more articles and full resources visit [Webscope's Blog](https://www.webscope.io/blog).

This article references:
* [Reusing Logic with Custom Hooks by React Team](https://react.dev/learn/reusing-logic-with-custom-hooks)
* [Interact with the clipboard by MDN Web Docs](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Interact_with_the_clipboard)
* Mantine's [`use-clipboard` Hook Implementation](https://mantine.dev/hooks/use-clipboard/) and [`use-timeout` Hook Implementation](https://mantine.dev/hooks/use-timeout/)

Regression bugs are the worst! I'll show you a neat and reliable path how to uncover regression bugs with a standard Git command, that not many people know of.

Hunting down regression using "git bisect"

## Intro

Regression bugs are the worst! 😠 Especially, when you've just introduced a huge change and you have no clear idea where the regression bug stems from.

I'll show you a quick and reliable path on how to uncover regression bugs with a standard Git command, that not many people utilize, which is a pity!

As this article is discussing a very specific scenario in developers' workflow, let me open with a real-world model scenario, to get you into the context.

You may not even need this article! If you're only here to read about `git bisect`'s API either jump to the bottom or navigate [to the Git docs.](https://git-scm.com/docs/git-bisect) The point of this article is to discuss a real-life use case rather than duplicate the Git docs.

## A real-world scenario

Storytime! 📚

Imagine you're working on a new, fancy feature, that you and the product team are very excited about. Once deployed, the feature is gonna bring a lot of value to your customers, moving you another tiny bit ahead of the competition. And you've been part of that! Exciting! 👏

You've spent days, maybe even weeks working on and perfecting the feature. The day finally comes. You receive the last required approval on your polished pull request. Proudly, you hit the "Merge PR" button and calmly watch the CI/CD pipeline take care of the deployment while sipping your cup of victorious coffee. ☕ You pat yourself on your back and feeling accomplished, you head home.

*... fast-forward to the next morning.* 🔅

You open your laptop to see a bunch of worrying messages from the product folks. Apparently, while shipping the awesome new feature, a bug 🐛 snuck through all the tests and even the code review! Now, your customers are complaining that something, that used to work before is now not working. You gulp and check out the feature branch, you hoped to never see again.

The root cause is not trivial and this is the commit history of the branch:

```plaintext
2bd81f7 chore: Initial commit
fd1c7ae feat: storing search state in user settings
03d78e refactor: basic tag autosuggest implementation
a2c6f9b feat: improve tag autosuggest algorithm
c1b2e7d chore: refactor search filter implementation
9e6c1a8 fix: correct fuzzy search implementation for tags
6c7d2b2 feat: add search suggestions to input field
e1f9a4d refactor: search input component reorganization
8a3b0c9 feat: add support for searching by date
7dfe573 test: add search performance testing
4a7b8f1 feat: integrate search input with external API
3a8bcb4 chore: add keyboard shortcuts for search input
b50b832 feat: allow searching within search results
d0e2b8f feat: add support for searching by category
5ab5e15 fix: improve search input accessibility
e7ba51c feat: add option to save search queries
4f1df68 test: add search input validation testing
1a2e82c feat: add ability to search within specific fields
0c38d2a feat: implement search input highlighting
e0ef1c6 feat: add support for searching within attachments
6d7e25d refactor: improve autocomplete for search input
9d7fae9 feat: add support for searching by location
6c7f6b3 test: implement search input throttling testing
3f49862 feat: add search input to mobile interface
1cbb0c2 refactor: implement search input suggestions from user history
7b642f1 chore: improve search input placeholder text
3e9a8f8 feat: add support for searching within shared documents
1d4e4d7 refactor: implement autocomplete for search input filters
f52973a feat: add support for searching within comments
7b64df1 fix: improve search input styling and layout
```

*(Don't over-analyze the commit history, it's ChatGPT-generated). Here's the prompt, for reference.*

If only you knew, where to start...

## Taking a naive approach

If you ask me, that is quite an intimidating number of commits. If the commits are not single-purpose or close to atomic, it's very likely that the `diff` is not gonna be the smallest as well.

![Large changes diff](https://images.prismic.io/webscopeio/d9751bee-c0f9-4b98-bc89-7554eb8bef1a_0636e283-f5ae-4837-98c2-13b9111e3bdf.png?auto=compress,format)

Since we have no idea, where the sneaky bug is stemming from, it's important to realize, **we're partially relying on a chance**, to discover it. Therefore, debugging by browsing the branch and asserting a bunch of pseudo-randomly placed `console.log` or `debug` statements while clicking through the app would be very ineffective here.

After all, you're an engineer and there must be a systematic approach, right?

## Tilting the odds in our favor

It's a general rule, that in case you're relying on chance, you better tilt the odds in your favor. How do we do that? We reduce the size of the faulty `diff` to an absolute minimum.

What's the smallest primitive we can work down to in a Git-versioned repository? You guessed it, It's a commit. In other words. Instead of this.

![Large changes diff](https://images.prismic.io/webscopeio/d9751bee-c0f9-4b98-bc89-7554eb8bef1a_0636e283-f5ae-4837-98c2-13b9111e3bdf.png?auto=compress,format)

We want to be digging through something like this.

![Small changes diff](https://images.prismic.io/webscopeio/1b61d36e-d5aa-4b04-8262-683a10dab6b8_ed3be351-06bf-4aea-bbb6-37d12cdc0019.png?auto=compress,format)

That sounds like less of a headscratcher, right? 🤔

## Leveraging "git bisect"

### What it is

`git bisect` is obviously a Git command and does exactly what we defined in the previous section. It helps us reduce the code to dig through by systematically identifying the first `bad` commit ("bad" is a terminus technicus here) in Git history.

The process happens in a controlled, iterative fashion (similar to a wizard 🧙), using simple [interval-halving, aka. bisection](https://en.wikipedia.org/wiki/Bisection_method).

### How does the command work

When you trigger `git bisect`, the runner requests two inputs.

* ❌ A commit (hash) that you know is `bad` - meaning "is broken".
    
* ✅ A commit (hash) that you know `good` - meaning "works fine".

Once you supply these two *interval borders*. The runner takes over. Iteratively, it starts checking out commits and asking you, whether things are broken or just fine on this particular commit.

Your only job is to re-run your test scenario, e.g.

* Refresh a *broken application UI* and test the functionality
    
* Re-run the *failing test case* and check whether it passes
    
* Execute a script and see if it returns `0` this time
    
* ... depends on your environment

With each step, it's your job to tell the *bisect runner,* if the commit is `good` or `bad`.

That's it! Since bisection is just another name for binary search, you'll locate the broken commit in very brief `log2(number_of_commits)` steps. 😎

* Looking through a history of **8 commits**? You'll know the answer in **3 steps**.
    
* **64 commits**? **6 steps**!
    
* Even if you're digging through as many as **1024 commits**, you'll know in **10 steps**.

![log(2)N chart](https://images.prismic.io/webscopeio/a58d9594-3418-4a57-aacc-faf1457cfc35_vyhvCP_aQlVh5GvT4OFLQ.png?auto=compress,format)

You've probably seen a log2(n) chart, right?

### A practical example - Visual

Let's take the series of commits from above. Here's a little animation of how `git bisect` locates **the first bad commit**.

Let's take `6d7e25d` as our broken commit, which we want to "identify". Below, you can watch a little animation of how we bisect from `2bd81f7 (good)` and `7b64df1 (bad)` all the way to the culprit.

![Git bisect animation](https://images.prismic.io/webscopeio/b4236859-899c-472b-ade1-5afb8053c7ea_animated.gif?auto=compress,format)

📽️ If the embedded animation is too small, feel free to click through [this link](https://images.prismic.io/webscopeio/b4236859-899c-472b-ade1-5afb8053c7ea_animated.gif?auto=compress,format) for a full-screen high-res vesion! Hope this animation says a thousand words.

### A practical example - CLI

In case you're a more hands-on type of person, let's also analyze the whole sequence of commands that lead us to the culprit (`0c38d2a)` for completeness. If you got the idea from the animation, feel free to skip this. It's gonna be very linear.

Let's go over the command sequence. We start off by asserting the borders of the interval by passing **a broken commit** and **a working commit**. In this case `HEAD` is broken, but `2bd81f7` works just fine.

👨‍💻 `git bisect start HEAD 2bd81f7`

Git acknowledges the internal borders and checks out a new commit - `5ab5e15`. Then informs us that the culprit will be identified in roughly 4 steps. Great!

🤖 `Bisecting: 14 revisions left to test after this (roughly 4 steps) [5ab5e15] fix: improve search input accessibility`

We re-run the target (application, test, script, ...) and access the commit as `good`.

👨‍💻 `git bisect good`

Git acknowledges the good commit and checks out further, to `9d7fae9` .

🤖 `Bisecting: 7 revisions left to test after this (roughly 3 steps) [9d7fae9] feat: add support for searching by location`

We re-run the target (application, test, script, ...) and access the commit as `bad`.

👨‍💻 `git bisect bad`

Git acknowledges the bad commit and checks out further, to `1a2e82c` .

🤖 `Bisecting: 3 revisions left to test after this (roughly 2 steps) [1a2e82c] feat: add ability to search within specific fields`

We re-run the target (application, test, script, ...) and access the commit as `good`.

👨‍💻 `git bisect good`

Git acknowledges the bad commit and checks out further, to `e0ef1c6` .

🤖 `Bisecting: 1 revision left to test after this (roughly 1 step) [e0ef1c6] feat: add support for searching within attachments`

We re-run the target (application, test, script, ...) and access the commit as `bad`.

👨‍💻 `git bisect bad`

Git acknowledges and checks out the final commit - `0c38d2a`.

🤖 `Bisecting: 0 revisions left to test after this (roughly 0 steps) [0c38d2a] feat: implement search input highlighting`

As we've evaluated all necessary commits, the process ends. Now we know `0c38d2a` is the first broken commit that we need to dig through!

I'll now leave you in peace to debug your broken commit! 😊

---

## Final words

The whole idea of using `git bisect` for debugging, resp. tracing regression is to isolate the smallest possible piece of code, that we reliably identify as faulty. The smaller the diff is, the easier should it is to locate the culprit code.

Now we know, `git bisect` can take of this in mere `log2(number_of_commits)` steps. Therefore, even if we're working with a large commit sequence, e.g. of 1024, we can trace the regression bug in mere 10 steps.

Hope you learned something new today and you'll think twice before trying to debug large branches in the future.

The article itself explores debugging z-index outside of your standard "Elements" panel. It explores debugging by solely a visual approach, that's implemented in some of the Chromium-based browsers but seems to go mostly unnoticed.

Z-index not working? Debug it the modern way.

I usually write technical articles that attempt to dig deep into the selected topic - *this is not one of them*. This is quite an opposite of your usual tech digest. A simple, but visual article.

⚠️ A side note: If you're on a slower connection, mind that the article contains a bunch of GIF examples. Give it time to load.

## Intro

If you're scratching your head, lamenting on why is your fancy modal, overlay, dropdown, or tooltip (or any other web element for that matter) covered by another web element, even though you already set its `z-index` higher than the culprit, you may find this article useful.

### What this article is

The article itself explores debugging `z-index` outside of your standard "Elements" panel. It explores debugging by solely a visual approach, that's implemented in some of the Chromium-based browsers but seems to go mostly unnoticed.

### What this article is NOT

It's not a deep dive into what `z-index` is, what's its relation to "Stacking Context", or how is it formed. Since we're exploring a solely visual way of debugging, being comfortable with these concepts is not a requirement to continue, but I'd strongly recommend reading through basic MDN docs [like this one on](https://developer.mozilla.org/en-US/docs/Web/CSS/z-index) `z-index` or [this one on "Stacking Context"](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context).

## A model scenario

Let's take my blog, and break it in a simple, silly way. I hope you can identify the problem.

For those who overlooked the issue - the dropdown elements are for "some reason" rendering under the elements of one of my articles.

Let's get to debugging, shall we?

![img](https://images.prismic.io/webscopeio/3fd7becf-45be-4a66-b0ee-9d02485bb1d1_z-index-bug.gif?auto=compress,format)

## Debugging in 3D

Now, if you're like me, you'd locate the element, `Inspect` it in your DEV tools, and start comparing the `z-indexes` of the dropdown and the article component.

In the simplest scenario, bumping the `z-index` of the dropdown would do the job. If the markup and styles are more intricate we'd have to start figuring out the formed stacking contexts by going up through all relevant predecessors of our components and fiddling with `z-indexes` and other CSS properties.

*Forget that for now, and let's try something new today.* Let's inspect the web page in *3D view and debug the problem visually*.

### Support

The "3D View" is currently only supported by MS Edge. There are other Chromium browsers, that support similar features called "Layers", however, it seems pretty limited from what I could see, so I recommend attempting this in MS Edge.

- MS Edge → ✅ (Supported) - Feature is called "3D View"
- Google Chrome → 🟧 (Support is limited) - Feature is called "Layers"
- Arc → 🟧 (Support is limited) - Feature is called "Layers"
- Opera GX → 🟧 (Support is limited) - Feature is called "Layers"
- Brave → 🟧 (Support is limited) - Feature is called "Layers"

I'm unsure about the rest of the browsers as well as the different implementations outside of Chromium. You'll have to fiddle with that by yourself.

### Getting the visual

Let's open up the "3D View".

1. Open the Dev Tools
2. Open Command Palette (Cmd+Shift+P on Mac, Ctrl+Shift+P on Win)
3. Find your "Show 3D View" or "Show Layers" command
4. Execute it
    
Your Dev Tool will open the desired "3D View" of the web page, so let's explore it.

![img](https://images.prismic.io/webscopeio/d3f4b036-41ee-479f-9da5-fb5d38c5411b_z-index-dev-tools.gif?auto=compress,format)

### Debugging, but fun?

Inside the "3D View" panel, you can see three tabs:

* Composited Layers
* Z-index
* DOM

We'll be exploring "Z-index" more, but let's just get those two others out of the way.

*Composited Layers tab -* Basically renders your (2D) web page in the 3D space. Quite a conservative view, but may be useful for web page elements that naturally stick out of the common view.

*DOM tab* - What this tab lacks in usefulness for `z-index` debugging, is it over-delivers in coolness. The tab allows you to basically peel the page layer-by-layer. What is this useful for? I have no idea but look at the colors!

![img](https://images.prismic.io/webscopeio/c56e427a-8533-43c9-8fa7-d31a2e1ba44a_z-index-flashy.gif?auto=compress,format)

### Debugging z-index

Let's get to the debugging part now, we still have a broken web page to fix, so let's visualize the z-index properties of the web page. Remember, we're trying to figure out why the article tile covers our dropdown menu.

Let's observe the web is 3D and try to locate the problem.

![img](https://images.prismic.io/webscopeio/b338eb0a-b3ea-421d-846a-3b68823cd669_z-index-model.gif?auto=compress,format)

From the "3D View", we can observe that on the z-axis, the article tile is *positioned above* the dropdown. Which exactly maps to the problem we're troubleshooting.

Let's try to reduce the view to give it more clarity.

![img](https://images.prismic.io/webscopeio/dcae7e03-a14b-4c35-8ee7-f7934563f3b2_z-index-model-1.gif?auto=compress,format)

In the first step, we reduced the amount of all rendered elements by only rendering distinct stacking contexts. Then, by slapping the `z-index` value labels to our respective contexts, we can see the problem in numbers and figure out the issue - visually.

While Hashnode uses `z-index` of `50` for the dropdowns, our culprit article tile somehow uses `z-index: 51`. There we go, silly mystery resolved.

![img](https://images.prismic.io/webscopeio/a2db4079-6b1a-4795-b5cc-c831df18e363_z-index-element.gif?auto=compress,format)

## Final words

It's great to see debugging tools are moving way beyond the usual digging in source code. MS Edge's "3D View" is a great example of a hidden gem, that can save you time drilling through markup element by element when debugging z-index-induced bugs.

As a said before, this was everything, but technical. However, I still hope you found this refreshing and useful.