Forem: André Matulionis

How to reuse your UI

André Matulionis — Fri, 26 Jul 2024 12:49:01 +0000

If you'd rather read it in portuguese, I've made a pt-BR version of this post.

Basically everyone I know ends up creating reusable components when learning about the DRY concept. This is a deceptively simple abstraction: it's easy to create a Button, but it's surprisingly difficult to reuse it across all use cases in a project.

I've learned a few things over the years, and I see that a lot of people end up messing around without realizing it. Let me share some tips to avoid a messy code.

I have a React bias but everything can be applied in other contexts, as long as there is UI componentization.

Quick Access

Avoid margins
Based on HTML props
Compose components
Use headless libraries
Avoid external dependencies
Migration
Putting it all together

1) Avoid margins

🔗

Placing margins in your component ends up breaking the expectation of component reuse. Spacing is important, and your component does not know the context where it will be applied.

Instead, leave the spacing responsibility to the parent containing the components. It is possible that it uses a different way to manage spacing, such as paddings and gaps.

There are several ideas ¹ ² ³ about how spacing should be created in components. But generally the conclusion is not to put spacing externally inerent to your component. It is more reliable for its parent component to handle margins.

And speaking of the parent component...

2) Based on HTML props

🔗
It is important that components are used in an expected way. Using an interface that everyone knows helps with this, and HTML attributes are a known interface.

If you want to insert a margin into the component, instead of creating a prop dedicated to the margin, your component can make it a generic div and accept styles and classes as props. The parent component will have the context and control to extend its component for unexpected cases.

"But this pattern is very common in the project, should I repeat its declaration in the parent?" Some props can be added alongside the traditional props. It's usually a variant prop, or size or similar. I recommend taking a look at libs like CVA or vanilla-extract to manage these props in a scalable way.

If the prop has a standard HTML name, it also requires no documentation. For new devs it is easier to learn, and for experienced people they create expectations and in turn increases productivity.

And this tip includes not only the name of each prop but also the value. Avoid creating an innovative contract for the prop, such as enums and objects. Instead, classic strings and JSX props make it easier to use.

JSX is also used to...

3) Compose components

🔗

Don't try to create components with too much structure. Create atomic components that are easy to control and reuse, and instead of adding props for bits of UI, use JSX.

For example, I've already made (and seen) components with props scattered throughout:



<IconButton
  icon="success"
  iconSize="16px"
  iconColor="black"
  iconPosition="end"
>Click here</Button>

These props remove control from who will use your component. If customization is required, this person will have to modify the <IconButton/>, which is rarely a good idea.

If you split responsibilities and support for children, the code will have a clear structure and whoever uses it will have more control over what they want to do:



<Button>
  Click here
  <SuccessIcon className="icon" />
</Button>
<style>
  .icon {
    height: 16px;
    width: 16px;
    color: black;
  }
</style>

Over time, some complex components can be structured, always based on these simpler components. New structures can be created based on these atomic components, but these new structures should not stop you from reusing the atomic components.

4) Use headless libraries

🔗

We have many UI patterns that HTML does not support natively today and that devs need to implement from scratch. A classic example is the switch component. It is similar to the checkbox, but both its appearance and interaction have its peculiarities that differ from the standard HTML checkbox.

You create a switch from scratch. It's a cool exercise and you do a good job. But it's likely that you didn't handle the component's keyboard and screen reader navigation correctly.

You read the specification of WAI-ARIA and implement accordingly. But now the code has become so complex that the rest of the team struggles following the code, someone else touches <Switch/> and they feel insecure not knowing if it broke, and the only one who can update this piece of code is you.

The project has dozens of reusable components, each bringing the same pain point. As it grows, it becomes easier to create a new component from scratch than to modify the one that already exists. Your reusable component ends up being not reusable.

Libraries of pre-made components came to facilitate this work. Today there are many styleless libraries, commonly called headless UI, for example React Aria, Radix and Headless UI . They implement the expected behavior and you only implement the style.

You may rather use styled libraries. I haven't had much opportunity to use it, but I know the popular ones: Ant Design, Material UI and Chakra UI.

The beauty of using pre-made components is that you have more confidence the page is accessible, without the need for a lot of code to maintain.

5) Avoid external dependencies

🔗

The first reusable components I made were inputs. As the project standard was to use Formik , I created the inputs integrated into Formik.

This seemed like a good decision at the time. But as the project grew, there were cases that did not align with this expectation, and several of the inputs did not need Formik. This added unnecessary friction that was increasingly difficult to deal with, and made it difficult to migrate to alternative libraries to Formik.

If your component is truly reusable, it should have no expectations from its context. The more context-free it is, the more reusable it is.

We can extend it to any logic external to the component. State management (redux), themes (styled components), validations (react-hook-form), layout (flex/grid), and other dependency injections. All integrations must be injected by props or JSX to avoid blocking your component.

Extra: 6) Migration

🔗

You might be inspired now, but it's possible that your project already has a reusable UI. Changing these components that are in widespread use is complex, and this discourages you from switching to better code.

But I'm here to say: don't give up on change. Instead, take one step at a time:

Bring the idea to your team. Run proofs of concept, show the value of the changes, and avoid making changes that people don't want to make. Always remember that code is made by humans for humans.
Try to adapt your changes as much as possible with the code that already exists. Some changes add a lot of value to the project, and other changes don't have as much impact. Choose your focus to migrate easily and avoid disrupting workflow.
Think about a migration plan. It is important that everyone on the team is aligned. Add new code, help people use it, deprecate old code, and little by little remove old code from your base.

Putting it all together

🔗

Finally, an example of a basic <Button/>:



import React, {
  ComponentPropsWithoutRef,
  forwardRef
} from 'react'
import {Link} from 'react-router-dom'
import {Slot} from '@radix-ui/react-slot'
import clsx from 'clsx'
import style from './button.module.css'

type Props = ComponentPropsWithoutRef<'button'> & {
  asChild?: boolean
}

const Button = forwardRef<HTMLButtonElement, Props>(
  ({className, asChild, ...props}, ref) => {
    const Comp = asChild ? Slot : 'button'
    return (
      <Comp
        className={clsx(style.button, className)}
        ref={ref}
        {...props}
      />
    )
  }
)

Explaining the code above:

It is a component that accepts all generic attributes as props <button/>.
It accepts a ref value
It implements a class .button that adds project-specific styles
I've used the Radix Slot component which helps me applying the button style to another component, it can be enabled using the prop asChild



<Button className="my-class">See details</Button>
<Button type="submit" ref={buttonRef}>Send info</Button>
<Button asChild>
  <Link to="/login">Enter</Link>
</Button>

In the end, reusable code helps a lot, but it is an abstraction and therefore must be well thought out. Creating reusable code that doesn't adapt to all contexts can create a snowball. It is important to use already recognized standards and give devs control to use them in unexpected ways.

Como reutilizar sua UI

André Matulionis — Wed, 03 Jul 2024 23:18:43 +0000

Basicamente todo mundo que conheço acaba criando componentes reutilizáveis para reaproveitar o trabalho feito. Essa é uma abstração enganosamente simples: é fácil criar um Button, mas é surpreendentemente difícil conseguir reutilizar ele em todos os casos de uso em um projeto.

Eu aprendi algumas coisas com o passar dos anos, e vejo que várias pessoas acabam metendo o pé na jaca sem perceber. Quero compartilhar algumas dicas para evitar que algumas jacas sejam pisadas.

Tenho um viés de React mas tudo pode ser aplicado em outros contextos, desde que tenha componentização da UI.

Acesso rápido

Evite margens
Se inspire em props HTML
Componhe componentes
Utilize bibliotecas headless
Evite dependências externas
Extra: Migração
Juntando tudo

1) Evite margens 🔗

Colocar margens no seu componente acaba quebrando a expectativa de reuso do componente. Espaçamento é algo importante, e seu componente não conhece onde vai ser aplicado.

Ao invés disso, deixe a responsabilidade de espaçamento para o pai que contém os componentes. É possível que ele utilize uma forma nova para gerenciar espaçamentos, como paddings e gaps.

Existem várias conversas ¹ ² ³ sobre como deve ser criado espaçamentos nos componentes. Mas geralmente a conclusão é não colocar espaçamento externo. É mais confiável que seu componente pai lide com margens.

E falando no componente pai...

2) Se inspire em props HTML 🔗

É importante que componentes sejam utilizados de uma forma esperada. Utilizar uma interface que todo mundo conhece ajuda nisso, e os atributos HTML são uma interface conhecida.

Caso queira inserir uma margem no componente, ao invés de criar uma prop dedicada à margem seu componente pode fazer como uma div genérica e aceitar estilos e classes como prop. O componente pai vai ter o contexto e o controle para estender seu componente para casos não esperados.

"Mas esse padrão é muito comum no projeto, vou ter que declarar sempre no pai?". Algumas props podem ser colocadas a mais com as props tradicionais ainda tendo destaque. Geralmente é uma prop variant, size, ou similar. Recomendo dar uma olhada em libs como CVA ou vanilla-extract pra gerenciar essas props de forma escalável.

Se a prop tiver um nome padrão do HTML ela também dispensa documentação. Para devs novos é mais fácil aprender, e para pessoas experientes já tem uma expectativa e isso aumenta a produtividade.

E isso inclui não só o nome de cada prop mas também o valor. Evite criar um contrato muito inovador na prop, como enums e objetos. Ao invés disso, as strings clássicas e JSX conseguem facilitar o uso.

E falando em JSX...

3) Componhe componentes 🔗

Não tente criar componentes com muita estrutura. Crie componentes atômicos que sejam fáceis de controlar e reutilizar, e ao invés de colocar props para pedaços de UI, use JSX.

Por exemplo, já fiz (e vi) props espalhadas no componente:

<IconButton
  icon="success"
  iconSize="16px"
  iconColor="black"
  iconPosition="end"
>Clique Aqui</Button>

Essas props removem o controle de quem vai utilizar seu componente. Caso precise de customização, a pessoa vai ter que modificar o IconButton, o que raramente é uma boa ideia.

Caso você separe as responsabilidades e suporte children, o código vai ter uma estrutura clara e quem o utilizar vai ter mais controle do que querem fazer:

<Button>
  Clique aqui
  <SuccessIcon className="icon" />
</Button>
<style>
  .icon {
    height: 16px;
    width: 16px;
    color: black;
  }
</style>

Com o tempo, alguns componentes complexos podem ser estruturados mas sempre com base nesses componentes mais simples. Novas estruturas vão ser criadas com base nesses componentes atômicos, mesmo assim não esconda eles por trás dessas estruturas.

4) Utilize bibliotecas headless 🔗

Temos muitos padrões de UI que hoje o HTML não suporta nativamente e que devs precisam implementar do zero. Um exemplo clássico é o componente de switch. Ele é parecido com o checkbox, mas tanto seu visual quanto sua interação tem suas peculiaridades que diferem do checkbox padrão do HTML.

Você cria um switch do zero. É um exercício legal e você faz um bom trabalho. Mas é provável que você não lidou corretamente com a navegação por teclado e leitor de tela do componente.

Você lê a especificação no WAI-ARIA e implementa de acordo com ela. Mas agora o código ficou tão complexo que todo o resto do time tem dificuldades para acompanhar o código, e o único que consegue mexer nele é você. Se outra pessoa mexe no <Switch /> ela fica insegura sem saber se quebrou algo.

O projeto tem dezenas de componente reutilizáveis cada um trazendo essa dor. Conforme cresce fica mais rápido fazer um componente do zero do que modificar o que já existe. Seu componente reutilizável acaba não reutilizado.

Bibliotecas de componentes pré-feitos vieram pra facilitar esse trabalho. Hoje existem muitas bibliotecas sem estilos, chamadas de headless UI, por exemplo React Aria, Radix e Headless UI. Elas implementam o comportamento esperado e você implementa o estilo.

Se preferir, tem como utilizar bibliotecas estilizadas. Eu não tive muita oportunidade de utilizar, mas conheço as populares Ant Design, Material UI e Chakra UI.

A beleza de utilizar componentes pré-prontos é que você cria mais confiança que a página esteja acessível, sem a necessidade de muito código para manter.

5) Evite dependências externas 🔗

Os primeiros componentes reutilizáveis que fiz foram inputs. Como o padrão do projeto era utilizar Formik, criei os inputs integrados ao Formik.

Isso parecia uma decisão acertada na época. Mas conforme o projeto foi crescendo tinham casos que não se alinhavam com essa expectativa, e vários dos inputs não precisavam do Formik. Isso adicionava uma fricção desnecessária cada vez mais difícil de lidar, e dificultou a migração para bibliotecas alternativas ao Formik.

Se seu componente é realmente reutilizável, ele não deve ter expectativas do seu contexto. Quanto mais ele sabe for livre do contexto, mais reutilizável ele é.

Podemos estender para qualquer lógica externa ao componente. Gerenciamento de estado (redux), temas (styled components), validações (react-hook-form), layout (flex/grid), e outras injeções de dependências. Toda as integrações devem ser injetadas por props para não engessar seu componente.

Extra: 6) Migração 🔗

Talvez você fique inspirado agora, mas é possível que seu projeto já tenha UI reutilizável. Mudar esses componentes que têm seu uso generalizado é uma tarefa complicada, e isso desencoraja a mudança para um código melhor.

Não desista da mudança. Dê um passo de cada vez:

Traga a ideia para o seu time. Faça provas de conceito, mostre o valor das mudanças, e evite fazer mudanças que as pessoas não querem fazer. Lembre-se que o código é feito para os humanos.
Tente adaptar ao máximo com o código que já existe. Algumas mudanças adicionam muito valor ao projeto, e outras mudanças não tem tanto impacto. Escolha seu foco pra facilitar o uso.
Pense em um plano de migração. É importante que todos do time estejam alinhados. Adicione o código novo, ajude pessoas a utilizá-lo, depreque código antigo, e de pouco em pouco remova o código antigo da sua base.

Juntando tudo 🔗

Para terminar, um exemplo de um <Button /> básico.

import React, {
  ComponentPropsWithoutRef,
  forwardRef
} from 'react'
import {Link} from 'react-router-dom'
import {Slot} from '@radix-ui/react-slot'
import clsx from 'clsx'
import style from './button.module.css'

type Props = ComponentPropsWithoutRef<'button'> & {
  asChild?: boolean
}

const Button = forwardRef<HTMLButtonElement, Props>(
  ({className, asChild, ...props}, ref) => {
    const Comp = asChild ? Slot : 'button'
    return (
      <Comp
        className={clsx(style.button, className)}
        ref={ref}
        {...props}
      />
    )
  }
)

Explicando o código acima:

É um componente que aceita como props todos os atributos do <button /> genérico.
Ele aceita receber ref
Ele implementa uma classe .button que adiciona os estilos do projeto
Caso você queira aplicar o estilo do botão em um outro componente, é possível através da prop asChild

<Button className="minha-classe">Ver detalhes</Button>
<Button type="submit" ref={buttonRef}>Enviar dados</Button>
<Button asChild>
  <Link to="/login">Entrar</Link>
</Button>

No fim, código reutilizável ajuda bastante, mas ele é uma abstração e portanto deve ser bem pensado. Criar código reutilizável que não se adapta a todos os contextos pode criar uma bola de neve. É importante utilizar padrões já reconhecidos e dar controle para os devs utilizarem de formas não esperadas.

Acessibilidade = Usabilidade

André Matulionis — Fri, 21 Jun 2024 22:43:53 +0000

Nós devs frontend não devemos pensar em acessibilidade como uma coisa separada de usabilidade. Usabilidade é um termo empregado pra dizer quão fácil é que o usuário consiga alcançar o que deseja com o produto. E o design tem que ser pensado considerando o perfil de usuário para melhorar a usabilidade.

Um exemplo são os atalhos de teclado como o Ctrl C / Ctrl V, que facilitam a tarefa para uma porção de usuários. Ao mesmo tempo, é importante deixar alternativas para usuários sem ciência desse atalho, por conta disso que no menu de contexto (botão direito do mouse) geralmente você encontra um "copiar" e um "colar" ali.

Acessibilidade é a mesma coisa que usabilidade, só que empregada para perfis específicos de usuário, geralmente portadores de deficiência. Um campo inacessível é um bug crítico de usabilidade com impacto igual a (ou maior que) um botão difícil de usar ou um carregamento lento.

Algumas coisitas que podemos fazer para melhorar no nosso dia a dia de dev frontend:

Aprenda mais sobre acessibilidade. Muitas gente aprende sobre "alt" e "tags semânticas" e pára aí. Aprenda sobre WCAG, WAI-ARIA, media features, e dissemine seu aprendizado.
Não reinvente a roda. HTML tem bastante coisa nativamente, e onde ele sozinho não consegue, use bibliotecas de componentes headless, tem muitas alternativas mas pessoalmente gosto de usar o Radix.
Batalhe pelo usuário. Quando for implementar algo novo, sempre considere como fator de implementação adaptar esse algo para uma gama de necessidades de usuários diferentes.
Teste o que criou, não fique só na teoria. Use leitores de tela, ou outras ferramentas de acessibilidade, para confirmar que o que fez está correto.

Um rant sobre API mal feita

André Matulionis — Sat, 09 Mar 2024 13:42:47 +0000

Esse post é mais reclamação do que um argumento bem feito. Por favor não leve tão a sério.

Eu trabalhei vários anos com Formik. Não gosto muito dele, já que ele tem um aspecto "boilerplate". Por conta disso, queria aprender como lidar com forms de outras maneiras.

No projeto que estou trabalhando hoje, já temos o react-hook-form instalado. Eu não tenho experiência com ele, então resolvi aproveitar a oportunidade.

Resumindo bastante, eu odiei. Fiquei trabalhando até tarde para tentar resolver um form com ele, e no final eu desisti e usei React puro. A API dele é bem complexa, e a documentação não ajuda.

Um exemplo

Eu estava usando um form simples que tem um único campo de username. Esse campo não aceita espaços, e se o usuário inputar espaço, ele deve ignorar. Além disso, o campo tem algumas validações.

Utilizando React puro, essa solução é possível.

function UsernameForm({onSubmit}) {
  const form = useForm()
  const [username, setUsername] = useState('')
  const isValid = validateUsername(username)
  return (
    <form onSubmit={form.handleSubmit(onSubmit)}>
      <input
        type="text"
        name="username"
        value={username}
        onChange={
          e => 
            setUsername(e.target.value.replaceAll(' ', ''))
        }
      />
      <button type="submit" disabled={!isValid}>Salvar</button>
    </form>
  )
}

Observação: nesse exemplo de username, remover espaços do input sem feedback é frustrante ao usuário e não recomendo. No meu caso real, o campo era um tanto mais complicado e o design já lidava com isso.

Esse exemplo deriva do conceito de controlled inputs que está na documentação oficial do React. É um exemplo simples do que pode ser feito em React.

Porém, isso entra em conflito com o react-hook-form. Tanto eu quanto ele precisamos ter controle das props do componente. Como vamos resolver esse conflito?

A API dele ajuda bastante em alguns casos. Se eu quero adicionar um onChange no meu input, eu consigo passar pra ele.

<input
  type="text"
  {...form.register('username', {
    onChange: e =>
      console.log(`username agora é ${e.target.value}`)
  })}
/>

No caso de controlled component, eu preciso de duas props: value e onChange.

<input
  type="text"
  {...form.register('username', {
    value: username,
    onChange:
      e => setUsername(e.target.value.replaceAll(' ', ''))
    validate: validateUsername,
  })}
/>

Funcionou! Quer dizer, mais ou menos. Ele não tá validando o form quando atualizo o username. formState.isValid sempre está retornando false, mesmo quando o username está válido.

Debugando

Fiquei tentando entender isso durante bastante tempo. Debuguei minha função de validação, fiz várias mudanças nos parâmetros de useForm e register, refatorei meu input, mas não mudava nada.

Depois de meia hora procurando na documentação, achei um pequeno ponto na API do register.

value: Set up value for the registered input. This prop should be utilised inside useEffect or invoke once, each re-run will update or overwrite the input value which you have supplied.

Então eu tava utilizando register de forma errada! Eu não deveria mandar value como prop diretamente no componente. Mas então, como faço pra controlar meu componente?

Depois de mais meia hora procurando na documentação, eu achei algo que parecia o que eu queria. E tentei aplicar.

function UsernameForm({onSubmit}) {
  const form = useForm()
  const username = form.watch('username')

  useEffect(() => {
    form.register('username', {
      validate: validateUsername,
    })
  }, [form.register])

  return (
    <form onSubmit={form.handleSubmit(onSubmit)}>
      <input
        type="text"
        value={username}
        onChange={
          e =>
            form.setValue('username', e.target.value.replaceAll(' ', ''))
        }
      />
      <button type="submit">Salvar</button>
    </form>
  )
}

Para ver esse código no doc, precisa acessar esse link e clicar em Custom register.

Achei isso incrivelmente frustrante. Na documentação, esse código está num canto escondido da parte avançada. O código também cria vários átomos de código que estão separados, mas que são bem entrelaçadas. E ainda por cima, ele adiciona um useEffect, um hook que idealmente seria utilizado pra sincronizar com sistemas externos, embora o form seja bem autossuficiente.

A API inicialmente fez algo muito bom, colocar onChange no register é uma solução simples e completa. Só que criar um value que não age como o esperado é uma decisão tão burra que me falta palavras pra descrever. Eu tenho certeza que essa decisão trouxe bugs em aplicações e frustrações para devs.

Ao mesmo tempo, a solução oficial de utilizar um conjunto de watch, um useEffect com register, e um setValue parece uma solução tão mal pensada que estou incrédulo até agora. Como react-hook-form é algo tão popular se não lida com um caso de uso simples?

Conclusão

Vou usar Zod puro agora

Sobre cores no CSS

André Matulionis — Fri, 08 Sep 2023 20:02:10 +0000

Recentemente vi um vídeo onde várias pessoas conversavam sobre cores. No final do vídeo, o moço Tom Scott mostrou suas habilidades de desenvolvedor mostrando que sabe traduzir um código hexadecimal (#BADBED) a sua cor equivalente:

BA é um valor alto de vermelho
DB é um valor mais alto ainda de verde
ED é um valor quase absoluto de azul

Misturando essas cores, ele concluiu que a cor seria um "ciano bem pastel", o que deixou todo mundo estupefato. Isso pode parecer incrível, mas é cotidiano para algum programador frontend mais experiente. Se você quiser converter para números, também temos a notação rgb() que converte números de 0 a 255 para os três canais de cores: rgb(186 219 237)

Mesmo assim, existe algo com RGB que não me agrada. Resolver ele não é intuitivo, você tem que fazer "contas" com as cores, na hora
de converter para uma porcentagem e na hora de misturar as cores.

Computadores entendem RGB, eles foi feita pra isso, mas para humanos, o processo é cansativo, já que não é o jeito que pensamos em cores.

Entra HSL

Quando vou descrever cores para pessoas, não uso notação RGB, "essa cor tem muito vermelho, e muito verde e só metade de verde". Eu geralmente falo "um amarelo claro", ou "um vermelho bem forte".

Criar cores HSL é mais intuitivo porque acaba adotando uma linguagem similiar. Nela temos três argumentos para descrever a cor:

h: Hue (ou matiz) controla a cor em si. É um valor que vai de 0deg a 360deg
s: Saturation controla quanto da cor é colocado. 0% transforma em cinza e 100% cria uma cor saturada
l: Lightness controla quanto de luminosidade é inserida na cor. 10% cria uma cor bem escuro, e 90% uma cor bem clara.

Pra ser sincero, não gosto muito do controle de Hue, não é muito intuitivo pensar em cores através de uma roda.

Mesmo assim, é fácil pegar o jeito, e depois disso não precisa fazer mais cálculos com cores.

0deg é vermelho
180deg é ciano
entre 0deg e 180deg tem laranja, amarelo e verde
entre 180deg e 360deg tem azul, rosa e lilás
Se eu me perder, lembro de um arco-íris

Uma combinação assim não é só mais intuitiva, também tem um controle mais simples e facilita a criação de temas.



:root {
  --hue-primary: 220deg;
  --color-primary-light: hsl(var(--hue-primary) 60% 80%);
  --color-primary-dark: hsl(var(--hue-primary) 90% 20%);

  --hue-secondary: calc(var(--hue-blue) + 120deg);
  --color-secondary-light: hsl(var(--hue-secondary) 60% 80%);
  --color-secondary-dark: hsl(var(--hue-secondary) 90% 20%);
}

(Eu duvido que consegue fazer isso usando notação rgb)

OKLCH

Temos HSL, e até recentemente eu estava bem satisfeito com essa notação.

Descobri recentemente sobre a notação oklch(). Ela resolve problemas que eu nem tinha percebido que existiam. É mais intuitiva, mais fácil de controlar, e abrange novas cores que não existem na RGB.

Embora a notação seja maior, oklch() ainda tem três argumentos. Ignora o 'ok' no nome e considera somente o 'lch':

l: Lightness controla a luminosidade igual ao hsl()
c: Chroma controla a intensidade, diferente da saturação do hsl()
h: Hue controla a cor em si igual ao hsl()

Chroma vs Saturation

Uma coisa que acabei aprendendo a lidar com hsl() é que cores de matizes diferentes tem "intensidades diferentes".

Um exemplo: três cores, todas com saturação máxima de 100%.



.red   { background-color: hsl(0deg 100% 50%); }
.green { background-color: hsl(120deg 100% 50%); }
.blue  { background-color: hsl(240deg 100% 50%); }

Na minha experiência eu me adequei com valores de saturação diferentes para matizes diferentes. No exemplo, o texto no quadrado azul está bem menos visível do que o texto no quadrado verde.

Com oklch(), isso não é mais necessário. Ele se restringe de forma que distribui melhor a intensidade



.red   { background-color: oklch(60% 50% 30deg); }
.green { background-color: oklch(60% 50% 150deg); }
.blue  { background-color: oklch(60% 50% 250deg); }

Isso facilita bastante na hora de criar paletas de cores, já que elas são bem consistentes na faixa completa de matizes.

Cores novas e mais vivas

Uma das coisas que oklch() traz, junto com outras notações, é a possibilidade de descrever cores em um espaço de cor mais completo.

Sem entrar em muita tecnicalidade, mas por anos o padrão de espaço de cor foi o sRGB, um espaço de cor que funciona muito bem.

Porém, mais recentemente, a Apple, com esse negócio de criar design que ela gosta, criou e adotou um espaço de cor mais completo, o Display-P3, que resolve pequenos problemas que sRGB tinham, além de aumentar o espaço de cores possíveis de serem exibidas.

Com o tempo, dispositivos além da Apple começaram a suportar P3. Hoje ainda não é amplamente disponível, mas com certeza faz a diferença para monitores e celulares que são capazes de utilizar esse espaço de cor.

Gradientes com grey zones

Alguns gradientes tem o problema clássico de criarem um espaço cinza na transição de cores.

Imagem retirada de CSS Tricks

Esse problema é comum no espaço sRGB. Como oklch() se expressa através do espaço P3, temos suavidade no gradiente, já que o gradiente se "curva" para usar mais as cores e diminuir a zona cinza.

Suporte

A notação hsl() já é segura e pode ser utilizada em qualquer browser. Até IE9 suporta ela!

A notação oklch() já tem suporte de todos os browsers modernos. Safari implementou no começo de 2022, e browsers como Chrome, Edge, Opera, Firefox e Samsung Internet começaram a suportar em 2023.

Infelizmente, o espaço de cor P3 precisam de suporte do hardware, o que ainda é restritivo para boa parte das pessoas. Porém, a notação oklch() já pode ser utilizada mesmo para dispositivos que usem sRGB.

Finalmentes

Eu espero que tenha convencido você de mudar do hexadecimal/rgb clássicos para notações mais intuitivas e humanas de aplicar cores. Experimente criar cores com a ajuda da oklch(), e use hsl() para projetos em produção. Argumento não falta para mudar.

Veja mais argumentos (em inglês)

https://evilmartians.com/chronicles/oklch-in-css-why-quit-rgb-hsl
https://www.smashingmagazine.com/2023/08/oklch-color-spaces-gamuts-css/
https://webkit.org/blog/10042/wide-gamut-color-in-css-with-display-p3/
https://blog.logrocket.com/oklch-css-consistent-accessible-color-palettes/

Procurando a motivação

André Matulionis — Thu, 20 Apr 2023 19:44:43 +0000

Esse post não é sobre código. Mesmo se não souber programar, você não deve ter dificuldades em acompanhar 😄

Eu já ouvi bastante feedback no meu trabalho. O mais constante sendo melhorias de comunicação, que até hoje tenho certo problema.

Um problema que ocorria frequentemente era que as minhas explicações que eram muito técnicas. Na minha conversa com o time de produto isso complicava tudo. Por exemplo, eu explicava todo o contexto por volta de uma nova implementação de feature. Levantava as possibilidades que conseguia pensar, trazendo as facilidades e dificuldades que trariam na implementação inicial e na manutenção do código. Eu estava pensando comigo mesmo e sendo transparente com todo mundo.

Isso era relevante se fosse discutir com pessoas mais seniores, mas raramente era o caso. O que aprendi com o tempo era entender o escopo do que as pessoas precisavam saber, e trazer isso a elas. Entender o porquê daquela comunicação existir, e relevar o que exatamente eu precisava comunicar de acordo com esse motivo.

Aplicando isso, as mensagens de Slack que eram 5 parágrafos gigantes explicando os pormenores da entrega viravam 5 frases breves focando no que a pessoa precisava saber. Pra escrever as 5 frases eu ainda demoro, mas a comunicação fica bem mais fluída assim.

Eu lembro quando eu criava testes de componentes React usando Enzyme. Foi ótimo aprender o mundo frontend com ele, porque eram simples, e qualquer um poderia criar testes sem esforço.

it('renders', () => {
  const wrapper = shallow(<Component />);
  expect(wrapper).toMatchSnapshot();
})

Eu gosto de pensar nesses testes como "snacks", eles são rápidos de serem escritos e entendidos, e raramente quebram. Se quebrar, era um processo simples corrigir eles, geralmente eu apertava U no teclado e o snapshot atualizava sozinho, eu nem precisava verificar.

Mas uma coisa que ficava escondida para mim era que os testes, sendo fáceis de serem mantidos, eram também muito inúteis. Muitos bugs passavam nesse método, e no final o valor dos testes era bem limitado.

React Testing Library chega na minha vida. Ela vem com um princípio:

The more your tests resemble the way your software is used, the more confidence they can give you.

Essa pequena frase afeta bastante. Para seguir esse princípio, a React Testing Library tem menos possibilidades do que a Enzyme, mas o que pra mim parecia um detrator da lib acabava sendo uma vantagem. Isso diminui o foco na estrutura do código, e aumenta o foco no usuário como valor principal dos testes.

Eu só fazia testes porque era considerado boa prática, mas nenhum momento eu tinha pensado em um Objetivo dos testes, que colocava valor nos testes em si. Eu nem precisava da React Testing Library pra aplicar esse princípio. Ao me restringir dentro do Enzyme, eu criava testes com mais valor.

DRY (Don't Repeat Yourself ou Não Se Repita) é um acrônimo bem popular de boa prática no mundo da programação. A ideia dele é reduzir retrabalho com a regra de não duplicar código.

Essa regra é aplicada não só no frontend, mas em todos os níveis de programação que já vi. E de longe é a mais popular e mais implementada por times. Uma crítica recente a essa "boa prática" é que ela introduz códigos complexos demais com o tempo.

O processo acaba sendo o seguinte: uma pessoa evita repetir o código introduzindo uma abstração. Outra pessoa, considerando que precisa dessa abstração, usa ela e altera pro seu caso. E mais uma pessoa, e outra, assim vai indo. Até que a abstração não faz mais sentido, mas é utilizada por todos.

Outras regras foram introduzidas para mitigar esse problema. WET (Write Everything Twice ou Escreva Tudo Duas Vezes) é uma regra que diz: "Todo código deve ser escrito no máximo duas vezes". É uma regra que mitiga esses problemas, mas ao meu ver tem outra regra, ou melhor, ideia, que diminui a complexidade de código, o AHA: "Avoid Hasty Abstractions" (ou Evite Abstrações Apressadas).

A ideia do AHA programming é introduzir abstrações no código quando elas forem necessárias, e diminuir o uso de abstrações simplesmente por abstrair.

A vantagem (e desvantagem) do AHA é que ele não dá uma regra fácil de ser seguida. Ele abre mão de uma regra definida para que a pessoa desenvolvendo consiga determinar vários fatores que definam se tal abstração é necessária. Isso faz com que alguns casos apareçam meio estranhos, por exemplo:

const DEBUG_QUERY_PARAM = 'shouldDebug'

function Component() {
  const { search } = useLocation()
  // ...

  const doSomething = () => {
    const shouldDebug = new URLQueryParams(location.search)
        .has(DEBUG_QUERY_PARAM);
    if (shouldDebug) {
      console.log('debugging happening');
    }
    // ...
  }
}

Esse código tem duas abstrações relevantes: DEBUG_QUERY_PARAM e shouldDebug. Ambas existem mas só são utilizadas uma vez.

Se for se basear só nas regras de DRY ou WET, ambas as abstrações não fazem sentido, elas estão sendo usadas só uma vez no código. Mas é importante capturar o propósito real por traz delas antes de removê-las.

DEBUG_QUERY_PARAM tem uma valor de documentar o comportamento. Ele informa pra quem está lendo que existe uma função de debug do código, e ele é controlado pela query param shouldDebug. A intenção do código não é reuso, mas sim documentação de uma feature.

shouldDebug tem o propósito de abstrair um código complexo em um código fácil de ser entendido por um humano, pode inclusive ensinar através dessa interface amigável. Além disso, ele representa melhor a intenção da pessoa que o criou, fazendo o trabalho de manutenção mais fácil caso haja algum bug.

⚠️ Eu não estou necessariamente dizendo que o código escrito é um bom código. Leve em conta o contexto dele antes de aplicar o mesmo racional.

Por quê?

Essas historietas estão conectadas por uma ideia, sintetizada por uma/duas palavra(s): "Por quê?" Pra trazer valor em uma tarefa, eu preciso entender o motivo dela.

Já vi uma técnica chamada "Os 5 porquês", criada com o objetivo de chegar à raiz do problema. Nela, você entra numa recursão: pergunta o motivo de um problema ocorrer, e depois disso procura explicar porque esse motivo existe, e continuamente.

Essa técnica pode ser aplicada onde você ainda não enxerga problemas. Tente entender a motivação por trás. Essa motivação não precisa ser a melhor do mundo, mas tem que ser sincera. Se você quer usar TypeScript invés de JS, você não precisa falar que tem mais qualidade ou os mesmos argumentos de sempre. Os argumentos podem ser baseados no seu contexto: talvez você queira experimentar TS no seu projeto, ou você queira melhorar seu portifólio profissional.

Post Scriptum

Sendo um pouco meta aqui e aplicando o post no próprio. Eu já tentei escrever muito, mas nunca terminei de escrever. Falei sobre esse assunto no post porque é um assunto que tenho muito o que falar, o que facilita a escrever. E no final, quero escrever posts como esse como parte da minha vida profissional.