Forem: Antonio Moruno Gracia

99% of frontend devs don't use this

Antonio Moruno Gracia — Mon, 14 Jul 2025 18:55:05 +0000

In the React world, most developers don’t think twice before using closures in their component render methods, especially when mapping over lists.

But what if I told you there's an underutilized, yet powerful alternative that can help with performance, readability, and even better integration with tools?

Let’s talk about HTML data-* attributes: a feature that’s rarely used by frontend developers, but deserves a second look.

❓ What are data-* Attributes?

HTML’s data-* attributes allow you to embed custom data inside DOM elements. In plain HTML:

<div data-user-id="123" data-role="admin">John</div>

In React, you can use them the same way:

<div data-user-id={user.id} data-role={user.role}>
  {user.name}
</div>

They are accessible in event handlers via the dataset object:

e.currentTarget.dataset.userId;

🧠 The Common Pattern: Closures in .map()

Let’s say you’re rendering a list of items:

{items.map((item) => (
  <button key={item.id} onClick={() => handleClick(item.id)}>
    {item.name}
  </button>
))}

This works fine. It’s readable and easy to write.

But behind the scenes, you're creating a new function for each item on every render: a closure that captures item.id.

In many apps, this has no practical impact. However...

⚠️ The Downsides of Closures

While closures are a fundamental part of JavaScript and React, using them inside .map() can have drawbacks:

1. Unnecessary Re-Renders

If you're using React.memo, React.useCallback, or virtualized lists (like react-window), new function references can cause unwanted re-renders. Since the function is recreated every time, memoization doesn't help.

2. Harder to Optimize

Imagine you're building a highly interactive list that renders hundreds of items. Minimizing re-renders becomes important, and inline closures can work against that.

✅ The Alternative: `data-*`

Instead of creating a closure for each item, attach metadata directly to the DOM using data-*:

function handleClick(e) {
  const id = e.currentTarget.dataset.id;
  console.log("Clicked item:", id);
}

{items.map((item) => (
  <button key={item.id} data-id={item.id} onClick={handleClick}>
    {item.name}
  </button>
))}

Single function reference → plays nicely with React.memo or React.useCallback
Improved performance for large lists or re-render-sensitive components

🤔 So Why Isn’t Everyone Doing This?

Because closures are easy, intuitive, and performant enough for most apps. data-* feels a bit "old-school," and it’s rarely mentioned in modern React/Frontend tutorials.

But in situations where performance or memoization matters, this approach can be a hidden gem.

✨ In Summary

While data-* attributes aren’t a common tool in a React developer’s toolbox, they offer real advantages in specific scenarios:

Reduce unnecessary function creations
Improve memoization and rendering performance
Enable simpler and cleaner event handling

They’re not a replacement for closures, but they’re a great alternative when performance or architecture calls for it.

Have you ever used data-* attributes like this? Or do you usually stick with closures? I’d love to hear your thoughts and experiences!

I hope you found this post interesting. Let me know what you think in the comments 👇

Goodbye useCallback and useMemo: How React Compiler Takes Over

Antonio Moruno Gracia — Sun, 10 Nov 2024 17:10:02 +0000

For React developers, optimizing component performance often means managing a set of tools like useCallback, useMemo, and memo to prevent unnecessary re-renders. These hooks allow developers to memoize values and functions, keeping their React apps efficient.

However, most of the times they also clutter the code and require frequent tuning, making their usage more of a headache rather than a helpful tool for clean, maintainable code.

React Compiler changes this paradigm by automatically handling these optimizations, allowing developers to focus on writing clean, maintainable code that follows React's best practices without being distracted by performance concerns.

By analyzing your component code and applying performance enhancements behind the scenes, React Compiler makes it possible to write React code that’s both high-quality and efficient, without manually configuring memoization.

With this, we’re looking at a future where developers can concentrate on building components the right way—using React principles—while React Compiler takes care of performance and optimization.

The Current State of Memoization in React

To understand how React Compiler changes things, let’s review how manual memoization works in React today.

useCallback

The useCallback hook allows us to memoize functions, ensuring they’re only recreated when their dependencies change. This is particularly useful when functions are passed as props to child components, as it prevents those components from re-rendering unnecessarily.

import { useCallback } from 'react';

const MyComponent = ({ onClick }) => {
  const handleClick = useCallback(() => {
    // handle click event
  }, [/* dependencies */]);

  return <button onClick={handleClick}>Click me</button>;
}

useMemo

useMemo works similarly but is used to memoize values rather than functions. It’s commonly used for heavy computations or data transformations that don’t need to be recalculated every render.

import { useMemo } from 'react';

const MyComponent = ({ data }) => {
  const processedData = useMemo(() => {
    return data.map(item => process(item));
  }, [data]);

  return <ChildComponent data={processedData} />;
}

memo

Finally, the memo function can be used to memoize entire components. If the props passed to the component haven’t changed, memo skips re-rendering the component.

When could this be useful? Well, imagine this situation:

export const Component = () => {
  const [count1, setCount1] = useState(0);
  const [count2, setCount2] = useState(0);

  return (
    <>
      <Title />
      <Counter count={count1} setCount={setCount1} />
      <Counter count={count2} setCount={setCount2} />
    </>
  );
}

Anytime count1 or count2 changes, the whole component and its children are rerendered (even if those children doesn't use the state). Wrapping those components with memo will avoid those unnecessary rerenders.

const Title = memo(function Title({ value }) {
  ...
});

const Counter = memo(function Counter({ value }) {
  ...
});

Now, the only children components that will rerender are those whose props have changed. If count1 changes, only the first <Counter/> will rerender. If count2 changes, only the second <Counter/> will rerender.

How React Compiler Changes the Game

React Compiler seeks to make these optimizations for us, eliminating the need for manually configuring useCallback, useMemo, or memo. By analyzing each component and its dependencies, React Compiler can automatically determine where and when to apply memoization. This means no more worrying about remembering which hooks to use or fine-tuning dependencies lists—React Compiler handles it all.

To highlight this, I will make use of this react compiled code visualizer. Let's take a look at an example.

Current transpiler

We can see that the transpiler simply calls the __jsx function (which works similarly to React.createElement) to build the virtual DOM.

React compiler

Let’s break this code down:

React introduces the c hook and uses it within the component. This creates an array of cacheable slots (called $ in this case), with as many slots as the compiler deems necessary (two in this case).
The first slot is always reserved for the component's hash—a unique identifier for each component, calculated based on its contents, including subcomponents, hooks, and other properties.
The remaining slots are reserved for the memoized version of the JSX (in this case, there is one slot, the second one).
We check if these slots have stored data. If they do, the memoized component is stored in the slot for reuse.
When a rerender occurs and this function is called again, the memoized component is retrieved from the $ array without needing to call the __jsx function again, preventing unnecessary rerendering.

This is a simple example, but it illustrates the concept well. Here are some other key points about the React compiler:

It handles nested components, hooks, and other complex structures seamlessly.
It identifies constants in the component that won’t change, avoiding redundant creation by directly using their values.
If a component breaks any of the Rules of React, the compiler switches to a safe mode. In this mode, the component isn’t memoized, which prevents potential bugs or unexpected behavior.
And more.

Final thoughts

React Compiler promises to revolutionize how we approach performance optimization in React. By eliminating the need for manual memoization hooks, it simplifies code and allows developers to build applications without getting bogged down in performance tweaks. As React Compiler becomes more integrated, it will free us from useCallback, useMemo, and memo, making React development more intuitive and accessible than ever, letting us focus on what really matters: building great apps.

That said, React Compiler is still in development and is not yet recommended for production use. However, there are some linting rules available, such as eslint-plugin-react-compiler, that prepare us for when the compiler becomes production-ready by surfacing problematic React code detected by the compiler.

This post is inspired in this youtube video. Don't hesitate to check it out in case you want to learn more about React compiler!

Keep it Silly, Stupid

Antonio Moruno Gracia — Sun, 31 Mar 2024 15:46:27 +0000

If you've entered this article because you think I misspelt the KISS principle, I'm sorry, but you've been clickbaited.

Let me explain myself.

The desing of reusable and flexible components has almost become a form of art (like any part of development actually).

However, it's easy to fall into the trap of creating overly complex components that are tightly coupled to specific use cases.

My take here is to keep them silly. That is, making them as dumb as possible. By doing so, we can maximize their reusability.

The key aspect of this paradigm is managing state from the outside. Instead of storing component state internally, we delegate state management to higher-level components that utilize them.

Let's take a look at how we can achieve that.

Managing state internally

Imagine we're creating a Dropdown component. The typical approach that many developers would take is as follows: when a user selects a field from the dropdown, we set that value within the dropdown component itself.

This way, we can set the component's state from the inside.

However, while creating the dropdown component with its internal state may seem sufficient for most scenarios, let's consider a different use case.

Imagine we want to reuse the Dropdown component in a filter page within our application. In this scenario, instead of setting the selected value within the dropdown itself, we would set a filter tag just below the dropdown when a user selects a field.

Now, our previous approach doesn't work. Some people might consider one of these options:

Create another new component just for this new use case.
Create a prop that indicates the component how it should behave.

Notice that both these two alternatives break the Open Closed Principle: any time we want our component to support one new use case, we'll have to modify it. None of those are a desirable choice.

Managing state with callbacks

The best approach here is to make our original component reusable by uplifting its state. But, how will we be able to set the component's state if we uplift it? Well, that's where callbacks come into play.

Rather than having a complex component manage its own state depending on its use case, we lift the state up to the parent component and pass down the necessary data and callbacks as props.

This way now, our component is opened for extension, but closed for modification

The dropdown component doesn't know what the callback does. It can set the dropdown value, set some filters, etc. It can do whatever we want.

The component just knows that it has to execute the callback. What the callback does is not its responsability. It's its parent's.

There are situations where we develop a component that we know we're not going to reuse. In such cases, applying this paradigm could potentially increase complexity. Therefore, it's important to use this approach wisely.

Instead of tightly coupling your components to specific use cases, consider composing them from the outside when necessary.

And that's why you should remember to Keep it ~~Simple~~ Silly, Stupid.

Thinking in Frontend

Antonio Moruno Gracia — Mon, 26 Feb 2024 20:34:56 +0000

In the dynamic universe of crafting software of any kind, there are a thousand roads to take. However, sometimes finding the best combination is the key. Frontend applications are no exception.

It's like having a bunch of Lego pieces at your disposal. Imagine that you want to build a new fancy house with your building blocks. You can achive it in multiple ways, but not all of them are the best way to do it: some bricks may be too big, others too small; others won't fit exactly as desired, etc.

In this article, we'll structure our minds so we'll be able to create more readable and manteinable layouts. We'll learn how thinking in frontend is.

Boxes, boxes and more boxes

At its core, this article encourages you to think of every element on the webpage as a box. This mental model simplifies the complexity of design by treating each component (be it text, images, or interactive elements) as a modular and self-contained entity: a box.

Try to think of any webpage. Even this article itself. It's full of boxes all over the place. They're everywhere!

Rather than focusing on specific properties like width, height, padding, border, or margin; the box paradigm urges developers to focus on the whole mix. Each box contributes to the overall visual harmony, and their arrangement determines the flow and structure of the entire interface.

In the example below, I've highlighted some of the boxes that compose a tipical Dev.to article page.

I encourage you to do the same exercise on your own. Try to imagine the boxes that compose this page. Some boxes are bigger, and boxes are smaller, but they all play an important role in composing the article.

Before starting coding your layout, do this mental exercise: think about which boxes does and contains what. Have in mind what responsability (positioning, aligning, containing) each of them should have in order to create a flexible and organized layout.

Talking about responsability, I encourage you to check this article afterwards 😄

If we start thinking that way, structuring our frontend applications turns out to be much easier, even entertaining! It's like being able to choose and create our own building blocks, which will compose the whole picture. It simplifies frontend chaos.

Why worrying that much?

Although this way of thinking might sound pretty straightforward (even obvious for some of you), you wouldn't believe how many times I've run into layouts in which this reasoning hasn't been applied.

Something that easy as creating the layout of some component or page could turn into a nightmare, resulting in creating messy code where, if you change any part of it, the complete layout falls to pieces.

Break down your design into manageable chunks, and suddenly, everything becomes way easier to handle. Styling, positioning, responsiveness – it all falls into place like pieces of a puzzle; easier code to read and mantain.

I encourage you to do this mental exercise before starting writing your code. Spend some time at it. You will save time later.

Avoid Over-Propping with Accessible Components in React

Antonio Moruno Gracia — Sun, 21 Jan 2024 20:14:43 +0000

One of React's basics are props. They are used to pass data from a parent component to its child components. While they are a great way to handle flow of data, sometimes we tend to overuse them, leading to increasing code complexity and reduced readability. It may make the component harder to maintain, understand and reuse.

In this short article I'd like to propose one way to handle this problem, taking advantage of the ARIA Attributes.

❌ The problem

Sometimes we need to pass some props to our components for styling purposes. In this example, we need to create a Radio Button, which changes its border color depending of whether it's checked or not (in this case we're using styled-components).

type ComponentProps = {
  $checked: boolean
}

const Component = styled.input<ComponentProps>`
  // Some styles...

  ${({ $checked }) =>
    $checked
      ? css`
          border-color: 1px solid blue;
        `
      : css`
          border-color: 1px solid grey;
        `
  }
`

// Some code

return 
  <>
    <Component
      $checked={!!value}
      checked={!!value}
      id="component"
      type="radio"
    />
    <label for="component">Radio input</label>
  </>

Since we already have the checked prop (html input has it natively), we'd have to create another prop if we wanted to apply some styles depending on it: $checked. We also need to type our component so Typescript knows that it has this new prop.

This technique adds a lot of unnecessary code and, moreover, it isn't accessible at all. Let's fix that.

✅ The solution

There are certain situations where we can avoid creating these props by ourselves. Instead, we can accomplish the same behaviour with ARIA Attributes.

const Component = styled.input`
  // Some styles...
  border-color: 1px solid grey;

  &[aria-checked='true'] {
    border-color: 1px solid blue;
  }
`

// Some code

return 
  <>
    <Component
      aria-checked={!!value}
      checked={!!value}
      id="component"
      type="radio"
    />
    <label for="component">Radio input</label>
  </>

Notice that we're using the aria-checked attribute here. Not only we're avoiding creating unnecessary props, but also our application is much more accessible, keeping also the behaviour as close to native as possible.

Another examples where this approach might be useful:

aria-expanded for a dropdown component.
aria-disabled when we want to disable operations over a certain element.
aria-selected for an element selected in a tablist.
etc.

Take into account that, as said before, this only applies for certain situations. Some ARIA Attributes might not provide the intented utility. You must be careful and responsible, taking accessibility seriously. Use this approach wisely.

The main point of this article is to state that, most of the times, is better to remain as close to native as possible, rather than creating unnecessary code.

I hope you liked it!

GraphQL Infinite Scroll

Antonio Moruno Gracia — Sun, 26 Nov 2023 18:08:23 +0000

Ever wonder how to enhance your website with an infinite scroll feature that keeps your users endlessly engaged?

In this article, we’re breaking down the process of creating an infinite scroll using GraphQL and React. By the end of this guide, you’ll be able to implement it in your own web projects.

Let’s dive in and unlock the secrets of infinite scrolling with GraphQL and React—it’s easier than you might think!

The Posts List

We are implementing a simple post list to serve as an example for this article. We will use this api to get some dummy posts.

In our case, we want to show the top 100 most rated post. Initially, we don't want to load all the posts at once. It would be more appropiate to load some posts, and when the user scrolls down the least then we load some more, and so on. That's the purpose of infinite scrolling: saving users from an initial full page load.

So, here we have the code that renders the page where we show all the posts.



// src/pages/posts/index.tsx
import Spinner from '~/components/Spinner'

import useLayout from './hooks'
import Post from './Post'
import {
  Container,
  Content,
  Description,
  Header,
  List,
  PageTitle,
  Title,
} from './styles'

const Layout = () => {
  const { loading, posts, thresholdElementRef } = useLayout()

  return (
    <Container>
      <PageTitle>Infinite Scroll</PageTitle>
      <Content>
        <Header>
          <Title>100 Most rated posts</Title>
          <Description>Check them all by scrolling down!</Description>
        </Header>
        {loading ? (
          <Spinner />
        ) : (
          <List>
            {posts.map(({ id, title }, index) => (
              <Post
                id={id}
                key={id}
                ref={
                  index === posts.length - 1 ? thresholdElementRef : undefined
                }
                title={title}
              />
            ))}
          </List>
        )}
      </Content>
    </Container>
  )
}

export default Layout

We are using a custom hook useLayout, from where we are extracting three things:

loading: Not relevant to this article. Just tells us if the query is still loading.
posts: The posts that are being rendered.
thresholdElementRef: A reference attached to the element that will serve as a threshold. In our case, that element will be the last post.

Let's take a look at our useLayout.



// src/pages/posts/hooks.tsx
import usePosts from '~/hooks/usePosts'
import useInfiniteScroll from '~/lib/use-infinite-scroll'

const useLayout = () => {
  const { fetchMorePosts, loading, posts } = usePosts()

  const { thresholdElementRef } = useInfiniteScroll({
    fetchNextPage: fetchMorePosts,
    options: { rootMargin: '400px' },
  })

  return { loading, posts, thresholdElementRef }
}

export default useLayout

Right here, we are creating the thresholdElementRef using
useInfiniteScroll. This library receives the fetchMorePosts function and some options as props. Let's break everything down step by step.

The `useInfiniteScroll` lib

This library will allow us to obtain a threshold reference, which we will asign to the element that will serve as a threshold.



// src/lib/use-infinite-scroll/index.ts
import useIntersectedElement from '../use-intersected-element'
import { UseInfiniteScrollProps } from './types'

const useInfiniteScroll = <ThresholdElement extends Element = Element>({
  fetchNextPage,
  options,
}: UseInfiniteScrollProps) => {
  const { thresholdElementRef } = useIntersectedElement<ThresholdElement>({
    callback: fetchNextPage,
    options,
  })

  return { thresholdElementRef }
}

export default useInfiniteScroll

This library just passes the received props to another library: useIntersectedElement.



// src/lib/use-intersected-element/index.ts
import { useEffect, useMemo, useState } from 'react'

import { UseIntersectedElementProps } from './types'

const useIntersectedElement = <ThresholdElement extends Element = Element>({
  callback,
  options,
}: UseIntersectedElementProps) => {
  const [thresholdElement, thresholdElementRef] =
    useState<ThresholdElement | null>(null)

  const observer = useMemo(
    () =>
      new IntersectionObserver(([entry]) => {
        if (!entry.isIntersecting) return

        callback()
      }, options),
    [callback, options],
  )

  useEffect(() => {
    if (!thresholdElement) return

    observer.observe(thresholdElement)

    return () => {
      observer.unobserve(thresholdElement)
    }
  }, [observer, thresholdElement])

  return { thresholdElementRef }
}

export default useIntersectedElement

export type { UseIntersectedElementProps }

Here, we create a state, whose setter is the ref that we've been talking about. Remember that, ultimately, this threshold element will be the last post of the list, as we mentioned before.

Then, we use IntersectionObserver to create an observer, which will execute the callback function received as an argument (remember the fetchMorePosts function in the useLayout hook?). If the entry (the target element) is not been intersected, then we execute nothing.

It can also receive some options. In our case (remember the useLayout hook), we only use the rootMargin: '400px', which increase the size of the root element's bounding box before computing intersections. You can take a look at the documentation in case of any doubts.

Finally, in the useEffect we are observing the threshold element, and unobserving it when the component unmounts.

The `fetchMorePosts`

What does GraphQL have to do with all of this? Well, here it comes!



// src/hooks/usePosts/index.ts
import { useQuery } from '@apollo/client'
import { useCallback, useMemo } from 'react'

import POSTS from '~/graphql/queries/posts'
import { PostsQuery, PostsQueryVariables } from '~/graphql/types'
import Post from '~/models/post'

import { MAX_NUMBER_OF_POSTS, POSTS_LIMIT } from './constants'

const usePosts = () => {
  const { data, fetchMore, loading } = useQuery<
    PostsQuery,
    PostsQueryVariables
  >(POSTS, {
    variables: {
      options: { paginate: { limit: POSTS_LIMIT, page: 1 } },
    },
  })

  const posts = useMemo(
    () => (data ? data.posts?.data?.map(Post.fromDto) ?? [] : []),
    [data],
  )

  const fetchMorePosts = useCallback(() => {
    if (posts.length === MAX_NUMBER_OF_POSTS) return

    fetchMore({
      updateQuery: (prev, { fetchMoreResult }) => {
        if (!fetchMoreResult) return prev

        return Object.assign({}, prev, {
          posts: {
            data: [
              ...(prev.posts?.data ?? []),
              ...(fetchMoreResult.posts?.data ?? []),
            ],
          },
        })
      },
      variables: {
        options: { paginate: { page: posts.length / POSTS_LIMIT + 1 } },
      },
    })
  }, [fetchMore, posts])

  return { fetchMorePosts, loading, posts }
}

export default usePosts

We need to use useQuery to fetch the data from the api. It is important that the api supports pagination. Pagination is a process used to divide a large dataset into smaller chunks (pages). This will allow us to request a "page" per request (ultimately allowing the implementation of an infinite scroll). In our case, we will request 10 posts per "page". We will store all those posts in posts.

So, here we have (finally 😅) the fetchMorePosts function. It makes use of the fetchMore function, which allows to send followup queries to our GraphQL server to obtain additional pages.

The behaviour would be the following: If we've reached the maximum number of posts, we stop requesting data. If not, fetchMorePosts will request the next 10 posts, adding them to posts.

You can find more information about GraphQL pagination in the official documentation.

Demonstration

We did it! Now we have an infinite scroll in our posts list.

So, to sum up:

We set the threshold reference to the last post that is being rendered (firstly, it will be the 10th, then the 20th, etc.)
We set the callback fetchMorePosts to the threshold, and execute it when the threshold is reached.
fetchMorePosts will query 10 posts at a time, adding them to the ones that have already been requested, until the limit is reached.

All the project code is available in this Github repository.

Final thoughts

Deciding to use GraphQL shouldn't be about adding infinite scroll. It's a bigger decision. However, GraphQL is a versatile tool that allows us to apply and implement some great things, and infinite scroll is not an exception.

I hope you've enjoyed the article and that it has encouraged you to add it to your projects. Thanks for your time!

CSS Learning Roadmap

Antonio Moruno Gracia — Mon, 23 Oct 2023 20:18:43 +0000

Cascading Style Sheets (CSS) is a fundamental technology for web development, empowering you to transform raw HTML into stunning, well-designed web pages.

In this roadmap, we'll provide a straightforward enumeration of key concepts, techniques, and areas of focus to help you progress in your CSS journey. Whether you're a novice or a seasoned developer, this roadmap is designed to be your reference for what to learn next.

Let's begin.

CSS Syntax

Understading CSS Syntax is fundamental in order to start learning CSS. This section introduces learners to selectors, properties, and values, explaining how to target HTML elements and apply styling.

Basic syntax
Selectors: (pseudo)classes, (pseudo)elements, attributes and combinators
Media queries and responsiveness

CSS Basics

In this section, you will dive into core styling principles. This provides a strong foundation for fundamental CSS concepts, which are used in many different situations.

Color, Texts and Fonts
Size and Units: absolute (px, in, pt, etc) and relative (em, rem, vh, vw, %, etc)
CSS Cascade
Basic display: Block elements and Inline elements
Height and Width: (min, max, fit)-content, maximum and minimum, etc.
CSS Box Model:
- Margin
- Border
- Padding
Managing overflow
Images: sizing, positioning and fitting

Positioned Layout

The use of position layout allows to control the placement of elements on a webpage. By mastering these key concepts, you'll gain the skills to design complex web layouts and add creative touches to your projects.

Relative positioning
Absolute positioning
Fixed positioning
Sticky positioning
Stacking contexts and z-index

Flexbox

Flexbox, or the Flexible Box Layout, is a powerful CSS layout model for creating responsive and dynamic page structures. This section serves as an introduction of these layout key concepts. As soon you understand them all, you will master this type of layout.

Understanding Flex layout basics
Content vs Items vs Self
Spacing, Justifying and Aligning
flex property: flex-grow, flex-shrink and flex-basis

Grid Layout

CSS Grid Layout is another essential layout tool. It allows to create two-dimensional grids and control the placement and alignment of elements with precision. This section presents some of the main grid concepts and properties, providing the steps to follow to build intricate page layouts.

Understanding Grid layout basics
Managing rows and columns
Content vs Items vs Self
Spacing, Justifying and Aligning

Bonus

This last section includes some CSS topics and practical applications that don't really fit in the sections above. This encompass topics like CSS animations, transitions, responsive design, and best practices for optimizing CSS code. It's a space to explore more specialized concepts and techniques that enhance a web developer's skill set.

Accessibility
Animations and effects:
- Transitions, transforming, keyframes
- Shadows, effects and gradients
Learning to manage CSS in the Browser Inspector
Styled-components and SASS

From my experience, I have always found it challenging to discover a guide to follow in order to master CSS. I must point out that this list is based on my personal experience. Each person should have its own path. Use this list as a guide, not as the source of true.

I hope this list proves to be useful for you.

Thanks for your time!

Don't use margin in CSS

Antonio Moruno Gracia — Tue, 10 Oct 2023 19:52:30 +0000

Nowadays, CSS has a wide range of tools and properties that allow designs that, until a few years ago, seemed impossible to implement. Many developers focus on learning this style language to the smallest detail, which can be quite challenging for some.

Despite not being considered a programming language by most, it's important to note that it's also a part of many applications. As developers, we should be responsible, making the code we develop as easy to understand, modify, and maintain as possible. CSS is no exception.

The goal of this post is to shed some light on a well-known property in CSS: margin. We will discuss its sometimes incorrect usage and propose alternative approaches that are much more maintainable and clean.

❌ When not to use

The main reason for not using margin lies in a matter of responsibility. When designing the layout of an application or an individual component, we should consider who is responsible for what.

(For the sake of the post, we will omit border styles and other details).

Between parent and children

Let's imagine that we want to implement the following layout. The goal is to position the blocks as shown in the image. Who is responsible for placing the child at a certain distance from the parent: the child or the parent?

It's the parent who should define the distance at which their children are positioned. This is the key. The responsibility lies within the parent block. If we wanted to change the content of the parent, we would probably want to preserve the distance that their children have from it, so these styles should belong to the parent.



.parent {
    padding: 24px;
}

.child {
    /*No margin needed*/
}

Of course, there are exceptions. It's possible that we may need to create a layout where the children are not at the same distance to the parent, as shown in the following image.

In this case, it's possible to approach the design as follows: the parent of the last two elements is not the same as the parent of the first element. We can create another element to serve as a wrapper for the last two elements and apply the "extra margin" they have as padding.



.parent {
    padding: 24px;
}

.wrapper {
    /*Extra padding for the last two children*/
    padding: 24px; 
}

.child {
    /*No margin needed*/
}

Note: The borders are shown simply to illustrate the blocks we would have at code level. The presence of an additional parent block would be invisible to the application end-user.

Between siblings

You may have noticed a detail in the previous layout: the child elements are also separated from each other.

This separation can be achieved by applying top or bottom margin to all of them. However, we come back to the same question: who should be responsible for separating the children from each other? Well, surprisingly, it should be the parent.

But, from the parent, how can we separate children from each other? The best option is to harness the power of the Grid Layout.

This post doesn't cover the use of this type of layout in detail. In summary, the Grid Layout allows us to treat the children of an element as if they were in a grid, organizing how they are positioned relative to each other. Among its options, it's possible to determine the exact distance at which elements are positioned from each other. How? Well, by using the gap property.



.parent {
    display: grid; /*Changes the display layout to grid*/
    gap: 24px; /*Desired gap between elements*/
    padding: 24px;
}

.child {
    /*No margin needed*/
}

The major advantage of using this alternative is that the gap property adds space only between the elements, neither at the beginning nor at the end. If we were to use margins for each element, we would need to ensure that these margins are not applied incorrectly to the first or last element to avoid unnecessary spacing.

Amazing! Isn't it?

✅ When to use

There are some occasions when using margin is not a bad alternative.

Margin: auto

If an element uses margin: auto, it will be centered horizontally with respect to its parent. However, there are several considerations to keep in mind:

This only works for centering elements horizontally, not vertically.
Inline elements (<a/>, <em/>, <span/>, etc) cannot be centered using this declaration. It only works for block elements.
We come back to the same question again: who is responsible for centering the element? In this case, the element would be centered by itself, not by its parent.
There are other properties within the flex and grid layouts that allow both vertical and horizontal centering (justify-content, align-items, etc), which could be more appropiate.

Despite these disadvantages, sometimes using margin: auto is simpler and quicker than any of the alternatives, so it's not a bad choice.

Overlapping

When it comes to overlaying elements, using margins can be very handy.

To achieve the layout from the previous image, we can apply a negative margin to the child element (such as margin-left: -120px), causing it to be displayed overlapped with its parent element.

There are other alternatives, such as the position property, which allows to position elements relative to another element. However, using this property may, among other things, cause the child element not to respect the parent's padding.

In this case, using negative margins is much simpler and more straightforward.

I hope you found this post interesting and that it helps you in your programming projects. The proposed alternatives are just one of the many options that CSS offers. In programming, there is not a single way to do things. In CSS, neither is there.

If you have any questions or want to share any ideas, please leave a comment below.

Thanks for your time!

Forem: Antonio Moruno Gracia

99% of frontend devs don't use this

❓ What are data-* Attributes?

🧠 The Common Pattern: Closures in .map()

⚠️ The Downsides of Closures

1. Unnecessary Re-Renders

2. Harder to Optimize

✅ The Alternative: data-*

🤔 So Why Isn’t Everyone Doing This?

✨ In Summary

Goodbye useCallback and useMemo: How React Compiler Takes Over

The Current State of Memoization in React

useCallback

useMemo

memo

How React Compiler Changes the Game

Current transpiler

React compiler

Final thoughts

Keep it Silly, Stupid

Managing state internally

Managing state with callbacks

Thinking in Frontend

Boxes, boxes and more boxes

Why worrying that much?

Avoid Over-Propping with Accessible Components in React

❌ The problem

✅ The solution

GraphQL Infinite Scroll

The Posts List

The useInfiniteScroll lib

The fetchMorePosts

Demonstration

Final thoughts

CSS Learning Roadmap

CSS Syntax

CSS Basics

Positioned Layout

Flexbox

Grid Layout

Bonus

Don't use margin in CSS

❌ When not to use

Between parent and children

Between siblings

✅ When to use

Margin: auto

Overlapping

✅ The Alternative: `data-*`

The `useInfiniteScroll` lib

The `fetchMorePosts`