DEV Community: Gabriel Teixeira da Silva

Hoje explorei como o Compound Pattern e a Composition API ajudam a criar componentes flexíveis, reutilizáveis e altamente configuráveis em aplicações modernas.

Gabriel Teixeira da Silva — Tue, 09 Dec 2025 14:21:19 +0000

Gabriel Teixeira da Silva

Dec 6 '25

Criando Componentes Flexíveis com Compound Pattern e Composition

Comments

5 min read

Criando Componentes Flexíveis com Compound Pattern e Composition

Gabriel Teixeira da Silva — Sat, 06 Dec 2025 14:31:52 +0000

Se você trabalha com React há algum tempo, provavelmente já se deparou com o dilema do "Componente Monolítico". Aquele componente que começa inofensivo, mas à medida que o projeto cresce, ele começa a aceitar dezenas de props para tratar cada pequena variação de layout e lógica.

Hoje, vamos falar sobre como evitar isso usando dois padrões poderosos: Compound Components e Composition Pattern, sem deixar de lado a Acessibilidade.

Vamos usar um exemplo clássico de UI: um Accordion (lista expansível), mas a lógica se aplica a Modais, Tabs, Menus e muito mais.

O Problema: A Abordagem Rígida

Imagine que você precisa criar um Accordion. A abordagem iniciante geralmente centraliza tudo na configuração:

// ❌ O jeito rígido (Componente Monolítico)
<Accordion
  items={[
    { id: 1, title: "O que é React?", content: "Uma lib JS..." },
    { id: 2, title: "Acessibilidade", content: "É essencial..." }
  ]}
  allowMultiple={true}
  iconPosition="right"
  titleColor="blue"
  // E se eu quiser colocar um ícone SVG no título?
  // E se eu quiser um botão dentro do conteúdo?
  // Mais props... 🤯
/>

O problema aqui é que a configuração (data) está misturada com a UI. Se o designer decidir que o título do segundo item precisa ser vermelho, você terá que "sujar" seu código com mais props condicionais.

A Solução: Compound Components + Acessibilidade

O padrão Compound Component permite que componentes trabalhem juntos, compartilhando estado implicitamente, enquanto a Composition deixa o desenvolvedor decidir onde renderizar cada parte.

Além disso, ao criarmos nossos próprios componentes, temos a responsabilidade de torná-los acessíveis. Um Accordion sem atributos ARIA (aria-expanded, aria-controls) é invisível para usuários que dependem de leitores de tela.

Queremos chegar neste resultado (DX - Developer Experience):

// ✅ O jeito flexível e acessível
<Accordion>
  <Accordion.Item value="item-1">
    <Accordion.Trigger>O que é React?</Accordion.Trigger>
    <Accordion.Content>
      Uma biblioteca JavaScript para criar interfaces...
    </Accordion.Content>
  </Accordion.Item>

  <Accordion.Item value="item-2">
    <Accordion.Trigger>
      <span>Acessibilidade</span>
      <IconeAcessibilidade /> 
    </Accordion.Trigger>
    <Accordion.Content>
      <button>Saiba mais</button>
    </Accordion.Content>
  </Accordion.Item>
</Accordion>

Mão na Massa: Implementando o Padrão

Vamos construir isso usando React Context, Hooks e useId para garantir a acessibilidade.

1. Criando o Contexto Principal

Primeiro, o estado global do Accordion.

import React, { createContext, useContext, useState, ReactNode, useId } from "react";

// Definindo o formato do nosso contexto
type AccordionContextType = {
  openItem: string | null;
  toggleItem: (value: string) => void;
};

const AccordionContext = createContext<AccordionContextType | undefined>(undefined);

const useAccordion = () => {
  const context = useContext(AccordionContext);
  if (!context) {
    throw new Error("Os componentes do Accordion devem estar dentro de <Accordion />");
  }
  return context;
};

2. O Componente Pai (Root)

interface AccordionProps {
  children: ReactNode;
}

const AccordionRoot = ({ children }: AccordionProps) => {
  const [openItem, setOpenItem] = useState<string | null>(null);

  const toggleItem = (value: string) => {
    setOpenItem((prev) => (prev === value ? null : value));
  };

  return (
    <AccordionContext.Provider value={{ openItem, toggleItem }}>
      <div className="accordion-root border rounded-md max-w-lg mx-auto">
        {children}
      </div>
    </AccordionContext.Provider>
  );
};

3. Os Sub-Componentes Inteligentes

Aqui está o segredo da acessibilidade. Vamos gerar IDs únicos para vincular o botão (Trigger) ao conteúdo (Content), para que o leitor de tela saiba o que aquele botão controla.

O Item (Gerenciador de IDs):

// Contexto para passar IDs e Valor para os filhos (Trigger e Content)
const ItemContext = createContext<{ 
  value: string; 
  triggerId: string; 
  contentId: string; 
} | undefined>(undefined);

const AccordionItem = ({ value, children }: { value: string; children: ReactNode }) => {
  const id = useId(); // Gera um ID único para este item
  const triggerId = `accordion-trigger-${id}`;
  const contentId = `accordion-content-${id}`;

  return (
    <ItemContext.Provider value={{ value, triggerId, contentId }}>
      <div className="accordion-item border-b last:border-none p-2">
        {children}
      </div>
    </ItemContext.Provider>
  );
};

O Gatilho (Trigger):

const AccordionTrigger = ({ children }: { children: ReactNode }) => {
  const { openItem, toggleItem } = useAccordion();
  const itemContext = useContext(ItemContext);

  if (!itemContext) throw new Error("Trigger deve estar dentro de um Item");

  const { value, triggerId, contentId } = itemContext;
  const isOpen = openItem === value;

  return (
    <button
      id={triggerId}
      aria-controls={contentId} // Diz ao leitor de tela o que este botão controla
      aria-expanded={isOpen}    // Diz se está aberto ou fechado
      onClick={() => toggleItem(value)}
      className="flex justify-between w-full p-4 font-medium text-left hover:bg-gray-50 transition focus:outline-none focus:ring-2 focus:ring-blue-500"
    >
      {children}
      <span aria-hidden="true">{isOpen ? "➖" : "➕"}</span>
    </button>
  );
};

O Conteúdo (Content):

const AccordionContent = ({ children }: { children: ReactNode }) => {
  const { openItem } = useAccordion();
  const itemContext = useContext(ItemContext);

  if (!itemContext) throw new Error("Content deve estar dentro de um Item");

  const { value, triggerId, contentId } = itemContext;
  const isOpen = openItem === value;

  if (!isOpen) return null;

  return (
    <div 
      id={contentId}
      role="region" 
      aria-labelledby={triggerId} // Vincula de volta ao botão
      className="p-4 text-gray-600 bg-white animate-fade-in"
    >
      {children}
    </div>
  );
};

4. Finalizando a Composição

export const Accordion = Object.assign(AccordionRoot, {
  Item: AccordionItem,
  Trigger: AccordionTrigger,
  Content: AccordionContent,
});

Por que a Acessibilidade Importa?

Quando criamos componentes customizados ("na unha"), perdemos a semântica nativa do HTML (como a tag <details> e <summary>).

Ao adicionar aria-expanded e aria-controls, garantimos que usuários que navegam via teclado ou leitores de tela tenham a mesma experiência que usuários visuais. Um componente bonito que não pode ser usado por todos é um componente incompleto.

Mas e o `<details>` e `<summary>`?

Você deve estar se perguntando: "Por que escrever tanto código se o HTML5 já tem as tags <details> e <summary>?"

Essa é uma ótima pergunta. O uso de tags nativas é sempre encorajado, pois garante acessibilidade e SEO "out-of-the-box". No entanto, criar um Accordion controlado via React (como fizemos acima) é necessário quando:

Exclusividade de Abertura: Queremos que, ao abrir um item, os outros se fechem automaticamente. Fazer isso com exige interceptar eventos e manipular o atributo open manualmente, o que nos traz de volta ao gerenciamento de estado.

Animações Fluidas: Animar o fechamento de um elemento nativo <details> ainda é complexo no CSS puro (devido à transição de height: auto). Com componentes React, temos controle total sobre o ciclo de vida da animação.

Design System Rigoroso: Quando precisamos de total liberdade visual sem lutar contra os estilos padrão do User Agent (como o triângulo padrão do <summary>).

Se o seu caso de uso é simples e não exige que um item feche o outro, vá de HTML nativo! Mas para construir componentes robustos de UI libraries, o padrão Compound oferece o controle que precisamos.

Conclusão

Padrões de projeto como o Compound Components são o segredo para bibliotecas robustas como Radix UI e Chakra UI. Eles oferecem o equilíbrio perfeito entre lógica encapsulada, liberdade de estilização e acessibilidade.

Da próxima vez que for criar um componente reutilizável, lembre-se: separe a lógica da UI e nunca se esqueça dos usuários que não usam mouse.

MVVM para Iniciantes: Desvendando o Padrão de Arquitetura

Gabriel Teixeira da Silva — Thu, 09 Oct 2025 11:32:42 +0000

MVVM para Iniciantes: Desvendando o Padrão de Arquitetura

A arquitetura MVVM (Model-View-ViewModel) é uma das abordagens mais populares e eficazes para organizar o código em aplicações modernas. Ela busca separar responsabilidades, tornando o código mais limpo, testável e escalável — características essenciais em projetos de médio e grande porte.

Neste artigo, vamos mergulhar no conceito de MVVM, entender suas camadas, vantagens e desafios, e ainda ver exemplos práticos para que você possa aplicar esse padrão em seus próprios projetos.

🧭 O Que é o MVVM?

O MVVM é um padrão de arquitetura criado por John Gossman em 2005, inicialmente para o framework Microsoft WPF (Windows Presentation Foundation).

Com o passar dos anos, sua adoção se expandiu e hoje está presente em diversas tecnologias como Angular, Vue, React, Flutter, SwiftUI, Jetpack Compose, e até mesmo em frameworks backend que lidam com a camada de apresentação.

O objetivo do MVVM é desacoplar a lógica da interface do usuário da lógica de negócios e manipulação de dados.

Isso permite que desenvolvedores trabalhem em diferentes partes da aplicação sem interferir uns nos outros, além de facilitar testes unitários e manutenção.

A estrutura básica é composta por três elementos:

Model  ↔  ViewModel  ↔  View

Cada camada tem um papel claro e definido, como veremos a seguir.

🧩 Entendendo as Camadas do MVVM

1. Model — O Coração dos Dados

O Model representa os dados da aplicação e a lógica de negócios.

Ele é responsável por acessar APIs, consultar bancos de dados, aplicar validações e regras do domínio.

Boas práticas:

Evite depender da UI;
Centralize regras de negócio aqui;
Mantenha o Model independente do framework utilizado.

Exemplo:

// models/User.ts
export interface User {
  id: number;
  name: string;
  email: string;
}

2. View — A Interface do Usuário

A View é responsável apenas por exibir informações e interagir com o usuário.

Ela observa o ViewModel e reage automaticamente às mudanças, sem precisar lidar com regras de negócio.

Boas práticas:

Não coloque lógica de negócio aqui;
Use data binding sempre que possível;
Deixe a View “burra”, focada apenas em apresentar dados.

Exemplo (Vue.js):

<!-- UserView.vue -->
<template>
  <section>
    <h1>{{ user.name }}</h1>
    <p>{{ user.email }}</p>
  </section>
</template>

3. ViewModel — O Elo Entre o Model e a View

O ViewModel atua como intermediário entre o Model e a View.

Ele é responsável por preparar e transformar os dados vindos do Model para que possam ser exibidos na View.

Em frameworks reativos, o ViewModel geralmente usa mecanismos como observables, reactive refs ou state hooks para notificar a View sobre mudanças.

Exemplo (Vue + Composition API):

// viewmodels/useUserViewModel.ts
import { ref, onMounted } from 'vue';
import type { User } from '../models/User';

export function useUserViewModel() {
  const user = ref<User | null>(null);

  async function fetchUser() {
    const response = await fetch('/api/user/1');
    user.value = await response.json();
  }

  onMounted(fetchUser);

  return { user, fetchUser };
}

E na View:

<!-- UserView.vue -->
<template>
  <div v-if="user">
    <h1>{{ user.name }}</h1>
    <p>{{ user.email }}</p>
  </div>
</template>

<script setup lang="ts">
import { useUserViewModel } from '../viewmodels/useUserViewModel';
const { user } = useUserViewModel();
</script>

🔄 Ciclo de Comunicação MVVM

O usuário interage com a View (clicando, digitando, etc.);
A View envia comandos ao ViewModel;
O ViewModel processa a ação e atualiza o Model, se necessário;
O Model retorna novos dados;
O ViewModel notifica a View sobre a mudança;
A View é atualizada automaticamente.

Esse fluxo cria uma camada de reatividade natural, evitando a manipulação direta do DOM e deixando a aplicação mais previsível.

🧪 Benefícios do MVVM

✅ Separação de responsabilidades: cada parte tem um papel claro.

✅ Facilidade de manutenção: alterar uma camada não quebra outra.

✅ Alta testabilidade: o ViewModel pode ser testado sem interface gráfica.

✅ Escalabilidade: o projeto cresce sem virar uma bagunça.

✅ Reutilização de código: o mesmo ViewModel pode alimentar diferentes Views.

⚠️ Desvantagens e Desafios

Nem tudo são flores! O MVVM também traz desafios:

📉 Curva de aprendizado: exige disciplina e organização.
🧩 Complexidade inicial: pode parecer overkill em projetos pequenos.
🔄 Sincronização de estados: requer atenção ao fluxo de dados para evitar inconsistências.
🧠 Testes mal definidos: se o ViewModel ficar muito grande, o padrão se perde.

Dica: mantenha o ViewModel enxuto, focado apenas em coordenar a lógica entre Model e View.

🧱 MVVM vs MVC vs MVP

Padrão	Papel do Intermediário	Comunicação	Exemplo de uso
MVC	Controller	View ↔ Controller ↔ Model	Aplicações clássicas web e server-side
MVP	Presenter	View ↔ Presenter ↔ Model	Aplicações Android antigas
MVVM	ViewModel	View ↔ Data Binding ↔ Model	Apps reativos modernos (Vue, Angular, React, Flutter)

O MVVM se destaca justamente pela reatividade e ligação automática de dados (data binding), algo que o MVC e o MVP não implementam de forma nativa.

💡 Boas Práticas ao Usar MVVM

1. Mantenha o ViewModel simples: nada de regras de negócio pesadas aqui.
2. Evite dependências diretas entre View e Model.
3. Use observables, refs ou estados globais bem definidos.
4. Organize pastas por funcionalidade:
- models/ → entidades e regras de domínio
- viewmodels/ → lógica de exibição
- views/ → componentes visuais
5. Escreva testes para o ViewModel (é onde mora a maior parte da lógica).

🚀 Conclusão

O MVVM é mais do que um padrão de arquitetura — é uma filosofia de desenvolvimento que preza pela clareza, modularidade e previsibilidade do código.

Ele te ajuda a construir aplicações robustas, com código sustentável, fácil de evoluir e testar.

Mesmo que no início pareça mais complexo, com o tempo, o MVVM se torna um aliado poderoso para qualquer desenvolvedor que deseja criar soluções escaláveis e bem estruturadas.

Comece pequeno: implemente um ViewModel em um projeto simples e observe como tudo começa a fazer sentido.

✍️ Autor: Gabriel Silva

💻 Engenheiro de Software | Foco em Arquitetura, Acessibilidade e Desenvolvimento Web

📚 "Tentando escrever código limpo e acessível."

Por que Acessibilidade Importa? Entenda o Essencial para Apps Mais Inclusivos

Gabriel Teixeira da Silva — Thu, 19 Jun 2025 22:48:38 +0000

Introdução

Você já parou para pensar em como pessoas com diferentes tipos de deficiência usam aplicativos? Acessibilidade é um tema cada vez mais relevante no universo do desenvolvimento, mas ainda pouco explorado na prática. Segundo a Organização Mundial da Saúde, mais de 1 bilhão de pessoas no mundo têm algum tipo de deficiência. Ou seja, ao desenvolver aplicativos acessíveis, ampliamos o alcance do nosso produto, promovemos inclusão e melhoramos a experiência para todos.

O que significa um aplicativo acessível?

Um aplicativo acessível é aquele que pode ser utilizado por todas as pessoas, independentemente de suas capacidades físicas, visuais, auditivas, motoras ou cognitivas. Isso vai além de cumprir uma lista de requisitos técnicos: trata-se de garantir autonomia e proporcionar uma experiência positiva para todos os usuários.

Pense em situações do dia a dia, como um usuário com deficiência visual navegando por um app usando um leitor de tela, ou uma pessoa com mobilidade reduzida utilizando apenas o teclado ou gestos simples para acessar funcionalidades essenciais.

Principais barreiras de acessibilidade em aplicativos

No desenvolvimento de aplicativos, alguns obstáculos comuns acabam limitando o acesso de parte dos usuários, como:

Baixo contraste de cores: dificulta a leitura, principalmente para pessoas com baixa visão ou daltonismo.
Textos pequenos ou ilegíveis: dificultam a compreensão, especialmente para pessoas com deficiência visual.
Falta de suporte a leitores de tela: impede que pessoas cegas ou com baixa visão utilizem o app.
Botões pequenos ou de difícil alcance: prejudicam quem tem limitações motoras.
Ausência de legendas em vídeos e descrições de imagens: limita o acesso de pessoas surdas ou com deficiência auditiva.
Fluxos complexos ou dependentes de gestos específicos: podem excluir pessoas com deficiência cognitiva ou motora.

Boas práticas para tornar seu app mais acessível

Existem práticas simples que, se adotadas desde o início do projeto, já fazem uma grande diferença:

Use cores com bom contraste: Ferramentas online ajudam a verificar se as combinações de cores estão acessíveis.
Permita ajuste de tamanho da fonte: Use unidades relativas e respeite as configurações de acessibilidade do sistema.
Descreva imagens e botões: Sempre use textos alternativos (alt text) em imagens e nomes claros em botões.
Garanta navegação por teclado e leitores de tela: Teste se todos os componentes podem ser acessados sem mouse (ou apenas por gestos simples).
Forneça legendas e transcrições: Para conteúdos em áudio ou vídeo, legendas e transcrições são essenciais.
Evite depender apenas de cor para transmitir informação: Use ícones, textos ou padrões junto com cores.

Ferramentas e recursos para desenvolvedores

Hoje, existem várias ferramentas para apoiar o desenvolvimento acessível:

Lighthouse (Web), Axe, WAVE: para análise automática de acessibilidade em aplicativos web.
Accessibility Scanner (Android), Accessibility Inspector (iOS): para verificar a acessibilidade em aplicativos mobile.
Documentações oficiais:

Além disso, comunidades como A11y Project oferecem conteúdo atualizado e dicas práticas.

Benefícios de investir em acessibilidade

Tornar seu aplicativo acessível traz vantagens que vão além do aspecto social:

Maior alcance de usuários: Você inclui pessoas que, de outra forma, seriam excluídas do seu produto.
Melhora da experiência para todos: Soluções acessíveis costumam ser mais intuitivas para qualquer pessoa.
Cumprimento de legislações: Em muitos países, incluindo o Brasil, já existem leis que exigem acessibilidade digital.
Valor para a marca: Empresas inclusivas são melhor vistas pelo público e pelo mercado.

Conclusão

Acessibilidade não é só uma tendência: é uma responsabilidade de todo desenvolvedor. Investir em aplicativos acessíveis é criar soluções mais justas, inovadoras e eficientes. Que tal dar o primeiro passo e começar a aplicar essas boas práticas nos seus projetos? Pequenas mudanças podem gerar grandes impactos na vida dos usuários!

Próximos passos e leituras recomendadas

Quando Usar um Gerenciador de Estado no React? Minha Experiência na Prática

Gabriel Teixeira da Silva — Mon, 20 Jan 2025 13:06:02 +0000

Oi pessoal, tudo bem?
Hoje quero compartilhar um pouco da minha experiência sobre quando é o momento ideal de usar uma biblioteca de gerenciamento de estado em aplicações React.

Comecei a construir um backoffice usando Next.js 14 e, no início, não senti necessidade de implementar nenhuma biblioteca de gerenciamento de estado. Para algumas informações globais, utilizei o React Context, que resolveu bem problemas simples.

Porém, conforme a aplicação cresceu, surgiu a necessidade de compartilhar informações entre componentes mais distantes. Foi aí que me deparei com o famoso problema do prop drilling. Esse cenário começou a tornar o código menos organizado e difícil de manter.

A partir dessa experiência, percebi que estava na hora de considerar o uso de uma solução mais robusta, como Zustand, Redux ou Jotai.

O que é Prop Drilling e por que pode ser um problema?

O prop drilling ocorre quando precisamos passar propriedades de um componente para outro que está distante na hierarquia, atravessando vários níveis intermediários. Em outras palavras, mesmo que um componente intermediário não utilize a propriedade, ele ainda precisa recebê-la e repassá-la para o próximo componente.

Para ilustrar, imagine que temos uma estrutura de componentes como esta:

App
 ├── Header
 │    └── UserMenu
 └── Main
      └── Sidebar
           └── UserProfile

Se quisermos passar informações de um usuário, como o nome, do componente App para o UserProfile, precisaríamos repassar a propriedade manualmente por todos os componentes intermediários:

function App() {
  const user = { name: "Gabriel" };

  return (
    <div>
      <Header user={user} />
      <Main user={user} />
    </div>
  );
}

function Header({ user }) {
  return <UserMenu user={user} />;
}

function Main({ user }) {
  return <Sidebar user={user} />;
}

function Sidebar({ user }) {
  return <UserProfile user={user} />;
}

function UserProfile({ user }) {
  return <p>Olá, {user.name}!</p>;
}

Este exemplo simples parece inofensivo, mas à medida que a aplicação cresce e mais componentes precisam dessas informações, o código pode rapidamente se tornar confuso e difícil de gerenciar. Qualquer alteração na estrutura da hierarquia pode exigir grandes mudanças no código, aumentando a probabilidade de erros.

Minha Experiência com Prop Drilling

Enquanto trabalhava no desenvolvimento de um backoffice construído com Next.js, comecei enfrentando o problema clássico do prop drilling. No início, a aplicação era relativamente simples, e as informações globais eram gerenciadas eficientemente com o React Context ou passando props entre os componentes.

No entanto, conforme a aplicação cresceu e se tornou mais complexa, alguns componentes precisavam compartilhar informações críticas com outros componentes que estavam distantes na hierarquia. Por exemplo, um componente que exibia uma lista precisava passar dados e funções para outro componente, que, por sua vez, deveria comunicar esses dados a subcomponentes ainda mais específicos. Isso exigiu que muitas propriedades fossem repassadas manualmente por vários níveis de componentes intermediários, mesmo que esses componentes não utilizassem as propriedades diretamente.

Essa abordagem funcionava inicialmente, mas, com o tempo, tornou o código difícil de manter, aumentar ou refatorar. Cada alteração nos componentes superiores tinha um impacto em cascata, exigindo ajustes em diversos pontos do código. Além disso, entender o fluxo dos dados ficou cada vez mais complicado para novos membros da equipe.

Foi nesse momento que percebi a necessidade de uma solução mais robusta para gerenciamento de estado. Bibliotecas como Redux, Zustand e Jotai começaram a fazer muito mais sentido, pois poderiam eliminar o excesso de dependências entre os componentes e centralizar o estado de forma mais clara e eficiente.

Por que escolhi o Zustand?

Com tantas opções disponíveis para gerenciamento de estado, como Redux, MobX, Jotai, e até mesmo o próprio React Context, decidi optar pelo Zustand. Minha escolha foi baseada em alguns fatores importantes:

Simplicidade: O Zustand é extremamente simples de usar. Ele possui uma API enxuta e fácil de entender, o que torna a curva de aprendizado muito menor quando comparado a outras soluções mais robustas, como o Redux.
Leveza: É uma biblioteca leve e sem dependências adicionais, o que contribui para um bundle size menor, mantendo a aplicação performática.
Escalabilidade: Embora minha aplicação ainda seja de porte médio, escolhi o Zustand pensando no futuro. Ele me oferece a flexibilidade para escalar e organizar o estado de forma modular, sem adicionar complexidade desnecessária.
Menos Boilerplate: Diferente de outras bibliotecas, o Zustand não exige a criação de actions ou reducers. Com apenas alguns hooks e configurações simples, já consigo gerenciar o estado global da aplicação de maneira eficiente.
Alternativa ao Context: O React Context é uma excelente solução para casos simples, mas pode se tornar problemático em aplicações maiores devido ao problema de re-renders desnecessários. O Zustand lida melhor com esses cenários, atualizando apenas os componentes que realmente dependem do estado alterado.

A partir do momento em que implementei o Zustand, percebi uma grande melhoria na organização e manutenção do meu código. A lógica de estado ficou centralizada e acessível, sem impactar negativamente a performance ou aumentar a complexidade da aplicação.

Usando Zustand para Resolver o Prop Drilling

Com Zustand, podemos centralizar o estado e acessá-lo diretamente nos componentes que precisam das informações. Aqui está como o exemplo ficaria:
Criando o Store com Zustand

import create from 'zustand';

// Criamos um store centralizado para gerenciar o estado do usuário
const useUserStore = create((set) => ({
  user: { name: "Gabriel" }, // Estado inicial
  setUser: (newUser) => set({ user: newUser }), // Método para atualizar o estado
}));

Refatorando os Componentes

Agora, em vez de passar o estado como prop por toda a hierarquia, podemos acessar o estado diretamente no componente que precisa dele.

function App() {
  return (
    <div>
      <Header />
      <Main />
    </div>
  );
}

function Header() {
  return <UserMenu />;
}

function Main() {
  return <Sidebar />;
}

function Sidebar() {
  return <UserProfile />;
}

function UserProfile() {
  const user = useUserStore((state) => state.user); // Acessamos o estado diretamente
  return <p>Olá, {user.name}!</p>;
}

Como Isso Resolve o Prop Drilling?

Estado Centralizado: O estado do usuário está centralizado no store do Zustand.
Acesso Direto: Cada componente que precisa do estado pode acessá-lo diretamente, sem depender de componentes intermediários.
Escalabilidade: Se o estado ou lógica de atualização crescer, podemos gerenciá-lo no store de maneira modular.

Claro! Aqui está uma sugestão para a conclusão do seu artigo:

Conclusão

Escolher o momento certo para introduzir uma biblioteca de gerenciamento de estado em uma aplicação React é uma decisão que depende muito do contexto e das necessidades do projeto. No meu caso, começar com soluções simples, como o React Context, funcionou bem em um primeiro momento. Contudo, à medida que a aplicação cresceu e os problemas de prop drilling começaram a aparecer, optei por adotar o Zustand pela sua simplicidade, leveza e escalabilidade.

Cada projeto tem seus próprios desafios, e não existe uma solução única que atenda a todos os casos. Por isso, é importante avaliar cuidadosamente os problemas que você está enfrentando e escolher a ferramenta que melhor se adapta ao cenário atual e ao crescimento futuro da aplicação.

Se você está começando ou lidando com um projeto de porte pequeno, pode ser que o React Context seja suficiente. Mas, se a sua aplicação começa a demandar um gerenciamento de estado mais robusto, bibliotecas como Zustand, Redux, ou Jotai podem ser uma excelente escolha.

E você? Já enfrentou problemas com prop drilling ou precisou adotar uma solução de gerenciamento de estado? Compartilhe sua experiência nos comentários, adoraria saber como você lidou com isso!

Entendendo SOLID no Contexto do JavaScript: Conceitos e Exemplos

Gabriel Teixeira da Silva — Mon, 16 Dec 2024 11:05:02 +0000

A introdução do paradigma de Programação Orientada a Objetos (POO) popularizou conceitos fundamentais da programação, como Herança, Polimorfismo, Abstração e Encapsulamento. Rapidamente, a POO se tornou um paradigma amplamente aceito, com implementações em diversas linguagens como Java, C++, C#, JavaScript, entre outras. Contudo, à medida que os sistemas orientados a objetos se tornaram mais complexos, muitos projetos enfrentaram desafios de manutenção e adaptação a mudanças.

Para melhorar a extensibilidade do software e reduzir a rigidez do código, Robert C. Martin (conhecido como Uncle Bob) apresentou, no início dos anos 2000, os princípios SOLID.

SOLID é um acrônimo que reúne cinco princípios — Princípio da Responsabilidade Única, Princípio do Aberto/Fechado, Princípio da Substituição de Liskov, Princípio da Segregação de Interfaces e Princípio da Inversão de Dependências. Esses princípios ajudam desenvolvedores a projetar e escrever códigos mais manuteníveis, escaláveis e flexíveis. O objetivo? Elevar a qualidade do software criado com base no paradigma de Programação Orientada a Objetos.

Neste artigo, exploraremos cada um dos princípios SOLID e mostraremos como aplicá-los no contexto de uma das linguagens mais populares da web: o JavaScript (apesar de o JavaScript implementar POO de uma maneira diferente, algo que exploraremos em outro artigo).

Princípio da Responsabilidade Única (SRP)

O Princípio da Responsabilidade Única é representado pela primeira letra de SOLID. Esse princípio sugere que uma classe ou módulo deve ter apenas uma responsabilidade, ou seja, apenas uma razão para ser modificada.

Simplificando, uma classe ou função deve desempenhar apenas um papel. Se uma classe lida com mais de uma funcionalidade, atualizar uma delas sem impactar as outras se torna complicado. Isso pode levar a falhas no desempenho do software ou até mesmo a bugs inesperados. Para evitar esses problemas, é importante escrever um código modular, onde as preocupações sejam separadas.

Se uma classe ou função tiver muitas responsabilidades, ela se torna difícil de modificar, testar e manter. Ao aplicar o SRP, conseguimos criar sistemas mais organizados, com menos chances de erros. Vamos ver um exemplo prático em JavaScript:

Exemplo de SRP no JavaScript

Código que viola o SRP:

Aqui temos uma classe que lida com várias responsabilidades ao mesmo tempo:

class Person {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }

  saveToDatabase() {
    console.log(`Salvando ${this.name} no banco de dados...`);
    // Lógica para salvar no banco de dados
  }

  sendWelcomeEmail() {
    console.log(`Enviando e-mail de boas-vindas para ${this.email}...`);
    // Lógica para enviar e-mail
  }
}

Problema:

A classe Person está lidando tanto com o armazenamento de dados no banco quanto com o envio de e-mails, o que são responsabilidades diferentes. Se algo mudar na lógica de e-mails, a classe Person precisará ser alterada, o que pode causar problemas.

Código que aplica o SRP:

Vamos separar as responsabilidades em classes diferentes:

class Person {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }
}

class PersonRepository {
  save(person) {
    console.log(`Salvando ${person.name} no banco de dados...`);
    // Lógica para salvar no banco de dados
  }
}

class EmailService {
  sendWelcomeEmail(person) {
    console.log(`Enviando e-mail de boas-vindas para ${person.email}...`);
    // Lógica para enviar e-mail
  }
}

// Uso:
const person = new Person("Gabriel", "gabriel@example.com");
const repository = new PersonRepository();
const emailService = new EmailService();

repository.save(person);
emailService.sendWelcomeEmail(person);

Por que é melhor?

Person é responsável apenas por representar uma pessoa.
PersonRepository lida exclusivamente com o armazenamento de dados no banco.
EmailService cuida apenas do envio de e-mails.
Essa separação de responsabilidades torna o código mais modular, fácil de testar e menos propenso a erros, além de simplificar futuras alterações.

Princípio Aberto/Fechado (OCP)

O Princípio Aberto/Fechado afirma que os componentes de software (classes, funções, módulos, etc.) devem estar abertos para extensão, mas fechados para modificação. Em um primeiro momento, isso pode parecer contraditório, mas o princípio sugere que o código deve ser projetado de forma a permitir extensões sem que o código existente precise ser alterado.

Esse princípio é essencial para a manutenção de bases de código grandes, pois permite a adição de novas funcionalidades com baixo risco de introduzir bugs. Em vez de modificar classes ou módulos existentes quando surgem novos requisitos, você deve estender as classes relevantes adicionando novos componentes.

No JavaScript, o OCP pode ser implementado utilizando recursos como herança (ES6+) ou composição. Vamos explorar isso com um exemplo:

Exemplo sem aplicar o OCP (violação do princípio):

Neste exemplo, temos uma classe Shape que calcula a área de diferentes formas geométricas. Para cada nova forma, precisamos modificar a classe principal.

class Shape {
  constructor(type, dimensions) {
    this.type = type;
    this.dimensions = dimensions;
  }

  calculateArea() {
    if (this.type === "circle") {
      return Math.PI * this.dimensions.radius ** 2;
    } else if (this.type === "rectangle") {
      return this.dimensions.width * this.dimensions.height;
    }
    // E assim por diante...
  }
}

const circle = new Shape("circle", { radius: 5 });
console.log(circle.calculateArea()); // Área do círculo

const rectangle = new Shape("rectangle", { width: 10, height: 20 });
console.log(rectangle.calculateArea()); // Área do retângulo

Problema:

Sempre que uma nova forma for adicionada (como triângulo ou quadrado), precisamos modificar a classe Shape, o que viola o OCP.

Exemplo aplicando o OCP:

Vamos reestruturar o código para seguir o Princípio Aberto/Fechado usando classes e herança:

// Classe base
class Shape {
  calculateArea() {
    throw new Error("Este método deve ser implementado pelas subclasses.");
  }
}

// Subclasses
class Circle extends Shape {
  constructor(radius) {
    super();
    this.radius = radius;
  }

  calculateArea() {
    return Math.PI * this.radius ** 2;
  }
}

class Rectangle extends Shape {
  constructor(width, height) {
    super();
    this.width = width;
    this.height = height;
  }

  calculateArea() {
    return this.width * this.height;
  }
}

// Uso:
const circle = new Circle(5);
console.log(circle.calculateArea()); // Saída: 78.54

const rectangle = new Rectangle(10, 20);
console.log(rectangle.calculateArea()); // Saída: 200

Por que isso segue o OCP?

A classe base Shape está fechada para modificações, ou seja, não precisamos alterá-la para adicionar novas formas.
Para suportar uma nova forma, como um triângulo, basta criar uma nova subclasse que implemente o método calculateArea.

Princípio da Substituição de Liskov (LSP)

O Princípio da Substituição de Liskov afirma que uma classe derivada deve ser substituível pela sua classe base sem que o funcionamento do sistema seja comprometido. Em outras palavras, se um objeto de uma classe base pode ser usado, um objeto de uma subclasse dessa classe também deve poder ser usado no lugar sem causar problemas.

Este princípio é essencial para garantir que o código seja flexível e extensível sem introduzir comportamentos inesperados. Ele exige que as subclasses respeitem o contrato da classe base, garantindo que o comportamento esperado permaneça consistente. Na prática, isso significa que:

Subclasses devem sobrescrever os métodos da classe pai sem quebrar o código. Ou seja, as implementações das subclasses devem manter a consistência do comportamento esperado.
Subclasses não devem desviar do comportamento da classe pai. Subclasses podem adicionar funcionalidades, mas não devem alterar ou remover funcionalidades definidas na classe pai.
O código que funciona com instâncias da classe pai deve funcionar também com instâncias das subclasses, sem precisar saber que a classe mudou. Isso significa que o código deve ser agnóstico em relação à classe específica utilizada, respeitando o contrato estabelecido pela classe base.

Violação do LSP

Vamos começar com um exemplo onde o princípio é violado. Considere uma hierarquia de classes relacionada a retângulos:

class Rectangle {
  constructor(width, height) {
    this.width = width;
    this.height = height;
  }

  getArea() {
    return this.width * this.height;
  }
}

class Square extends Rectangle {
  constructor(side) {
    super(side, side);
  }

  set width(value) {
    this._width = value;
    this._height = value;
  }

  set height(value) {
    this._width = value;
    this._height = value;
  }

  get width() {
    return this._width;
  }

  get height() {
    return this._height;
  }
}

// Uso:
const rectangle = new Rectangle(10, 20);
console.log(rectangle.getArea()); // Saída: 200

const square = new Square(10);
square.width = 15;
console.log(square.getArea()); // Saída esperada: 225, mas pode causar confusão

Problema:

Embora Square seja uma subclasse de Rectangle, o comportamento de Square é inconsistente. Quando alteramos width ou height em Square, isso afeta ambas as dimensões, o que não é o caso para Rectangle.
Isso quebra o contrato implícito da classe base, violando o LSP.

Como corrigir o LSP

Para evitar essa violação, podemos separar Square e Rectangle em duas classes independentes que implementam uma interface comum (ou seguem um contrato comum no JavaScript):

class Shape {
  getArea() {
    throw new Error("Este método deve ser implementado pela subclasse.");
  }
}

class Rectangle extends Shape {
  constructor(width, height) {
    super();
    this.width = width;
    this.height = height;
  }

  getArea() {
    return this.width * this.height;
  }
}

class Square extends Shape {
  constructor(side) {
    super();
    this.side = side;
  }

  getArea() {
    return this.side ** 2;
  }
}

// Uso:
const rectangle = new Rectangle(10, 20);
console.log(rectangle.getArea()); // Saída: 200

const square = new Square(10);
console.log(square.getArea()); // Saída: 100

Por que isso segue o LSP?

Rectangle e Square agora são classes independentes, ambas respeitando o contrato da classe base Shape.
O comportamento de cada classe é consistente com sua definição, sem causar problemas quando substituídas.

Princípio da Segregação de Interfaces (ISP)

O Princípio da Segregação de Interfaces (ISP) estabelece que nenhum cliente deve ser forçado a depender de métodos ou interfaces que não utiliza. Em termos práticos, isso significa que devemos criar interfaces menores e mais específicas, relevantes para os clientes que as consomem, ao invés de interfaces grandes e monolíticas que forçam os clientes a implementar métodos desnecessários.

Manter nossas interfaces compactas oferece diversas vantagens:

Facilita a manutenção, depuração e testes.
Evita dependências desnecessárias entre diferentes partes do sistema.
Minimiza o impacto de mudanças: alterações em uma parte da interface não devem forçar alterações em outras partes do código.

Sem o ISP, mudanças em interfaces grandes podem exigir refatorações extensas e complexas, especialmente em bases de código maiores.

Desafio no JavaScript

Diferentemente de linguagens baseadas em C, como Java ou C#, o JavaScript não possui suporte nativo a interfaces. Entretanto, podemos aplicar os conceitos de ISP utilizando objetos, classes e contratos implícitos.

Exemplo sem aplicar o ISP (violação do princípio)

Aqui temos uma interface implícita que força diferentes classes a implementar métodos que nem sempre fazem sentido:

class MultiFunctionPrinter {
  printDocument(doc) {
    console.log(`Imprimindo: ${doc}`);
  }

  scanDocument(doc) {
    console.log(`Escaneando: ${doc}`);
  }

  faxDocument(doc) {
    console.log(`Enviando fax: ${doc}`);
  }
}

// Impressora básica que não precisa de fax
class BasicPrinter extends MultiFunctionPrinter {
  faxDocument() {
    throw new Error("Fax não suportado nesta impressora.");
  }
}

// Uso:
const printer = new BasicPrinter();
printer.printDocument("Relatório");
printer.faxDocument("Relatório"); // Erro!

Problema:

A classe BasicPrinter é forçada a implementar um método faxDocument, mesmo que não seja necessário.
Isso viola o ISP porque BasicPrinter está dependente de uma funcionalidade que não utiliza.

Corrigindo para aplicar o ISP

Podemos dividir a interface em partes menores, cada uma representando um conjunto de responsabilidades específicas:

// Interfaces menores representadas por classes ou funções
class Printer {
  printDocument(doc) {
    console.log(`Imprimindo: ${doc}`);
  }
}

class Scanner {
  scanDocument(doc) {
    console.log(`Escaneando: ${doc}`);
  }
}

class Fax {
  faxDocument(doc) {
    console.log(`Enviando fax: ${doc}`);
  }
}

// Classes específicas implementam apenas as interfaces necessárias
class BasicPrinter extends Printer {}

class AdvancedPrinter extends Printer {
  constructor() {
    super();
    this.scanner = new Scanner();
    this.fax = new Fax();
  }

  scanDocument(doc) {
    this.scanner.scanDocument(doc);
  }

  faxDocument(doc) {
    this.fax.faxDocument(doc);
  }
}

// Uso:
const basicPrinter = new BasicPrinter();
basicPrinter.printDocument("Relatório"); // Saída: Imprimindo: Relatório

const advancedPrinter = new AdvancedPrinter();
advancedPrinter.printDocument("Contrato"); // Saída: Imprimindo: Contrato
advancedPrinter.scanDocument("Contrato"); // Saída: Escaneando: Contrato
advancedPrinter.faxDocument("Contrato"); // Saída: Enviando fax: Contrato

Por que agora segue o ISP?

Cada classe (ou "interface") está focada em uma responsabilidade específica (Printer, Scanner, Fax).
Classes concretas, como BasicPrinter e AdvancedPrinter, implementam apenas as funcionalidades que realmente utilizam.
O sistema agora é mais modular, fácil de estender e menos propenso a erros ao adicionar novas funcionalidades.

Benefícios do ISP

Modularidade: As interfaces menores tornam o código mais fácil de entender e gerenciar.
Redução de dependências: Classes e módulos dependem apenas das funcionalidades relevantes.
Extensibilidade: Novas funcionalidades podem ser adicionadas sem impactar partes não relacionadas do sistema.

Aqui está uma versão adaptada para português da explicação do Princípio da Inversão de Dependência (Dependency Inversion Principle - DIP) com exemplos em JavaScript:

Princípio da Inversão de Dependência (DIP)

O Princípio da Inversão de Dependência (DIP) estabelece que módulos de alto nível (como lógica de negócios) devem depender de abstrações, e não de implementações concretas. Isso significa que, em vez de classes de alto nível se conectarem diretamente a classes de baixo nível, ambas devem depender de uma abstração comum.

Esse princípio ajuda a reduzir as dependências diretas no código, tornando-o mais modular, flexível e testável. Ele permite que desenvolvedores modifiquem e expandam a lógica de alto nível sem complicações, mesmo que os componentes de baixo nível mudem.

Por que o DIP favorece abstrações?

Ao introduzir abstrações, podemos:

Reduzir impactos de mudanças: Alterar uma implementação concreta não afeta a lógica de alto nível.
Melhorar a testabilidade: Podemos usar mocks ou stubs para simular abstrações durante os testes.
Aumentar a flexibilidade: O sistema se torna mais modular e fácil de estender.

O DIP promove o acoplamento fraco (loose coupling) em vez do acoplamento forte (tight coupling). Isso significa que as partes do sistema são menos dependentes umas das outras, facilitando a manutenção e expansão.

Exemplo sem aplicar o DIP (violação do princípio)

Neste exemplo, uma classe de alto nível (OrderService) depende diretamente de uma classe de baixo nível (EmailService):

class EmailService {
  sendEmail(message) {
    console.log(`Enviando e-mail: ${message}`);
  }
}

class OrderService {
  constructor() {
    this.emailService = new EmailService();
  }

  placeOrder(order) {
    console.log("Pedido realizado:", order);
    this.emailService.sendEmail("Seu pedido foi recebido.");
  }
}

// Uso:
const orderService = new OrderService();
orderService.placeOrder("Pedido #123");

Problema:

A classe OrderService está fortemente acoplada à implementação de EmailService. Se quisermos trocar EmailService por outro serviço (como SMSService), teremos que modificar OrderService, violando o DIP.

Exemplo aplicando o DIP

Agora vamos introduzir uma abstração para desacoplar OrderService da implementação concreta de EmailService:

// Abstração
class NotificationService {
  sendNotification(message) {
    throw new Error("Este método deve ser implementado por subclasses.");
  }
}

// Implementação concreta
class EmailService extends NotificationService {
  sendNotification(message) {
    console.log(`Enviando e-mail: ${message}`);
  }
}

class SMSService extends NotificationService {
  sendNotification(message) {
    console.log(`Enviando SMS: ${message}`);
  }
}

// Classe de alto nível
class OrderService {
  constructor(notificationService) {
    this.notificationService = notificationService; // Injeção de dependência
  }

  placeOrder(order) {
    console.log("Pedido realizado:", order);
    this.notificationService.sendNotification("Seu pedido foi recebido.");
  }
}

// Uso:
const emailService = new EmailService();
const smsService = new SMSService();

const orderServiceWithEmail = new OrderService(emailService);
orderServiceWithEmail.placeOrder("Pedido #123"); // Saída: Enviando e-mail: Seu pedido foi recebido.

const orderServiceWithSMS = new OrderService(smsService);
orderServiceWithSMS.placeOrder("Pedido #124"); // Saída: Enviando SMS: Seu pedido foi recebido.

Por que agora segue o DIP?

Desacoplamento:
- OrderService depende da abstração NotificationService, e não de implementações concretas como EmailService ou SMSService.
- Podemos alterar ou substituir a implementação concreta sem modificar OrderService.
Injeção de dependência:
- O OrderService recebe a dependência (notificationService) como parâmetro no construtor. Isso é conhecido como injeção de dependência (dependency injection).
Flexibilidade:
- Podemos adicionar novas implementações de NotificationService (como PushNotificationService) sem alterar a lógica de alto nível em OrderService.

Vantagens do DIP

Facilidade de manutenção: Alterar componentes de baixo nível não afeta módulos de alto nível.
Modularidade: As partes do sistema são mais independentes.
Testabilidade: É fácil criar mocks para testar módulos de alto nível sem depender de implementações reais.
Extensibilidade: Novas funcionalidades podem ser adicionadas sem causar grandes alterações no sistema.

Conclusão

Os princípios SOLID são fundamentais para criar sistemas mais organizados, flexíveis e fáceis de manter. Aplicá-los no contexto do JavaScript pode parecer desafiador inicialmente, especialmente por ser uma linguagem dinâmica e sem suporte nativo a alguns conceitos como interfaces. No entanto, como vimos, com abordagens práticas como herança, abstrações e injeção de dependências, é possível incorporar esses princípios e alcançar um código mais modular e resiliente.

Ao adotar SOLID no dia a dia, você não apenas melhora a qualidade do seu código, mas também reduz o risco de bugs e torna o desenvolvimento mais eficiente a longo prazo. Que tal começar a aplicar esses conceitos no seu próximo projeto?

Melhores Práticas de Acessibilidade Web com ARIA (Accessible Rich Internet Applications)

Gabriel Teixeira da Silva — Fri, 20 Sep 2024 14:02:37 +0000

A acessibilidade web é uma parte essencial do desenvolvimento de interfaces, especialmente quando falamos de componentes dinâmicos e interativos que precisam ser usados por todas as pessoas, independentemente de suas habilidades. Nesse contexto, a WAI-ARIA (Accessible Rich Internet Applications) oferece um conjunto de atributos que tornam esses componentes mais acessíveis para usuários de tecnologias assistivas, como leitores de tela.

Neste artigo, vamos explorar o que é WAI-ARIA, como usá-lo corretamente e compartilhar exemplos práticos de sua implementação.

O que é WAI-ARIA?

WAI-ARIA, ou Accessible Rich Internet Applications, é um conjunto de especificações desenvolvido pelo W3C que define como tornar o conteúdo e os componentes de interfaces mais acessíveis para usuários com deficiências.

Esses atributos são especialmente úteis em componentes interativos complexos, como menus dinâmicos, modais e sliders, onde a semântica padrão do HTML não é suficiente para comunicar a natureza interativa desses elementos para tecnologias assistivas.

Principais Atributos ARIA

Aqui estão alguns dos atributos ARIA mais comuns e como eles podem ser usados para melhorar a acessibilidade de componentes:

1. aria-label

O atributo aria-label fornece uma descrição personalizada para um elemento interativo. Ele é útil quando o conteúdo visual do elemento não é suficiente para descrevê-lo adequadamente para leitores de tela.

Exemplo de Uso:

<button aria-label="Fechar janela">X</button>

Por que usar: Em casos onde o texto visível não é suficiente para descrever a função do botão (como um ícone), o aria-label adiciona um texto descritivo que será lido por leitores de tela.

2. aria-hidden
O atributo aria-hidden indica que um elemento, e todos os seus filhos, devem ser ignorados por tecnologias assistivas, como leitores de tela.

Exemplo de Uso:

<div aria-hidden="true">Este conteúdo será ignorado pelo leitor de tela</div>

Por que usar: É útil quando há elementos decorativos ou repetidos no layout que não devem ser anunciados pelos leitores de tela. Também pode ser aplicado para ocultar elementos temporariamente

3. aria-live

O aria-live é um atributo que define a prioridade com que uma mudança no conteúdo de uma área deve ser anunciada por um leitor de tela.

Valores possíveis: off, polite, e assertive.

Exemplo de Uso:

<div aria-live="polite">Notificações serão lidas quando o usuário estiver pronto.</div>

Por que usar: Ele é útil em áreas onde o conteúdo muda dinamicamente (como uma notificação ou mensagem de erro), e é necessário garantir que essas mudanças sejam anunciadas ao usuário.

4. aria-expanded
O aria-expanded é usado para indicar o estado expandido ou colapsado de um elemento interativo, como um menu dropdown ou um acordeão.

Exemplo de Uso:

<button aria-expanded="false" aria-controls="menu">Abrir Menu</button>
<div id="menu" hidden>
    <p>Conteúdo do menu...</p>
</div>

Por que usar: Ele é importante para indicar o estado de visibilidade de um elemento e garantir que usuários de leitores de tela saibam se algo foi expandido ou colapsado.

5. aria-controls
O atributo aria-controls é utilizado para indicar que o elemento atual controla a visibilidade ou o conteúdo de outro elemento. Ele é particularmente útil em componentes interativos, como menus, acordeões, ou dropdowns, onde o estado de um elemento (como um botão) afeta a exibição de outro (como um painel ou uma lista).
Como Funciona

O aria-controls recebe o id do elemento que está sendo controlado. Esse atributo ajuda tecnologias assistivas, como leitores de tela, a entender que um determinado elemento tem controle sobre outro, melhorando a acessibilidade e a experiência do usuário.

Exemplo de Uso:

<button aria-expanded="false" aria-controls="menu">Abrir Menu</button>
<div id="menu" hidden>
    <p>Conteúdo do menu...</p>
</div>

Neste exemplo:

O botão tem o atributo aria-controls="menu", indicando que ele controla a exibição do elemento com o id="menu".
Quando o usuário interagir com o botão e o menu for exibido ou oculto, o atributo aria-expanded pode ser atualizado para refletir o estado atual, informando ao leitor de tela se o menu está aberto (true) ou fechado (false).

Conclusão

A acessibilidade é um aspecto fundamental no desenvolvimento web, e o uso correto de atributos ARIA pode transformar a experiência de usuários que dependem de tecnologias assistivas, como leitores de tela. Atributos como aria-label, aria-hidden, aria-live, aria-expanded e aria-controls ajudam a garantir que componentes dinâmicos e interativos sejam compreendidos e acessíveis a todos os usuários.

Ao implementar esses atributos nos seus projetos, você estará contribuindo para a criação de uma web mais inclusiva, onde todos possam navegar e interagir com conteúdo sem barreiras.

Quer aprender mais?

Os atributos ARIA são amplos e oferecem muitas opções para tornar interfaces mais acessíveis. Se você quiser se aprofundar no uso de ARIA e conhecer outros atributos que podem melhorar a acessibilidade do seu site, recomendo conferir a documentação completa de WAI-ARIA.

Além disso, seguir as diretrizes da WCAG (Web Content Accessibility Guidelines) pode ajudar a garantir que seu site atenda aos padrões internacionais de acessibilidade

Referências

Para se aprofundar ainda mais sobre acessibilidade web e garantir que seus projetos sigam as melhores práticas, consulte os seguintes recursos:

Esses links são excelentes pontos de partida para aprofundar seus conhecimentos sobre acessibilidade e aplicar diretrizes fundamentais em seus projetos web.

Se precisar de ajuda ou tiver dúvidas, estou à disposição. Sinta-se à vontade para entrar em contato!

Desvendando o Async/Await: Simplificando a Programação Assíncrona com JavaScript

Gabriel Teixeira da Silva — Thu, 04 Jul 2024 18:36:05 +0000

Conceitos Básicos

O que é Programação Assíncrona?

Programação assíncrona é uma técnica de programação que permite a execução de operações que podem demorar um certo tempo para serem concluídas, como requisições de rede, leitura de arquivos ou consultas a bancos de dados, sem bloquear o fluxo principal do programa. Em vez de esperar que essas operações terminem, o programa pode continuar executando outras tarefas. Isso é especialmente útil em aplicações web, onde a responsividade e a performance são cruciais para a experiência do usuário.

Callbacks e Promises

Antes do advento de async/await, a programação assíncrona em JavaScript era tradicionalmente feita usando callbacks e Promises.

Callbacks: Um callback é uma função passada como argumento para outra função, que será executada após a conclusão de uma operação assíncrona. No entanto, callbacks podem levar ao que é conhecido como "callback hell", onde múltiplos callbacks aninhados tornam o código difícil de ler e manter.
```
function fetchData(callback) {
    setTimeout(() => {
        callback('data');
    }, 1000);
}

fetchData((data) => {
    console.log(data);
});
```

Promises: Promises foram introduzidas para melhorar a legibilidade do código assíncrono. Uma Promise representa um valor que pode estar disponível agora, no futuro ou nunca. Promises permitem encadear operações assíncronas de maneira mais clara e gerenciável.

function fetchData() {
    return new Promise((resolve, reject) => {
        setTimeout(() => {
            resolve('data');
        }, 1000);
    });
}

fetchData().then((data) => {
    console.log(data);
}).catch((error) => {
    console.error(error);
});

O que é Async/Await?

async e await são palavras-chave introduzidas no ES2017 (ES8) que simplificam ainda mais o uso de Promises, permitindo escrever código assíncrono que parece síncrono.

async: A palavra-chave async é usada para declarar uma função assíncrona. Uma função assíncrona sempre retorna uma Promise.

async function fetchData() {
    return 'data';
}

fetchData().then((data) => {
    console.log(data);
});

await: A palavra-chave await só pode ser usada dentro de uma função assíncrona. Ela pausa a execução da função até que a Promise seja resolvida, simplificando o fluxo do código.

async function fetchData() {
    const response = await fetch('https://api.example.com/data');
    const data = await response.json();
    return data;
}

fetchData().then((data) => {
    console.log(data);
});

Com async e await, o código assíncrono se torna mais linear e fácil de entender, eliminando a necessidade de encadeamento excessivo de then e catch.

Exemplos Práticos e Tratamento de Erros

Exemplo Simples

Vamos começar com um exemplo simples de uma função assíncrona que busca dados de uma API usando async/await.

async function fetchData() {
    const response = await fetch('https://api.example.com/data');
    const data = await response.json();
    return data;
}

fetchData().then(data => {
    console.log(data);
});

Múltiplas Chamadas Assíncronas

Às vezes, você precisa fazer múltiplas chamadas assíncronas e esperar que todas sejam concluídas. Você pode usar Promise.all para isso.

async function fetchMultipleData() {
    const [response1, response2] = await Promise.all([
        fetch('https://api.example.com/data1'),
        fetch('https://api.example.com/data2')
    ]);
    const data1 = await response1.json();
    const data2 = await response2.json();
    return { data1, data2 };
}

fetchMultipleData().then(({ data1, data2 }) => {
    console.log(data1, data2);
});

Tratamento de Erros com Try/Catch

O uso de try/catch em funções assíncronas permite capturar e lidar com erros de forma clara e concisa.

async function fetchData() {
    try {
        const response = await fetch('https://api.example.com/data');
        if (!response.ok) {
            throw new Error('Network response was not ok');
        }
        const data = await response.json();
        return data;
    } catch (error) {
        console.error('Failed to fetch data:', error);
    }
}

fetchData().then(data => {
    if (data) {
        console.log(data);
    }
});

Exemplo Completo: Integração com API e Tratamento de Erros

Vamos combinar tudo o que aprendemos em um exemplo mais completo. Suponha que estamos construindo uma função que busca e processa dados de múltiplas APIs e lida com possíveis erros.

async function fetchUserData() {
    try {
        const userResponse = await fetch('https://api.example.com/user');
        if (!userResponse.ok) {
            throw new Error('Failed to fetch user data');
        }
        const userData = await userResponse.json();

        const postsResponse = await fetch(`https://api.example.com/users/${userData.id}/posts`);
        if (!postsResponse.ok) {
            throw new Error('Failed to fetch user posts');
        }
        const userPosts = await postsResponse.json();

        return { userData, userPosts };
    } catch (error) {
        console.error('Error fetching data:', error);
    }
}

fetchUserData().then(data => {
    if (data) {
        console.log('User Data:', data.userData);
        console.log('User Posts:', data.userPosts);
    }
});

Conclusão

async/await simplifica significativamente a programação assíncrona em JavaScript, tornando o código mais legível e fácil de manter. Com a capacidade de escrever código assíncrono que parece síncrono, desenvolvedores podem evitar os problemas comuns de callbacks aninhados e o encadeamento excessivo de Promises.

Recursos Adicionais

Para aprofundar seu conhecimento sobre async/await e programação assíncrona, aqui estão alguns recursos úteis:

Acessibilidade em Foco: Novidades no GNOME 46

Gabriel Teixeira da Silva — Sat, 23 Mar 2024 18:39:46 +0000

Antes de mergulharmos nas inovadoras melhorias de acessibilidade introduzidas pelo GNOME na versão 46, talvez você esteja se perguntando: o que exatamente é o GNOME? Permita-me oferecer uma breve introdução a este influente ambiente de desktop.

o que exatamente é o GNOME?

O GNOME é um ambiente de desktop livre e de código aberto, amplamente reconhecido por sua simplicidade, acessibilidade e elegância. Projetado para ser intuitivo e eficiente, é uma das interfaces gráficas mais populares entre os usuários de sistemas operacionais baseados em Linux e UNIX. Com um forte foco em usabilidade e experiência do usuário, o GNOME oferece uma área de trabalho organizada que facilita a navegação, o gerenciamento de janelas e a interação com aplicativos e arquivos. Além disso, é desenvolvido e mantido por uma comunidade ativa, que se dedica a melhorar continuamente suas funcionalidades e acessibilidade, garantindo que o ambiente seja inclusivo e acessível a todos os usuários.

Caso tenha interesse em explorar mais sobre o universo do GNOME e suas vastas possibilidades, ao final deste artigo, você encontrará uma seleção de links cuidadosamente escolhidos. Eles servirão como um ponto de partida para aprofundar seus conhecimentos no fascinante mundo do GNOME.

Melhorias de Acessibilidade no Gnome 46

A acessibilidade é um foco primordial no desenvolvimento do GNOME 46, com diversas melhorias significativas já implementadas e outras previstas para a versão 4.14 do GTK. Esses avanços abrangem vários aspectos da acessibilidade, refletindo o compromisso contínuo em tornar o GNOME ainda mais inclusivo. Um destaque especial neste esforço tem sido o aprimoramento do leitor de tela Orca, que recebeu atenção especial para melhorar a experiência do usuário e expandir suas funcionalidades.

Você pode estar curioso sobre o que exatamente é o GTK, mencionado anteriormente. Vamos esclarecer: GTK, originalmente uma abreviação para GIMP Toolkit, é uma biblioteca de desenvolvimento fundamental para a criação de interfaces gráficas de usuário (GUIs) no ambiente GNOME. Facilitando o desenvolvimento de aplicativos visuais ricos e interativos, o GTK serve como a espinha dorsal para a maioria dos aplicativos dentro do ecossistema GNOME. Com uma arquitetura extensível e suporte a várias linguagens de programação, o GTK não apenas permite, mas encoraja o desenvolvimento de aplicativos acessíveis e visualmente atraentes.

Retomando nosso foco nas inovações em acessibilidade que o GNOME 46 introduziu, vamos explorar as principais melhorias a seguir.

Por debaixo do capô, um significativo esforço de modernização está em andamento. Isso resultará em melhor desempenho e confiabilidade, além de possibilitar a compatibilidade com o Wayland e aplicativos em sandbox no futuro.
Uma nova funcionalidade de modo de suspensão foi adicionada. Esse recurso bastante solicitado permite aos usuários desativar temporariamente o Orca, usando o atalho Ctrl+Alt+Shift+Q. O modo de suspensão é útil ao usar máquinas virtuais que possuem seus próprios leitores de tela, bem como aplicativos autovocais.
Novos comandos permitem que o Orca informe o status do sistema, incluindo status da bateria, uso de CPU e memória.
A navegação por tabelas foi bastante melhorada, com mais aplicativos sendo suportados e novos comandos adicionados, incluindo navegação por tabela de alternância (Orca+Shift+T) e mover para a célula final (Orca+Alt+Shift+🡰/🡲/🡱/🡳).
O Orca agora tem suporte experimental para Spiel, uma emocionante API de síntese de fala de próxima geração. Aqueles que estão interessados nessa funcionalidade são convidados a ajudar a.

O Orca não foi o único lugar onde aconteceram melhorias de acessibilidade para o GNOME 46. Outras melhorias incluem um modo de alto contraste que agora está mais consistente e utilizável, e uma nova configuração para mostrar símbolos de ligado e desligado em interruptores.

Conclusão

A acessibilidade no universo Linux raramente ocupa os holofotes, mas estou aqui para mudar essa narrativa. Pode ser uma surpresa para muitos descobrir que o Linux possui um leitor de tela nativo. Ainda há um caminho longo a percorrer em termos de acessibilidade no GNOME e no Linux, especialmente com a transição para o Wayland como protocolo padrão em várias distribuições. Contudo, é animador ver os progressos sendo feitos nesta área. Como um apaixonado pelo open source e um defensor da acessibilidade, decidi contribuir ativamente para melhorar a acessibilidade no Linux.

Este é apenas o início de uma série dedicada a explorar acessibilidade e Linux. Se você tiver dúvidas, sugestões ou quiser iniciar uma conversa sobre este tema tão importante, não hesite em entrar em contato. Agradeço imensamente por ter acompanhado este post até o fim. Fique ligado para mais insights e discussões em futuros artigos. Até lá, que a força esteja com você em sua jornada pelo mundo do Linux e da acessibilidade.

Referências

Listas Lineares Descomplicadas: Entenda a Base das Estruturas de Dados

Gabriel Teixeira da Silva — Wed, 21 Feb 2024 15:28:28 +0000

Olá, pessoal! Estou de volta para mergulharmos juntos no universo das estruturas de dados, um pilar fundamental no mundo da computação. Recentemente, decidi revisitar e aprofundar meus conhecimentos nessa área crítica, e quero compartilhar essa jornada com vocês. Hoje, nosso foco será nas listas lineares: vamos explorar o que são, como funcionam, sua origem e por que são tão essenciais para a programação. Este artigo é apenas o início de uma série dedicada a desvendar as estruturas de dados, então, preparem-se para aprender e crescer conosco nessa aventura. Vamos lá?

Entendendo Listas Lineares com Alocação Sequencial

No universo das estruturas de dados, a linearidade é definida pela capacidade de percorrer elementos de forma sequencial, um após o outro, estabelecendo um único caminho para essa travessia. Neste contexto, as listas se destacam como exemplares de estruturas lineares, compostas por uma série de elementos organizados em sequência. No entanto, essa sequencialidade, tão clara no nível do software, nem sempre se reflete diretamente no hardware. Isso significa que, embora elementos adjacentes (nas posições i e i + 1) pareçam consecutivos na estrutura de dados, eles podem não estar fisicamente adjacentes na memória do computador.

A alocação sequencial surge como uma solução para essa discrepância, garantindo que os elementos de uma lista sejam armazenados de forma contígua na memória. Esse método de armazenamento não apenas simplifica o acesso e a gestão dos elementos, mas também otimiza o desempenho da lista ao minimizar o tempo necessário para localizar cada elemento. Ao armazenar dados de forma sequencial, facilitamos a implementação de algoritmos eficientes para manipulação dessas listas, desde operações simples como inserção e remoção até tarefas mais complexas de busca e ordenação. A alocação sequencial, portanto, é fundamental para a eficácia e a eficiência das listas lineares em diversas aplicações computacionais, representando um elo crítico entre a teoria abstrata das estruturas de dados e a prática concreta de programação.

Tomemos o JavaScript como um exemplo prático: as arrays, que são declaradas com colchetes [], exemplificam perfeitamente o conceito de listas lineares com alocação sequencial. Essa característica permite que realizemos acessos aleatórios aos seus elementos utilizando índices. Por exemplo, ao escrevermos lista[3], estamos acessando diretamente o quarto elemento da array (considerando que, em JavaScript, a contagem de índices inicia-se em 0). Esse acesso direto é possível porque a array armazena seus elementos de forma contígua na memória, facilitando a localização de qualquer item sem a necessidade de percorrer sequencialmente a lista desde o início. Este método de acesso otimiza significativamente a eficiência de operações de leitura e escrita em listas, refletindo a importância da alocação sequencial em linguagens de programação de alto nível e suas aplicações no desenvolvimento de software.

# lista linear em alocação sequencial
const lista = [1, 2, 3, 4, 5];

# acesso aleatório
console.log(lista[2]);

Agora que temos uma compreensão clara sobre o que são listas lineares, podemos considerá-las como os fundamentos básicos das estruturas de dados. Dentro do universo das listas sequenciais, existem várias operações fundamentais que nos permitem manipulá-las de forma eficaz. Entre essas operações, destacam-se o acesso a elementos específicos, a inserção de novos elementos, a remoção de elementos existentes, a combinação de duas ou mais listas lineares em uma única lista, além da capacidade de dividir uma lista linear em várias listas menores.

Em linguagens de programação de alto nível, como JavaScript e Python, essas funcionalidades já estão amplamente implementadas por meio de bibliotecas e construções da linguagem, permitindo que os desenvolvedores as utilizem sem a necessidade de compreender detalhadamente como estão implementadas internamente. Isso simplifica significativamente o processo de desenvolvimento de software, mas pode também obscurecer o entendimento dos princípios fundamentais que regem essas operações.

No entanto, ao mergulharmos na programação com uma linguagem como C, que oferece um controle mais granular sobre a memória e as estruturas de dados, temos a oportunidade de implementar manualmente essas operações com listas lineares. Isso não apenas nos permite entender os mecanismos internos por trás de cada operação, mas também apreciar a complexidade e a elegância envolvidas na gestão eficiente de dados. Através dessa abordagem mais fundamentada, podemos explorar em profundidade como as listas são organizadas na memória, como as operações de inserção e remoção afetam a estrutura de dados e como a combinação e divisão de listas são realizadas, proporcionando uma compreensão mais rica e completa do funcionamento das estruturas de dados.

Conclusão

Com uma base sólida agora estabelecida sobre o que são listas lineares, você pode estar se perguntando como podemos implementar essas funcionalidades essenciais. A linguagem C, com seu controle detalhado sobre estruturas de dados e gerenciamento de memória, serve como uma ferramenta ideal para essa exploração. No entanto, dedicaremos um post exclusivo para mergulhar nessa implementação, pois introduzir esses conceitos aqui tornaria nosso diálogo excessivamente longo. O foco deste artigo foi estabelecer uma compreensão clara das listas lineares e suas operações fundamentais.

Fique atento ao próximo artigo, onde colocaremos a teoria em prática, implementando algumas dessas operações críticas de listas na linguagem C. Prometo que será uma jornada enriquecedora e esclarecedora, ideal para quem deseja aprofundar seu entendimento sobre estruturas de dados de uma maneira prática e aplicada.

Espero sinceramente que este artigo tenha sido tanto útil quanto inspirador. Entender estruturas de dados foi, e às vezes ainda é, um desafio para mim, mas é indiscutivelmente um dos pilares mais importantes da ciência da computação. Continuemos juntos nesta jornada de aprendizado. Até nosso próximo encontro, desejo-lhe sucesso e inspiração na sua aventura pelo fascinante mundo das estruturas de dados. Que a força esteja com você

O Papel do Back-end no Desenvolvimento Front-end: Introdução à Arquitetura BFF

Gabriel Teixeira da Silva — Thu, 25 Jan 2024 21:37:11 +0000

Como um entusiasta do front-end, sempre encontrei alegria e desafios em equal medida ao trabalhar com interfaces de usuário e a experiência do usuário. No entanto, recentemente me deparei com um desafio intrigante: mergulhar no mundo do back-end, especificamente no desenvolvimento de um BFF (Back For Front-end). Inicialmente, me vi confuso, questionando o que exatamente seria um BFF e como ele se encaixaria no ecossistema do desenvolvimento web. À medida que me aventurei neste novo território, percebi que estava não só expandindo minhas habilidades, mas também ganhando uma compreensão mais profunda de como o back-end pode potencializar e transformar experiências no front-end. Este artigo é um relato dessa jornada, uma introdução à arquitetura BFF e um olhar sobre como ela redefine o papel do back-end no desenvolvimento front-end.

Mas afinal, o que é um BFF?

Acompanhe-me nesta exploração e vamos descobrir juntos. BFF é um acrônimo para Backend For Frontend. Essencialmente, trata-se de um componente de back-end que tem a missão de prover os dados necessários para cada front-end da aplicação. Funcionando como um 'meio de campo', ele facilita a comunicação entre os front-ends e os diferentes back-ends em uma aplicação baseada em microsserviços. Isso otimiza a comunicação e o processamento de dados entre o servidor e o cliente, simplificando o desenvolvimento no front-end e contribuindo para uma experiência de usuário mais fluida e eficiente.

A arquitetura BFF vai além de simplesmente fornecer dados; ela permite uma customização fina e adaptativa das respostas para diferentes tipos de front-end, seja um aplicativo móvel, uma web app ou até mesmo dispositivos IoT. Isso significa que, em vez de um front-end ter que se adaptar a uma variedade de serviços de back-end, é o BFF que se molda para atender às necessidades específicas de cada interface. Esta abordagem resulta em um código mais limpo e modular no front-end, reduzindo a complexidade e aumentando a eficiência do desenvolvimento. Além disso, o BFF pode desempenhar um papel vital na implementação de políticas de segurança, autenticação e autorização, agindo como um guardião que assegura que apenas os dados apropriados sejam entregues a cada cliente. A adesão à arquitetura BFF não apenas melhora o desempenho e a usabilidade das aplicações, mas também potencializa uma arquitetura de software mais sustentável e escalável a longo prazo.

Mas onde exatamente o BFF se encaixa no panorama do desenvolvimento de software?

Agora que compreendemos o que é um BFF, seu propósito e os problemas que ele resolve, vamos ilustrar seu uso com um exemplo concreto. Imaginemos, por exemplo, uma aplicação para gestão de contas bancárias. Esta aplicação poderia ser estruturada dividindo-se em contextos menores e independentes, o que facilita a manutenção e aprimora o gerenciamento da escalabilidade de cada parte do sistema.

Vamos imaginar a seguinte divisão:

Nessa estrutura, cada aspecto da aplicação é tratado como um serviço distinto, caracterizado por sua autonomia e independência. Isso permite o isolamento efetivo das regras de negócio pertinentes a cada área, resultando em serviços mais focados e coesos.

Neste cenário, a nossa aplicação de gestão de contas bancárias poderia ser segmentada em três principais microsserviços: um para o extrato bancário, outro dedicado à gestão de saldo e um terceiro para gerenciamento de usuários. Essa separação permite que cada microsserviço opere de maneira independente, o que é uma grande vantagem, especialmente em termos de estabilidade e manutenção. Se um serviço enfrenta problemas, isso não afeta diretamente os outros, minimizando interrupções e melhorando a resiliência geral do sistema.

Neste exemplo de aplicação bancária, consideremos a tela inicial onde informações cruciais são exibidas - informações estas que são fornecidas por diferentes serviços: extrato, saldo e usuário. Aqui surge um desafio comum em arquiteturas baseadas em microsserviços: ao invés de uma fonte de dados centralizada, temos dados vitais dispersos em três fontes distintas. Cada serviço opera independentemente, armazenando e gerenciando suas próprias informações, o que pode complicar a coleta e a exibição harmoniosa desses dados na interface do usuário.

Uma abordagem para lidar com os dados dispersos em nossa aplicação bancária seria fazer com que o front-end execute simultaneamente três requisições para os respectivos microsserviços, buscando as informações necessárias para a tela inicial. Embora esta solução possa parecer viável, ela introduz uma série de complicações arquiteturais.

Primeiramente, isso resulta em uma confusão de responsabilidades: o front-end, que deveria focar apenas na renderização, acaba assumindo também o controle de fluxo das comunicações com os diversos microsserviços. Isso não só aumenta o acoplamento entre front-end e back-end, dificultando os testes, como também pode retardar a renderização da tela inicial devido à sobrecarga de tarefas.

Além disso, ao exigir que o front-end gerencie três requisições paralelas, impõe-se uma carga adicional ao lado do cliente. Ele precisa não apenas renderizar a tela, mas também coordenar essas múltiplas requisições, o que pode afetar a performance e a eficiência da aplicação.

Aqui é onde o BFF se torna essencial. Em vez de o aplicativo bancário realizar três requisições separadas para cada microsserviço a fim de construir a página inicial, ele poderia simplesmente fazer uma única requisição a um BFF. O BFF, então, se encarrega de comunicar-se com os microsserviços necessários, coletando e compilando os dados para a montagem da tela.

Esta solução supera os desafios de sobrecarregar o front-end com múltiplas requisições. Ela mantém as fontes de dados ocultas e indistintas para os componentes de front-end, simplificando a estrutura de consumo de dados.

Além disso, se for necessário reestruturar onde os dados, como os detalhes do extrato, são armazenados ou combiná-los com informações de outros microsserviços, essa mudança ocorre de forma transparente para o aplicativo. O ajuste é feito apenas no BFF, que continua entregando as informações ao front-end da mesma forma, independentemente das mudanças internas nos serviços de back-end.

Considerações Finais: Navegando Pelos Detalhes e Desafios do BFF

Os BFFs são essenciais para fornecer dados específicos para diferentes interfaces de usuário, como web e mobile, em uma aplicação. Eles permitem customizar as informações conforme a necessidade de cada cliente, podendo haver BFFs distintos para diferentes tipos de front-end. No exemplo de uma aplicação bancária, um BFF poderia ser projetado especificamente para a web, necessitando de mais dados, enquanto outro seria para mobile, com menos dados requeridos. No entanto, usar um BFF único para ambas as interfaces pode levar ao over-fetching, onde, por exemplo, a interface mobile recebe mais dados do que necessita. Isso resulta em esforços desnecessários para processar dados irrelevantes e um consumo excessivo de banda larga e dados, afetando a eficiência do aplicativo.

Conclusão

Espero que este artigo tenha sido útil e inspirador para você. Embora explorar o back-end tenha sido um desafio, a jornada tem sido extremamente gratificante e cheia de aprendizados. Nos artigos futuros, estou ansioso para compartilhar mais de minhas experiências com vocês, continuando a aprimorar nosso conhecimento juntos. Em breve, trarei também conteúdo sobre acessibilidade na web, um tema igualmente importante e fascinante. Agradeço a todos que acompanharam este artigo. Estou sempre aberto a sugestões e dúvidas; afinal, o aprendizado é um caminho que trilhamos juntos. Até a próxima, e que a força esteja com você na sua própria aventura no mundo do desenvolvimento!

Referências

Compreendendo as Diferenças entre useEffect, useMemo e useCallback

Gabriel Teixeira da Silva — Thu, 07 Sep 2023 15:17:06 +0000

Mas, o que é um Hook?

No React, um hook é uma função especial que permite que você "ligue-se" a recursos e funcionalidades do React em componentes funcionais. Os hooks foram introduzidos no React 16.8 para permitir o uso de estados e outros recursos anteriormente disponíveis apenas em componentes de classe em componentes funcionais.
Os hooks permitem que você adicione funcionalidades de gerenciamento de estado, efeitos colaterais, contexto, referências e muito mais aos seus componentes funcionais.
Neste artigo, abordaremos as distinções entre três hooks essenciais do React: useEffect, useMemo e useCallback.

useEffect

O useEffect trata principalmente de lidar com efeitos colaterais em componentes React. Efeitos colaterais geralmente incluem operações como buscar dados, manipular o DOM e gerenciar assinaturas. Aqui está uma análise das suas principais características:

Propósito: O propósito principal do useEffect é executar código que tenha efeitos colaterais. Esses efeitos colaterais podem estar relacionados à renderização do componente ou a mudanças em suas dependências.
Uso: Você fornece uma função de retorno para o useEffect, e o React executa essa função depois que o componente foi renderizado ou quando as dependências especificadas foram alteradas.
Casos de Uso Típicos: O useEffect é comumente utilizado para tarefas como buscar dados, configurar e limpar ouvintes de eventos e realizar ações em resposta a mudanças em props ou estado.

Exemplo de Uso

import React, { useState, useEffect } from 'react';

function ExemploUseEffect() {
  // Defina um estado para armazenar uma contagem
  const [count, setCount] = useState(0);

  // useEffect é usado para realizar efeitos colaterais
  useEffect(() => {
    // Atualize o título da página com a contagem atual
    document.title = `Contagem: ${count}`;

    // Este código será executado após cada renderização
    // e sempre que 'count' for alterado.

    // É uma boa prática retornar uma função de limpeza
    // se você precisar desfazer algum efeito.
    return () => {
      document.title = 'Aplicação React'; // Reverter o título
    };
  }, [count]); // Especifique as dependências aqui

  return (
    <div>
      <p>Contagem: {count}</p>
      <button onClick={() => setCount(count + 1)}>Incrementar</button>
    </div>
  );
}

export default ExemploUseEffect;

Neste exemplo, usamos o useEffect para atualizar o título da página com a contagem atual toda vez que o estado count for alterado. Observamos que passamos [count] como um segundo argumento para o useEffect. Isso especifica as dependências do efeito, ou seja, quando o efeito deve ser executado novamente. Neste caso, o efeito será acionado sempre que count mudar.

Além disso, fornecemos uma função de retorno no useEffect. Esta função será chamada quando o componente for desmontado ou quando a dependência count mudar novamente. É uma prática recomendada para fazer a limpeza de efeitos quando eles não são mais necessários.

Quando você clicar no botão "Incrementar", a contagem aumentará e o título da página será atualizado de acordo com o valor atual da contagem.

useMemo

O useMemo é inteiramente voltado para a memorização. A memorização é uma técnica na qual o resultado de uma função ou expressão custosa é armazenado em cache, de modo que seja recalculado apenas quando suas dependências mudam. Aqui está uma análise das suas principais características:

Propósito: O useMemo é usado para memorizar (armazenar em cache) o resultado de uma função ou expressão. Isso pode melhorar o desempenho ao evitar cálculos desnecessários.
Uso: Você fornece uma função e uma matriz de dependências para o useMemo. O React executa a função e armazena em cache seu resultado. Se as dependências mudarem, a função é reexecutada e o resultado é atualizado.
Casos de Uso Típicos: A memorização é útil para cálculos computacionalmente custosos ou para evitar renderizações desnecessárias de componentes.

Exemplo de Uso

import React, { useState, useMemo } from 'react';

function ExemploUseMemo() {
  // Defina dois estados para armazenar números
  const [num1, setNum1] = useState(5);
  const [num2, setNum2] = useState(10);

  // Use useMemo para calcular a soma dos números apenas quando eles mudarem
  const soma = useMemo(() => {
    console.log('Calculando a soma...');
    return num1 + num2;
  }, [num1, num2]); // Dependências

  return (
    <div>
      <p>Número 1: {num1}</p>
      <p>Número 2: {num2}</p>
      <p>Soma: {soma}</p>
      <button onClick={() => setNum1(num1 + 1)}>Incrementar Número 1</button>
      <button onClick={() => setNum2(num2 + 1)}>Incrementar Número 2</button>
    </div>
  );
}

export default ExemploUseMemo;

Neste exemplo, estamos usando o useMemo para calcular a soma dos números num1 e num2. O cálculo da soma é uma operação simples, mas suponha que tivéssemos uma operação computacionalmente cara em vez disso.

O useMemo recebe uma função de cálculo e uma matriz de dependências como argumentos. A função de cálculo será executada apenas quando uma das dependências (num1 ou num2) mudar. Isso significa que a soma só será recalculada quando um dos números for incrementado.

Dentro da função de cálculo, você pode realizar qualquer operação que desejar. Neste exemplo, usamos um console.log para demonstrar quando a soma está sendo calculada.

Ao clicar nos botões "Incrementar Número 1" ou "Incrementar Número 2", apenas o número relevante é atualizado, e a soma é recalculada somente quando necessário, graças ao uso do useMemo. Isso ajuda a evitar cálculos desnecessários e melhora o desempenho do componente.

useCallback

O useCallback está intimamente relacionado ao useMemo, mas foca na memorização de funções em vez de valores. É particularmente útil ao passar funções de retorno de chamada para componentes filhos. Aqui está uma análise das suas principais características:

Propósito: useCallback é usado para memorizar (armazenar em cache) uma função de modo que ela seja recriada apenas quando suas dependências mudam. Isso pode otimizar o desempenho ao passar funções de retorno de chamada como propriedades.
Uso: Você fornece uma função e uma matriz de dependências para useCallback. O React retorna uma versão memorizada da função. Se as dependências mudarem, uma nova função memorizada é criada.
Casos de Uso Típicos: É comumente usado para memorizar funções de retorno de chamada, especialmente ao passar essas funções para componentes filhos.

Exemplo de Uso

import React, { useState, useCallback } from 'react';

function ExemploUseCallback() {
  // Defina um estado para armazenar um contador
  const [contador, setContador] = useState(0);

  // Defina uma função de retorno de chamada para incrementar o contador
  const incrementarContador = useCallback(() => {
    setContador(contador + 1);
  }, [contador]); // Dependência: contador

  return (
    <div>
      <p>Contador: {contador}</p>
      <button onClick={incrementarContador}>Incrementar Contador</button>
    </div>
  );
}

export default ExemploUseCallback;

Neste exemplo, estamos usando o useCallback para memorizar a função incrementarContador. A função incrementarContador simplesmente incrementa o valor do contador quando o botão é clicado.

Observe que passamos [contador] como uma matriz de dependência para useCallback. Isso significa que a função incrementarContador será memorizada e recriada apenas quando a dependência contador mudar. Isso é útil para evitar que a função seja recriada em cada renderização, economizando recursos.

Ao clicar no botão "Incrementar Contador", o valor do contador aumenta, e a função incrementarContador é chamada sem ser recriada desnecessariamente. Isso melhora a eficiência e é particularmente útil ao passar essa função como propriedade para componentes filhos, onde a memorização pode economizar ciclos de renderização.

Principais Diferenças

useEffect é usado para lidar com efeitos colaterais e executar código após a renderização ou quando certas dependências mudam.
useMemo é usado para memorizar o resultado de uma função ou expressão a fim de evitar recalculos desnecessários.
useCallback é usado para memorizar funções, sendo especialmente útil para otimizar componentes filhos que dependem de funções de retorno de chamada.

Todos os três hooks recebem uma matriz de dependências. Quando essas dependências mudam, useEffect executa sua função de efeito, useMemo recalcula o valor e useCallback recria a função memorizada.

Em resumo, esses hooks têm propósitos distintos e são ferramentas valiosas para gerenciar diferentes aspectos dos seus componentes React. Compreender quando e como usar useEffect, useMemo e useCallback podem contribuir para tornar seus aplicativos React mais eficientes e tornar a
manutenção mais simples.

DEV Community: Gabriel Teixeira da Silva

Hoje explorei como o Compound Pattern e a Composition API ajudam a criar componentes flexíveis, reutilizáveis e altamente configuráveis em aplicações modernas.

Criando Componentes Flexíveis com Compound Pattern e Composition

Criando Componentes Flexíveis com Compound Pattern e Composition

O Problema: A Abordagem Rígida

A Solução: Compound Components + Acessibilidade

Mão na Massa: Implementando o Padrão

1. Criando o Contexto Principal

2. O Componente Pai (Root)

3. Os Sub-Componentes Inteligentes

4. Finalizando a Composição

Por que a Acessibilidade Importa?

Mas e o <details> e <summary>?

Conclusão

MVVM para Iniciantes: Desvendando o Padrão de Arquitetura

MVVM para Iniciantes: Desvendando o Padrão de Arquitetura

🧭 O Que é o MVVM?

🧩 Entendendo as Camadas do MVVM

1. Model — O Coração dos Dados

2. View — A Interface do Usuário

3. ViewModel — O Elo Entre o Model e a View

🔄 Ciclo de Comunicação MVVM

🧪 Benefícios do MVVM

⚠️ Desvantagens e Desafios

🧱 MVVM vs MVC vs MVP

💡 Boas Práticas ao Usar MVVM

🚀 Conclusão

Por que Acessibilidade Importa? Entenda o Essencial para Apps Mais Inclusivos

Introdução

O que significa um aplicativo acessível?

Principais barreiras de acessibilidade em aplicativos

Boas práticas para tornar seu app mais acessível

Ferramentas e recursos para desenvolvedores

Benefícios de investir em acessibilidade

Conclusão

Próximos passos e leituras recomendadas

Quando Usar um Gerenciador de Estado no React? Minha Experiência na Prática

O que é Prop Drilling e por que pode ser um problema?

Minha Experiência com Prop Drilling

Por que escolhi o Zustand?

Usando Zustand para Resolver o Prop Drilling

Conclusão

Entendendo SOLID no Contexto do JavaScript: Conceitos e Exemplos

Princípio da Responsabilidade Única (SRP)

Exemplo de SRP no JavaScript

Princípio Aberto/Fechado (OCP)

Princípio da Substituição de Liskov (LSP)

Princípio da Segregação de Interfaces (ISP)

Desafio no JavaScript

Exemplo sem aplicar o ISP (violação do princípio)

Corrigindo para aplicar o ISP

Por que agora segue o ISP?

Benefícios do ISP

Princípio da Inversão de Dependência (DIP)

Por que o DIP favorece abstrações?

Exemplo sem aplicar o DIP (violação do princípio)

Exemplo aplicando o DIP

Por que agora segue o DIP?

Vantagens do DIP

Conclusão

Melhores Práticas de Acessibilidade Web com ARIA (Accessible Rich Internet Applications)

O que é WAI-ARIA?

Principais Atributos ARIA

Conclusão

Quer aprender mais?

Referências

Desvendando o Async/Await: Simplificando a Programação Assíncrona com JavaScript

Conceitos Básicos

O que é Programação Assíncrona?

Callbacks e Promises

O que é Async/Await?

Exemplos Práticos e Tratamento de Erros

Exemplo Simples

Múltiplas Chamadas Assíncronas

Tratamento de Erros com Try/Catch

Exemplo Completo: Integração com API e Tratamento de Erros

Conclusão

Recursos Adicionais

Acessibilidade em Foco: Novidades no GNOME 46

o que exatamente é o GNOME?

Mas e o `<details>` e `<summary>`?