DEV Community: Gabriel Afonso

The other side of the table: a technical interviewer's perspective

Gabriel Afonso — Sat, 18 Apr 2026 14:58:15 +0000

The main purpose of dev.to is not to please LinkedIn’s corporate theater, but to speak directly to other developers like myself.

So let’s be honest: in the IT market, most people spend a good portion of their careers building a personal brand in pursuit of a better life.

“Better” is subjective. It usually means higher income, a supportive work environment, room to learn and grow, and an interesting product to work on.

Building that personal brand also requires a lot of preparation so you can prove you’re capable of solving a company’s daily challenges. And we all know how exhausting that can be. The market has been bad for a while, making job seeking pretty much unbalanced. The interviewer barely needs effort to convince the candidate.

That said, I’ve recently found myself on an unexpected mission: evaluating other people’s skills and helping decide on a new teammate, alongside some very talented and genuinely great people. The process confirms a few clichés and imposes some interesting challenges.

In this post, I’d like to talk about what I expect from a candidate, but also what a candidate should expect from me. And my favorite part: my struggles. 🙃

You need to express your thinking clearly and half of that responsibility is mine

This is a tricky one: I can’t guess what’s going on in your mind, so both your approach and mine shape the overall perception.

More than that, clear communication is arguably the most important skill any team needs.

If we’re going through a coding challenge, you need to think out loud. Take a moment for an initial scan, but then start explaining your thoughts in detail. This is especially important because (here comes the cliché) understanding how you approach a problem matters more than solving 100% of it. No one expects you to perform perfectly under pressure.

Theory is important as hell, and it's not about "memorizing what you never use"

For you and me.

If the interview is more of a “question and answer” format, it’s on me to turn it into a fluid, friendly conversation... and that often requires improvisation. There will be moments when your answer is incomplete or slightly off, and it’s my role to help you expand on it.

By “help” I mean creating space for you to demonstrate what you know and rethink your approach. This matters even when your answer is already strong because it shows curiosity and a willingness to go deeper, which earns extra points.

And that leads to the next challenge…

I need to know what I’m talking about

During these conversations, candidates have every right to ask questions, and that puts some pressure on me too. But it’s also a great opportunity to grow.

I’m rooting for you 🤞

Even though interviews cost the company time and take me away from other responsibilities, I genuinely hope you do well and that we end up working together.

Despite being an evaluation process, remember: everyone involved is on your side.

Don’t tie rejection to your self-worth

This should be obvious, but it’s completely understandable how rejection can affect self-esteem. There are countless factors influencing a hiring decision, and it’s simply impossible to fully capture every developer’s strengths.

Remember: everyone involved is learning.

We’ve all been through hiring processes, and we know there’s a fair amount of luck involved.

Wrapping up

Interviewing can be fun. It pushes us, as developers, to reflect on what a role truly expects from us.

If you have the opportunity to do it on behalf of your company, embrace it and get yourself thinking on a new organisational level.

I could write forever about it, but will keep it short. Let's keep the discussion on the comments! Tell me if you have been through a similar experience.

React: Fine-grained reactivity should be the norm

Gabriel Afonso — Fri, 15 Sep 2023 13:48:43 +0000

This article attempts to explain why the current state of React has fundamental flaws so we can slowly build the knowledge to understand how to overcome them, for both better user and developer experience.

Disclaimer: We will need to simplify some concepts a little bit for didactic reasons, but you'll find a list with a lot of great content in the references section, in case you're curious. Also, you should have some familiarity with React, its Virtual Dom, and basic hooks.

If you wanna try yourself
React rendering model is flawed
Introducing Fine-grained reactivity 🤌
- First: Observer Pattern! 👀
- Coming up with a better definition
The easiest way to achieve fine-grained reactivity in React
Conclusion
References

If you wanna try yourself

First, make sure you have React developer tools installed in your browser and check the Highlight updates when components render option.

Second, here is the repo with all examples. You can simply clone it and follow the instructions on the readme.

We'll be using an application created with create-next-app configured with Typescript and TailwindCSS.

Now, let's go!

React rendering model is flawed

Don't get me wrong: React is amazing, robust and has been giving life to all sorts of projects for over a decade. But that's precisely why people are able to detect its flaws and are so passionate about improving it (or coming up with a new competitor once in a while).

So, the problem we are going to discuss today is rendering. React rendering model basically makes a whole component and its children re-render on every state change. Let's take a look at a very basic example:

import { useState } from "react";
import Button from "@/components/Button";

export default function DefaultCounter() {
  const [count, setCount] = useState(0);

  return (
    <div className="bg-green-900 p-2 rounded-md">
      <h2 className="text-xl text-white">Default counter</h2>
      <p className="text-white">Counter: {count}</p>
      <Button onClick={() => setCount(count + 1)}>Increase</Button>
    </div>
  );
}

Every time we click on the button, the count increases (the state changes), which causes a re-render in every child of our DefaultCounter component. Notice the highlight in our Button.

Here is another example, passing props to a child counter display and an unrelated component. Passing props or not is irrelevant in this case.

import { useState } from "react";
import UnrelatedElement from "@/components/UnrelatedElement";
import Button from "@/components/Button";

export default function CounterPassingProp() {
  const [count, setCount] = useState(0);

  return (
    <div className="bg-green-900 p-2 rounded-md">
      <h2 className="text-xl text-white">Outer Counter passing prop</h2>
      <p className="text-white">Counter: {count}</p>
      <Button onClick={() => setCount(count + 1)}>Increase</Button>

      <InnerCounter count={count} />
      <UnrelatedElement />
    </div>
  );
}

type Props = {
  count: number;
};

export function InnerCounter({ count }: Props) {
  return (
    <div className="bg-green-600 p-2 rounded-md my-2">
      <h2 className="text-xl text-white">Inner counter receiving prop</h2>
      <p className="text-white">Counter: {count}</p>
    </div>
  );
}

Again, everything is re-rendering.

We could maybe try to substitute the counter state for a ref, since state is the cause of re-rendering, right?

export default function CounterWithRef() {
  const count = useRef(0);

  return (
    <div className="bg-green-900 p-2 rounded-md">
      <h2 className="text-xl text-white">Counter using ref</h2>
      <p className="text-white">Counter: {count.current}</p>
      <Button onClick={() => count.current++}>Increase</Button>
    </div>
  );
}

Well... nothing seems to happen because ref doesn't force any part of the component to re-render, so we can't see the updated value of the counter on the screen.

Could we use some hack like directly modifying innerHTML? Maybe, but that's totally an anti-pattern. A way to force a re-render would be creating a new state like:

const [, setForceUpdate] = useState(Date.now());

And then calling setForceUpdate when the click event is triggered, which also completely kills our purpose and causes a lot of confusion. Please, don't do it!

Those performance problems are only partially fixable and the cost in complexity for something like that doesn't make much sense. In our example, specifically, the best we could do is to wrap the elements that don't have props changing with memo:

const MemoUnrelatedElement = memo(UnrelatedElement);

// and then we use inside our Counter component
<MemoUnrelatedElement />

From the docs:

memo lets you skip re-rendering a component when its props are unchanged.

Now UnrelatedElement won't re-render. Nice!

But what about the other children?

Wrapping InnerCounter with memo, would be irrelevant since it receives the count state as a prop, which is changing.
Wrapping Button with memo would also be irrelevant. Button receives the setter function as a prop, which has changed.

What about abstracting the setter passed to Button and wrapping it with the useCallback hook?

  const increment = useCallback(() => {
    setCount(count + 1);
  }, [count]);

  // and then
  <Button onClick={increment}>increment</Button>

It won't work because it was not designed for it. The default behavior of React is to recreate increment declaration in every render, pointing to a new reference (remember: functions are not primitive values, so "same implementation" doesn't mean "same function").

useCallback was created to cache that declaration, making sure we are pointing to the same reference, unless some dependency changes, which is exactly our case.

This is the best we've got so far:

There must exist a better solution, and luckily, it does!

Introducing Fine-grained reactivity 🤌

Trying to come up with a definition, I've found it quite difficult to express it formally. A very vague definition would be "an architectural approach that focuses on efficiently updating and rendering user interfaces in response to changes in the underlying data or state."

But that doesn't say anything at all.

First: Observer Pattern! 👀

In order to learn how fine-grained reactivity is implemented, we need to understand the concept of Observers.

Simplified as much as possible, this design pattern contains two types of entities:

Subject: an entity that contains a list of observers for each type of event
Observers: entities subscribed to the Subject that get notified by it based on a type of event

Think of the Subject as a job portal that sends you notifications with open positions based on your profession.

subject.notify("software-dev");

You, as an Observer subscribed on the "software-dev" list, will do something with that information, like opening the link to the open position's page.

observer.update();

For real-world examples with detailed implementation, I highly recommend reading this explanation, but the idea of notifying a list of observers based on a type of event is enough to get the following topics.

Coming up with a better definition

Fine-grained reactivity aims for performance. The goal is to track changes and re-render the UI as least as possible, through a graph full of nodes. Those nodes here are conceptually called Primitives. Let's take a look at each one of them.

Signals: observables (event emitters), which we can access their values through getters and setters.
Reactions: observe our Signals and re-run them every time the Signal's value changes.
Derivations: memoization mechanisms that cache expensive derived values.

So you can see this technique as turning the states into observables in a graph that notifies changes in any children.

Those concepts are widely implemented in other frameworks like Qwik, Solid.js, and Preact. Each one approaches reactivity with different mechanisms that take care of unused nodes, clean-ups, keeping the graph as shallow as possible, ensuring synchronous execution through transactions, etc. I won't dare to touch those subjects for now.

The easiest way to achieve fine-grained reactivity in React 🔥

Disclaimer: that's solely my point of view.

Legend State is a state-management library that achieves that level of efficiency. It exposes an API with the primitives discussed above through custom hooks and wrappers for our components.

Let's rebuild our simple counter:

import { ObservablePrimitiveBaseFns } from "@legendapp/state";
import { useObservable, Memo } from "@legendapp/state/react";
import UnrelatedElement from "@/components/UnrelatedElement";
import Button from "@/components/Button";

export default function FineGrainedCounter() {
  const count$ = useObservable(0);

  return (
    <div className="bg-green-900 p-2 rounded-md">
      <h2 className="text-xl text-white">Legend Counter</h2>
      <p className="text-white">
        Counter: <Memo>{count$}</Memo>
      </p>
      <Button onClick={() => count$.set((prev) => prev + 1)}>increment</Button>

      <InnerCounter count$={count$} />
      <UnrelatedElement />
    </div>
  );
}

type Props = {
  count$: ObservablePrimitiveBaseFns<number>;
};

export function InnerCounter({ count$ }: Props) {
  return (
    <div className="bg-green-600 p-2 rounded-md my-2">
      <h2 className="text-xl text-white">Inner counter receiving prop</h2>
      <p className="text-white">
        Counter: <Memo>{count$}</Memo>
      </p>
    </div>
  );
}

useObservable is a custom hook that creates a Signal count$ with get, set and value. In this case, our previous count state. The $ (dollar sign) at the end of the variable is a convention.

Mind-blowing 🤯

Also, let's get an example with derivations. Here is probably the most used example in the history of computed values:

import { useState } from "react";

export default function DefaultFullName() {
  const [firstName, setFirstName] = useState("");
  const [lastName, setLastName] = useState("");

  return (
    <div className="bg-green-900 p-2 gap-2 flex flex-col rounded-md w-[30ch]">
      <h2 className="text-xl text-white">Default computed</h2>

      <FirstName handleChange={(e) => setFirstName(e.target.value)} />
      <LastName handleChange={(e) => setLastName(e.target.value)} />

      <p className="text-white">
        Full name: {firstName} {lastName}
      </p>
    </div>
  );
}

function FirstName({ handleChange }) {
  return (
    <>
      <label htmlFor="lastName" className="text-white">
        Last name:
      </label>
      <input id="lastName" onChange={handleChange} />
    </>
  );
}

function LastName({ handleChange }) {
  return (
    <>
      <label htmlFor="firstName" className="text-white">
        First name:
      </label>
      <input id="firstName" onChange={handleChange} />
    </>
  );
}

As we saw before, everything is going to re-render on every state change:

Now, the same component with Legend State:

import { useObservable, observer, Memo } from "@legendapp/state/react";
import { ObservableObject } from "@legendapp/state";

const FullName = ({
  user,
}: {
  user: ObservableObject<{
    firstName: string;
    lastName: string;
  }>;
}) => (
  <p className="text-white">
    Full name: <Memo>{user.firstName}</Memo> <Memo>{user.lastName}</Memo>
  </p>
);

const FirstName = observer(
  ({
    user,
  }: {
    user: ObservableObject<{
      firstName: string;
      lastName: string;
    }>;
  }) => (
    <div className="flex flex-col gap-2">
      <label htmlFor="firstName" className="text-white">
        First Name
      </label>
      <input
        id="firstName"
        value={user.firstName.get()}
        onChange={(e) => user.firstName.set(e.target.value)}
      />
    </div>
  )
);

const LastName = observer(
  ({
    user,
  }: {
    user: ObservableObject<{
      firstName: string;
      lastName: string;
    }>;
  }) => (
    <div className="flex flex-col gap-2">
      <label htmlFor="lastName" className="text-white">
        Last Name
      </label>
      <input
        id="lastName"
        value={user.lastName.get()}
        onChange={(e) => user.lastName.set(e.target.value)}
      />
    </div>
  )
);

export default function FineGrainedFullName() {
  const user = useObservable({
    firstName: "",
    lastName: "",
  });
  return (
    <div className="bg-green-900 p-2 gap-2 flex flex-col rounded-md w-[30ch]">
      <h2 className="text-xl text-white">Fine Grained Full Name</h2>
      <FirstName user={user} />
      <LastName user={user} />
      <FullName user={user} />
    </div>
  );
}

Note how the renders are isolated to the input components changing their state - in this case, their signal's value. And how the full name field also doesn't trigger a re-render even dynamically being updated!

Legend does way more than that: It simplifies context, global state, persistency, reference values, and much more, but we'll keep that for a future article.

Conclusion

That's it, devs! If you wanna deep-dive on the subject, I can't recommend the links on the references section enough. 🤓

Thank you so much for reading.

References

https://refactoring.guru/design-patterns/observer/typescript/example
https://indepth.dev/posts/1269/finding-fine-grained-reactive-programming#how-it-works
https://legendapp.com/open-source/legend-state/
https://legendapp.com/open-source/state/fine-grained-reactivity/
https://www.builder.io/blog/usesignal-is-the-future-of-web-frameworks
https://dev.to/ryansolid/a-hands-on-introduction-to-fine-grained-reactivity-3ndf
https://medium.com/hackernoon/becoming-fully-reactive-an-in-depth-explanation-of-mobservable-55995262a254
https://preactjs.com/blog/introducing-signals/
https://hygraph.com/blog/react-memo

Custom React hooks go beyond reusability

Gabriel Afonso — Fri, 08 Sep 2023 13:07:44 +0000

React allows us to create functions that handle stateful logic called hooks, and that brings some interesting possibilities to write cleaner components.

First of all: hooks vs. other functions
Reusability
Separation of concerns: components
Separation of concerns: logic and data display
Testing
Conclusion
References

First of all: hooks vs. other functions

Custom hooks are not simply functions with "use" in their names. They were designed to deal with stateful logic. If there is no need to deal with state, you can simply create a utility function. But we will see in a minute that this is debatable due other factors.

Reusability

There are plenty of examples on the Web of hooks that encapsulate reusable logic. Here is a very simple one to handle fetching data:

export default function useFetch(url: string) {
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState<Error | null>(null);
  const [data, setData] = useState<unknown>(null);

  useEffect(() => {
    setLoading(true);

    fetch(url)
      .then((response) => response.json())
      .then((parsed) => {
        setData(parsed);
      })
      .catch((err) => {
        setError(new Error("An error occurred while fetching the data"));
      })
      .finally(() => {
        setLoading(false);
      });
  }, [url]);

  return { loading, error, data };
}

And then we would be able to use that anywhere, like:

import useFetch from "./hooks/useFetch";

export default function App() {
  const { error, loading, data } = useFetch(
    "https://pokeapi.co/api/v2/pokemon/ditto"
  );

  if (loading) return <p>Loading...</p>;
  if (error) return <p>{error.message}</p>;

  return (
    <div className="App">
      <p>Pokemon name: {data?.species.name}</p>
    </div>
  );
}

But our focus today is to accomplish something different.

Separation of concerns: components

As in the docs:

"Instead of artificially separating technologies by putting markup and logic in separate files, React separates concerns with loosely coupled units called “components” that contain both."

So let's try another example. Here we have a Progress bar that tracks the user's position while scrolling through an article, for example. We'll be using just a little bit of TailwindCSS for styling.

import {
  DetailedHTMLProps,
  ProgressHTMLAttributes,
  useEffect,
  useState,
} from "react";

type Props = DetailedHTMLProps<
  ProgressHTMLAttributes<HTMLProgressElement>,
  HTMLProgressElement
>;

export default function ProgressBar(props: Props) {
  const [pageHeight, setPageHeight] = useState(0);
  const [progress, setProgress] = useState(0);

  useEffect(() => {
    function handleScroll() {
      setProgress(window.scrollY);
    }

    const windowHeight = document.body.clientHeight - window.innerHeight;
    setPageHeight(windowHeight);

    window.addEventListener("scroll", handleScroll);
    return () => {
      window.removeEventListener("scroll", handleScroll);
    };
  }, []);

  return (
    <progress
      {...props}
      className="w-full [&::-webkit-progress-value]:rounded-r-lg [&::-webkit-progress-bar]:bg-transparent [&::-webkit-progress-value]:bg-violet-400 [&::-moz-progress-bar]:transparent"
      aria-label="Page scroll progress"
      tabIndex={0}
      aria-valuenow={progress}
      aria-valuemax={pageHeight}
      value={progress}
      max={pageHeight}
    />
  );
}

Breaking it down a little bit:

We create states to store the page size and scroll position
When the component renders for the first time, we add an event listener to get the user's vertical scroll position
When the component unmounts, we use the useEffect's cleanup function to remove the event listener.

Note: There are other ways of doing it, but I'm using Next.js so it's easier for this example to just handle the whole logic inside a useEffect to tell Next.js we are on the client side and have access to the window object.

And here is the result:

That's 100% valid and follows React's philosophy, but it's too verbose. Any component slightly more complex, or even this one with newer features, can easily become too long and hard to read.

Separation of concerns: logic and data display

The beauty of custom hooks is that we can keep concerns separated by components, but that doesn't mean we must stop there, and we also don't need to artificially separate technologies.

We can separate its logic from the data display! In other words: we can treat data in one place and have a presentational layer in another. Our component doesn't need to be a single file.

So let's create our useProgress hook:

import { useEffect, useState } from "react";

export default function useProgress() {
  const [pageHeight, setPageHeight] = useState(0);
  const [progress, setProgress] = useState(0);

  useEffect(() => {
    function handleScroll() {
      setProgress(window.scrollY);
    }

    const windowHeight = document.body.clientHeight - window.innerHeight;
    setPageHeight(windowHeight);

    window.addEventListener("scroll", handleScroll);
    return () => {
      window.removeEventListener("scroll", handleScroll);
    };
  }, []);

  return { pageHeight, progress };
}

And now our progress bar just imports the two values it needs, hiding the implementation.

import { DetailedHTMLProps, ProgressHTMLAttributes } from "react";
import useProgress from "./hooks/useProgress";

type Props = DetailedHTMLProps<
  ProgressHTMLAttributes<HTMLProgressElement>,
  HTMLProgressElement
>;

export default function ProgressBar(props: Props) {
  const { progress, pageHeight } = useProgress();

  return (
    <progress
      {...props}
      className="w-full [&::-webkit-progress-value]:rounded-r-lg [&::-webkit-progress-bar]:bg-transparent [&::-webkit-progress-value]:bg-violet-400 [&::-moz-progress-bar]:transparent"
      aria-label="Page scroll progress"
      tabIndex={0}
      aria-valuenow={progress}
      aria-valuemax={pageHeight}
      value={progress}
      max={pageHeight}
    />
  );
}

Note: Here we can argue if every function inside our custom hook would deal only with stateful logic or if it could also include "utils". Overall, I particularly would expect to see only stateful logic.

Testing

react-testing-library allows us to test our hooks with the renderHook function, which can be very helpful (and it doesn't forbid you from also mocking it in your component). In the example below I'm just testing the hook, but the Github repo at the end of this article is a little more complete.

import { renderHook, fireEvent } from "@testing-library/react";
import useProgress from "./index";

describe("useProgress custom hook", () => {
  it("renders with correct initial values", () => {
    const { result } = renderHook(() => useProgress());

    expect(result["current"]["progress"]).toBe(0);
    expect(result["current"]["pageHeight"]).toBe(-768);
  });

  it("updates progress value on vertical scroll", () => {
    const { result } = renderHook(() => useProgress());

    fireEvent.scroll(window, { target: { scrollY: 300 } });

    expect(result["current"]["progress"]).toBe(300);
    expect(result["current"]["pageHeight"]).toBe(-768);
  });
});

Conclusion

This article aims to demonstrate that we can rely on powerful React features to keep our code cleaner and maintainable. If you disagree or would like to contribute with more details or possibilities, you're more than welcome to comment.

Also, don't forget to read the docs linked in the references section below. It will provide you with a deeper knowledge of how React works.

Github repo with full example

References

Your pagination is probably not accessible

Gabriel Afonso — Thu, 31 Aug 2023 14:28:01 +0000

Pagination is a feature widely implemented in several visual interfaces that require listing data (like blogs, social media, and e-commerce) since it provides a better user experience and prevents the need to fetch all data from the server at once (imagine that!). But are you doing it right?

What do I mean by "right"?
Initial code
Why not buttons?
Final code
Conclusion
References

What do I mean by "right"?

By "right" I mean "to include all users on the web." Or are you just stacking pretty links with numbers? Or even worse: stacking buttons (we will discuss that)!

Initial code

In order to understand what is happening, let's start with a very basic version of the component, and over the article we can improve it. In this tutorial, for didactic purposes, we are going to use only HTML and CSS. No need to render the number of pages dynamically or anything like that.

<nav>
  <ul class="pagination__list">
    <li class="pagination__list-item">
      <a class="pagination__anchor" href="path/to/page">Previous</a>
    </li>
    <li class="pagination__list-item">
      <a class="pagination__anchor" href="path/to/page">1</a>
    </li>
    <li>
      <a class="pagination__ellipsis">&#8230;</a>
    </li>
    <li class="pagination__list-item">
      <a class="pagination__anchor" href="path/to/page">6</a>
    </li>
    <li class="pagination__list-item">
      <a class="pagination__anchor" href="path/to/page">
        7
      </a>
    </li>
    <li class="pagination__list-item pagination__list-item--current">
      <a href="#" class="pagination__anchor">8</a>
    </li>
    <li class="pagination__list-item">
      <a class="pagination__anchor" href="path/to/page">9</a>
    </li>
    <li class="pagination__list-item">
      <a class="pagination__anchor" href="path/to/page">10</a>
    </li>
    <li>
      <a class="pagination__ellipsis">&#8230;</a>
    </li>
    <li class="pagination__list-item">
      <a class="pagination__anchor" href="path/to/page">20</a>
    </li>
    <li class="pagination__list-item">
      <a class="pagination__anchor" href="path/to/page">Next</a>
    </li>
  </ul>
</nav>

This version is a good start, actually. At least we are using semantic html correctly, explicitly saying it's a nav component, and listing the links properly. But this is far from accessible: people using assistive technologies, such as screen readers, will need to guess several things by context!

Why not buttons?

Simply put: don't frustrate your users. Someone navigating on your website expects elements to behave as they should.

A link will redirect you to a new page or section within the same page, and a button will trigger an action.

Both are focusable, but people interacting through the keyboard trigger links with the enter key, and buttons with the space key.

There are interesting discussions about it regarding filters that change router parameters, though. But we will keep it out of this article.

And please, no div tags with event listeners. It requires a lot of code, it harms the readability of other developers and it's not semantic at all!

Final code

First, let's break down the improvements you will see below:

We added an aria-label="pagination" because that's most likely not the only navigation component on the page, so we should explicitly differentiate it from the main nav.
Pay attention to the .visually-hidden class. We use it in span tags to provide more context for people using screen readers while hiding it from the visual user interface. It is implemented in accessibility-focused component libraries like Radix-ui.
For the current page, we add aria-current="page" as an indicator of the active link. The aria-label="page" provides the same additional context as the visually-hidden span.

<nav aria-label="pagination">
  <ul class="pagination__list">
    <li class="pagination__list-item">
      <a class="pagination__anchor" href="path/to/page">Previous <span class="visually-hidden">page</span></a>
    </li>
    <li class="pagination__list-item">
      <a class="pagination__anchor" href="path/to/page"><span class="visually-hidden">page</span> 1 <span class="visually-hidden">(first page)</span></a>
    </li>
    <li>
      <a class="pagination__ellipsis">&#8230;</a>
    </li>
    <li class="pagination__list-item">
      <a class="pagination__anchor" href="path/to/page"><span class="visually-hidden">page</span> 6</a>
    </li>
    <li class="pagination__list-item">
      <a class="pagination__anchor" href="path/to/page">
        <span class="visually-hidden">page</span> 7
      </a>
    </li>
    <li class="pagination__list-item pagination__list-item--current">
      <a href="#" class="pagination__anchor" aria-label="page 8" aria-current="page">8</a>
    </li>
    <li class="pagination__list-item">
      <a class="pagination__anchor" href="path/to/page"><span class="visually-hidden">page</span> 9</a>
    </li>
    <li class="pagination__list-item">
      <a class="pagination__anchor" href="path/to/page"><span class="visually-hidden">page</span> 10</a>
    </li>
    <li>
      <a class="pagination__ellipsis">&#8230;</a>
    </li>
    <li class="pagination__list-item">
      <a class="pagination__anchor" href="path/to/page"><span class="visually-hidden">page</span> 20 <span class="visually-hidden">(last page)</span></a>
    </li>
    <li class="pagination__list-item">
      <a class="pagination__anchor" href="path/to/page">Next <span class="visually-hidden">page</span></a>
    </li>
  </ul>
</nav>

Here is the full CSS:

/* Small reset */
body {
  box-sizing: border-box;
}

* {
  padding: 0;
  margin: 0;
  list-style-type: none;
}

.pagination__list {
  display: flex;
  align-items: center;
  justify-content: center;
  margin-top: 20px;
  gap: 5px;
}

.pagination__list-item {
  background-color: #4682b4;
  padding: 10px;
  border-radius: 5px;
  cursor: pointer;
}

.pagination__list-item--current {
  background-color: #191970;
}

.pagination__anchor {
  text-decoration: none;
  color: #ffffff;
}

.visually-hidden {
  border: 0;
  padding: 0;
  margin: 0;
  position: absolute !important;
  height: 1px;
  width: 1px;
  overflow: hidden;
  clip: rect(1px 1px 1px 1px);
  clip: rect(1px, 1px, 1px, 1px);
  clip-path: inset(50%);
  white-space: nowrap;
}

You can also check it out on code sandbox:

Conclusion

Keep in mind that there is always room for improvement. There are different assistive technologies, different disabilities, and different ways to interact with websites. Our main goal here is to start thinking about best practices and to build a better web for everyone, step-by-step.

Please, feel free to contribute in the comments. We are all learning!

Thank you for reading.

DEV Community: Gabriel Afonso

The other side of the table: a technical interviewer's perspective

You need to express your thinking clearly and half of that responsibility is mine

Theory is important as hell, and it's not about "memorizing what you never use"

I need to know what I’m talking about

I’m rooting for you 🤞

Don’t tie rejection to your self-worth

Wrapping up

React: Fine-grained reactivity should be the norm

Table of Contents

If you wanna try yourself

React rendering model is flawed

Introducing Fine-grained reactivity 🤌

First: Observer Pattern! 👀

Coming up with a better definition

The easiest way to achieve fine-grained reactivity in React 🔥

Conclusion

References

Custom React hooks go beyond reusability

Table of contents

First of all: hooks vs. other functions

Reusability

Separation of concerns: components

Separation of concerns: logic and data display

Testing

Conclusion

References

Your pagination is probably not accessible

Table of contents

What do I mean by "right"?

Initial code

Why not buttons?

Final code

Conclusion

References