DEV Community: Leonardo Muniz

Nomeação de Variáveis CSS: Boas Práticas e Abordagens

Leonardo Muniz — Wed, 10 Jul 2024 10:09:19 +0000

Recentemente, enquanto navegava na internet, como todo bom desenvolvedor front-end, quis "roubar" a paleta de cores de um site. Então, abri o inspetor de elementos para copiar os valores hexadecimais das cores e me deparei com uma surpresa inusitada: as variáveis CSS estavam nomeadas de forma inconsistente.

juro, nao è meme.

Como você pode perceber, os valores das variáveis não correspondiam aos seus nomes, o que é um exemplo clássico de "naming inconsistency" (inconsistência de nomenclatura). É crucial evitar isso em sua base de código.

Nomear variáveis CSS é essencial para a organização, legibilidade e manutenção do código em projetos front-end. Apesar de parecer trivial, muitas empresas ainda não adotam um padrão de nomenclatura.

Este artigo explora várias abordagens para a nomeação de variáveis CSS, destacando a importância de escolhas semânticas e práticas consistentes, se voce ainda não sabe como declarar variaveis, eu te aconselho primeiro ler este artigo no MDN Web Docs, e depois voltar pra cá pra gente falar sobre as varias abordagens possiveis.

Índice

Por que Usar Variáveis CSS?
Vantagens das Variáveis CSS
Abordagens para Nomear Variáveis CSS
Nomeação Baseada em Cores
Nomeação Semântica
Combinação de Nomes Semânticos e de Cores
Nomeação Contextual
Nomeação Baseada em Escopo
Nomeação Baseada em Componentes
Nomeação Baseada em Tipos de Valores
Nomeação Baseada em Temas
Ferramentas de Linting para Variáveis CSS
Conclusão

Por que Usar Variáveis CSS? 🔗

Segundo CSS Tricks, variáveis CSS (custom properties) proporcionam flexibilidade e poder ao CSS, permitindo a criação de temas dinâmicos e o ajuste de estilos em tempo real. Jonathan Harrell destaca que variáveis CSS são nativas, dinâmicas e podem ser redefinidas dentro de media queries, além de funcionarem em qualquer contexto CSS, seja ele pré-processado ou não.

Vantagens das Variáveis CSS 🔗

Reutilização: Permitem o uso consistente de valores em todo o projeto.
Manutenção: Facilita a atualização de estilos ao alterar valores em um único lugar.
Legibilidade: Nomes significativos tornam o código mais fácil de entender e manter.

Abordagens para Nomear Variáveis CSS 🔗

1. Nomeação Baseada em Cores 🔗
Nomear variáveis CSS com base nas cores é uma abordagem direta. Esta técnica é útil para pequenos projetos ou quando as cores têm um uso limitado, mas deve-se ter cuidado com possíveis problemas de manutenção, estou citando esta abordagem aqui, mas não recomendo usa-la.

:root {
  --blue: #4267b2;
  --indigo: #3b2614;
  --purple: #754218;
  --pink: #f1ece7;
  --red: #b50000;
  --orange: #dc3545;
  --yellow: #f2b300;
  --green: #009733;
}

Vantagens:

Clareza imediata: Facilita a identificação da cor exata.
Simplicidade: Fácil de implementar.

Desvantagens:

Semântica limitada: Não indica o propósito da cor.
Reutilização: Pode ser confuso em projetos maiores com múltiplos contextos de uso.
Manutenção: Alterar uma cor pode quebrar a consistência semântica.

2. Nomeação Semântica 🔗

Nomear variáveis com base no propósito ou contexto de uso melhora a compreensão do código.

:root {
  --primary-color: #4267b2;
  --secondary-color: #3b2614;
  --accent-color: #754218;
  --background-color: #f1ece7;
  --error-color: #b50000;
  --warning-color: #dc3545;
  --info-color: #f2b300;
  --success-color: #009733;
}

Vantagens:

Clareza semântica: Indica o propósito ou contexto da cor.
Facilidade de manutenção: Simples de atualizar e reutilizar.
Suporte a temas: Fácil implementação de temas diferentes.
Consistência: Facilita a colaboração em equipes.

Desvantagens:

Abstração: Pode requerer mais esforço para mapear nomes a cores específicas.
Curva de aprendizado: Pode ser desafiador para novos desenvolvedores.

3. Combinação de Nomes Semânticos e de Cores 🔗

Combina semântica com a descrição da cor, proporcionando clareza e contexto.

:root {
  --primary-blue: #4267b2;
  --secondary-brown: #3b2614;
  --accent-purple: #754218;
  --background-pink: #f1ece7;
  --error-red: #b50000;
  --warning-orange: #dc3545;
  --info-yellow: #f2b300;
  --success-green: #009733;
}

Vantagens:

Detalhamento: Combina clareza imediata com contexto semântico.
Contexto adicional: Facilita a compreensão e manutenção.

Desvantagens:

Verbosidade: Pode resultar em nomes mais longos e verbosos.

4. Nomeação Contextual 🔗

As variáveis são nomeadas de acordo com o contexto de uso.

:root {
  --header-background: #333;
  --header-color: #fff;
  --footer-background: #222;
  --footer-color: #ccc;
}

.header {
  background-color: var(--header-background);
  color: var(--header-color);
}

.footer {
  background-color: var(--footer-background);
  color: var(--footer-color);
}

Vantagens:

Clareza contextual: Facilita a identificação do propósito das variáveis em partes específicas do layout.
Evita conflitos: Útil em grandes projetos com múltiplos componentes.

Desvantagens:

Potencial de repetição: Pode haver redundância de variáveis para diferentes contextos.

5. Nomeação Baseada em Escopo 🔗

As variáveis são nomeadas para refletir o escopo específico onde serão usadas. Isso pode ajudar a evitar conflitos de nomenclatura em grandes projetos.

:root {
  --button-primary-bg: #007bff;
  --button-primary-color: #fff;
  --button-secondary-bg: #6c757d;
  --button-secondary-color: #fff;
}

.button-primary {
  background-color: var(--button-primary-bg);
  color: var(--button-primary-color);
}

.button-secondary {
  background-color: var(--button-secondary-bg);
  color: var(--button-secondary-color);
}

Vantagens:

Evita conflitos: Reduz a chance de colisões de nomes em grandes bases de código.
Escopo claro: Facilita a manutenção e leitura do código.

Desvantagens:

Complexidade: Pode adicionar complexidade ao gerenciar muitos escopos diferentes.

6. Nomeação Baseada em Componentes (Component-based Naming) 🔗

As variáveis são nomeadas de acordo com os componentes específicos da interface. Isso é comum em metodologias como BEM (Block Element Modifier).

:root {
  --card-background: #fff;
  --card-border: 1px solid #ddd;
  --card-title-color: #333;
}

.card {
  background-color: var(--card-background);
  border: var(--card-border);
}

.card-title {
  color: var(--card-title-color);
}

Vantagens:

Clareza de componente: Facilita a identificação das variáveis relacionadas a componentes específicos.
Modularidade: Facilita a reutilização de estilos em diferentes partes do projeto.

Desvantagens:

Manutenção: Pode ser mais difícil manter consistência em projetos muito grandes.

7. Nomeação Baseada em Tipos de Valores (Type-based Naming) 🔗

As variáveis são nomeadas para refletir o tipo de valor que representam. Isso é útil para manter consistência em todo o projeto.

:root {
  --color-primary: #3498db;
  --color-secondary: #2ecc71;
  --font-size-small: 12px;
  --font-size-medium: 16px;
  --font-size-large: 24px;
  --spacing-small: 8px;
  --spacing-medium: 16px;
  --spacing-large: 32px;
}

.text-primary {
  color: var(--color-primary);
}

.text-secondary {
  color: var(--color-secondary);
}

.small-text {
  font-size: var(--font-size-small);
}

.medium-text {
  font-size: var(--font-size-medium);
}

.large-text {
  font-size: var(--font-size-large);
}

.margin-small {
  margin: var(--spacing-small);
}

.margin-medium {
  margin: var(--spacing-medium);
}

.margin-large {
  margin: var(--spacing-large);
}

Vantagens:

Consistência: Facilita a manutenção e leitura ao usar uma convenção clara para tipos de valores.
Modularidade: Facilita a reutilização de variáveis em diferentes contextos.

Desvantagens:

Verbosidade: Pode resultar em nomes longos.

8. Nomeação Baseada em Temas (Theming) 🔗

As variáveis são nomeadas para refletir diferentes temas ou modos (como modo claro e modo escuro).

:root {
  --color-background-light: #ffffff;
  --color-background-dark: #000000;
  --color-text-light: #000000;
  --color-text-dark: #ffffff;
}

.light-theme {
  background-color: var(--color-background-light);
  color: var(--color-text-light);
}

.dark-theme {
  background-color: var(--color-background-dark);
  color: var(--color-text-dark);
}

Vantagens:

Flexibilidade: Facilita a criação e manutenção de diferentes temas visuais.
Consistência: As variáveis podem ser facilmente trocadas para alterar o tema.

Desvantagens:

Complexidade: Gerenciar múltiplos temas pode adicionar complexidade ao projeto.

Ferramentas de Linting para Variáveis CSS 🔗

Ferramentas de linting podem ajudar a garantir que as variáveis sigam convenções de nomenclatura específicas, promovendo consistência no código. Exemplos de ferramentas incluem:

Stylelint: Um linter moderno e flexível para CSS que pode ser configurado para verificar a consistência das variáveis.
PostCSS: Uma ferramenta que transforma o CSS com plugins, incluindo verificações de variáveis.
CSS Linter: Ferramenta específica para garantir o uso correto e consistente de variáveis CSS.

Conclusão 🔗

Essas abordagens e práticas podem ajudar a garantir que o uso de variáveis CSS em seus projetos seja eficiente, organizado e fácil de manter. A escolha da abordagem certa depende das necessidades e da escala do seu projeto, bem como das preferências e práticas da sua equipe de desenvolvimento.

Créditos 🔗

Este artigo foi inspirado por experiências pessoais e estudos em várias fontes de referência, incluindo CSS Tricks e trabalhos de Jonathan Harrell.

CSS Variable Naming: Best Practices and Approaches

Leonardo Muniz — Wed, 10 Jul 2024 10:06:22 +0000

Recently, while browsing the internet, like any good front-end developer, I wanted to "steal" the color palette of a site. So, I opened the inspector to copy the hexadecimal values of the colors and came across an unusual surprise: the CSS variables were named inconsistently.

I swear, it's not a meme.

As you can see, the variable values did not match their names, which is a classic example of "naming inconsistency". It is crucial to avoid this in your codebase.

Naming CSS variables is essential for the organization, readability, and maintenance of the code in front-end projects. Despite seeming trivial, many companies still do not adopt a naming standard.

This article explores various approaches to naming CSS variables, highlighting the importance of semantic choices and consistent practices. If you don't know how to declare variables yet, I recommend you first read this article on MDN Web Docs, and then come back here so we can talk about the various possible approaches.

Why Use CSS Variables?
Benefits of CSS Variables
Approaches to Naming CSS Variables
Color-Based Naming
Semantic Naming
Combination of Semantic and Color Names
Contextual Naming
Scope-Based Naming
Component-Based Naming
Type-Based Naming
Theme-Based Naming
Linting Tools for CSS Variables
Conclusion

Why Use CSS Variables? 🔗

According to CSS Tricks, CSS variables (custom properties) provide flexibility and power to CSS, allowing for the creation of dynamic themes and real-time style adjustments. Jonathan Harrell highlights that CSS variables are native, dynamic, and can be redefined within media queries, working in any CSS context, whether preprocessed or not.

Benefits of CSS Variables 🔗

Reuse: Enable consistent use of values throughout the project.
Maintenance: Simplifies style updates by changing values in one place.
Readability: Meaningful names make the code easier to understand and maintain.

Approaches to Naming CSS Variables 🔗

1. Color-Based Naming 🔗

Naming CSS variables based on colors is a straightforward approach. This technique is useful for small projects or when colors have limited use, but care must be taken with potential maintenance issues. I'm mentioning this approach here, but I don't recommend using it.

:root {
  --blue: #4267b2;
  --indigo: #3b2614;
  --purple: #754218;
  --pink: #f1ece7;
  --red: #b50000;
  --orange: #dc3545;
  --yellow: #f2b300;
  --green: #009733;
}

Advantages:

Immediate clarity: Makes it easy to identify the exact color.
Simplicity: Easy to implement.

Disadvantages:

Limited semantics: Does not indicate the purpose of the color.
Reuse: Can be confusing in larger projects with multiple usage contexts.
Maintenance: Changing a color can break semantic consistency.

2. Semantic Naming 🔗

Naming variables based on their purpose or usage context improves code understanding.

:root {
  --primary-color: #4267b2;
  --secondary-color: #3b2614;
  --accent-color: #754218;
  --background-color: #f1ece7;
  --error-color: #b50000;
  --warning-color: #dc3545;
  --info-color: #f2b300;
  --success-color: #009733;
}

Advantages:

Semantic clarity: Indicates the purpose or context of the color.
Ease of maintenance: Simple to update and reuse.
Theming support: Easy implementation of different themes.
Consistency: Facilitates team collaboration.

Disadvantages:

Abstraction: May require more effort to map names to specific colors.
Learning curve: Can be challenging for new developers.

3. Combination of Semantic and Color Names 🔗

Combines semantics with color description, providing clarity and context.

:root {
  --primary-blue: #4267b2;
  --secondary-brown: #3b2614;
  --accent-purple: #754218;
  --background-pink: #f1ece7;
  --error-red: #b50000;
  --warning-orange: #dc3545;
  --info-yellow: #f2b300;
  --success-green: #009733;
}

Advantages:

Detailing: Combines immediate clarity with semantic context.
Additional context: Facilitates understanding and maintenance.

Disadvantages:

Verbosity: Can result in longer, more verbose names.

4. Contextual Naming 🔗
Variables are named according to their usage context.


:root {
  --header-background: #333;
  --header-color: #fff;
  --footer-background: #222;
  --footer-color: #ccc;
}

.header {
  background-color: var(--header-background);
  color: var(--header-color);
}

.footer {
  background-color: var(--footer-background);
  color: var(--footer-color);
}

Advantages:

Contextual clarity: Makes it easy to identify the purpose of variables in specific layout parts.
Avoids conflicts:** Useful in large projects with multiple components.

Disadvantages:

Potential repetition: There may be redundancy of variables for different contexts.

5. Scope-Based Naming 🔗
Variables are named to reflect the specific scope where they will be used. This can help avoid naming conflicts in large projects.


:root {
  --button-primary-bg: #007bff;
  --button-primary-color: #fff;
  --button-secondary-bg: #6c757d;
  --button-secondary-color: #fff;
}

.button-primary {
  background-color: var(--button-primary-bg);
  color: var(--button-primary-color);
}

.button-secondary {
  background-color: var(--button-secondary-bg);
  color: var(--button-secondary-color);
}

Advantages:

Avoids conflicts: Reduces the chance of name collisions in large codebases.
Clear scope: Facilitates code maintenance and readability.

Disadvantages:

Complexity: Can add complexity when managing many different scopes.

6. Component-Based Naming 🔗
Variables are named according to specific interface components. This is common in methodologies like BEM (Block Element Modifier).

:root {
  --card-background: #fff;
  --card-border: 1px solid #ddd;
  --card-title-color: #333;
}

.card {
  background-color: var(--card-background);
  border: var(--card-border);
}

.card-title {
  color: var(--card-title-color);
}

Advantages:

Component clarity: Makes it easy to identify variables related to specific components.
Modularity: Facilitates reuse of styles in different parts of the project.

Disadvantages:

Maintenance: Can be more difficult to maintain consistency in very large projects.

7. Type-Based Naming 🔗
Variables are named to reflect the type of value they represent. This is useful for maintaining consistency throughout the project.

:root {
  --color-primary: #3498db;
  --color-secondary: #2ecc71;
  --font-size-small: 12px;
  --font-size-medium: 16px;
  --font-size-large: 24px;
  --spacing-small: 8px;
  --spacing-medium: 16px;
  --spacing-large: 32px;
}

.text-primary {
  color: var(--color-primary);
}

.text-secondary {
  color: var(--color-secondary);
}

.small-text {
  font-size: var(--font-size-small);
}

.medium-text {
  font-size: var(--font-size-medium);
}

.large-text {
  font-size: var(--font-size-large);
}

.margin-small {
  margin: var(--spacing-small);
}

.margin-medium {
  margin: var(--spacing-medium);
}

.margin-large {
  margin: var(--spacing-large);
}

Advantages:

Consistency: Facilitates maintenance and readability by using a clear convention for types of values.
Modularity: Facilitates reuse of variables in different contexts.

Disadvantages:

Verbosity: Can result in long names.

8. Theme-Based Naming 🔗

Variables are named to reflect different themes or modes (such as light mode and dark mode).

:root {
  --color-background-light: #ffffff;
  --color-background-dark: #000000;
  --color-text-light: #000000;
  --color-text-dark: #ffffff;
}

.light-theme {
  background-color: var(--color-background-light);
  color: var(--color-text-light);
}

.dark-theme {
  background-color: var(--color-background-dark);
  color: var(--color-text-dark);
}

Advantages:

Flexibility: Facilitates the creation and maintenance of different visual themes.
Consistency: Variables can be easily swapped to change the theme.

Disadvantages:

Complexity: Managing multiple themes can add complexity to the project.

Linting Tools for CSS Variables 🔗

Linting tools can help ensure that variables follow specific naming conventions, promoting consistency in the code. Examples of tools include:

Stylelint: A modern, flexible linter for CSS that can be configured to check variable consistency.

PostCSS: A tool that transforms CSS with plugins, including variable checks.

CSS Linter: A specific tool to ensure correct and consistent use of CSS variables.

Conclusion 🔗

These approaches and practices can help ensure that the use of CSS variables in your projects is efficient, organized, and easy to maintain. The right approach depends on your project's needs and scale, as well as your development team's preferences and practices.

Credits 🔗

This article was inspired by personal experiences and studies from various reference sources, including CSS Tricks and the works of Jonathan Harrell.

Arquitetura Resiliente no React: Usando Error Boundaries

Leonardo Muniz — Thu, 02 Nov 2023 20:19:20 +0000

Recentemente estava implementando numa página um leitor de pdf para uma revista, testei no browser desktop e tudo funcionava perfeitamente.

O problema nasceu no mobile, pois após avançar algumas páginas do pdf o site quebrava completamente: “Application error: a client-side exception has occurred (see the browser console for more information).”.

Resumo do conteúdo

O que são Error Boundaries?
Quando usar e quando não usar
Opcionais
Bibliotecas de Terceiros

Não vou falar da solução, mas sim de como evitar que sua aplicação quebre completamente nesses casos, utilizando o conceito de Error Boundary para apresentar um UI alternativa em caso de erro.

Tela de erro nao tratada

UI com tratamento de error boundary

Antes do React 16, um erro em qualquer componente poderia levar a falhas em toda a aplicação, pois o erro era propagado (intensionalmente, nao é um bug, é uma feature mesmo🫣), quebrando completamente o site e criando uma experiência ruim para o usuário. Com a chegada do React 16, os Error Boundaries foram introduzidos, permitindo que desenvolvedores capturassem e tratassem erros em componentes específicos, sem derrubar toda a aplicação.

O que são Error Boundaries? 🔗

Error Boundaries são componentes React que capturam erros JavaScript em seus componentes filhos, registram esses erros e exibem uma interface de fallback em vez do componente que falhou, funcionando como um catch{} para componentes.

Atualmente, é disponível somente como componente de classe e, até o momento, não há indícios da equipe do React querer mudar isso (ok, oficialmente nao tem, mas voce vai encontrar formas de fazer isso tanto manualmente quanto com libs externas e falarei disso mais pra frente.)

Exemplo de código:

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    return { hasError: true };
  }

  componentDidCatch(error, info) {
    logErrorToService(error, info.componentStack);
  }

  render() {
    if (this.state.hasError) {
      return <h1>Algo deu errado.</h1>;
    }
    return this.props.children;
  }
}

Vamos entender melhor o papel das funções:

getDerivedStateFromError: Esta função estática é usada para atualizar o estado local do componente e renderizar uma UI de fallback após um erro.
componentDidCatch: Este método é acionado após um erro ser capturado pelo Error Boundary. É útil para registro de erros ou efeitos colaterais.

Ao usar o Error Boundary em sua aplicação, envolva os componentes que você deseja proteger:

<ErrorBoundary>
 <SeuComponente />
</ErrorBoundary>

Voce tambem pode envolver toda a aplicacao, tambem pode envolver o conteudo do site excluindo o layout ou ate mesmo somente rotas, tudo depende do design que voce escolher e que fizer mais sentido no seu contexto.

Quando usar e quando não usar 🔗

Quando usar:

Em componentes ou funcionalidades não críticas.
Quando incorporar widgets ou bibliotecas de terceiros.

Quando não usar:

Para erros esperados (como erros de API conhecidos).
Dentro de manipuladores de eventos.
Em erros que devem ser tratados de maneira específica e não genérica.
Código assíncrono: Error Boundaries não capturam erros em operações assíncronas fora de componentes React, como setTimeout ou requestAnimationFrame. Para tratar erros em operações assíncronas dentro de componentes, você deve usar blocos try/catch.
Renderização do lado do servidor
Erros lançados no próprio Error Boundary.

Opcionais: 🔗

Integre Error Boundaries a soluções de monitoramento de erros para rápida identificação e correção, voce pode integrar com Sentry ou Exceptionless por exemplo.
Teste seus Error Boundaries para garantir que eles funcionem como esperado em diferentes cenários.

Bibliotecas de Terceiros: react-error-boundary 🔗

Enquanto os Error Boundaries nativos do React são poderosos, algumas bibliotecas de terceiros foram desenvolvidas para simplificar e enriquecer essa funcionalidade. Uma das mais populares é a react-error-boundary.

Principais benefícios:

API Simplificada: Com react-error-boundary, você pode criar um boundary de erro com uma simples função de fallback, sem a necessidade de criar uma classe componente, alem de oferecer diversas outras possibilidades, que nao irei tratar hoje.

exemplo com react-error-boundary:


import { ErrorBoundary } from 'react-error-boundary'

function FallbackComponent({ error }) {
  return <div>Ocorreu um erro: {error.message}</div>
}

<ErrorBoundary FallbackComponent={FallbackComponent}>
  <SeuComponente />
</ErrorBoundary>

Hooks e Utilitários Adicionais: A biblioteca oferece o hook useErrorHandler, que permite capturar e tratar erros dentro de componentes funcionais e funções personalizadas.

Reinicialização Automática: Com a propriedade onReset, você pode definir como o componente deve se reiniciar após um erro.

Resilient Architecture in React: Using Error Boundaries

Leonardo Muniz — Sun, 29 Oct 2023 15:42:47 +0000

Recently I was implementing a pdf reader for a magazine on a page, I tested it on the desktop browser and everything worked perfectly.

The problem occurred on mobile, because after going through a few pages of the pdf, the site crashed completely: "Application error: a client-side exception has occurred (see the browser console for more information).".

Content summary

What is Error Boundaries?
When to use and when not to use
Optionals
Third-party libraries

I'm not going to talk about the solution, but about how to prevent your application crashing completely in these cases, using the concept of Error Boundary to present an alternative UI in the case of an error.

Error screen not handled

UI with error boundary handling

Before React 16, an error in any component could result in the entire application crashing, as the error was propagated (intentionally, it's not a bug, it's a feature🫣), completely breaking the site and creating a bad user experience. With the arrival of React 16, Error Boundaries were introduced, allowing developers to capture and handle errors in specific components, without bringing down the entire application.

What are Error Boundaries? 🔗

Error Boundaries is a React component that catches JavaScript errors in its child components, logs those errors and displays a fallback interface instead of the failed component, working like a *catch{} for components.

Currently, it's only available as a class component and, so far, there's no evidence of the React team wanting to change this (ok, officially there isn't, but you'll find ways to do this both manually and with external libs and I'll talk about that later).

Code Example:

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    return { hasError: true };
  }

  componentDidCatch(error, info) {
    logErrorToService(error, info.componentStack);
  }

  render() {
    if (this.state.hasError) {
      return <h1>Something has gone wrong.</h1>;
    }
    return this.props.children;
  }
}

Let's better understand the role of the functions:

getDerivedStateFromError: This static function is used to update the local state of the component and render a fallback UI after an error.
componentDidCatch: This method is triggered after an error is caught by the Error Boundary. It is useful for logging errors or side effects.

When using Error Boundary in your application, wrap the components you want to protect:

<ErrorBoundary>
  <Component />
</ErrorBoundary>

You can also involve the entire application or you can involve the content of the site excluding the layout or even just routes, it all depends on the design you choose and which makes the most sense in your context.

When to use and when not to use 🔗

When to use

In non-critical components or functionalities.
When incorporating widgets or third-party libraries.

When not to use

For expected errors (such as known API errors).
Within event handlers.
For errors that should be handled specifically and not generically.
Asynchronous code: Error Boundaries do not catch errors in asynchronous operations outside of React components, such as setTimeout or requestAnimationFrame. To handle errors in asynchronous operations inside components, you must use try/catch blocks.
Server-side rendering
Errors thrown in the Error Boundary itself.

Optionals: 🔗

Integrate Error Boundaries with error monitoring solutions for quick identification and correction, you can integrate with Sentry or Exceptionless for example.
Test your Error Boundaries to ensure that they work as expected in different scenarios.

Third-party libraries: react-error-boundary 🔗
While React's native Error Boundaries are sufficient to handle these needs, some third-party libraries have been developed to simplify and enrich this functionality. One of the most popular is react-error-boundary.

Main benefits

Simplified API: With react-error-boundary, you can create an error boundary with a simple fallback function, without the need to create a component class, and it offers several other possibilities, which I won't go into today.

example with react-error-boundary:



import { ErrorBoundary } from 'react-error-boundary'

function FallbackComponent({ error }) {
  return <div>An error has occurred: {error.message}</div>
}

<ErrorBoundary FallbackComponent={FallbackComponent}>
  <Component />
</ErrorBoundary>

Additional Hooks and Utilities: The library offers the useErrorHandler hook, which allows you to catch and handle errors within functional components and custom functions.

Automatic Restart: With the onReset property, you can define how the component should restart itself after an error.

[EN] Viewport units in CSS: Beyond VH

Leonardo Muniz — Mon, 23 Oct 2023 20:53:28 +0000

Well, this text comes from someone who's just discovered something and wants to tell the whole world about it. Up until a few hours ago, I didn't know there were other viewport units besides vh/vw. how did I notice that?? By facing responsiveness issues and searching for solutions. I had implemented a modal that needed to take up 100% of the page height. So '100vh' worked pretty well... on desktop. The real problem emerged when I tested it on a mobile device. Below, I explain the problem and how I solved it.

In this article, I'll try to discuss the 'new' CSS viewport units: svh, lvh, and dvh. But first, let's understand a few basics before we delve deeper.

Summary of content

What is a Viewport?
VH Problems
SVH — Small Viewport Height
LVH — Large Viewport Units
DVH — Dynamic Viewport Units
Browser Compatibility
Progressive Enhancement

What is a Viewport? 🔗

In a nutshell, the viewport is the visible area of a web page on a device. The size of the viewport varies according to the device, the browser, and can even be changed by the user if they resize the browser window.

VH — Viewport Height

"VH" was introduced in CSS module 3 and is a relative CSS unit. It allows webpage elements to be sized based on the screen size, creating a responsive layout. Thus, 'vh' represents a percentage of the viewport height.

1vh=1% of the viewport height.

.foo {
height: 50vh; /* The element will be 50% of the viewport height */
}

VH Problems 🔗

While 'vh' brought many improvements, especially for desktops, mobile devices posed some challenges. Some browsers have a navigation bar that occupies screen space. This bar usually overlays the webpage content and can dynamically expand or retract based on the direction the user scrolls. Therefore, 'vh' can behave unexpectedly on some devices.

Because of these problems, the community discussed and came up with some solutions:

SVH — Small Viewport Height 🔗

'svh' is defined considering the viewport size when the navigation bar (or other browser items) is expanded. So when the browser occupies as much space as possible, the page content will be the smallest.

In the example below, '100svh' will occupy the screen space considering the expanded navigation bar, without content "hanging" beneath the bar.

.container {
height: 100svh; /* The element will be the viewport height considering the expanded UI */
}

When to use:
When you want to ensure content won't be obscured by the browser's UI.

When to avoid:
If the browser's UI is retracted, as there might be extra white space.

LVH — Large Viewport Units 🔗

Conversely, 'lvh' is the opposite of 'svh'. It's defined considering the viewport size when the navigation bar or other browser items are retracted. Essentially, 'lvh' behaves similarly to 'vh'.

.container {
height: 100lvh; /* The element will be the viewport height considering the retracted UI */
}

When to use:
To maximize content space when the browser's UI is retracted.

When to avoid:
If the browser's UI is expanded, as content might be obscured.

DVH — Dynamic Viewport Units 🔗

As the name suggests, Dynamic Viewport is dynamic. It automatically adjusts the content size based on the browser's UI, whether expanded or retracted. Although this might seem perfect, one must be cautious: using 'dvh' could cause content to resize when the user scrolls, which could be distracting and degrade user experience, not to mention potential performance costs.

.container {
height: 100dvh; /* The element's height will dynamically adjust with the browser's UI */
}

When to use:
When you want dynamic height adjustments as the browser's UI changes.

When to avoid:
If dynamic resizing could distract the user or negatively impact user experience.

Browser compatibility 🔗


108	108	101	15.4

Progressive Enhancement 🔗

@supports is a conditional CSS rule that allows you to check whether or not a browser supports a certain property or value. It's very useful if you want to apply advanced or experimental styles and ensure that if the browser doesn't support it, it offers a valid alternative to the browser without harming the user experience.
This is "progressive enhancement".

Here's a basic example:

/* Standard styles for all browsers */
div {
    height: 50vh; /* using the traditional vh unit */
}

/* Specific styles for browsers that support svh */
@supports (height: 50svh) {
    div {
        height: 50svh; /* using the new svh unit */
    }
}

This ensures that if the browser doesn't support SVH, it will use VH.

Thanks Camilo , for the wonderful suggestions for this article, you're amazing!

[it-IT] Unità di Viewport nei CSS: Oltre il VH

Leonardo Muniz — Tue, 10 Oct 2023 08:36:40 +0000

Fino a poche ore fa ignoravo l'esistenza di altre unità di viewport oltre a vh/vw, e come me ne sono accorto? Cercando soluzioni per problemi di responsività mi sono accorto di avere implementato una modale concepita per occupare il 100% dell'altezza della pagina: '100vh' funzionava molto bene... sul desktop.
Il problema si palesa davvero durante i test su un dispositivo mobile.
Qui di seguto la descrizione del problema e come l'ho risolto.

In questo articolo cercherò di parlare un po' delle nuove unità CSS viewport: svh, svh, dvh. Ma prima serve introdurre alcuni concetti.

Che cos'è un Viewport?

In poche parole, il viewport è l'area visibile di una pagina web su un dispositivo. Ovviamente, le dimensioni del viewport variano a causa del dispositivo o del browser e possono anche essere modificate dall'utente se questo ridimensiona la finestra del browser.

VH - Viewport Height

Il "VH" è stato introdotto nel modulo 3 dei CSS ed è un'unità relativa dei CSS; consente di ridimensionare gli elementi della pagina in base alle dimensioni dello schermo, creando un layout reattivo. Il 'vh' rappresenta una percentuale dell'altezza del viewport.

1vh = 1% dell'altezza del viewport.



.foo {
height: 50vh;  /* O elemento terá 50% da altura do viewport */
}

Problemi di VH

Bene, 'vh' ha portato molti miglioramenti, ma per i desktop; sui dispositivi mobili abbiamo ancora problemi perché alcuni browser hanno la barra di navigazione che occupa spazio sullo schermo. Di solito questa barra si trova sopra il contenuto della pagina, e può espandersi o ritirarsi dinamicamente in base alla direzione in cui l'utente "scorre" la pagina, di conseguenza 'vh' può avere un comportamento inaspettato su alcuni dispositivi.

A causa di questi problemi la comunità ha discusso e proposto alcune soluzioni:

SVH - Small Viewport Height

L'SVH è definito considerando la dimensione del viewport quando la barra di navigazione (o altri elementi del browser) è espansa, cioè quando il browser occupa tutto lo spazio possibile il contenuto della pagina sarà il più piccolo possibile.

Come nell'esempio seguente, "100svh" occuperà lo spazio dello schermo quando la barra di navigazione è espansa, senza che il contenuto rimanga sotto la barra.



.container {
    height: 100svh; /* L'elemento avrà l'altezza del viewport, considerando l'interfaccia utente espansa. */
}

*Quando conviene usarlo Quando si vuole garantire che il contenuto non sia coperto dall'UI del browser.
*Quando è meglio evitare Se l'UI del browser è chiusa, perché potrebbe esserci dello spazio bianco in più.

LVH - Large Viewport Height

Possiamo dire che 'lvh' è l'opposto di 'svh'. E' definito considerando la dimensione del viewport quando la barra di navigazione o altri elementi del browser sono minimizzati, quindi quando il browser occupa il minor spazio possibile il contenuto della pagina sarà massimizzato, in pratica 'lvh' agisce in modo simile a 'vh'.



.container {
    height: 100lvh; /* L'elemento avrà l'altezza del viewport, considerando l'interfaccia utente collassata. */
}

*Quando conviene usarlo Per massimizzare lo spazio del contenuto quando l'interfaccia utente del browser è chiusa.
*Quando è meglio evitare Se l'UI del browser è espansa, perché il contenuto può essere coperto.

DVH - Dinamyc Viewport Height

Dinamyc Viewport (come suggerisce il nome) è dinamico, adatta/regola automaticamente le dimensioni del contenuto in base all'interfaccia utente del browser sia che questo risulti espanso o al contrario compresso. Nonostante questo possa sembrare perfetto bisogna essere consapevoli che l'uso di 'dvh' può causare il ridimensionamento del contenuto quando l'utente scorre, condizione che può essere causa di fastidio e una cattiva UX, oltre a essere costoso in termini di prestazioni.



.container {
    height: 100dvh; /* L'altezza dell'elemento si adatta dinamicamente all'UI del browser. */
}

*Quando conviene usarlo Quando si desidera una variazione dinamica dell'altezza al variare dell'interfaccia utente del browser.
*Quando è meglio evitare Se il ridimensionamento dinamico potrebbe distrarre o influire negativamente sull'esperienza dell'utente.

[PT-BR] Unidades de Viewport no CSS: Além do VH

Leonardo Muniz — Thu, 05 Oct 2023 10:25:06 +0000

Bom, este texto parte de um deslumbrado que acabou de descobrir uma coisa e quer contar pra todo mundo, ate algumas horas atras eu nao sabia que existiam outras unidades de viewport alem de vh/vw, e como eu percebi isso? Tendo problemas de responsividade pra resolver e indo atras de soluções, acontece que eu implementei um modal que deve ocupar 100% da altura da pagina, então '100vh' funcionou muito bem…no desktop, o problema apareceu de verdade quando eu testei usando um dispositivo mobile, aqui abaixo eu explico o problema e como eu resolvi.

Neste artigo vou tentar falar um pouco das novas unidades de viewports CSS: svh, svh, dvh. Mas antes, vamos tentar entender algumas coisas antes de nos aprofundarmos.

O que é Viewport ?

Resumidamente, viewport é a area visível de uma pagina web em um dispositivo, obviamente o tamanho do viewport varia de acordo com o dispositivo, com o browser e pode ate ser alterado pelo usuario se ele redimensionar a janela do navegador.

VH — Viewport Height

O “VH” foi introduzido no modulo 3 do CSS e é uma unidade relativa do CSS, ele permite que os elementos da pagina sejam dimensionados de acordo com o tamanho da tela, criando um layout responsivo, sendo assim, o ‘vh’ representa uma porcentagem da altura do viewport.

1vh = 1% da altura do viewport.

.foo {
height: 50vh;  /* O elemento terá 50% da altura do viewport */
}

Problemas do VH

Bom, o ‘vh’ trouxe muitas melhorias, mas para desktops, ja nos dispositivos mobile, tivemos alguns problemas, pois alguns navegadores tinham a barra de navegação que ocupa um espaço da tela, e geralmente essa barra fica por cima do conteúdo da pagina, podendo dinamicamente expandir ou retrair de acordo com a direção que o usuário “scrolla” a página, por isso, o ‘vh’ pode ter comportamento inesperado em alguns dispositivos.

Por causa desses problemas, a comunidade discutiu e chegou em algumas soluções:

SVH — Small Viewport Height

O ‘svh’ é definido considerando o tamanho do viewport quando a barra de navegação (ou outros itens do navegador) esta expandida, ou seja, quando o navegador ocupa o máximo de espaço possível o conteúdo da pagina sera o menor possível.

Como no exemplo abaixo, ‘100svh’ irá ocupar o espaço da tela considerando a barra de navegação expandida, sem “sobrar” conteúdo por baixo da barra.

.container {
    height: 100svh; /* O elemento terá a altura do viewport considerando a UI expandida */
}

Quando usar:
Quando desejar garantir que o conteúdo não será coberto pela UI do navegador.

Quando evitar:
Se a UI do navegador estiver retraída, pois pode haver espaço em branco extra.

LVH — Large Viewport Units

Ja o ‘lvh’ podemos dizer que é o contrario do ‘svh’, ele é definido considerando o tamanho do viewport quando a barra de navegação ou outros itens do navegador estão retraídos, sendo assim, quando o navegador ocupa o minimo de espaço possível, o conteúdo da página será o maior possível, praticamente o ‘lvh’ age de forma semelhante ao ‘vh’.

.container {
    height: 100lvh; /* O elemento terá a altura do viewport considerando a UI retraída */
}

Quando usar:
Para maximizar o espaço de conteúdo quando a UI do navegador estiver retraída.

Quando evitar:
Se a UI do navegador estiver expandida, pois o conteúdo pode ser coberto.

DVH — Dynamic Viewport Units

O Dinamyc Viewport, como o nome ja diz, é dinâmico, ele adapta/ajusta automaticamente o tamanho do conteúdo de acordo com a UI do navegador, seja expandida ou retraída, apesar disso parecer perfeito, é necessário estar atento, pois usar ‘dvh’ pode causar redimensionamento de conteúdo quando o usuario scrolla a pagina, oque pode causar incomodo e uma UX ruim, além de poder ser custoso em termos de performance.

.container {
    height: 100dvh; /* A altura do elemento se ajustará dinamicamente com a UI do navegador */
}

Quando usar:
Quando desejar um ajuste dinâmico da altura conforme a UI do navegador muda.

Quando evitar:
Se o redimensionamento dinâmico puder distrair o usuário ou afetar negativamente a experiência do usuário.

Veja este exemplo no CodePen ViewPorts examples

DEV Community: Leonardo Muniz

Nomeação de Variáveis CSS: Boas Práticas e Abordagens

Índice

Por que Usar Variáveis CSS? 🔗

Vantagens das Variáveis CSS 🔗

Abordagens para Nomear Variáveis CSS 🔗

2. Nomeação Semântica 🔗

3. Combinação de Nomes Semânticos e de Cores 🔗

4. Nomeação Contextual 🔗

5. Nomeação Baseada em Escopo 🔗

6. Nomeação Baseada em Componentes (Component-based Naming) 🔗

7. Nomeação Baseada em Tipos de Valores (Type-based Naming) 🔗

8. Nomeação Baseada em Temas (Theming) 🔗

Ferramentas de Linting para Variáveis CSS 🔗

Conclusão 🔗

Créditos 🔗

CSS Variable Naming: Best Practices and Approaches

Table of Contents

Why Use CSS Variables? 🔗

Benefits of CSS Variables 🔗

Approaches to Naming CSS Variables 🔗

8. Theme-Based Naming 🔗

Linting Tools for CSS Variables 🔗

Arquitetura Resiliente no React: Usando Error Boundaries

Resumo do conteúdo

Resilient Architecture in React: Using Error Boundaries

Content summary

[EN] Viewport units in CSS: Beyond VH

Summary of content

What is a Viewport? 🔗

VH — Viewport Height

VH Problems 🔗

SVH — Small Viewport Height 🔗

LVH — Large Viewport Units 🔗

DVH — Dynamic Viewport Units 🔗

Browser compatibility 🔗

Progressive Enhancement 🔗

[it-IT] Unità di Viewport nei CSS: Oltre il VH

Che cos'è un Viewport?

VH - Viewport Height

Problemi di VH

SVH - Small Viewport Height

LVH - Large Viewport Height

DVH - Dinamyc Viewport Height

[PT-BR] Unidades de Viewport no CSS: Além do VH

O que é Viewport ?

VH — Viewport Height

Problemas do VH

SVH — Small Viewport Height

LVH — Large Viewport Units

DVH — Dynamic Viewport Units