Forem: doug-source

Estrutura do projeto React para escalar: decomposition, camadas e hierarquia

doug-source — Sat, 05 Apr 2025 01:51:44 +0000

Nota: apenas traduzi o texto abaixo e postei aqui. As referências estão no fim deste artigo.

Como estruturar React apps "da maneira certa" parece ser o assunto do momento recentemente, desde que o React existe. A opinião oficial do React sobre isso é que ele "não tem opiniões". Isso é ótimo, nos dá liberdade total para fazer o que quisermos. E também é ruim. Isso leva a tantas opiniões fundamentalmente diferentes e muito fortes sobre a estrutura adequada do React app, que até mesmo os desenvolvedores mais experientes às vezes se sentem perdidos, sobrecarregados e precisam chorar em um canto escuro por causa disso.

Eu, é claro, também tenho uma opinião forte sobre o tópico 😈. E nem vai ser "depende" dessa vez 😅 (quase). O que quero compartilhar hoje é o sistema, que vi funcionando muito bem em:

um ambiente com dezenas de equipes vagamente conectadas no mesmo repositório trabalhando no mesmo produto
em um ambiente acelerado de uma pequena startup com apenas alguns engenheiros
ou mesmo para projetos de uma pessoa (sim, eu uso isso o tempo todo para minhas coisas pessoais)

Só lembre-se, assim como o Código do Pirata, tudo isso é mais o que você chamaria de "diretrizes" do que regras reais.

O que precisamos da convenção de estrutura de projeto

Não quero entrar em detalhes sobre por que precisamos de convenções como essa em primeiro lugar: se você chegou a este artigo, provavelmente já decidiu que precisa dela. O que eu quero falar um pouco, antes de pular para soluções, é o que torna uma convenção de estrutura de projeto ótima.

Replicabilidade

A convenção de código deve ser compreensível e fácil o suficiente para ser reproduzida por qualquer membro da equipe, incluindo um estagiário recém-contratado com experiência mínima em React. Se a maneira de trabalhar em seu repositório exige um PhD, alguns meses de treinamento e debates profundamente filosóficos sobre cada segundo PR... Bem, provavelmente será um sistema realmente bonito, mas não existirá em nenhum outro lugar além do papel.

Inferrabilidade

Você pode escrever um livro e gravar alguns filmes sobre "A maneira de trabalhar em nosso repositório". Você provavelmente pode até convencer todos na equipe a ler e assistir (embora você provavelmente não vá). O fato é: a maioria das pessoas não vai memorizar cada palavra, se é que vai. Para que a convenção realmente funcione, ela deve ser tão óbvia e intuitiva, de modo que as pessoas na equipe idealmente sejam capazes de fazer engenharia reversa apenas lendo o código. No mundo perfeito, assim como com comentários de código, você nem precisaria escrevê-lo em lugar nenhum - o código e a estrutura em si seriam sua documentação.

Independência

Um dos requisitos mais importantes das diretrizes de estrutura de codificação para várias pessoas, e especialmente várias equipes, é solidificar uma maneira para os desenvolvedores operarem independentemente. A última coisa que você quer é vários desenvolvedores trabalhando no mesmo arquivo, ou equipes constantemente invadindo as áreas de responsabilidade umas das outras.

Portanto, nossas diretrizes de estrutura de codificação devem fornecer tal estrutura, onde as equipes sejam capazes de coexistir pacificamente dentro do mesmo repositório.

Otimizado para refatoração

Último, mas no mundo moderno do frontend, é o mais importante. O frontend hoje em dia é incrivelmente fluido. Patterns, frameworks e melhores práticas estão mudando constantemente. Além disso, espera-se que entreguemos features rapidamente hoje em dia. Não, RÁPIDO. E então reescrevê-lo completamente depois de um mês. E então talvez reescrevê-lo novamente.

Então se torna muito importante para nossa convenção de codificação não nos forçar a "colar" o código em algum lugar permanente sem nenhuma maneira de movê-lo. Ela deve organizar as coisas de tal forma que a refatoração seja algo que seja realizado casualmente em uma base diária. A pior coisa que uma convenção pode fazer é tornar a refatoração tão difícil e demorada que todos fiquem apavorados com ela. Em vez disso, deve ser tão simples quanto respirar.

...

Agora que temos nossos requisitos gerais para a convenção de estrutura do projeto, é hora de entrar em detalhes. Vamos começar com o panorama geral e, então, detalhar.

Organizando o projeto em si: decomposition

A primeira e mais importante parte da organização de um grande projeto que esteja alinhado com os princípios que definimos acima é a "decomposition": em vez de pensar nisso como um projeto monolítico, pode ser pensado como uma composição de recursos mais ou menos independentes. A boa e velha discussão "monólito" vs "microsserviços", apenas dentro de um React app. Com essa abordagem, cada feature é essencialmente um "nanoserviço" de certa forma, que é isolado do restante das features e se comunica com elas por meio de uma "API" externa (geralmente apenas React props).

Mesmo apenas seguindo essa mentalidade, comparado à abordagem mais tradicional do "projeto React", você terá praticamente tudo da nossa lista acima: equipes/pessoas poderão trabalhar independentemente em features em paralelo se as implementarem como um monte de "black boxes" conectadas umas às outras. Se a configuração estiver correta, deve ser bem óbvio para qualquer um também, só exigiria um pouco de prática para se ajustar à mudança de mentalidade. Se você precisar remover uma feature, você pode simplesmente "desconectá-la" ou substituí-la por outra feature. Ou se você precisar refatorar os detalhes internos de uma feature, você pode fazer isso. E enquanto a "API" pública dele permanecer funcional, ninguém de fora vai nem perceber.

Estou descrevendo um React component, não é? 😅 Bem, o conceito é o mesmo, e isso torna o React perfeito para essa mentalidade. Eu definiria uma "feature", para distingui-lo de um "component", como "um monte de components e outros elements unidos em uma funcionalidade completa da perspectiva do usuário final".

Agora, como organizar isso para um único projeto? Especialmente considerando que, comparado a microsserviços, ele deve vir com muito menos encanamento: em um projeto com centenas de features, extraí-los todos para microsserviços reais será quase impossível. O que podemos fazer em vez disso é usar a arquitetura multi-package monorepo: é perfeita para organizar e isolar features independentes como packages. Um package é um conceito que já deve ser familiar para qualquer um que instalou algo do npm. E um monorepo - é apenas um repo, onde você tem o código-fonte de vários packages vivendo juntos em harmonia, compartilhando ferramentas, scripts, dependências e, às vezes, uns aos outros.

Então o conceito é simples: projeto React → dividi-lo em features independentes → colocar essas features em packages.

Se você nunca trabalhou com monorepo configurado localmente e agora, depois que mencionei "package" e "npm", se sente desconfortável com a ideia de publicar seu projeto privado: não fique. Nem publicação nem código aberto são requisitos para que um monorepo exista e para que os desenvolvedores obtenham os benefícios dele. Da perspectiva do código, um package é apenas uma pasta, que tem o arquivo package.json com algumas propriedades. Essa pasta é então linked por meio dos links simbólicos do Node à pasta node_modules, onde os packages "tradicionais" são instalados. Esse linking é realizado por ferramentas como Yarn ou Npm: é chamada de "workspaces", e ambos oferecem suporte a isso. E eles tornam os packages acessíveis em seu código local como qualquer outro package baixado do npm.

Ficaria assim:

/packages
  /my-feature
    /some-folders-in-feature
    index.ts
    package.json // isto é o que define o my-feature package
  /another-feature
    /some-folders-in-feature
    index.ts
    package.json // isto é o que define o another-feature package

e no package.json eu teria esses dois campos importantes:

{
  "name": "@project/my-feature",
  "main": "index.ts"
}

Onde o campo "name" é, obviamente, o nome do package - basicamente o alias para esta pasta, através do qual ele será acessível ao código no repositório. E "main" é o entry point principal para o package, ou seja, qual arquivo será importado quando eu escrever algo como

import { Something } from '@project/my-feature';

Existem alguns repositórios públicos de projetos conhecidos que usam a abordagem monorepo de vários packages: Babel, React, Jest, para citar alguns.

Por que packages em vez de apenas folders

À primeira vista, a abordagem dos packages parece "apenas dividir seus recursos em folders, qual é o problema" e não parece tão inovadora. No entanto, há algumas coisas interessantes que os packages podem nos dar, que folders simples não podem.

Alias. Com packages, você pode se referir à sua feature pelo nome, não pela localização. Compare isto:

import { Button } from '@project/button';

com esta abordagem mais "tradicional":

import { Button } from '../../components/button';

No primeiro import, é óbvio - estou usando um generic component de "button" do meu projeto, minha versão de design system.

Na segunda, não está tão claro - o que é esse button? É o generic button de "design system"? Ou talvez parte dessa feature? Ou uma feature "acima"? Posso usá-la aqui, talvez tenha sido escrito para algum caso de uso muito específico que não vai funcionar na minha nova feature?

Fica ainda pior se você tiver vários folders "utils" ou "common" no seu repositório. Meu pior pesadelo de código se parece com isso:

import { bla } from '../../../common';
import { blabla } from '../../common';
import { blablabla } from '../common';

Com packages, poderia ser algo como isto:

import { bla } from '@project/button/common';
import { blabla } from '@project/something/common';
import { blablabla } from '@project/my-feature/common';

Instantaneamente óbvio o que vem de onde e o que pertence a onde. E as chances são de que o código "my-feature" "common" foi escrito apenas para uso interno da feature, nunca foi feito para ser usado fora da feature, e reutilizá-lo em outro lugar é uma má ideia. Com pacotes, você verá isso imediatamente.

Separation of concerns. Considerando que todos nós estamos acostumados com os npm packages e o que eles representam, fica muito mais fácil pensar sobre sua feature como um module isolado com sua própria API pública quando ele é escrito como um "package" imediatamente.

Dê uma olhada nisso:

import { dateTimeConverter } from '../../../../button/something/common/date-time-converter';

vs isso:

import { dateTimeConverter } from '@project/button';

O primeiro provavelmente se perderá em todos os imports ao redor e passará despercebido, transformando seu código em The Big Ball of Mud. O segundo levantará algumas sobrancelhas instantâneamente e naturalmente: um date time converter? De um button? Sério? O que naturalmente forçará limites mais claros entre diferentes features/packages.

Suporte integrado. Você não precisa inventar nada, a maioria das ferramentas modernas, como IDE, typescript, linting ou bundlers oferecem suporte a packages prontos para uso.

A refatoração é fácil. Com as features separadas em packages, a refatoração se torna agradável. Quer refatorar o conteúdo do seu package? Vá em frente, você pode reescrevê-lo completamente, desde que mantenha a entry da API a mesma, o resto do repositório nem notará. Quer mover seu package para outro local? É só arrastar e soltar de um folder, se você não renomeá-la, o resto do repositório não será afetado. Quer renomear o package? Basta pesquisar e substituir uma string no projeto, nada mais.

Entry points explícitos. Você pode ser muito específico sobre o que exatamente de um package está disponível para os consumidores externos se quiser realmente adotar a mentalidade de "somente API pública para os consumidores". Por exemplo, você pode restringir todos os imports "profundos", tornar coisas como @project/button/some/deep/path impossíveis e forçar todos a usar somente API pública explicitamente definida no arquivo index.ts. Dê uma olhada em Package entry points e a documentação de Package exports para exemplos de como isso funciona.

Como split o código dentro de packages

A maior dificuldade das pessoas na arquitetura multi-package é qual é o momento certo para extrair código em um package? Cada pequena feature deve ser um? Ou talvez os packages sejam apenas para coisas grandes, como uma página inteira ou até mesmo um app?

Na minha experiência, há um equilíbrio aqui. Você não quer extrair cada pequena coisa em um package: você acabará com apenas uma lista plana de centenas de packages minúsculos de um único arquivo sem estrutura, o que meio que anula o propósito de introduzi-los em primeiro lugar. Ao mesmo tempo, você não gostaria que seu package se tornasse muito grande: você atingirá todos os problemas que estamos tentando resolver aqui, apenas dentro desse package.

Aqui estão alguns limites que eu costumo usar:

"design system" type das coisas como buttons, modal dialogs, layouts, tooltips, etc., todos devem ser packages
features em alguns limites de IU "naturais" são bons candidatos para um package - ou seja, algo que vive em um modal dialog, em uma drawer, em um slide-in panel, etc.
features "compartilháveis" - aquelas que podem ser usadas em vários lugares
algo que você pode descrever como uma "feature" isolada com limites claros, lógicos e idealmente visíveis na IU

Além disso, assim como no artigo anterior sobre como dividir o código em components, é muito importante que um package seja responsável apenas por uma coisa conceitual. Um package que exporta um Button, CreateIssueDialog e DateTimeConverter faz muitas coisas ao mesmo tempo e precisa ser "split up".

Como organizar packages

Embora seja possível criar apenas uma lista simples de todos os packages, e para certos tipos de projetos isso funcionaria, para produtos grandes e pesados de UI provavelmente não será o suficiente. Ver algo como packages "tooltip" e "settings page" juntos me faz estremecer 😖. Ou pior - se você tiver packages "backend" e "frontend" juntos. Isso não é apenas confuso, mas também perigoso: a última coisa que você quer é acidentalmente pull algum código "backend" para seu frontend bundle.

A estrutura real do repositório dependeria muito do que exatamente é o produto que você está implementando (ou mesmo quantos produtos existem), se você tem backend ou apenas frontend, e provavelmente mudará e evoluirá significativamente ao longo do tempo. Felizmente, esta é a grande vantagem dos packages: a estrutura real é completamente independente do código, você pode drag-and-drop eles e reestruturá-los uma vez por semana sem quaisquer consequências se houver necessidade.

Considerando que o custo do "erro" na estrutura é bastante baixo, não há necessidade de pensar demais, pelo menos no início. Se o seu projeto for somente frontend, você pode até começar com uma lista simples:

/packages
  /button
  ...
  /footer
  /settings
  ...

e evoluir ao longo do tempo para algo como isto:

/packages
  /core
    /button
    /modal
    /tooltip
    ...
  /product-one
    /footer
    /settings
    ...
  /product-two
    ...

Ou, se você tiver um backend, poderia ser algo assim:

/packages
  /frontend
    ... // o mesmo que acima
  /backend
    ... // alguns backend packages específicos
  /common
    ... // alguns packages que são que são conpartilhados entre frontend e backend

Onde em "common" você colocaria algum código que fosse compartilhado entre frontend e backend. Normalmente serão algumas configs, constants, utils do tipo lodash, types compartilhados.

Como estruturar um package em si

Para resumir a grande seção acima: "use monorepo, extraia features em packages". 🙂 Agora para a próxima parte - como organizar o package em si. Três coisas são importantes aqui para mim: naming convention, separar o package em layers distintas e hierarquia estrita.

Naming convention

Todo mundo adora nomear coisas e debater sobre o quão ruins são as outras coisas, não é? Para reduzir o tempo gasto em intermináveis tópicos de comentários do GitHub e "calm down poor geeks" com TOC relacionado ao código como eu, é melhor concordar com uma "convenção de nomenclatura" de uma vez para todos.

Qual usar não importa muito na minha opinião, desde que seja seguido consistentemente ao longo do projeto. Se você tem ReactFeatureHere.ts e react-feature-here.ts no mesmo repositório, um gatinho chora em algum lugar 😿. Eu costumo usar este:

/my-feature-name
  /assets     // se eu tiver algumas imagens, elas vão para um folder próprio
    logo.svg
  index.tsx   // código principal da feature
  test.tsx    // tests para a feature se necessário
  stories.tsx // stories para storybooks se eu usar elas
  styles.(tsx|scss) // Gosto de separar os styles da lógica dos components
  types.ts    // se os types forem compartilhados entre diferentes arquivos dentro da feature
  utils.ts    // utils muito simples que são usados *apenas* nesta feature
  hooks.tsx   // pequenas hooks que eu uso *somente* nesta feature

Se uma feature tiver alguns components menores imported diretamente para index.tsx, eles ficarão assim:

/my-feature-name
  ... // o mesmo que antes
  header.tsx
  header.test.tsx
  header.styles.tsx
  ... // etc

ou, mais provavelmente, eu extrairia eles imediatamente para folders e eles ficariam assim:

/my-feature-name
  ... // index o mesmo de antes
  /header
    index.tsx
    ... // etc, exatamente o mesmo naming aqui
  /footer
    index.tsx
    ... // etc, exatamente o mesmo naming aqui

A abordagem de folders é muito mais otimizada para desenvolvimento orientado a copiar e colar 😊: ao criar uma nova feature copiando e colando a estrutura da feature próxima, tudo o que você precisa fazer é renomear apenas um folder. Todos os arquivos serão nomeados exatamente da mesma forma. Além disso, é mais fácil criar um modelo mental do package, refatorar e mover o código (sobre isso na próxima seção).

Layers dentro de um package

Um package típico com uma feature complicada teria algumas "layers" distintas: pelo menos a layer "UI" e a layer "Data". Embora seja provavelmente possível misturar tudo, eu ainda recomendaria não fazer isso: renderizar buttons e buscar dados do backend são preocupações muito diferentes. Separá-los dará ao package mais estrutura e previsibilidade.

E para que o projeto permaneça relativamente saudável em termos de arquitetura e código, o crucial é ser capaz de identificar claramente as layers que são importantes para seu app, mapear o relacionamento entre elas e organizar tudo isso de uma forma que esteja alinhada com quaisquer ferramentas e frameworks usados.

Se eu estivesse implementando um projeto React do zero hoje, com Graphql para manipulações de dados e React state puro para gerenciamento de state (ou seja, sem Redux ou qualquer outra biblioteca), eu teria as seguintes layers:

"Data" layer - queries, mutations e outras coisas que são responsáveis por conectar-se às fontes de dados externas e transformá-las. Usado apenas pela UI layer, não depende de nenhuma outra layer.
"Shared" layer - vários utils, functions, hooks, mini-components, types e constants que são usados em todo o package por todas as outras layers. Não depende de nenhuma outra layer.
"ui" layer - a implementação real da feature. Depende das layers "data" e "shared", ninguém depende dela.

É isso!

Se eu estivesse usando alguma biblioteca externa de gerenciamento de state, provavelmente adicionaria a layer "state" também. Essa provavelmente seria uma ponte entre "data" e "ui", e portanto usaria as layers "shared" e "data" e "UI" usaria "state" em vez de "data".

E do ponto de vista dos detalhes da implementação, todas as layers são top-level folders em um package:

/my-feature-package
  /shared
  /ui
  /data
  index.ts
  package.json

Com cada "layer" usando a mesma naming convention descrita acima. Então sua "data" layer ficaria mais ou menos assim:

/data
  index.ts
  get-some-data.ts
  get-some-data.test.ts
  update-some-data.ts
  update-some-data.test.ts

Para packages mais complicados, eu poderia split essas layers, preservando seu propósito e suas características. A layer "Data" poderia ser split em "queries" ("getters") e "mutations" ("setters"), por exemplo, e essas podem permanecer no folder "data" ou subir:

/my-feature-package
  /shared
  /ui
  /queries
  /mutations
  index.ts
  package.json

Ou você pode extrair algumas sub-layers da "shared" layer, como "types" e "UI components compartilhados" (o que transformaria instantaneamente essa sub-layer no tipo "IU" a propósito, já que ninguém além de "IU" pode usar UI components).

/my-feature-package
  /shared-ui
  /ui
  /queries
  /mutations
  /types
  index.ts
  package.json

Contanto que você consiga definir claramente qual é o propósito de cada "sublayer", saber qual "sublayer" pertence a qual "layer" e conseguir visualizar e explicar isso para todos na equipe - tudo funciona!

Hierarquia rigorosa dentro das layers

A peça final do quebra-cabeça, que torna essa arquitetura previsível e sustentável, é uma hierarquia rigorosa dentro das layers. Isso será especialmente visível na IU layer, já que em React apps ela geralmente é a mais complicada.

Vamos começar, por exemplo, a estruturar uma página simples, com um header e um footer. Teríamos o arquivo "index.ts" - o arquivo principal, onde a página se reúne, e os components "header.ts" e "footer.ts".

/my-page
  index.ts
  header.ts
  footer.ts

Agora, todos eles terão seus próprios components que eu gostaria de colocar em seus próprios arquivos. "Header", por exemplo, terá os components "Search bar" e "Send feedback". Na maneira flat "tradicional" de organizar apps, nós colocaríamos eles um ao lado do outro, não é? Seria algo assim:

/my-page
  index.ts
  header.ts
  footer.ts
  search-bar.ts
  send-feedback.ts

E então, se eu quiser adicionar o mesmo button "send-feedback" ao footer component, eu novamente faria import dele para "footer.ts" de "send-feedback.ts", certo? Afinal, ele está próximo e parece natural.

Infelizmente, o que aconteceu foi que violamos os limites entre nossas layers ("UI" e "shared") sem nem perceber. Se eu continuasse adicionando mais e mais components a essa estrutura flat, e provavelmente continuarei, applications reais tendem a ser bem complicadas, provavelmente violarei elas mais algumas vezes. Isso transformará esse folder em sua própria "bola de lama", onde é completamente imprevisível qual component depende de qual. E, como resultado, desembaraçar tudo isso e extrair algo desse folder, quando chegar a hora da refatoração, pode se tornar um exercício muito complicado.

Em vez disso, podemos estruturar essa layer de forma hierárquica. As regras são:

apenas os arquivos principais (por exemplo, "index.ts") em uma pasta podem ter subcomponents (sub-modules) e podem import eles
você pode import apenas dos "children", não dos "vizinhos"
você não pode pular um level e pode import apenas dos children diretos

Ou, se preferir visual, é apenas uma árvore:

E se você precisar compartilhar algum código entre diferentes levels dessa hierarquia (como nosso send-feedback component), você verá instantaneamente que está violando as regras da hierarquia, já que onde quer que você coloque ele, você terá que import ele dos parents ou dos vizinhos. Então, em vez disso, ele seria extraído para a layer "shared" e imported de lá.

Ficaria assim:

/my-page
  /shared
    send-feedback.ts
  /ui
    index.ts
    /header
      index.ts
      search-bar.ts
    /footer
      index.ts

Dessa forma, a IU layer (ou qualquer layer onde essa regra se aplica) se transforma em uma estrutura de árvore, onde cada branch é independente de qualquer outro branch. Extrair qualquer coisa desse package agora é moleza: tudo o que você precisa fazer é drag e drop um folder em um novo lugar. E você sabe com certeza que nenhum component na árvore da IU será afetado por ela, exceto aquele que realmente usa ele. A única coisa com a qual você pode precisar lidar adicionalmente é a "shared" layer.

O app completo com a data layer ficaria assim:

Algumas layers claramente definidas, completamente encapsuladas e previsíveis.

/my-page
  /shared
    send-feedback.ts
  /data
    get-something.ts
    send-something.ts
  /ui
    index.ts
    /header
      index.ts
      search-bar.ts
    /footer
      index.ts

React recomenda não aninhar

Se você ler a documentação do React sobre a estrutura de projeto recomendada, verá que React realmente recomenda não aninhar muito. A recomendação oficial é "considere limitar-se a um máximo de três ou quatro pastas aninhadas dentro de um único projeto". E essa recomendação é muito relevante para essa abordagem também: se seu package ficar muito aninhado, é um sinal claro de que você pode precisar pensar em splitting ele em packages menores. 3-4 níveis de aninhamento, na minha experiência, são suficientes até mesmo para features muito complicadas.

A beleza da arquitetura de packages, porém, é que você pode organizar seus packages com tanto aninhamento quanto precisar sem ficar preso a essa restrição - você nunca se refere a outro package por seu relative path, apenas por seu nome. Um package com o nome @project/change-setting-dialog que reside no path packages/change-settings-dialog ou está oculto dentro de /packages/product/features/settings-page/change-setting-dialog, será chamado de @project/change-setting-dialog independentemente de sua localização física.

Ferramenta de gerenciamento Monorepo

É impossível falar sobre multi-packages monorepo para sua arquitetura sem tocar pelo menos um pouco nas ferramentas de gerenciamento monorepo. O maior problema geralmente é o gerenciamento de dependências dentro dele. Imagine se alguns dos seus monorepo packages usam uma dependência externa, lodash por exemplo.

/my-feature-one
  package.json // este usa lodash@3.4.5
/my-other-feature
  package.json // este usa lodash@3.4.5

Agora o lodash lança uma nova versão, lodash@4.0.0, e você quer mover seu projeto para ele. Você precisaria atualizá-lo em todos os lugares ao mesmo tempo: a última coisa que você quer é que alguns dos packages permaneçam na versão antiga, enquanto outros usem a nova. Se você estiver no npm ou no antigo yarn, isso seria um desastre: eles instalariam várias cópias (não duas, várias) do lodash em seu sistema, o que resultaria em tempos maiores de instalação e build, e seus tamanhos de bundles disparando. Sem mencionar a diversão de desenvolver uma nova feature quando você está usando duas versões diferentes da mesma biblioteca em todo o projeto.

Não vou tocar no que usar se seu projeto for publicado no npm e de código aberto: provavelmente algo como Lerna seria o suficiente, mas esse é um tópico completamente diferente.

Se, no entanto, seu repositório for private, as coisas estão ficando mais interessantes. Porque tudo o que você realmente precisa para que essa arquitetura funcione é packages "aliasing", nada mais. Ou seja, apenas links simbólicos básicos que tanto o Yarn quanto o Npm fornecem por meio da ideia de workspaces. Parece com isso. Você tem o arquivo "root" package.json, onde você declara onde estão os workspaces (ou seja, seus packages locais):

{
    "private": true,
    "workspaces": ["packages/**"]
}

E então, da próxima vez que você executar yarn install, todos os packages do folder packages se tornarão packages "adequados" e estarão disponíveis no seu projeto por meio dos name deles. Esse é todo o monorepo setup!

Quanto às dependências. O que acontecerá se você tiver a mesma dependência em alguns packages?

/packages
  /my-feature-one
    package.json // este usa lodash@3.4.5
  /my-other-feature
    package.json // este usa lodash@3.4.5

Quando você executa yarn install, ele irá "hoist" (içar) esse package para o root node_modules:

/node_modules
  lodash@3.4.5
/packages
  /my-feature-one
    package.json // este usa lodash@3.4.5
  /my-other-feature
    package.json // este usa lodash@3.4.5

Esta é exatamente a mesma situação que se você declarasse lodash@3.4.5 apenas no root package.json. O que estou dizendo é, e provavelmente serei enterrado vivo pelos puristas da internet por isso, incluindo eu mesmo há dois anos: você não precisa declarar nenhuma das dependências em seus packages locais. Tudo pode ir para o root package.json. E seus arquivos package.json em packages locais serão apenas arquivos json muito leves, que especificam apenas os fields "name" e "main".

Configuração muito mais fácil de gerenciar, especialmente se você estiver apenas começando.

Estrutura do projeto React para scale: visão geral final

Huh, isso foi muito texto. E mesmo isso é apenas uma breve visão geral: muitas outras coisas podem ser ditas sobre o tópico! Vamos recapitular o que já foi dito, pelo menos:

Decomposition é a chave para scale com sucesso seu React app. Pense no seu projeto não como um "projeto" monolítico, mas como uma combinação de "features" independentes do tipo caixa-preta com sua própria API pública para os consumidores usarem. A mesma discussão de "monólito" vs "microservices" realmente.

Arquitetura Monorepo é perfeita para isso. Extraia suas features em packages; organize seus packages da maneira que melhor funciona para seu projeto.

Layers dentro de um package são importantes para dar a ele alguma estrutura. Você provavelmente terá pelo menos uma "data" layer, uma "UI" layer e uma "shared" layer. Pode introduzir mais, dependendo de suas necessidades, só precisa ter limites claros entre elas.

Estrutura hierárquica de um package é legal. Ela facilita a refatoração, força você a ter limites mais claros entre as layers e força você a dividir seu package em outros menores quando ele se torna muito grande.

Gerenciamento de dependências em um monorepo é um tópico complicado, mas se seu projeto for private, você não precisa se preocupar com isso. Apenas declare todas as suas dependências no root package.json e mantenha todos os packages locais livres delas.

Você pode dar uma olhada na implementação dessa arquitetura neste repositório de exemplo: https://github.com/developerway/example-react-project. Este é apenas um exemplo básico para demonstrar os princípios descritos no artigo, então não se assuste com packages pequenos com apenas um index.ts: em um app real, eles serão muito maiores.

Isso é tudo por hoje. Espero que você consiga aplicar alguns desses princípios (ou até mesmo todos eles!) aos seus apps e veja melhorias no seu desenvolvimento diário imediatamente! ✌🏼

Fonte

Artigo escrito por Nadia Makarevich.

Lógica de tail call optimization (TCO) sem TCO

doug-source — Fri, 28 Mar 2025 15:10:44 +0000

Como todos nós sabemos, existe pouca adoção de tail call optimization (TCO) dentro das JavaScript engines atualmente no mercado.

Mas como poderíamos então implementar uma lógica (que inicialmente usa recursão) sem estourar a callstack do navegador?

Até onde eu sei, existem duas maneiras de fazer isso.

Com uma técnica chamada trampoline (não explicarei nesse post)
Com generator functions (foco desse post)

Vou apenas elencar um exemplo de implementação e futuramente (não agora) vou explicar cada detalhe dessa abordagem.

A lógica abaixo soma, através de recursão, todos os elementos presentes dentro de um array:

function sum(nums) {
    if (nums.length === 0) {
        return 0;
    }
    return nums[0] + sum(nums.slice(1));
}

Esse código acima estoura a pilha de execução a partir de um determinado tamanho de array.

Dentro do Node (na versão v23.6.0), que usa V8 como engine e presente aqui em meu sistema operacional, esse estouro de pilha de execução aconteceu a partir de 15226 elementos.

Com function generators e sem recursão, separei em duas functions o trabalho necessário para conseguir executar essa lógica, podendo o array até ter mais elementos:

function makeGenerator() {
    "use strict";
    return function* (nums) {
        let acc = 0;
        for (let item of nums) {
            yield;
            acc += item;
        }
        return acc;
    }
}

function pickGeneratorReturn(gen) {
    let obj;
    do {
        obj = gen.next();
    } while(!obj.done);
    return obj.value;
}

Agora experimente executar a soma anterior, mas talvez com... digamos... 100000 elementos 🤯:

const list = Array.from({ length: 100000 }, (_, i) => i+1);
const result = pickGeneratorReturn(makeGenerator()(list));
console.log(result);

Legal, né?

Bebam água 🥤!

Até mais... 👋

De uma página para vários components

doug-source — Thu, 28 Nov 2024 16:31:25 +0000

Li esse trecho sobre componentização em um livro e achei muito interessante:

"O termo component-based development (CBD) é um pattern no qual a IU de uma determinada aplicação é dividida em vários "components". Dividir páginas grandes em pequenas unidades individuais reduz a complexidade da aplicação e ajuda o desenvolvedor a se concentrar no escopo e na responsabilidade individual de cada seção."

Fonte

Livro Vue.js 3 for Beginners escrito por Simone Cuomo.

Math.ceil vs Math.floor

doug-source — Tue, 12 Nov 2024 00:17:09 +0000

Volta e meia me deparo com chamadas dos métodos ceil e floor, pertencentes à Math. Ambos os métodos possuem a finalidade de arredondamento de um floating point number para um integer number. Porém, uma pergunta que sempre me surge, quase que de forma automática, é:

Afinal, existiria alguma forma de comparar visualmente a lógica dessas duas functions?

Bom... Deixe-me tentar.

Imaginemos que exista um gráfico no qual possamos colocar cada argumento passado para essas functions:

Math.ceil(num)

Tem a função de arredondar um número para o valor inteiro mais próximo, maior ou igual (>=) ao número atual.

num === 1.3

Olhando o número inserido no gráfico acima, qual seria o número inteiro mais próximo >= à 1.3? O número 2, é claro!

num === -2.001

Olhando o número inserido no gráfico acima, qual seria o número inteiro mais próximo >= à -2.001? Como estamos agora perante uma escala negativa, o próximo número inteiro >= é -2.

Math.floor(num)

Tem a função de arredondar um número para o valor inteiro mais próximo, menor ou igual (<=) ao número atual. Resumidamente funciona igual à Math.ceil, porém com sentido inverso no gráfico.

num === 1.3

Olhando o número inserido no gráfico acima, qual seria o número inteiro mais próximo <= à 1.3? O número 1, é claro!

num === -2.001

Olhando o número inserido no gráfico acima, qual seria o número inteiro mais próximo <= à -2.001? Como estamos agora perante uma escala negativa, o próximo número inteiro <= é -3.

Assim, analizando o sentido do arredondamento dessas functions e levando o gráfico em consideração, temos:

Lembrar de conceitos utilizando imagens (como a mencionada acima) costuma me auxiliar bastante na fixação deles. 😉

...

12 técnicas modernas de CSS para problemas de CSS mais antigos

doug-source — Fri, 06 Sep 2024 02:06:46 +0000

Nota: apenas traduzi o texto abaixo e postei aqui. As referências estão no fim deste artigo.

Descobrir técnicas modernas de CSS é uma das melhores maneiras de apimentar o processo geral de web design. Se você tem trabalhado com CSS, pode ter encontrado alguns layouts ou problemas de compatibilidade entre navegadores. Por exemplo, estilos CSS3 não funcionam com versões legadas do Internet Explorer. Ainda assim, há muitas instâncias em que queremos usar um recurso e descobrimos que ele não é suportado ou se comporta de forma diferente entre navegadores. Portanto, ao trabalhar em tecnologias de desenvolvimento web, o teste de compatibilidade de navegadores de sites e web apps também é importante.

No entanto, conforme as tecnologias da web evoluem, os desenvolvedores estão se esforçando para descobrir como lidar com outros problemas também. Por exemplo, alavancar outras bibliotecas para otimizar o tempo de carregamento de um site muito carregado ou tornar as tags div mais responsivas sem depender muito do Bootstrap. Com os desafios em evolução e aumentando, o CSS também evoluiu.

Neste tutorial avançado de CSS, discutiremos 12 técnicas modernas de CSS para superar problemas antigos que vinham com CSS.

Vamos começar com técnicas modernas de CSS!

Novo em CSS Selectors? Confira esta Ultimate CSS Selector cheat sheet para impulsionar sua carreira em web design.

1. CSS Selectors avançados

Entender como os CSS selectors funcionam é essencial se você planeja desenvolver um arquivo CSS reutilizável que pode ser usado para outras páginas ou componentes de IU. Caso esteja procurando um recurso valioso que forneça informações perspicazes sobre CSS Selectors, confira The Ultimate CSS Selectors Cheat Sheet.

Você já deve estar familiarizado com selectors baseados em classes, em ID e em elementos. Vamos dar uma olhada em alguns selectors avançados.

Universal Selector

Universal selectors podem ser usados em todos os elementos de um site. Por exemplo, se você quiser ter uma margin específica para todos os elementos em sua página, você tem que escrever –

* {
  margin: 1.5rem;
}

Attribute Selector

E se você quiser aplicar um style específico a certos elementos que têm atributos semelhantes, mas class names diferentes? Você pode usar attribute selectors.

[class*="component_"] {
    border: 2px solid blue;
}

Attribute selector aplicará uma border aos elementos com class name component_title e component_label.

Child Combinator

E se você quiser deixar o font size de um menu na navigation bar em negrito, mas o conteúdo nav for gerado dinamicamente? Eles não têm nenhuma CSS class específica. Você pode usar um child combinator.

.navigation-menu > ul > li > a {
    font-weight: bold;
}

Pseudo Classes

Você já viu uma tabela com linhas alternadas tendo uma cor diferente? Quer saber como podemos fazer isso com apenas algumas linhas de CSS? A resposta é pseudo-classes. Vamos dar uma olhada no código.

tbody tr:nth-child(odd) {
    background-color: green;
}

Ele aplicará um background verde às linhas ímpares da tabela.

Em vez de "ímpar" ou "par", você também pode usar properties como n+1 ou 3n+1 para aplicar properties diferentes a linhas diferentes.

2. Substituindo o antigo grid system

Quando chegou aos desenvolvedores, o bootstrap grid foi benéfico. Ele resolveu o propósito de ter containers responsivos uniformemente distribuídos em dispositivos de diferentes resoluções. Mas com o tempo, os desenvolvedores precisaram de uma solução alternativa. Não somos mais obrigados a usar uma biblioteca pesada apenas para grids.

Técnicas modernas de CSS como grid nos deram uma solução simplificada. Vamos descobrir como.

$minColumnWidth: 10rem;

.grid {
    display: grid;
    grid-template-columns: repeat(auto-fit, minmax($minColWidth, 1fr));
    grid-gap: 2rem;

    & + .grid {
        margin-top: $gridGap;
    }
}

Então, o que fizemos aqui?

Primeiro, definimos uma width mínima para grid elements.

Em grid-template-columns, usamos a repeat function para que o CSS aplique os mesmos parâmetros a cada column. Além disso, usamos auto-fit em vez de um número. O motivo é que as columns agora terão a mesma width, independentemente de quantas columns você usar, elas se esticarão e preencherão o espaço disponível.

Também usamos a minmax() function para definir a width máxima para cada column e mantivemos 1fr como o valor máximo. Isso garante que o conteúdo preencha uma coluna até o espaço total disponível.

Por fim, adicionamos um gap e uma regra opcional para aplicar o mesmo valor entre containers consecutivos.

O resultado?

Só há uma desvantagem. Para mais de três columns, em algumas viewports, você pode encontrar uma "orphan column".

Você pode resolver o problema com media queries, mas precisa escrever muitos códigos para vários breakpoints.

3. Mantendo o height uniforme dos elementos

Houve um tempo em que usávamos o jQuery para calcular para garantir que o height dos containers fosse igual. Isso foi quando o conteúdo dos dois containers não era igual, mas queríamos tornar o height deles igual para o UX.

Mas como as técnicas modernas de CSS tornaram o processo mais simples? Bem, usando o grid system.

/* Parent container */
.parent {
    display: grid;
    grid-auto-flow: column;
}
/* Child elements */
.child {
    height: 100%;
}

Ao alternar o grid-auto-flow para row ou column, podemos ter containers de width ou height uniformes.

Também podemos usar a mesma funcionalidade com código mais simples usando CSS flexbox.

/* Parent elements */
.parent {
    display: flex;

    /* Child elements */
    .child {
        height: 100%;
    }
}

Então, qual é melhor? A resposta é que ambos têm sua parcela igual de vantagens de uso. Se você quer uma solução para resolver apenas o problema de elementos com height igual, flexbox é a melhor opção. No entanto, no flexbox, os elementos podem não ter width igual.

O Grid, no entanto, pode lidar com elementos com width igual, se for isso que você precisa. Além disso, se você quiser ter um número máximo de columns em cada linha, grid pode lidar com a matemática. Mas se você usar flexbox, precisará definir um cálculo para esse propósito.

4. Melhorando a experiência do usuário com Smooth Scrolls

Com sticky headers, links "de volta ao topo" não são muito usados hoje em dia, mas houve um tempo em que estavam na moda. A ideia era criar um link que permitisse ao usuário rolar de volta para o topo do site. Vamos descobrir como desenvolver links "de volta ao topo" usando técnicas modernas de CSS.

Vamos criar o conteúdo primeiro.

<header id="header">Title</header>
<main>
    <article>
        <!-- conteúdo vai aqui -->
    </article>
    <!-- Link "De volta ao Topo" -->
    <div class="back-to-top-wrapper">
        <a
            href="#header"
            class="back-to-top-link"
            aria-label="Go Back to Top"
        >
            Top
        </a>
    </div>
</main>

Primeiro, adicionaremos smooth scrolling à nossa página.

html {
    scroll-behavior: smooth;
}

Então, estilizaremos o link "de volta ao topo" conforme nossa preferência. Você também pode adicionar um SVG icon bacana em vez de estilização manual.

Agora, é hora de escolher como sua rolagem se comportará. Defina um scroll length.

$scrollLength: 100vh;

Em seguida, no wrapper, defina o scroll value para o scroll length predefinido.

.back-to-top-wrapper {
    position: absolute;
    top: $scrollLength;
}

Adicione os styles necessários ao link "de volta ao topo". Lembre-se de usar position-sticky para mantê-lo em uma posição específica.

.back-to-top-link {
    /*
     * usando 'fixed' como fallback quando `sticky` não for suportado
     */
    position: fixed;
    position: sticky;
    /*
     * atinge o posicionamento desejado dentro da viewport
     * em relação ao topo da viewport quando `sticky` assume
     * o controle, ou sempre que o fallback `fixed` for usado
     */
    top: calc(100vh - 5rem);
    // ... outros styles
}

Pronto, temos o resultado desejado.

5. Melhorando a acessibilidade do seu site adicionando Alternate: focus

Acessibilidade é um recurso essencial para qualquer site, pois é obrigatório seguir as diretrizes WCAG. Mas o que significa acessibilidade? Significa que seus sites devem ser acessíveis a todos, especialmente para pessoas com deficiência.

Frequentemente, removemos :focus outlines em buttons ou links para nos livrar do style nativo. No entanto, ao fazer isso, deixamos de fornecer um "alternate focused stage". Como resultado, as pessoas que usam o teclado para navegar em um site não conseguem detectar o elemento atualmente em foco. É uma violação direta de acessibilidade.

Podemos sentir que o :focus style default do navegador não fica bem nos elementos atraentes que você manteve em sua página. No entanto, é o ideal seria adicionar algumas linhas de código para um "alternate focus style". Por exemplo, suponha que temos um button.

Você pode adicionar –

button:focus {
    outline: max(1px, 0.1em) solid currentColor;
    outline-offset: 0.25em;
}

Aqui, estamos considerando currentColor como a theme color da sua página. No seu caso, é green.

Usando outline-offset, podemos ajustar o espaçamento do outline do elemento.

Pronto, o "focused stage" não match à cor do button? Você também deve verificar as principais ferramentas para testes de acessibilidade.

6. CSS Font Rules e criação de uma Typography Scale fluida

A tipografia é a melhor maneira de melhorar a aparência de qualquer webpage simplista. CSS nos ajuda a desenvolver uma base de type scales essenciais. Vamos descobrir como.

font-unit recomendada

Está confuso sobre o que usar? %, rem, em ou px? A primeira coisa que você precisa fazer ao definir a tipografia é — esqueça o px. Ele não "scale" em proporção quando o usuário aumenta ou diminui o zoom no navegador. A unidade recomendada é rem.

O valor default de 1rem é 16px, e os font sizes definidos em rem permanecem consistentes quando os usuários aumentam o zoom no navegador.

em é proporcional à font-size rule do ancestral mais próximo de um elemento. Ele só pode ser usado quando você deseja o comportamento do child de spacing relativo ao parent element.

% tem comportamento quase semelhante ao em. No entanto, quando você precisa de dimensionamento relativo, em é mais preferível.

Confira o Nikola Testing - Teste seus sites baseados na estrutura CSS Nikola em mais de 3.000 navegadores diferentes para desktop e dispositivos móveis.

Prevenindo Text Overflow

Evitar text-overflow é uma boa maneira de proteger seu site do futuro. Ele garante que, se algum texto em um container aumentar no futuro, o texto não se mova para além do container ou de sua borda.

p,
li,
h1,
h2,
h3,
h4 {
    // Auxilia a evitar o overflow de palavras/nomes/URLs longas
    word-break: break-word;
}

Tipografia responsiva

Se você selecionou um font size grande globalmente, poderá ter overflow issues em dispositivos pequenos. Para resolver esse problema, temos um fluid type. Isso significa definir um valor de font size que se ajusta de acordo com a viewport, assim como imagens responsivas. Você pode usar um código para calcular o tamanho mínimo e o tamanho base.

font-size: unquote(
    "min(max(#{$fluid-min}rem, #{$fluid-scaler}), #{$level-size})"
);

Ou você pode usar vw (viewport width) como font unit.

Além da tipografia responsiva, você pode testar a responsividade do web design usando o LT Browser.

Usando LT Browser, uma ferramenta de teste responsivo que permite testar sites para teste responsivo em mais de 50 viewports de dispositivos pré-construídas.

LT Browser vem com recursos incríveis como Sincronizar dispositivos em paralelo em várias viewports de dispositivos para obter uma melhor visualização do conteúdo de mídia e objetos. O recurso de network throttling pode ajudar você a testar sites em diferentes condições de rede, de parâmetros baixos a altos, como online, 3G lento, 3G rápido e até offline.

LT Browser é equipado com todas as ferramentas e recursos essenciais que desenvolvedores e designers precisam em seu workflow diário. Para saber mais sobre os recursos do LT Browser, você pode consultar nosso blog: 11 razões pelas quais os desenvolvedores devem usar o LT Browser.

O vídeo passo a passo abaixo ajudará você a começar a usar o LT Browser!

7. Styling Radio Buttons

Desenvolvedores precisam de um radio button com style customizado, pois o HTML radio button default aparece de forma diferente em navegadores diferentes. A seguir está a aparência dos radio buttons no Firefox em execução no Mac.

E é assim que eles ficam no Safari.

Não só isso, radio buttons nativos não podem ser scaled com o font-size.

Vamos verificar a solução para criar um radio button uniforme que apareça da mesma forma em todos os navegadores e seja scaled consistentemente com o font-size da label.

Vamos começar com o HTML primeiro.

<label class="radio radio-gradient">
    <span class="radio-input">
        <input type="radio" name="radio">
        <span class="radio-control"></span>
    </span>
    <span class="radio-label">Option 1</span>
</label>
<label class="radio radio-before">
    <span class="radio-input">
        <input type="radio" name="radio">
        <span class="radio-control"></span>
    </span>
    <span class="radio-label">Option 2</span>
</label>

Agora, vamos ao CSS. Estamos usando SCSS para facilmente theming os radio buttons.

Primeiro, criaremos uma color variable customizada.

:root {
    --color: green;
}

Em seguida, estamos usando um universal selector para resetting o box-sizing method. Ele incluirá border e padding no cálculo do tamanho final de qualquer elemento.

*,
*:before,
*:after {
    box-sizing: border-box;
}

Adicionamos uma CSS class .radio às labels. Estamos usando grid-gap para adicionar algum espaçamento entre o button e as labels. Também usaremos :focus-within e transform para que o tamanho da label aumente quando essa opção específica estiver em foco.

.radio {
    display: grid;
    grid-template-columns: min-content auto;
    grid-gap: 0.5em;
    font-size: 2.25rem;
    color: var(--color);

    &:focus-within {
        .radio-label {
            transform: scale(1.05);
            opacity: 1;
        }
    }
}

Ajustaremos a line-height, adicionaremos uma transition e também reduziremos a opacity da label quando a opção não estiver em foco.

.radio-label {
    line-height: 1;
    transition: 180ms all ease-in-out;
    opacity: 0.8;
}

Adicionaremos um display-flex ao button que encapsula o "control" customizado e o input nativo.

Também usaremos um box-shadow duplo no focused stage e garantiremos uma diferença entre o button base e o focused stage.

.radio-input {
    display: flex;

    input {
        opacity: 0;
        width: 0;
        height: 0;

        &:focus + .radio-control {
            box-shadow: 0 0 0 0.05em #fff, 0 0 0.15em 0.1em currentColor;
        }
    }
}

Adicionando um style quando o button está no "checked stage".

.radio-gradient input:checked + .radio-control {
    background: radial-gradient(
        currentcolor 50%, rgba(255, 0, 0, 0) 51%
    );
}

Criando o :before element, para animar o button quando ele estiver unchecked.

.radio-before {
    .radio-control {
        display: grid;
        place-items: center;
    }

    input + .radio-control::before {
        content: "";
        width: 0.5em;
        height: 0.5em;
        box-shadow: inset 0.5em 0.5em currentColor;
        border-radius: 50%;
        transition: 180ms transform ease-in-out;
        transform: scale(0);
    }
    input:checked + .radio-control::before {
        transform: scale(1);
    }
}

Por fim, adicionando o style ao radio button e ao body.

.radio-control {
    display: block;
    width: 1em;
    height: 1em;
    border-radius: 50%;
    border: 0.1em solid currentColor;
    transform: translateY(-0.05em);
}
body {
    min-height: 100vh;
    display: grid;
    place-content: center;
    grid-gap: 2rem;
    padding: 1rem;
}

Aqui está o output:

8. Mantendo a bottom position do footer

Embora com Single page applications, esse problema não surja tanto, se você estiver criando uma webpage estática, você pode frequentemente encontrar seu footer flutuando para cima.

Podemos nos livrar desse problema com dois métodos.

Grid

Vamos dar uma olhada no código.

body {
    min-height: 100vh;
    display: grid;
    grid-template-rows: auto 1fr auto;
}

Aqui, mantivemos um height mínimo do body. Depois disso, usamos grid-template-rows para espaçar o conteúdo corretamente. O método usa uma unidade fracionária que calcula o espaço disponível e o distribui para várias linhas. Assim, ele preencherá todo o espaço disponível entre o header e o footer.

Flexbox

Usando flexbox, o método é mais simples.

body {
    min-height: 100vh;
    display: flex;
    flex-direction: column;
}

Primeiro, com min-height, garantimos que o body se estende até a height total da tela. Então, definir uma flex-direction retém block elements empilhados e mantém o comportamento do document normal.

9. Images animadas

Quando o CSS não era muito modernizado, os usuários tinham dificuldade para animar image captions e image sizes usando jQuery e position:absolute.

No entanto, hoje em dia, com algumas linhas de código, podemos animar captions e disparar as animações ao passar o mouse sobre uma image. Vamos dar uma olhada no código.

.image-caption {
    /* ... styles existentes */
    transition: transform 500ms ease-in;
    will-change: transform;
}
/*
 * A CSS property transition ajuda a animar a caption. 
 * Podemos disparar a animação ao passar o mouse usando -
 */
.image:hover {
    .image-caption {
        transform: translateY(0);
    }
}

Ele resolve o problema com o mouse hovering. Mas e se alguém usar um teclado para navegar em uma webpage? Nesse caso, podemos usar o focus em vez do hover.

.image:focus {
    outline: none;
}
.image:hover,
.image:focus {
.image-caption {
    transform: translateY(0);
}

10. Uso avançado de Border Radius e Box Shadow

Desenvolvedores hoje em dia não precisam lidar com o incômodo de criar boxes com cantos arredondados para containers que eles querem tornar arredondados. Graças à css property border-radius que o CSS3 nos deu. Por exemplo:

.element {
    border-radius: 20% 50%;
}

Eu sei, é uma forma estranha. Mas isso foi feito para demonstrar o uso de border-radius; se você aplicar valores calculados, você pode dar a um container qualquer forma que você quiser. Por exemplo –

.element {
    border-radius: 3vw 4vw 8vw 2vw;
}

Podemos usar valores percentuais que são relativos ao tamanho do elemento. Unidades relativas como vw (unidades de viewport) são úteis se você quiser manter a consistência. Elas parecem menores no celular e maiores no desktop, mas mantêm um formato redondo consistente.

Outra propriedade interessante que nos ajuda a adicionar uma experiência de usuário agradável e relaxante aos elementos da nossa página é box-shadow. Normalmente usamos box shadow para adicionar uma dica de elevação a elementos como cards ou buttons. Por exemplo:

.element {
    box-shadow: 3px 4px 5px 0px rgba(0, 0, 0, 0.38);
}

Aqui, temos um offset horizontal de 3px e um offset vertical de 4px. Também temos um blur radius de 5px, nenhum spread radius e color shadow acinzentado. Você pode ajustar os valores conforme sua escolha para melhorar a aparência do box.

Uma feature exclusiva do box-shadow é que você pode adicionar várias camadas. Por exemplo:

.element {
    box-shadow: 2px 4px 0 4px yellowgreen,
      4px 8px 0 8px yellow,
      8px 10px 0 12px red;
}

Também temos um image hack interessante. Quer saber como adicionar efeito de vinheta a uma image usando box-shadow? A resposta é, usando inset shadows.

.image-container {
    width: 30vmin;
    height: 30vmin;
    box-shadow: inset 0 0 4vmin 3vmin rgba(0, 0, 0, 0.5);
}

11. Mantendo seus elementos centralizados

Antes, se precisássemos manter um elemento no centro de uma página, tínhamos que usar absolute positions e definir valores de left, right, top e bottom. Bem, esses dias acabaram. As técnicas modernas de CSS nos fornecem uma solução direta que ajuda a manter uma posição centralizada em várias resoluções.

Para manter um elemento centralizado horizontal e verticalmente, temos que adicionar apenas duas propriedades ao elemento.

.element {
    display: grid;
    place-content: center;
}

Se você quiser usar flexbox para manter a consistência entre os outros elementos do flexbox na página, precisará de uma linha extra de styling.

.element {
    display: flex;
    align-items: center;
    justify-content: center;
}

Agora, e se você quiser colocar um elemento alinhado centralmente em qualquer eixo específico? Bem, nesse caso, você tem que remover a CSS property display. Para alinhamento centralizado verticalmente, você tem que escrever:

.element {
    /* ... */
    align-content:center;
    /* ... */
}

Aqui está o resultado:

Por outro lado, para manter um elemento centralizado horizontalmente, em vez de align-content, você deve usar justify-content.

.element {
    /* ... */
    justify-content:center;
    /* ... */
}

A solução mencionada acima foi para grid items. Para flex items, o código muda um pouco.

Para alinhamento vertical, você tem que escrever:

.element {
    /* ... */
    justify-content: center;
    flex-direction: column;
    /* Para alinhamento horizontal, você precisará de */
    justify-content: center;
    /* ... */
}

12. Desenhando Formas Usando CSS

As técnicas modernas de CSS nos poupam do trabalho de usar scripts para desenhar objetos. Agora temos alguns métodos úteis para criar formas CSS básicas. Vamos descobrir como criar triângulos CSS.

Usando Borders

Usar a CSS property border pode nos ajudar a criar triângulos. Vamos começar com o container primeiro.

.triangle {
    border-style: solid;
    border-color: transparent;
}

Agora, vamos usar a CSS property border-width e dar uma cor ao lado esquerdo da borda.

.triangle {
    border-style: solid;
    border-color: transparent;
    /* top | right | bottom | left */
    border-width: 7px 0 7px 10px;
    border-left-color: blue;
}

O resultado é mostrado abaixo:

Podemos embaralhar os valores top, right, bottom e left de border-width para alterar a orientação do triângulo.

Usando linear-gradient

Podemos usar isso junto com a CSS property background-image.

Primeiro de tudo, vamos criar um container, dar dimensões e evitar background-repeat.

.triangle {
    width: 8em;
    height: 10em;
    background-repeat: no-repeat;
}

Agora, vamos adicionar nossos gradients. Isso dará uma cor azul à metade do container.

Após adicionar os dois gradients, a forma se torna como um triângulo espelhado no container.

.element {
    background-image: linear-gradient(
      32deg, blue 50%, rgba(255, 255, 255, 0) 50%
    ),
    linear-gradient(
        148deg, blue 50%, rgba(255, 255, 255, 0) 50%
    );
}

Agora, vamos tentar fazer o box parecer um triângulo. Vamos mudar o background-size. Nosso triângulo terá 100% de width, mas apenas metade da height.

.element {
    /* ... */
    background-size: 100% 50%;
    /* ... */
}

Finalmente, para evitar overlapping, temos que adicionar uma background position, já que a position default de ambos os gradientes é 0 0.

.element {
    /* ... */
    background-position: top left, bottom left;
    /* ... */
}

Então, nossa forma finalmente parece um triângulo. No entanto, há uma desvantagem nesse método. A forma não é responsiva. Se a proporção mudar, talvez precisemos recalcular os graus.

Concluindo!

O CSS está evoluindo em um ritmo rápido. Desenvolvedores estão criando CSS-only libraries para depender menos de scripts e reduzir o tamanho de um site, tornando-o mais amigável ao SEO. Esperamos que este tutorial avançado de CSS seja útil para você explorar como as técnicas modernas de CSS nos ajudam a resolver alguns problemas comuns que os desenvolvedores geralmente enfrentam e dependem de scripts para resolver. Informe-nos se você conhece ou usou alguma outra técnica moderna de CSS para resolver problemas relacionados ao design.

Fonte

Artigo escrito por arnabroychowdhury.

Remover background de uma image usando apenas CSS

doug-source — Wed, 04 Sep 2024 17:53:36 +0000

Nota: apenas traduzi o texto abaixo e postei aqui. As referências estão no fim deste artigo.

Neste blog post para iniciantes, aprenderemos como remover o background de uma image usando apenas CSS, especificamente a CSS property mix-blend-mode. Esta técnica é útil para criar efeitos visuais interessantes e melhorar o desempenho do seu site, reduzindo a necessidade de imagens editadas.

Por que esse truque é importante?

Ao baixar um arquivo .png, você pode esperar que ele tenha um transparent background. No entanto, nem sempre é esse o caso. Às vezes, um arquivo .png pode ter uma background color sólida, como white ou black.

Nesses casos, você pode usar a CSS property mix-blend-mode para remover a background color sólida e criar a aparência de um transparent background.

O que é mix-blend-mode?

mix-blend-mode é uma CSS property que define como o conteúdo de um elemento deve se misturar com o conteúdo do parent element e seu background. Com isso, você pode criar misturas e cores agradáveis para partes do conteúdo de um elemento, dependendo de seu background direto.

Confira este artigo.

Para remover o background de uma image, usaremos a CSS property mix-blend-mode com o valor multiply. Este valor removerá as partes mais brancas da image. Aqui está um exemplo:

Imagem dentro de div:

Image dentro da div com mix-blend-multiply:

Da mesma forma, podemos escrever isso com TailwindCSS.

Neste tutorial, aprendemos como remover o background de uma image usando apenas CSS e a property mix-blend-mode. Essa técnica permite maior flexibilidade de design, melhor desempenho e melhores benefícios de SEO em comparação ao uso de imagens editadas. Com esse conhecimento, você pode criar efeitos visuais interessantes em seu site e melhorar a experiência geral do usuário.

Fonte

Artigo escrito por jeetvora331.

Como funciona o clear em CSS?

doug-source — Wed, 04 Sep 2024 17:52:41 +0000

Nota: apenas traduzi o texto abaixo e postei aqui. As referências estão no fim deste artigo.

A CSS property clear funciona com relação à CSS property float. Ela define se um elemento deve ser movido abaixo dos elementos "floating" que o precedem.

Vamos entender isso com a ajuda de um exemplo.

Consideraremos quatro blocos vermelho, amarelo, azul e verde que serão adicionados um após o outro e todos eles serão colocados no mesmo nível.

Então faremos cada elemento "float" para a "left" um por um, o que significa que eles serão movidos um nível acima de sua posição inicial. Isso permitirá que outros elementos "não-floating" wrap (quebrem) o elemento floating.

Nota - O próximo block ocupará a posição do floating block, por isso não é visível. Quando mudamos a dimensão do próximo block, observamos que ele é coberto com o floating block que está presente uma camada acima dele.

Depois disso, aplicaremos clear:left ao block azul, o que significa que nenhum elemento estará floating à left do block azul.

Com a ajuda da CSS property clear podemos especificar qual lado dos floating elements não pode executar o float. Ela define ou retorna a posição com relação aos floating objects.

Valores aceitos na CSS property clear


.element {
    clear: none;
    clear: left;
    clear: right;
    clear: both;
    clear: inline-start;
    clear: inline-end;

    clear: inherit;
    clear: initial;
    clear: revert;
    clear: revert-layer;
    clear: unset;
}

Abaixo segue o código dos exemplos acima mostrados:

HTML:

<div class="wrapper">
    <div class="red block"></div>
    <div class="yellow block"></div>
    <div class="blue block"></div>
    <div class="green block"></div>
</div>

CSS:

.wrapper{
    height:100vh;
    padding: 30px;
    text:center;
    background: #3A3B3C;
}
.block {
    height:40px;
    width:40px;
    border-radius: 4px;
}
.red {
    background: #CB6D51;
    float:left;
}
.yellow {
    background:#FBE7A1;
    float: left;
}
.blue {
    background: #3090C7;
    float: left;
    clear:both;
}
.green {
    background: #2E8B57;
    float: left;
}

Tentei cobrir o funcionamento da CSS property clear usando um exemplo básico para melhor compreensão. Por favor, compartilhe seus exemplos e sinta-se à vontade para adicionar a este post 😊.

Bom aprendizado!👩🏻‍💻

Fonte

Artigo escrito por Jasmin Virdi.

Como me tornei melhor com CSS

doug-source — Wed, 04 Sep 2024 17:51:36 +0000

Nota: apenas traduzi o texto abaixo e postei aqui. As referências estão no fim deste artigo.

Olá a todos 👋, hoje quero compartilhar com vocês uma (de muitas) coisas que fiz que fizeram o CSS funcionar para mim.

Quando comecei a aprender CSS, queria colocar o que tinha aprendido em prática. Mas sou péssimo em projetar coisas, então, embora quisesse fazer alguns layouts e designs com CSS, estava sem ideias. Olhando para trás agora, talvez eu devesse ter escolhido um site e feito um clone do design e layout 🤷, mas acho que, como iniciante, foi um pouco intimidador.

Então, como consegui fazer isso?

Um dia, vi um vídeo no YouTube em que os desenvolvedores estavam desafiando uns aos outros para algo chamado CSS Battle. CSS Battle é um site que tem várias "Artes" que são projetadas puramente usando CSS, eles fornecem a color palette para você e tudo o que você precisa fazer é recriar o design com o mínimo possível de caracteres.

Pensei, parece muito divertido, gosto de um bom quebra-cabeça/desafio, então fiz a tentativa. Eu não estava muito preocupado em obter a pontuação mais alta ou usar o menor número de caracteres, eu só queria escrever algum CSS.

Lembro que passei o dia inteiro naquele site, tentando recriar designs diferentes (CSS Art?). Acho que aprendi muitas coisas novas sobre positioning, pseudo-elements, transformation e outras CSS properties que nunca tinha visto antes. Mas acho que o que me manteve naquele site foi eu ter tentando obter 100% de correspondência aos designs (isso nunca aconteceu 😥).

Eu recomendaria a qualquer pessoa que esteja lutando para encontrar um método para fazer o CSS funcionar, que experimente o CSS Battle. Ainda tenho as "técnicas" que aprendi quando resolvi o CSS Battle nos meus projetos hoje.

Se você chegou até aqui, obrigado por ler, aqui vai um grande coração para você, criado usando uma div e pseudo-elements.

HTML:

<div></div>

CSS:

body {
    display: grid;
    place-items: center;
    height: 100vh;
    background: #333;
}

div {
    width: 200px;
    height: 300px;
    position:relative;
}

div::before, div::after {
    content: "";
    height: 100%;
    width: 90%;
    background: #DA0037;
    position: absolute;
    border-radius: 200px 200px 0 0;
}
div::before{
    left: -50px;
    transform: rotate(-45deg);
}
div::after {
    left: 35px;
    transform: rotate(45deg);
}

Abaixo segue o resultado:

Você já tentou o CSS Battle antes? O que você acha dele?

Se quiser entrar em contato comigo, sinta-se à vontade para me contatar no Twitter.

Fonte

Artigo escrito por Tanwa Sripan.

Como funciona @import em CSS? Quais são os prós e os contras. 🤔

doug-source — Mon, 05 Aug 2024 05:11:26 +0000

Nota: apenas traduzi o texto abaixo e postei aqui. As referências estão no fim deste artigo.

Todos nós devemos ter usado @import em nossos arquivos CSS para importar uma stylesheet dentro de outra stylesheet. Ao trabalhar em grandes projetos, frequentemente utilizamos imports para usar os mesmos styles em diferentes views.

A declaração @import tem alguns prós e contras relacionados a ela. Vamos primeiro discutir como funciona a importação usando o <link> element no arquivo HTML.

Pessoalmente, prefiro usar mídia em vez de texto para entender quaisquer conceitos e também gosto de usá-los em meus artigos. 😅

Então, vamos tentar entender a diferença entre usar @import e <link> element para carregar arquivos CSS seguido dos prós e contras da declaração @import.

Funcionamento da declaração @import

No exemplo acima, podemos ver que a importação de stylesheets entre si cria um gráfico de dependência. Devido a esta árvore de dependências, o arquivo css base, que é homeview.css, é baixado primeiro e, em seguida, os arquivos css dependentes são baixados, que são button.css e form.css.

Funcionamento do <link> element

Quando stylesheets são carregadas usando link elements, elas são baixadas ao mesmo tempo, ou seja, o navegador pode baixar todas essas stylesheets em paralelo.

Já cobrimos a principal diferença entre as duas abordagens, agora vamos nos concentrar nos prós e contras da declaração @import.

Prós de usar CSS @import

Economiza tempo na abordagem de copiar e colar o mesmo código em cada arquivo ou adicionar links.
Bom para construir projetos organizacionais de médio a grande porte.
Crie o arquivo CSS primário e importe outros arquivos, como typography ou images. Essa forma de gerenciar arquivos CSS é simples, mas eficaz e ajuda a manter uma boa estrutura do projeto.

Contras de usar CSS @import

O único aspecto negativo que vem com a declaração @import é aumentar o tempo de carregamento da página se não for usado durante o processo de build. À medida que avança e lê os imports e depois os aplica. Embora a diferença de tempo seja muito pequena, pode impactar seu search ranking, onde os bots usam o tempo de carregamento da página para calcular o ranking.

Tentei cobrir resumidamente todos os pontos principais de @import que definem o fluxo e o funcionamento da declaração CSS. 😊

Deixe-me saber se perdi alguma coisa 😉

Feliz aprendizado! 👩‍💻

Fonte

Artigo escrito por Jasmin Virdi.

A diferença entre Pseudo-Classes e Pseudo-Elements em CSS

doug-source — Mon, 05 Aug 2024 02:53:10 +0000

Nota: apenas traduzi o texto abaixo e postei aqui. Diferente do artigo original, inseri aqui os códigos dos exemplos do codepen. As referências estão no fim deste artigo.

Em CSS, pseudo-classes e pseudo-elements são dois tipos de palavras-chave que você pode combinar com selectors. Elas são usados para atingir o estado do elemento ou partes específicas de um elemento.

Neste artigo, exploraremos as diferenças entre os dois, juntamente com seu histórico e melhores práticas.

Sintaxe

Os dois pontos simples : referem-se a pseudo-classes
Os dois pontos duplos :: referem-se a pseudo-elements

Pseudo-Classes vs Pseudo-Elements

Pseudo em si significa falso, irreal ou fake. O prefixo pseudo-, é usado para referenciar classes ou elements que não são "reais". O termo "não real" neste contexto significa não um DOM element (Document Object Model), mas sim um elemento virtual criado para propósitos de estilo.

Para formar uma definição melhor, vamos discutir a diferença entre pseudo-classes e pseudo-elements com mais detalhes.

O que são Pseudo-Classes em CSS?

Pseudo-classes (:) são usadas principalmente para estilizar um elemento que está sob vários estados. Ao se referir ao estado, isso inclui a condição ou comportamento do usuário, por exemplo, hover, active, focus ou disabled. Os estados geralmente envolvem interação do usuário.

Por exemplo, podemos direcionar todos os links para ter uma text color lavender quando o usuário passar o mouse sobre o link.



a:hover {
    color: lavender;
}

Inspecione o DevTools de seu browser e você encontrará outros exemplos de estado. Aqui você também pode testar e debugar styles aplicados com base no estado (e a pseudo-class relacionada usada) alternando-os entre ligado e desligado.

Existem mais de 50 tipos de pseudo-classes, então eu recomendo fortemente que você analise todas as possibilidades.

Teste o exemplo de código abaixo, inspecione as pseudo-classes e tente adicionar uma nova.



<main class="container">
    <div>
        <p>Interactive</p>
        <button class="button">
            Submit
        </button>
    </div>
    <div>
        <p>Disabled</p>
        <button class="button" disabled>
            Submit
        </button>
    </div>
</main>



* {
    box-sizing: border-box;
    font-family: inherit;
    font-size: inherit;
    font-style: inherit;
}
body {
    background: #1D1F21;
    font-family: Inter, sans-serif; 
    font-size: 16px;
    font-style: normal;
    font-size: 1.75em;
    color: #ede7f6;
}
.container {
    height: 100vh;
    display: flex;
    justify-content: center;
    align-items: center;
    gap: 2em;
}
.button {
    background: #553285;
    padding: .5em 1em;
    border: none;
    border-radius: 4px;
    color: #ede7f6;
}

/* PSEUDO-CLASSES */

.button:hover {
    background: #7B52AB
    cursor: pointer;
}

.button:active {
    background: #9768D1;
}

.button:disabled {
    opacity: 0.5;
    cursor: not-allowed;
    pointer-events: none;
}

/* 
    Teste algumas outras pseudo-classes abaixo.

    selector:pseudo-class {
        // insira style aqui
    }
*/

Pseudo-Classes funcionais

Outra variação do tipo de pseudo-class é a pseudo-class funcional. Essas chamadas de function recebem um parâmetro de uma lista de selectors para match aos elementos.

Ao contrário de outros tipos de pseudo-classes que miram estados estáticos, como hover, essas podem mirar dinamicamente events e interações do usuário.



:is()
/* A pseudo-class matches-any realiza o match de qualquer elemento que match a qualquer um
dos selectors na lista fornecida. */

:not()
/* A pseudo-class de negação, ou matches-none, representa qualquer elemento 
que não seja representado por seu argumento. */

:where()
/* A pseudo-class de ajuste de especificidade realiza o match de qualquer elemento que
match a qualquer um dos selectors na lista fornecida sem adicionar nenhum 
peso de especificidade. */

:has()
/* A pseudo-class relacional representa um elemento se qualquer um dos 
selectors relativos match quando ancorado ao elemento attached. */

recurso

O que são Pseudo-Elements em CSS?

Pseudo-elements (::) são usados para estilizar partes específicas de um elemento. Eles podem ser usados para atingir a primeira letra ou a primeira linha. Ou podem ser usados para inserir conteúdo antes ou depois do elemento.

Vale a pena se familiarizar com este index de pseudo-elements para aprender mais sobre as palavras-chave disponíveis.

Como exemplo, para criar uma primeira letra grande de um parágrafo, você pode fazer isso usando first-letter assim:



p::first-letter {
    font-size: 9em;
}

Outro exemplo comum de um pseudo-elements é usar ::before ou ::after para inserir conteúdo antes ou depois do elemento alvo.

Teste o exemplo de código abaixo para ver como você pode usar ::before e ::after para criar linhas antes e depois de um elemento de texto.



<h1>Element</h1>



html {

    font-family: Lato, sans-serif;

    background: linear-gradient(to bottom right, #c4a3ff, #96c2ff);

    height: 100%;

}

h1 {

    display: flex;

    align-items: center;

    justify-content: center;

}

/* PSEUDO-ELEMENTS */

h1::before,

h1::after {

    content: "";

    height: 3px;

    background: black;

    flex: 1;

    margin: 0.2em;

}

A diferença entre : e :: em CSS

Como lição, lembre-se de que há uma diferença fundamental entre dois pontos simples e dois pontos duplos. Mais importante ainda, : refere-se a pseudo-classes e :: refere-se a pseudo-elements.

História dos ::

Historicamente, havia apenas um único dois-pontos : para definir pseudo-classes e pseudo-elements. A notação :: foi introduzida com CSS3 como uma forma de diferenciar os dois.

Pseudo-elements e pseudo-classes são conceitos relacionados que fornecem diferentes maneiras de estilizar um elemento. Como resultado, a ligeira variação na sintaxe entre eles é lógica.

Usar apenas a sintaxe de dois-pontos não é recomendado para ambos, pois se tornou obsoleto. Os navegadores ainda aceitarão : para ambos atualmente, por motivos de compatibilidade com versões anteriores. Como é possível encontrar qualquer uma das sintaxes, entender o contexto histórico em torno disso é benéfico.

Melhores práticas quando usar : vs ::

A melhor prática ao escolher qual sintaxe de dois pontos usar é manter os padrões atuais do CSS3. Seguir esses padrões melhorará a manutenibilidade da sua base de código, então é útil manter e aplicar diretrizes sobre isso para sua base de código.

Isso também ajudará a proteger seu CSS para o futuro. Como discutimos, os navegadores atualmente aceitam a sintaxe de dois pontos simples para ambos, mas isso pode não ser sempre o caso. Ao usar a sintaxe de dois pontos duplos para pseudo-elements, você pode ajudar a evitar erros e bugs no futuro, pois o CSS continua a mudar e evoluir.

A distinção de sintaxe entre os dois oferece melhorias de legibilidade. Isso esclarece o que você está almejando e é útil ao lidar com selectors intrincados que envolvem múltiplos pseudo-elements e pseudo-classes juntos.

Encapsulando

Entender a diferença entre uma pseudo-class e um pseudo-element é essencial para escrever CSS sustentável. Pseudo-classes são usadas para mirar o estado. Pseudo-elements são usados para mirar partes específicas de um element.

Espero que este artigo tenha ajudado a entender as diferenças entre pseudo-classes e pseudo-elements, juntamente com o histórico e as melhores práticas ao usá-los.

Boa estilização!

Se você quiser aprender mais sobre CSS, pode me encontrar no Twitter.

Fonte

Artigo escrito por Natalie Pina.

Escrevendo Lógica em CSS

doug-source — Mon, 05 Aug 2024 00:21:31 +0000

Nota: apenas traduzi o texto abaixo e postei aqui. As referências estão no fim deste artigo.

CSS é uma linguagem de programação altamente especializada com foco em style systems. Por causa desse caso de uso único e sua natureza declarativa, às vezes é difícil de entender. Algumas pessoas até negam que seja uma linguagem de programação. Vamos provar que estão errados programando um style system inteligente e flexível.

Estruturas de controle

Linguagens mais tradicionais e de uso geral (como JavaScript) nos dão ferramentas como "Conditions" (if/then), "Loops" (for, while), "Logical Gates" (===, &&, etc.) e "Variables". Essas estruturas são nomeadas de forma diferente em CSS, sua sintaxe é muito diferente para acomodar melhor o caso de uso específico de estilizar um document, e algumas delas simplesmente não estavam disponíveis em CSS até alguns anos atrás.

Variables

Variables são as mais diretas. Elas são chamadas de Custom properties em CSS (embora todos as chamem de variáveis de qualquer maneira, até mesmo sua própria sintaxe).

:root {
    --color: red;
}
span {
    color: var(--color, blue);
}

O traço duplo declara uma variable e atribui um valor. Isso tem que acontecer em um escopo porque fazer isso fora de um selector quebraria a sintaxe CSS. Observe o selector :root, que funciona como um escopo global.

Conditions

As Conditions podem ser escritas de várias maneiras, dependendo de onde você deseja usar elas. Os selectors têm escopo para seus elements, as media queries têm escopo global e precisam de seus próprios selectors.

Attribute Selectors:

[data-attr='true'] {
    /* if */
}
[data-attr='false'] {
    /* elseif */
}
:not([data-attr]) {
    /* else */
}

Pseudo classes

:checked {
    /* if */
}
:not(:checked) {
    /* else */
}

Media Queries:

:root {
    color: red; /* else */
}
@media (min-width > 600px) {
    :root {
        color: blue; /* if */
    }
}

Loops

Counters são a forma mais direta de loops em CSS, mas também a que tem o caso de uso mais restrito. Você só pode usar counters na content property, exibindo ela como texto. Você pode ajustar seu "increment", seu "starting point" e seu "value" em qualquer ponto dado, mas o output é sempre limitado a texto.

main {
    counter-reset: section;
}

section {
    counter-increment: section;
    counter-reset: section;
}

section > h2::before {
    content: 'Headline ' counter(section) ': ';
}

Mas e se você quisesse usar um loop para definir um layout pattern recorrente? Esse tipo de loop é um pouco mais obscuro: é a auto-fill property dos grids.

.grid {
    display: grid;
    grid-template-columns: repeat(auto-fill, minmax(300px, 1fr));
}

Isso preenche o grid com tantos elementos quantos ele puder encaixar, enquanto dimensiona eles para preencher o espaço disponível, mas quebra eles em várias linhas quando necessário. Ele se repete enquanto encontrar grid itens e limita eles a uma width mínima de 300px e uma width máxima de uma fração do tamanho do grid container deles. Provavelmente é mais fácil ver do que explicar:

codepen

E, finalmente, há "looped selectors". Eles pegam um argumento, que pode ser uma fórmula para selecionar com muita precisão.

section:nth-child(2n) {
    /* seleciona todos os elementos pares */
}

section:nth-child(4n + 2) {
    /* seleciona a cada quarto items, iniciando a partir do segundo */
}

Para casos realmente especiais, você pode combinar :nth-child() com :not(), como:

section:nth-child(3n):not(:nth-child(6)) {
    /* seleciona a cada 3 elementos, mas não o sexto elemento */
}

codepen

Você pode substituir :nth-child() por :nth-of-type() e :nth-last-of-type() para alterar o escopo desses últimos exemplos.

Logic Gates

Ana Tudor escreveu um artigo sobre CSS Logic Gates. Login Gates trabalham com a ideia de combinar variáveis com calc. Ela então continua modelando e animando 3D objects com isso. Parece mágica arcana, fica muito mais insano conforme o artigo avança e é geralmente uma das melhores explicações de por que CSS é de fato uma linguagem de programação.

Técnicas

O Owl Selector

* + * {
    margin-top: 1rem;
}

O Owl Selector seleciona cada item que segue um item. Aplicar um margin-top a isso efetivamente adiciona um gap entre os itens, como o grid-gap faz, mas sem o grid system. Isso também significa que é mais customizável. Você pode sobrescrever sua margin-top e adaptar para qualquer tipo de conteúdo. Quer ter 1rem de espaço entre cada item, mas 3rem antes de um título? Isso é mais fácil de fazer com um owl selector do que em um grid.

Kevin Pennekamp tem um artigo aprofundado sobre isso que até explica seu algoritmo em pseudocódigo.

Conditional Styling

Podemos criar toggles em nosso código css que ligam e desligam certas regras com variables e calc. Isso nos dá condições muito versáteis.

.box {
    padding: 1rem 1rem 1rem calc(1rem + var(--s) * 4rem);
    color: hsl(0, calc(var(--s, 0) * 100%), 80%);
    background-color: hsl(0, calc(var(--s, 0) * 100%), 15%);
    border: calc(var(--s, 0) * 1px) solid hsl(0, calc(var(--s, 0) * 100%), 80%);
}

.icon {
    opacity: calc(var(--s) * 100%);
    transform: scale(calc(var(--s) * 100%));
}

codepen

Dependendo do valor de --s, .box habilitará ou desabilitará seus alert styles.

Automatic contrast colors

Vamos levar a mesma lógica um passo adiante e criar uma color variable que depende do seu contraste com a background color:

:root {
    --theme-hue: 210deg;
    --theme-sat: 30%;
    --theme-lit: 20%;
    --theme-font-threshold: 51%;

    --background-color: hsl(var(--theme-hue), var(--theme-sat), var(--theme-lit));

    --font-color: hsl(
        var(--theme-hue),
        var(--theme-sat),
        clamp(10%, calc(100% - (var(--theme-lit) - var(theme-font-threshold)) * 1000), 95%)
    );
}

Este snippet calcula um background color a partir de valores HSL e uma font color black ou white, invertendo o valor de lightness (luminosidade) do background. Isso por si só pode resultar em baixo contraste de cor (uma fonte cinza de 40% em um background cinza de 60% é praticamente ilegível), então subtrairei um valor threshold (o ponto em que a cor muda de white para black), multiplicarei por um valor insanamente alto como 1000 e farei clamp nele entre 10% e 95%, para obter uma porcentagem de lightness válida no final. Tudo é controlável editando as quatro variáveis no início do snippet.

codepen

Este método também pode ser usado para escrever lógica de cores intrincada e themes automáticos, com base apenas em valores HSL.

Limpando as stylesheets

Vamos combinar o que temos até agora para limpar a stylesheet. Ordenando tudo por viewports parece um pouco espaguete, mas ordenar isso por componente não parece nada melhor. Com variables, podemos ter o melhor dos dois mundos:

/* define variables */
:root {
    --paragraph-width: 90ch;
    --sidebar-width: 30ch;
    --layout-s: "header header" "sidebar sidebar" "main main" "footer footer";
    --layout-l: "header header" "main sidebar" "footer footer";
    --template-s: auto auto minmax(100%, 1fr) auto /
        minmax(70%, var(--paragraph-width)) minmax(30%, var(--sidebar-width));
    --template-l: auto minmax(100%, 1fr) auto /
        minmax(70%, var(--paragraph-width)) minmax(30%, var(--sidebar-width));
    --layout: var(--layout-s);
    --template: var(--template-s);
    --gap-width: 1rem;
}

/* manipula variables por viewport */
@media (min-width: 48rem) {
    :root {
        --layout: var(--layout-l);
        --template: var(--template-l);
    }
}

/* realiza o bind no DOM */
body {
    display: grid;
    grid-template: var(--template);
    grid-template-areas: var(--layout);
    grid-gap: var(--gap-width);
    justify-content: center;
    min-height: 100vh;
    max-width: calc(
        var(--paragraph-width) + var(--sidebar-width) + var(--gap-width)
    );
    padding: 0 var(--gap-width);
}

codepen

Todas as global variables são definidas no topo e ordenadas por viewport. Essa seção efetivamente se torna a Definition of Behavior, esclarecendo questões como:

Quais aspectos globais da stylesheet temos? Estou pensando em coisas como font size, colors, medidas repetidas, etc.
Quais aspectos que mudam frequentemente nós temos? Container widths, Grid layouts e similares vêm à mente.
Como os valores devem mudar entre as viewports? Quais global styles se aplicam a qual viewport?

Abaixo estão as definições de regras, ordenadas por componente. As Media Queries não são mais necessárias aqui, porque elas já estão definidas no topo e colocadas em variables. Podemos simplesmente codificar em nossas stylesheets sem interrupções neste ponto.

Leando o hash parameter

Um caso especial de pseudo classes é o :target selector, que pode ler o hash fragment da URL. Aqui está uma demonstração que usa essa mecânica para simular uma experiência semelhante a SPA:

codepen

Eu escrevi um post sobre isso. Só esteja ciente de que isso tem algumas implicações sérias de acessibilidade e precisa de alguma mecânica JavaScript para realmente ser livre de barreiras. Não faça isso em um live environment.

Definindo Variables em JavaScript

Manipular CSS variables se tornou uma ferramenta muito poderosa agora. Também podemos aproveitar isso em JavaScript:

    // configura --s em :root
    document.documentElement.style.setProperty('--s', e.target.value);

    // configura --s scoped para #myID
    const el = document.querySelector('#myID');
    el.style.setProperty('--s', e.target.value);

    // lê variables de um element
    const switch = getComputedStyle(el).getPropertyValue('--s');

Os exemplos de codepen acima funcionam exatamente assim.

Resumo

CSS é muito capaz de definir layout systems inteligentes e reativos. Suas estruturas de controle e algoritmos podem ser um pouco estranhos em comparação com outras linguagens, mas eles estão lá e estão à altura da tarefa. Vamos parar de apenas descrever alguns styles e começar a fazer eles funcionar.

Fonte

Artigo escrito por Daniel Schulz

Princípios de Design - Uma lista dos princípios de design

doug-source — Sun, 04 Aug 2024 23:06:57 +0000

Nota: apenas traduzi o texto abaixo e postei aqui. As referências estão no fim deste artigo.

Quando você começa a aprender teoria de design gráfico, pode se surpreender ao descobrir que há regras específicas que você precisa seguir ao projetar.

Essas regras são conhecidas como princípios de design, e neste artigo, você aprenderá os fundamentos dos 13 princípios de design.

Saber o que são princípios de design lhe dará uma melhor compreensão de como criar designs mais harmoniosos e melhores experiências de usuário.

Aqui está o que abordaremos neste guia:

O que são princípios de design?
Os 13 princípios do design:
- Equilibrio
- Variedade
- Ênfase
- Contraste
- Hierarquia
- Repetição
- Pattern (Padrão)
- Movimento
- Ritmo
- Proporção
- Alinhamento
- Unidade
- White space (espaço em branco)

O que são princípios de design?

Os princípios de design são um conjunto rigoroso de regras.

Os designers seguem essas regras para criar experiências agradáveis para o usuário e produtos finais visualmente atraentes.

Essas regras são ferramentas e diretrizes que ajudam o designer a criar um senso de harmonia e equilíbrio em seus designs.

Elas garantem usabilidade e um efeito geral agradável para visualizadores e usuários.

Os 13 Princípios do Design

Equilíbrio

Cada elemento de design em uma página tem um peso diferente, dependendo do seu tamanho, forma ou cor.

Esse peso é conhecido como peso visual.

O equilíbrio no design é como você organiza e posiciona elementos em uma composição, e é sobre distribuir o peso desses elementos.

Uma composição sem equilíbrio significa que um elemento domina todos os outros.

Para criar equilíbrio, você precisa posicionar os elementos corretamente.

Por exemplo, pode ser que um elemento de um lado seja muito "mais pesado" do que o resto e seja avassalador, fazendo com que o design pareça instável.

Existem dois tipos de equilíbrio:

Equilíbrio simétrico
Equilíbrio assimétrico

Com o equilíbrio simétrico, pense em desenhar uma linha vertical invisível no centro da página e dividi-la em dois lados.

Os itens em ambos os lados da linha têm peso visual distribuído uniformemente e criam uma imagem espelhada.

A ordem, a posição e o alinhamento dos elementos são iguais em ambos os lados, criando consistência no design.

O equilíbrio assimétrico é o oposto do equilíbrio simétrico.

Os elementos em ambos os lados têm arranjos diferentes, pois também têm uma ordem e posicionamento que variam na composição.

Embora cada lado tenha um peso visual diferente, o design geral mantém um peso visual igual em ambos os lados.

Não há imagem espelhada, e ambos os lados parecem diferentes, mas o design ainda é estável.

Por exemplo, o design assimétrico pode ser quando três elementos mais leves em um lado, empilhados um sobre o outro, equilibram um único item mais pesado no lado oposto.

O equilíbrio assimétrico cria interesse visual e adiciona um toque moderno ao design.

Variedade

A variedade cria interesse visual e evita que o design se torne monótono e previsível.

A variedade é criada usando elementos que não são semelhantes entre si.

Com o uso da variedade, você tem uma boa chance de manter o interesse e o engajamento dos espectadores.

A variedade no design é alcançada com o uso de muitas coisas diferentes, algumas das quais são:

variando tamanhos,
variando formas,
variando cores,
variando texturas,
variando a tipografia

Ênfase

O propósito da ênfase é criar um ponto focal.

Um ponto focal é um objeto que se destaca instantaneamente e chama a atenção do espectador ou usuário à primeira vista.

Quando há ênfase em um elemento de design, significa que o objeto específico é destacado do resto e, portanto, é de grande significância e importância.

Por exemplo, você pode pensar em ênfase como um texto com todas as letras maiúsculas e em negrito.

A ênfase pode ser o heading (título) principal em um site.

Também pode ser uma mensagem de algum tipo.

Você pode querer transmitir algo crucial ou cauteloso aos seus espectadores e precisa ter certeza de que seu público esteja ciente disso e se concentre nisso primeiro.

A ênfase também pode ser um botão grande com uma cor brilhante sob um item para compra - isso pode funcionar como um chamado para ação para os visitantes.

É o que você quer que os outros percebam primeiro - as informações essenciais que alguém precisa estar ciente e prestar atenção ao ver seu trabalho pela primeira vez.

É uma parte específica do conteúdo que precisa se destacar do resto do design.

Além do texto e da cor, a ênfase é obtida com tamanho, forma, peso, textura e posição, para citar alguns.

Ao criar ênfase, certifique-se de fazê-lo sem perturbar o equilíbrio geral da composição e sem criar um efeito avassalador e chocante.

Contraste

Enquanto a ênfase é sobre acentuar um único elemento, o contraste tem a ver com o grau aparente e destacado de diferença entre dois ou mais elementos de design que estão próximos.

Essa diferença pode ser que um elemento tenha um background escuro e o outro tenha um background claro.

Também pode ser que um elemento tenha um tom mais frio, enquanto o outro tenha um tom mais quente. Ou que um elemento seja maior e o outro seja menor em tamanho. Ou usar uma fonte serifada em algum texto e um texto sem serifa em outro pedaço de texto.

Por exemplo, preste atenção na webpage dos artigos publicados no domínio da freeCodeCamp.

Ao navegar na página de um computador desktop ou laptop, você verá que no canto superior direito, há dois botões nos quais você pode clicar:

o botão 'Forum' tem um background escuro que é a mesma do resto da navigation bar,
o botão 'Donate' tem um background amarelo brilhante que o destaca.

Isso é considerado contraste. Há dois elementos muito diferentes um ao lado do outro, mas um chama mais a atenção e exige sua atenção.

No geral, o contraste destaca dois elementos totalmente opostos com características altamente diferentes. A diferença tem que ser perceptível.

Existem diferentes tipos de contraste, como contraste de cor ou contraste de tamanho, forma ou textura.

O objetivo é criar variação e interesse e, portanto, criar foco e ênfase, mantendo o equilíbrio no design.

Um bom contraste anda de mãos dadas com as melhores práticas de acessibilidade e a criação de produtos e serviços utilizáveis para todos. É necessário levar em consideração pessoas com deficiência visual.

Pense em outro exemplo.

Digamos que há um elemento com um background cinza claro e algum texto cinza escuro. Então, há outro elemento com a mesma cor de fundo, mas há algum texto preto.

Qual é mais fácil de ler? O segundo com o texto preto.

Há um contraste de cor maior entre o background e a cor do foreground (texto).

Há uma falta de contraste no primeiro elemento - isso torna a leitura do texto muito mais difícil.

Hierarquia

A hierarquia organiza elementos visuais em ordem de importância.

O papel da hierarquia no design é criar um sistema de ranking visual de acordo com a prioridade lógica do conteúdo. Ela ajuda a guiar os espectadores das informações mais importantes para as menos importantes, criando um fluxo e arranjo lógicos desse conteúdo.

Pense na ordem típica dos elementos em uma webpage.

Lemos de cima para baixo, então o olho do espectador deve ser atraído imediatamente para as informações essenciais antes de começar a rolar a página.

Então, isso significa que as informações cruciais precisam estar no topo da página - elas precisam ser as informações mais proeminentes e ter o rank mais alto na página.

Veja o exemplo a seguir.

No topo de uma webpage, normalmente há o logotipo da empresa primeiro.

Depois, há uma navigation bar ou dropdown menu, que ajuda os usuários a decidir a área do site com a qual desejam interagir.

Também pode haver uma barra de pesquisa para os usuários inserirem palavras-chave para pesquisar um tópico específico e economizar tempo.

Então, pode haver uma chamada para action ou o "heading" (título) principal que reforça o propósito da página e seu conteúdo.

Então, pode haver a área principal que conteria um subheading (subtítulo) com algum texto, depois outro subheading com mais texto, e assim por diante.

Essa ordem cria organização visual e ajuda os espectadores a distinguir qual conteúdo parece ser o mais importante e merece sua atenção.

Ele orienta os espectadores do início do conteúdo até o fim - da maior prioridade para a menor prioridade.

A posição dos elementos significa importância - a informação mais importante está sempre mais alta em uma página, enquanto se algo estiver na parte inferior, não é tão importante.

Outras maneiras de criar hierarquia no design são usar cores para criar contraste e alternar o tamanho dos elementos de maneiras diferentes.

Sem hierarquia, todo o conteúdo pareceria o mesmo, e nada se destacaria e sinalizaria importância, o que levaria à confusão para os visualizadores.

Repetição

Repetição é quando um elemento específico é repetido várias vezes ao longo do design.

O papel da repetição no design é criar consistência e unidade.

A repetição cria relacionamentos e associações entre elementos aparentemente separados e diferentes e cria um vínculo entre eles - um elo comum que une tudo.

Para obter repetição, você usa a mesma cor específica ou o mesmo color scheme (esquema de cores) várias vezes ao longo do design.

Ou usa um tipo de fonte específico ou uma frase recorrente ao longo da página.

Um elemento comumente repetido em designs é um logotipo, que desempenha um papel crítico na criação de uma identidade de marca.

Um logotipo fará com que os espectadores e usuários se familiarizem com a marca. Eles reconhecerão e distinguirão sua voz e tom de outras marcas.

Os usuários memorizarão e identificarão o logotipo com a visão e missão da empresa.

Eles saberão do que se trata a marca.

Pattern

Pattern, à primeira vista, parece ser muito semelhante à repetição, pois implica que os elementos ocorrem várias vezes ao longo da página.

No entanto, eles têm diferenças significativas.

Enquanto a repetição lida com o mesmo elemento se repetindo ao longo do design, um pattern se concentra em vários e diferentes elementos de design se repetindo da mesma forma ao longo da composição.

Um pattern no design é sobre a repetição de mais de um elemento.

Um exemplo de pattern no mundo real são ladrilhos e papéis de parede.

Um exemplo de web pattern é o uso de backgrounds em sites e applications para criar harmonia e uma sensação coesa.

Movimento

Movimento é como os olhos se movem ao visualizar e interagir com uma composição.

Movimento se refere à maneira como o olho do observador viaja e o caminho que ele percorre ao longo de um design.

O designer usa o movimento para guiar o observador em torno de diferentes elementos do design.

Eles criam diferentes áreas focais para cada ponto no tempo para capturar efetivamente a atenção do observador, movendo-se de um elemento para outro em uma sequência direcionada bem pensada.

Normalmente, o olho do observador vê primeiro o elemento mais importante, depois o segundo mais importante, depois o terceiro e assim por diante.

Um exemplo de movimento pode ser ver uma escada em espiral quando você está no topo - seu olho se moverá ao longo das diferentes linhas e bordas.

O movimento na web pode ser criado por:

O uso de efeitos animados,
O uso de efeitos de blurring,
O uso de efeitos em espiral,
O uso de linhas e bordas,
O uso de diferentes sinais de direção que fornecem orientação, indicando ao espectador para mover seu foco para a esquerda, direita ou olhar para baixo ou para cima.

Ritmo

Ritmo envolve a combinação de repetição, variedade e movimento.

Ritmo é como vários elementos de design que são diferentes uns dos outros se repetem em uma ordem específica.

Repetir ou alternar um grupo de elementos diferentes na mesma ordem e em intervalos específicos é uma maneira de criar ritmo no design.

Existem cinco tipos diferentes de ritmo no design, dependendo do tipo de intervalo:

Ritmo randômico
Ritmo regular
Ritmo fluido
Ritmo progressivo
Ritmo alternado

Os elementos seguem um tempo e se movem e fluem de forma organizada.

Assemelha-se à sensação de seguir uma coreografia de dança ou se mover ao ritmo de uma música.

Em vez de trazer a atenção para apenas uma área do design ou guiar o observador de uma parte diferente para outra, o ritmo se concentra em mover os olhos do observador por toda a composição.

Proporção

Proporção em design se refere ao tamanho e peso visual de dois ou mais elementos visuais.

Proporção também é a relação entre esses elementos visuais.

A relação é baseada no tamanho. É como o tamanho de um objeto se compara e é correlacionado ao tamanho do outro objeto.

Essencialmente, é como os elementos escalam em tamanho em relação uns aos outros.

Por exemplo, proporção compara e mede a importância dos elementos uns para os outros.

Digamos que há dois objetos - um é maior e o outro é muito menor.

O elemento maior será mais perceptível, o que indica que ele é mais importante do que o menor.

Um design bem proporcionado significa que o tamanho de todos os elementos preserva o equilíbrio, a unidade e a harmonia para todo o design.

Boa proporção significa que todos os elementos se relacionam bem entre si.

Alinhamento

Alinhamento se refere a como os elementos visuais são alinhados, ordenados e estruturados em comparação uns aos outros e em comparação com todo o design.

É uma maneira de criar uma conexão e fluxo visual entre objetos relacionados e criar um resultado mais unificado no design.

Ao alinhar os diferentes objetos visuais, você ajuda a guiar seu visualizador por todo o design.

As formas mais comuns de alinhamento são alinhamento à esquerda, alinhamento à direita e alinhamento centralizado.

Unidade

Unidade no design é como diferentes elementos visuais se unem para criar coesão e completude no design e um efeito harmonioso.

Com unidade, itens aparentemente diferentes criam uma sensação de "unidade". Isso pode ser alcançado de algumas maneiras diferentes.

Por exemplo, elementos de tamanhos diferentes podem ter a mesma cor e estar próximos uns dos outros.

Isso faz com que pareçam pertencer um ao outro ou como se estivessem relacionados e fossem semelhantes de alguma forma.

White space

White space também é conhecido como espaço negativo.

Essencialmente, white space se refere a áreas que não têm elementos visuais e áreas com espaço vazio e não utilizado ao redor de elementos já existentes em um design.

White space não significa necessariamente que o espaço vazio seja branco - pode ser de qualquer cor. Ele se refere mais ao vazio e ao espaço disponível em seu design e ao fato de que algumas áreas não contêm nada.

White space é sobre não adicionar nenhum elemento à composição e adota uma abordagem mais minimalista e simplista ao design. Às vezes, menos é realmente mais.

White space cria espaço para respirar no design.

Quando muita coisa acontece em uma página, os visualizadores podem facilmente ficar sobrecarregados com todas as informações que precisam absorver. O white space ajuda a evitar que isso aconteça. Ele torna qualquer texto disponível mais legível e cria uma experiência de usuário melhor em todos os aspectos.

White space elimina qualquer desordem desnecessária e cria um ponto focal. Portanto, use o white space ao redor de elementos importantes para destacá-los.

Conclusão

Espero que agora você tenha um entendimento de alto nível dos princípios de design e tenha uma ideia melhor de como implementá-los em seus designs futuros.

Obrigado pela leitura!

Fonte

Artigo escrito por Dionysia Lemonaki