DEV Community: Allan Ramos

React será compilado

Allan Ramos — Thu, 22 Feb 2024 20:37:50 +0000

Este artigo é uma tradução do artigo React Will Be Compiled de Brad Westfall.

Ontem, a equipe do React fez uma postagem no blog anunciando no que têm trabalhado para o React. Andrew Clark, da equipe do React, nos fornece uma boa análise das mudanças:

// Detect dark theme var iframe = document.getElementById('tweet-1758229889595977824-684'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1758229889595977824&theme=dark" }

Correção: Anteriormente, afirmei que seria a versão 19 que seria compilada. O anúncio da equipe do React mencionou o React compilado e eu assumi (assim como outros) que isso se referia à versão 19. Parece que a versão 19 terá muitos recursos mencionados em sua postagem, mas a compilação provavelmente será na próxima versão (como indica Andrew, provavelmente até o final deste ano, 2024).

// Detect dark theme var iframe = document.getElementById('tweet-1760433969118769654-741'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1760433969118769654&theme=dark" }

Seja qual for a versão, espero que esta postagem ajude qualquer pessoa que se sinta confusa sobre o que significa o React se tornar "compilado". Tentarei mostrar exemplos e contexto histórico sobre como chegamos a este ponto, pois tem sido um tópico muito discutido e às vezes é difícil acompanhar, especialmente se você não viu toda a história do React se desenrolar.

O React compilado resolverá os principais problemas dos hooks

Conforme continuamos, mantenha em mente estes princípios do React que não mudarão quando compilarmos o React:

O estado do React é imutável.
A interface do usuário é uma função do estado.
Rerrenderizar quando o estado muda para produzir uma nova interface do usuário.

Além dos números de versão, penso no React como tendo três eras distintas.

A era dos componentes de classe (sem primitivo para abstração)
A era dos Hooks (precisamos memoizar)
A era compilada (auto-memoização)

Estamos prestes a entrar na era compilada, mas como chegamos até aqui?

Para aqueles de nós que criaram projetos com class components, lembramos dos problemas que as classes nos causavam quando queríamos abstrair e reutilizar nosso código. O React estava carente de um "primitivo" para reutilização de código, então a comunidade inventou padrões como HOCs (Higher-Order Components) e Render Props, que eram menos do que ideais. Acontece que o problema em criar um primitivo era que as próprias classes não nos forneciam o nível de composição de que precisávamos. Então, a equipe do React começou a buscar alternativas às classes e a se concentrar na composição funcional.

Naquela época, componentes funcionais já existiam, mas o chamávamos de Stateless Functional Components porque não podiam ter estado ou outros aspectos de ciclo de vida que as classes tinham. A equipe do React viu os componentes funcionais como uma forma de nos dar o primitivo que precisávamos. Se ao menos eles pudessem descobrir uma maneira de permitir que os componentes funcionais "se conectassem" aos ciclos de vida do React 😉

Sim, daí vem o termo "hooks".

Quando os hooks foram anunciados em 2018, eu estava na conferência. Lembro-me de quando Ryan Florence subiu ao palco para falar logo após o anúncio e fez uma refatoração de "render props para hooks" na frente de todos. Ficamos impressionados. Hooks, e especificamente hooks personalizados, seriam o primitivo que estávamos perdendo.

O que não percebemos na época foi que misturar todo o nosso código em uma única função poderia nos fornecer composição, mas viria como uma compensação porque agora teríamos que memoizar. Não percebemos que as classes naturalmente nos protegiam da memoização, dada a natureza do rerenderização.

Nos class components, o método de renderização isola seu código dos outros métodos do ciclo de vida, o que por sua vez significa que uma rerenderização não afetará adversamente o código que não faz parte da fase de renderização. Isso provavelmente foi menos uma decisão de design e mais uma característica de como as classes funcionam. 🧐 Isso parece quase bobo de mencionar, mas desempenha um papel nas evoluções que viriam a seguir.

React com Memoização

Para ser honesto, os class components eram terríveis. Lembro-me de quando mudamos nosso currículo de workshop de dois dias para hooks e metade de nossos tópicos simplesmente evaporaram porque os class components introduziam tanta complexidade nas aplicações que não precisávamos mais ensinar.

Se criássemos um class component com um método para lidar com o envio de formulário, o método nunca precisaria ser "memoizado". Vamos ver o que acontece quando fazemos algo semelhante com componentes funcionais:

function App() {
  const [state, setState] = useState()
  function onSubmit() {
    // lógica do evento
  }
  return <form onSubmit={onSubmit}></form>
}

Talvez você não tenha percebido imediatamente, mas esta função será recriada toda vez que houver uma rerenderização, o que significa que será uma nova função na memória. Normalmente, não é um problema que as funções se recriem e, neste exemplo, não está causando nenhum problema para nós. Vale ressaltar, no entanto, que isso não aconteceria em classes porque seria um método separado da fase de renderização.

Também vale ressaltar que a ideia geral de coisas precisarem se recriar em JavaScript não é específica do React. Posso mostrar-lhe meu código jQuery de 2008 que também recriaria funções e objetos. Estou apenas brincando, não faço ideia de onde está meu código de 2008.

Agora vamos refatorar o código um pouco:

function App() {
  const [state, setState] = useState()
  function onSubmit() {
    // lógica do evento
  }
  return <Form onSubmit={onSubmit} />
}

const Form = ({ onSubmit }) {
  // ...
}

Ainda não é um problema que `onSubmit será uma nova função em cada renderização.

A rerrenderização de App causará uma rerrenderização de Form neste caso. Alguns dirão que um componente receberá uma rerrenderização apenas se suas props mudarem. Isso não é verdade. O Form receberá uma rerenderização quando o App receber uma rerenderização, independentemente das props. Por enquanto, simplesmente não importa se a propriedade onSubmit está mudando.

Agora, digamos que tenhamos alguma razão para evitar que Form seja rerenderizado quando App é rerenderizado. Este exemplo é demasiadamente simplista, mas digamos que memoizamos Form:

jsx // Agora, Form só será rerenderizado se suas props específicas mudarem. Não a cada // vez que App for rerenderizado const Form = React.memo(({ onSubmit }) => { // ... })

Agora temos um problema.

O React depende fortemente de verificações de igualdade estrita para saber se uma variável mudou, o que é uma maneira sofisticada de dizer que eles usam === e Object.is() para comparar o antigo com o novo. Quando você compara primitivos do JavaScript (como strings) entre si com ===, o JavaScript os compara pelos valores (você já sabia disso). Mas quando o JavaScript compara arrays, objetos ou funções entre si, o uso de === está comparando suas identidades, em outras palavras, sua alocação de memória. É por isso que {} === {} é false no JavaScript porque esses são dois identidades de objeto diferentes na memória.

Fazer Form = React.memo(fn) é como dizer:

Ei React, só queremos rerenderizar Form se suas props realmente mudarem de acordo com uma verificação de identidade.

Isso cria um problema porque onSubmit muda toda vez que App é rerenderizado. Isso levará a que Form seja sempre rerenderizado, o que significa que a memoização não nos ajuda em nada. É um sobrecarga sem sentido para o React neste ponto.

Agora, precisamos voltar e garantir que onSubmit não mude sua identidade quando App` é rerenderizado:

function App() {
  const [state, setState] = useState()

  const onSubmit = useCallback(() => {
    // lógica do evento
  }, [])

  return <Form onSubmit={onSubmit} />
}

Nós usamos o useCallback para estabilizar a função para que sua identidade não mude. De certa forma, é um tipo de memoização. Em termos excessivamente simplificados, memoização significa "lembrar" ou "armazenar em cache" a resposta de uma função.

É como se estivéssemos dizendo:

Ei React, lembre-se da identidade desta função que estou passando para useCallback. Quando tivermos rerenders, estou te dando uma nova função toda vez, mas esqueça isso, me dê a identidade da função original da primeira vez que te chamei.

Memoizar a função onSubmit não é normalmente necessário, mas se tornou necessário quando Form foi memoizado e recebeu `onSubmit como uma propriedade. Na React Training, chamamos isso de "sangramento de implementação"(implementation bleed).

O problema não para por aí. Vamos adicionar mais código:

`jsx
function App() {
const [state, setState] = useState()

const settings = {}
const onSubmit = useCallback(() => {
const x = settings.x
// código
}, [])

// código
}
`

O objeto settings(configurações) se recria em cada renderização de App. Isso não é um problema por si só, mas se você conhece bem o React, sabe que o linter pedirá para você colocar settings no array de dependências do useCallback` neste caso:

const settings = {}
const onSubmit = useCallback(() => {
  const x = settings.x
  // ...
}, [settings])

Se fizermos isso, é como se estivéssemos dizendo:

Queremos que onSubmit seja estável e não mude a cada renderização. Mas queremos que useCallback recrie onSubmit se qualquer uma das coisas neste array de dependências mudar.

Você pode se perguntar: "por que eu gostaria que onSubmit mudasse?"

Eu concordo com você, provavelmente não precisa mudar, mas há muitas situações no React em que coisas como useCallback e useMemo precisam re-memoizar e criar uma nova identidade para seu valor de retorno quando seu array de dependências muda. O linter simplesmente não sabe que nunca queremos que onSubmit seja diferente neste caso.

Lembre-se de que o linter está quase sempre certo, mas escolhi este exemplo para mostrar como podemos não querer o que o linter quer.

Se ouvirmos o linter e colocarmos settings no array de dependências, aqui está o que acontecerá:

Quando App é rerenderizado...
settings se torna um novo objeto que não é === ao que estava na renderização anterior.
O array de dependências vê settings como diferente de acordo com === mesmo que seus valores não tenham mudado.
A mudança no array de dependências significa que useCallback retorna uma nova identidade para onSubmit.
O Form é rerenderizado porque onSubmit muda.

Em resumo, a memoização de Form é inútil. Ele sempre será rerenderizado quando App for rerenderizado. Então agora temos mais "sangramento de implementação"(implementation bleed) porque precisamos memoizar settings com useMemo apenas para que possamos manter a memoização de onSubmit intacta.

Vamos dar um passo atrás para aquela pergunta:

Por que eu gostaria que onSubmit mudasse? Não poderíamos simplesmente desativar o linter nesse caso?

Claro, neste caso, acho que podemos deixar settings fora do array de dependências ou podemos simplesmente memoizá-lo, que é o que eu provavelmente faria. Ou até mesmo poderíamos argumentar que não precisávamos do formulário memoizado em primeiro lugar, o que teria evitado essa bagunça. Isso não é o ponto, é apenas um exemplo. O ponto é que a memoização no React frequentemente leva a um cascata de "sangramento de implementação"(implementation bleed).

O tópico dos arrays de dependência e por que o linter quer que você coloque coisas neles vai muito além do escopo deste post. Eu provavelmente poderia falar sobre esse tópico por horas porque é vasto, com muitos detalhes. A verdade é que o linter geralmente está certo e tem boas intenções. O problema é que MUITOS desenvolvedores do React não entendem seu raciocínio e acham que o linter é apenas uma pequena sugestão. Na minha experiência, quando você ignora o linter, provavelmente encontrará bugs.

Aqui está um exemplo perfeito: Alguns anos atrás, estava conversando com alguém no Twitter que disse que nunca colocava funções no array de dependências de seu useEffect porque às vezes criava um loop infinito. Eu disse algo como "por que você não usa useCallback nessas funções, isso evitará o loop. O problema é que a função está mudando com muita frequência".

Eles disseram "O que é useCallback?"

É comum as pessoas não entenderem memoização ou React o suficiente e depois ficarem frustradas com o linter.

Dependente de memoização

Se você trabalhou o suficiente com React, sabe que pode ser um incômodo lidar com os arrays de dependências. O linter pode lhe dizer para colocar coisas no array e você não gosta do resultado (como um loop). É fácil ficar irritado com o linter, mas o linter estava certo. Não porque o React "quer" um loop infinito, é claro, mas porque você precisava também memoizar algo agora.

Os arrays de dependência são uma forma de lidar com o fato de que todo o nosso código está co-localizado em um componente funcional que rerenderiza, e queremos monitorar as mudanças nas variáveis ao longo do tempo. Às vezes, acabamos colocando objetos, arrays e funções no array de dependências, então certifique-se de estabilizá-los com memoização. A maneira como explico o que o React significa por "estável" é "uma variável que não muda a menos que você queira".

Vamos demonstrar isso com código:

function App() {
  const [misc, setMisc] = useState()
  const [darkMode, setDarkMode] = useState(false)
  const options = { darkMode }

  return <User options={options} />
}

function User({ options }) {
  useEffect(() => {
    // get user
  }, [options])

  // ...
}

Podemos ver que quando o estado misc em App muda, a consequência em cascata é que options mudará e, portanto, o useEffect será executado novamente, mesmo que o efeito não tenha nada a ver com o estado misc. Portanto, é melhor envolver a variável options em um useMemo. Quando você fizer isso, o linter pedirá corretamente para você colocar `darkMode no array de dependências:

jsx const [darkMode, setDarkMode] = useState(false) const options = useMemo(() => { return { darkMode } }, [darkMode])

Ao fazer isso, estamos dizendo:

Queremos que options seja estável, até que o modo escuro mude. Em seguida, reestabilize-o em uma nova identidade. Mas não faça nada quando o estado misc mudar, porque não está em nosso array (não dependemos dele).

Sim, entendi o ponto. No React, a memoização é fundamental e é responsabilidade do desenvolvedor implementá-la corretamente. Caso contrário, podem ocorrer bugs e problemas de desempenho. É importante entender como e quando aplicar a memoização para garantir um código eficiente e livre de erros.

Sempre compilamos o React

Dependendo da sua definição do termo, você poderia argumentar que o React sempre teve uma etapa de compilação (JSX). Para mim, parece ser um termo solto no JavaScript que basicamente significa que o código que você escreve é diferente do código que é executado no navegador.

Minha primeira experiência com o React foi em 2015. Babel e React ainda eram relativamente novos para a maioria dos desenvolvedores. De certa forma, sua popularidade cresceu em conjunto. O React é famosamente conhecido por compilar JSX em chamadas de função. Então, eu acho que o React é tecnicamente compilado, mas sempre senti que era um pequeno syntax sugar e que a semântica de um elemento JSX se tornando uma função muito previsível significa para mim que é uma quantidade de compilação relativamente "leve".

Hoje em dia, também compilamos TypeScript para JavaScript, o que para mim é engraçado, porque neste caso significa apenas que todo o TypeScript que escrevemos evapora quando salvamos e o código que resta é o JavaScript. Mas eu acho que ainda se encaixa na minha definição de "o que você escreve é o que você obtém".

Compilar é um espectro

Para mim, parece que "frameworks compilados" se situam em um espectro onde alguns são compilados um pouco e outros são compilados bastante:

O React parece estar mais no lado "não muito" em comparação com alguns outros frameworks JavaScript modernos. Para mim, a regra do "o que você vê é o que você obtém" determinará onde você está neste espectro. O JSX significa que o React é um pouco compilado, mas o outro código que escrevo não é compilado pelo React.

Por outro lado, o Svelte é tão fortemente compilado que seu criador o descreveu como nem mesmo sendo JavaScript. O Svelte é realmente mais uma linguagem de programação porque a semântica do que você escreve está tão longe da semântica do que você obtém quando ele se transforma em JavaScript.

Não estou tentando tornar este um post de comparação, ou dizer que um caminho é melhor que o outro, ou que compilar é bom ou ruim. Estou simplesmente dizendo que parece ser um espectro onde diferentes frameworks JavaScript compilam menos, ou compilam mais, ou compilam até o ponto em que nem mesmo são realmente JS mais.

O anúncio da equipe do React é que o React vai ser mais compilado do que era antes. Será mais do que alguns dos outros? Não tenho certeza. Não importa muito onde ele acaba neste espectro para mim. O que importa mais é por que ele está sendo compilado. A resposta é por razões diferentes das dos outros.

Compilando para Auto-Memoização

O React não está abandonando a imutabilidade e indo em rumo para a observabilidade. Ainda terá verificações de identidade e arrays de dependência. Então, o fato de estar compilado agora não faz o React parecer semelhante aos outros. Ele será compilado para que possamos ter auto-memoização. O React é o mesmo de sempre, mas sem as desvantagens da memoização manual, que era um dos principais problemas com hooks e componentes funcionais.

Pessoalmente, estou acostumado com minha lógica acima do JSX ser deixada intocada. Essa mudança será principalmente desaprender a pensar em termos de memoização manual. Terei que confiar no compilador para tomar boas decisões para mim e ainda estou incerto sobre quanto disso terei que orientar o compilador vs "It Just Works™". Estou otimista e interessado em experimentar.

Em resumo, vale ressaltar que essa ideia não surgiu do nada. Estamos discutindo isso como uma possibilidade no React há três anos, desde que Xuan Huang introduziu a ideia na React Conf 2021. Também houve momentos em que foi o tópico quente no Twitter nos círculos do React há alguns anos.

Minha esperança é que, se você não estava ciente dessas conversas, este post forneça exemplos e contexto justos sobre como chegamos a este ponto. Obrigado por ler!

Tudo que sei sobre Style Guides, Design Systems, e Biblioteca de Componentes

Allan Ramos — Thu, 27 Jul 2023 18:46:08 +0000

Esse artigo é uma tradução do artigo original Everything I Know About Style Guides, Design Systems, and Component Libraries criado por Lee Robinson.

Durante a maior parte do ano passado, investi arduamente em desenvolvimento front-end e design. Quando iniciei minha nova função, identifiquei a necessidade de uma biblioteca de componentes e a criei. Desde então, aprendi muito sobre style guides, design systems, biblioteca de componentes(component libraries) e suas melhores práticas. Este post será um mergulho profundo em tudo o que aprendi no ano passado.

Por que você deveria se importar?

Todo site começa simples. Talvez exista uma página com algumas coisas diferentes, mas ele começará de forma humilde.

Então, aos poucos, ele começa a crescer.

Nova páginas são adicionadas e novas funcionalidades são implementadas. Talvez existam vários times focados em partes específicas do site. Você também por estar focado em mobile.

Você começa a notar que os botões em uma parte do site são um pouco diferentes dos outros. Uma equipe decide construir uma funcionalidade que outra equipe já fez (sem saber). Falhas de comunicação acontecem. A consistência é perdida.

Este problema poderia ter sido evitado? Com certeza. No entanto, por que isso sempre acontece? A menos que você pense em seu processo de design e desenvolvimento de forma atencipada, você terá problemas mais tarde à medida que o projeto aumenta.

Para evitar que esse problema aconteça ou corrigir a falta de consistência existente em seus produtos, você precisa de três coisas:

Style Guide
Biblioteca de componentes
Design System

Fique tranquilo se você ainda não tem ideia do que estou falando. No final deste artigo você terá consumido quase um ano de tentativa e erro, pesquisa e desenvolvimento.

O que é Style Guide?

Um style guide é um conjunto de regras sobre como sua marca deve ser exibida. Isso é tanto visual (design e imagens) quanto conteúdo escrito (voz e tom).

O objetivo de um style guide é permitir que vários colaboradores criem conteúdo de forma clara que represente a marca de forma coesa. Quase todas as grandes marcas têm um style guide, embora nem todas sejam públicas.

O que é uma biblioteca de componentes?

Uma biblioteca de componentes é uma implementação viva do seu style guide. É um conjunto compartilhado de componentes que os desenvolvedores podem consumir para criar aplicações que reflitam sua marca. Alguns benefícios notáveis:

Ter uma biblioteca de componentes significa que quem for utilizar acabará codando menos.
Como há uma centralização, você pode garantir que todos os componentes atendam aos requisitos de acessibilidade.
Os componentes se tornam mais robustos com vários contribuidores enviando correções de bugs e melhorias em um único local.
Menos duplicação de código permitirá que você lance novos produtos e reescreva código legado de forma mais rápida.

O que é Design System?

Um design system é um conjunto de padrões, documentação e princípios, juntamente com os componentes para atingir esses padrões. É a junção de seu style guide e a biblioteca de componentes. Um dos design systems mais populares é do Google, Material Design.

Um design system deve conter:

Conteúdo: A linguagem para projetar uma experiência de produto mais ponderada.
Design: Os elementos visuais do design system.
Componentes: Os blocos de construção para o desenvolvimento de novos produtos e funcionalidades.
Padrões: As pequenas partes para criar experiências de produto significativas.

Por onde você deve começar?

Dependendo do estado da sua empresa/produto, você pode ter um ponto de partida diferente. Este é o esboço antes de entrarmos em detalhes:

Crie um inventário de padrões de design existentes.
Estabeleça princípios de design e comece um style guide.
Defina seus design tokens.
Crie ou identifique um conjunto de ícones.
Escolha linguagens/frameworks para dar suporte.
Avalie entre monorepo ou um único pacote.
Avalie entre CSS/Sass e CSS-in-JS.
Crie uma biblioteca de componentes.
Escolha uma plataforma de documentação.
Escreva uma documentação do design system.

Construindo um Design System

Crie um inventário de padrões de design existentes

A não ser que você esteja começando do zero, você precisará identificar todos os padrões de design em uso na sua interface e documentar toda inconsistência. O objetivo deve ser permanecer com a mesma experiência do usuário, independentemente da parte do produto em que o usuário está.

Comece a documentar e revisar com sua equipe, e identifique os padrões que mais lhe agradam. Isso fará com que vocês tenham uma ideia do que seu style guide precisará.

Estabeleça princípios de design e comece um style guide

Chegou a hora de traduzir essas descobertas para um style guide. Você pode usar ferramentas como:

Minha recomendação seria o Figma, mas em última análise, depende de sua equipe e empresa. Aqui estão alguns tutoriais úteis do Figma para iniciantes.

Defina seus design tokens

Os design tokens são os átomos do design system - especificamente, são entidades nomeadas que armazenam atributos de design. Nós os usamos nos lugares de valores hard-codados(como valores hexadecimais para cor ou valores de pixel para espaçamento) para manter um sistema visual escalável e consistente para o desenvolvimento da interface.

Isso inclui coisas como:

Por exemplo, vamos dar uma olhada no Design System da Vercel:

--geist-foreground: #000;
--geist-background: #fff;
--accents-1: #fafafa;
--accents-2: #eaeaea;
--accents-3: #999999;
--accents-4: #888888;
--accents-5: #666666;
--accents-6: #444444;
--accents-7: #333333;
--accents-8: #111111;
--geist-success: #0070f3;
--geist-error: #ee0000;
--geist-warning: #f5a623;
--dropdown-box-shadow: 0 4px 4px 0 rgba(0, 0, 0, 0.02);
--dropdown-triangle-stroke: #fff;
--scroller-start: var(--geist-background);
--scroller-end: rgba(255, 255, 255, 0);
--shadow-small: 0 5px 10px rgba(0, 0, 0, 0.12);
--shadow-medium: 0 8px 30px rgba(0, 0, 0, 0.12);
--shadow-large: 0 30px 60px rgba(0, 0, 0, 0.12);
--portal-opacity: 0.25;

Agora existe uma linguagem comum entre designers e desenvolvedores.

Crie ou identifique um conjunto de ícones

Se você já tem ícones, precisará escolher quais você não jogará fora. Talvez não faça sentido você criar seus próprio ícones dependendo do tamanho da sua empresa. Talvez seja melhor utilizar uma biblioteca de ícones open-source. Alguns exemplos:

Mesmo que você construa o seu próprio pacote ou use uma opção open-source, você deve padornizar e identificar padrões de uso. Também vale a pena considerar quem são os usuários finais do seu conjunto de ícones - designers, desenvolvedores e marketing?

Usando SVGs, você pode tornar a biblioteca de ícones sua única fonte de verdade. Seu processo pode ficar assim:

Os designers criam/fornecem SVGs puros.
Otimize e comprima os SVGs usando SVGO.
Crie automaticamente componentes React automaticamente usando SVGR pros desenvolvedores.
Gere PNGs e JPEGs em diferentes resoluções para marketing.
Gere SVGs em um bundled de fontes para ser usada em aplicativos mobile.

Escolha linguagens/frameworks para dar suporte

Quais linguagens ou frameworks você está mantendo atualmente? Qual deve ser o suporte da biblioteca de componentes? É importante pensar nisso com antecedência para que você possa arquitetar adequadamente sua biblioteca.

Se você tiver uma aplicação que usa script tags em vez de ES Modules, então precisará configurar sua biblioteca de componentes para fazer o bundle em um único arquivo. Por exemplo, uma aplicação com JavaScript puro precisaria de algo assim em um arquivo HTML.

<script src="/js/component-library.min.js"></script>

Para fazer isso, você pode usar Webpack ou Rollup. Eu recomendaria o Webpack, pois é o padrão de mercado. Eu também recomendo o TSDX se você quiser usar o TypeScript.

Avalie entre monorepo ou um único pacote

Um monorepo permite que você crie e publique várias bibliotecas de um único repositório. Embora resolva alguns problemas muito reais, também cria outros. É importante entender os prós e os contras.

O monorepo pode ser uma boa pois…

Pacotes pequenos através da diminuição do escopo dos componentes incluídos em um pacote.
Processo compartilhado de build, lint, teste e release para vários pacotes versus repositórios separados com código duplicado.
Controle mais granular do semver(versionamento semântico) pacote por pacote.

O monorepo pode não ser uma boa pois…

Ferramental e infraestrutura adicionais necessárias.
Quem estiver desenvolvendo será obrigado a importar uma variedade de pacotes em vez de uma única biblioteca de componentes.
Está no hype, tecnologia de ponta. O mercado está adotando, mas você pode se deparar com problemas que poucos experimentaram sem um caminho claro para uma solução.

Algumas perguntas que o ajudarão a identificar qual solução é a melhor para sua empresa:

Você tem múltiplos repositórios sendo publicados via NPM?
Seu processo de build, test, lint e infraestrutura complexos? Esse processo está duplicado em vários lugares?
Quantos repositórios você tem (ou planeja ter no próximo ano?)?
Quão grande é seu time? Quantos farão uso da biblioteca de componentes?
Será open-source? Você pode aprender com outras pessoas do mercado para ajudar a resolver problemas?
Você a vê a necessidade de múltiplos pacotes no futuro? (e.g. icons, codemods, etc).

Para empresas bem pequenas, eu diria que monorepos são desnecessários. Implementá-lo tem seu momento e lugar. Eu já usei em um lugar com 150 desenvolvedores para distribuir 10 pacotes diferentes de uma vez, abrangendo aplicativos internos e externos.

Avalie entre CSS/Sass e CSS-in-JS

CSS-in-JS é forma mais fácil para construir estilos e distribuir através do NPM. Para um bom desempenho, considere usar uma solução de tempo de execução quase zero, como Stitches.

Se a sua biblioteca de componentes precisar gerar HTML/CSS puros, eu recomendo ficar com o Sass. Um ótimo exemplo disso é o design system Carbon da IBM. Você pode usar variáveis CSS para conter seus design tokens.

<button class="bx--btn bx--btn--primary" type="button">Button</button>

Se você usa React, confira meu post Como eu deveria estilizar minha aplicação React?

Crie uma biblioteca de componentes

Com seus requisitos técnicos definidos e seu style guide iniciado, agora você poderá começar a construir uma biblioteca de componentes. Minha recomendação seria usar o *React juntamente * do Storybook.

Criar uma biblioteca de componentes é muito mais do que apenas traduzir o style guide em código.

Você precisa pensar em como quem utilizará seus componentes irão interagir com eles. Que tipo de API eles esperariam? O que fornece mais clareza e é autodocumentado? Por exemplo, considere botões. Você tem diferentes variações de botões - primário, secundário, etc.

Você deve ter um componente separado para cada tipo?

<PrimaryButton>Hello World!</PrimaryButton>
<SecondaryButton>Hello World!</SecondaryButton>

ou usar uma prop?

<Button>Hello World!</Button>
<Button variant="secondary">Hello World!</Button>

Continuando, como você deveria chamar essa prop? variant? type? Você chegou a considerar que type é uma atributo reservado do elemento HTML <button>? Esse é o tipo de decisão que você precisará fazer aos construir sua biblioteca de componentes.

Algumas outras coisas pra você considerar:

Você deveria permitir a quem usar sua biblioteca de passar propriedades CSS pro component React, ou eles deveriam ter que estender/wrappar componentes para alcançar o estilo desejado? Se você escolher o primeiro, considere styled-system.
Você deve construir um comportamento de loading direto no componente, ou deveria existir um componente genérico para isso (spinner, skeleton)?
Como vocoê deve testar de forma pura o visual de componentes? Teste de Snapshot? Visual diff testing?
Como os desenvolvedores precisarão fazer para integrar sua biblioteca de componentes? Deve haver uma redefinição de estilo global? Eles devem adicionar algum plugin do Babel?
Você deveria utilizar Conventional Commits para gerar automaticamente um changelog?
Seus componentes precisarão estar presentes no ambiente web e mobile? Considere usar o React Native Web para compartilhar seus componentes entre as plataformas.

Escolha uma plataforma de documentação

Você precisa de uma plataforma para exibir seu desygn sistem. Se você está apenas começando, eu recomendaria usar o Storybook Docs.

Essa combinação alcançará o resultado de outras plataformas semelhantes, como Docz, Styleguidist e Docusaurus.

Copie facilmente trechos de código de exemplos de componentes
Gere automaticamente uma tabela de props com base em prop-types e defaultProps
Facilmente veja as variações de um componente
Escreva documentação utilizando MDX

Se você é inflexível em seu design system refletindo sua marca e sua biblioteca de componentes, eu recomendaria uma solução personalizada usando MDX. Isso permitirá que você insira componentes React dentro de arquivos Markdown. O blog que você está lendo agora usa isso.

Ter uma solução verdadeiramente personalizada permite controle total sobre sua documentação. Um exemplo pelo qual estou extremamente impressionado é o Atomize React.

Escreva uma documentação do design system

Agora que você escolheu uma plataforma para documentar, é a hora de escrever. Você deve incluir:

Processo de instalação e configuração da biblioteca de componentes
Definições de props e types para cada componente
Exemplos de componentes junto com trechos de código copiáveis
Escolhas de tecnologia e racional das escolhas

Também considere colocar:

Uma sessão de "Começando" com um tutorial
Informações sobre como trabalhar com temas
Um code playground para interagir com os componentes
Modelos prontos de UI para escolher

Conclusão

Passei muito tempo no ano passado pensando em design systems. Construir uma biblioteca de componentes do zero me deu uma nova apreciação pela quantidade de trabalho que envolve o desenvolvimento front-end e o design. Abaixo, você encontrará uma lista de design systems que me inspiraram e servem como ótimas referências.

Sinta-se à vontade para entrar em contato se quiser conversar sobre a construção de design systems.

Referências

Design Systems

Programação AHA

Allan Ramos — Fri, 16 Dec 2022 13:59:45 +0000

Esse artigo é uma tradução do artigo original AHA Programming criado por Kent C. Dodds.

Veja minha talk: Programação AHA

DRY

DRY (um acrônimo para "Don't Repeat Yourself", traduzindo "Não se repita"), é um antigo princípio de software que a Wikipedia resume assim:

Cada porção de conhecimento em um sistema deve possuir uma representação única, de autoridade e livre de ambiguidades em todo o sistema.

Essa geralmente é uma boa prática que eu adoto(embora de forma menos dogmática do que a definição encoraja). O maior problema que tive com duplicação de código(aka copia/cola, basicamente a antítese do DRY) é perceber que tinha um bug, o corrigi, e depois encontrei esse bug de novo em outro lugar, e precisei consertá-lo novamente.

Teve uma vez que peguei um código que pegava pesado com essa duplicação de código, e precisei corrigir um bug em oito lugares diferentes! Pensa em alguém irritasdo! Abstrair esse código em uma função para ser chgamada de qualquer lugar, teria ajudado MUITO.

WET

Aqui outro conceito que a galera chamou de WET(Write Everything Twice, traduzindo "Escreva tudo duas vezes"). Ele é igualmente dogmático e normativo. Conlin Durbin a definiu como:

Você pode se perguntar "Eu não escrevi isso antes?" duas vezes, mas nunca três.

Nessa mesma codebase, existiam abstrações que chegavam ao extremo, mais atrapalhando do que ajudando. Era um código em AngularJS com muitos controllers, e era passado o this para uma função que poderia corrigir métodos e propriedades para this de uma forma aprimorando a instância do controller com certas habilidades. Uma espécie de pseudo-herança, eu acho. Foi SUPER confuso, difícil de entender, e eu fiquei com medo de fazer qualquer alteração nessa área da codebase.

O código foi reutilizado em muito mais que três lugares, mas a abstração era ruim e desejei que o código tivesse sido duplicado.

AHA

AHA (se pronuncia "Aha!" mesmo) é um acrônico que eu consegui de Cher Scarlett que significa

Avoid Hasty Abstractions(Evite abstrações precipitadas)

A maneira como penso nesse princípio foi lindamente descrita por Sandi Metz, que escreveu:

prefira duplicação a uma abstração errada

Essa é uma regra de ouro muito boa, e quero que você a leia novamente, então leia o post de Sandi sobre o assunto: A Abstração Errada. É fantástico.

Aqui está outro importante princípio relacionado que desejo te mostrar:

Optimize for change first
Otimize para mudar primeiro

Acho que o ponto chave é que não sabemos pra onde irá nosso código. Podemos investir semanas otimizando e deixando o código mais performático, ou criando a melhor API para nossa nova abstraçnao, apenas apra descobrir que no dia seguinte nós assumimos suposições erradas, e a API precisará ser completamente refeita, ou a funcionalidade para o qual o código foi escrito não é mais necessária. Não sabemos com certeza. Tudo o que podemos realmente ter certeza é que as coisas provavelmente mudarão, e se nunca mudarem, não tocaremos no código de qualquer maneira, então quem se importa com sua aparência?

Agora, não me entenda errado, não estou sugerindo anarquia. Estou sugerindo que devemos ficar atentos ao fato de que não sabemos quais requisitos serão colocados em nosso código no futuro.

Então, estou tranquilo com duplicação de código até que você esteja bem confiante dos casos de uso desse código duplicado. Quais partes do código são diferentes que dariam bons argumentos para sua função? assim que você tiver alguns lugares onde esse código está, as semelhanças gritarão com você por abstração e você estará no estado de espírito para fornecer essa abstração.

Se você abstrair cedo, porém, achará que a função ou componente é perfeito para seu caso de uso e, portanto, apenas dobrará o código para se adequar ao seu novo caso de uso. Isso continuará várias vezes até que a abstração seja basicamente toda a sua aplicação em instruções de if e loops 😂😭

Há alguns anos, fui contratado para revisar a codebase de uma empresa e usei uma ferramenta chamada jsinspect para identificar pedaços de código copiado/colado, e mostrar a eles oportunidades de abstração. Eles tinham um monte de código duplicado e, da minha perspectiva, era óbvio como as abstrações deveriam ser.

Acho que a grande lição sobre programação "AHA" é que você não deve ser dogmático sobre quando começar a escrever abstrações, mas sim escrever a abstração quando parecer certo, e não ter medo de duplicar o código até chegar lá.

Conclusão

Sinto que uma abordagem comedida e pragmática aos princípios de software é importante. Por isso eu prefiro AHA ao invés de DRY ou WET. Elá é focada em te ajudar a ficar ligado em suas abstrações, sem fornecer regras rígidas para quando é ou não certo abstrair algum código em uma função ou módulo.

Espero que tenha te ajudado. Se você está com abstrações ruins até o talo, fique de boas. A Sandi tem algumas dicas pra você de como sair disso! Basta ler a postagem de seu blog. Boa sorte!

Automatizando a criação de arquivos com Plop.js

Allan Ramos — Fri, 16 Dec 2022 13:19:07 +0000

Repetição que poderia não existir

Não é que eu me esforce muito para tal, mas criar sempre aquela mesma estruturinha e conteúdo base de arquivos é aquele tipo de tarefa que poderia não existir.

Segue abaixo um exemplo do que eu crio quando insiro um novo componente em meu projeto React:

//index.ts
export { MyComponent } from './MyComponent'
export type { MyComponentProps } from './MyComponent'

//MyComponent.tsx
import * as React from 'react'

export type MyComponentProps = {
  name: string
}

export const MyComponent = ({ name }: MyComponentProps) => (
  <p>
    { name }
  </p>
)

//MyComponent.stories.tsx
import * as React from 'react'
import { ComponentStory, ComponentMeta } from '@storybook/react'

import { MyComponent } from '.'
import type { MyComponentProps } from '.'

export default {
  title: 'Components/MyComponent',
  component: MyComponent,
} as ComponentMeta<typeof MyComponent>

const Template: ComponentStory<typeof MyComponent> = (args: MyComponentProps) => (
  <MyComponent {...args} />
)

export const Default = Template.bind({})
Default.args = {
  name: 'João Banana',
}

//MyComponent.test.tsx
import * as React from 'react'
import { render, screen } from '@testing-library/react'

import { MyComponent } from '.'
import type { MyComponentProps } from '.'

const defaultProps = {
  name: 'João Banana',
}

const selectors = {
  name: (name = defaultProps.name) => screen.getByText(name),
}

const renderComponent = (props: MyComponentProps = defaultProps) =>
  render(<MyComponent {...props} />)

  test('should render the component correctly', async () => {
    renderComponent()

    expect(selectors.name()).toBeInTheDocument()
  })

No final das contas o que eu tenho é um componente, arquivo do storybook e arquivo do teste. Por mais que cada componente seja diferente e os testes e suas propriedades mudem, existe uma base de código presente em todos.

Conhecendo o Plop.js

O Plop.js permite criarmos comandos para gerar arquivos com a estrutura que desejarmos.

Basta rodar um npm run plop para ver algo como a imagem abaixo, escrever algumas informações e ter toda aquela estrutura que mostrei anteriormente em uma pasta nova de meu projeto.

Instalando

npm install --save-dev plop

Insira o comando abaixo em seu package.json:

"plop": "plop"

Criando nosso gerador de componentes

Na raíz de seu projeto, crie o arquivo plopfile.js com o seguinte conteúdo:

const componentGenerator = require('./plop/component/index')

module.exports = function (plop) {
  componentGenerator(plop)
}

Estamos criando uma função que o Plop.js executará passando o objeto plop como parâmetro. Com esse objeto executaremos funções para criar nosso gerador.

Criando um arquivo gerador base para componentes

O que eu desejo com o Plop.js é que apenas com o nome de meu componente ele crie uma pasta com toda a estrutura de código e arquivos. Para isso, vamos criar um arquivo no caminho plop/component/index.js com o seguinte conteúdo:

module.exports = function (plop) {
  plop.setGenerator('component', {
    description: 'this is a skeleton plopfile',
    prompts: [], // array com perguntas que serão mostradas no terminal
    actions: []  // array de ações para serem executadas após respoder as perguntas
  });
};

Esse é o conteúdo base de um gerador. Você usa a função setGenerator com 2 parâmetros. O primeiro, o nome do gerador, e o segundo, um objeto com 3 opções:

description: descrição do gerador;
prompts: array com perguntas que serão mostradas no terminal;
actions: array de ações para serem executadas após respoder as perguntas.

Sabendo disso, vamos começar a primeira e única pergunta de nosso gerador, que é saber qual o nome do componente:

module.exports = function (plop) {
  plop.setGenerator('component', {
    description: 'React component generator',
    prompts: [
      {
        type: 'input',
        name: 'component_name',
        message: 'Enter the component name: '
      }
    ],
  })
};

Com esse código estamos configurando justamente isso que você está vendo. Um input com o texto "Enter the component name:" e com o nome "component_name", que usaremos nas actions.

Para finalizarmos essa parte, agora precisamos definir as ações. O que eu desejo é que sejam criados 4 arquivos diferentes, cada um com sua configuração e código diferente. Para isso, vamos deixar o código assim:

module.exports = function (plop) {
  plop.setGenerator('component', {
    description: 'React component generator',
    prompts: [
      {
        type: 'input',
        name: 'component_name',
        message: 'Enter the component name: '
      }
    ],
    actions: [
      {
        type: 'add',
        path: './src/components/{{pascalCase component_name}}/index.ts',
        templateFile: 'plop/component/index-template.hbs'
      },
      {
        type: 'add',
        path: './src/components/{{pascalCase component_name}}/{{pascalCase component_name}}.tsx',
        templateFile: 'plop/component/component-template.hbs'
      },
      {
        type: 'add',
        path: './src/components/{{pascalCase component_name}}/{{pascalCase component_name}}.stories.tsx',
        templateFile: 'plop/component/stories-template.hbs'
      },
      {
        type: 'add',
        path: './src/components/{{pascalCase component_name}}/{{pascalCase component_name}}.test.tsx',
        templateFile: 'plop/component/test-template.hbs'
      }
    ]
  })
};

Vamos entender cada um das chaves presentes nesse objeto:

type: 'add': estou dizendo que desejo adicionar um único arquivo em determinado caminho de meu projeto;
path: './src/components/{{pascalCase component_name}}/index.ts': aqui eu informo o caminho de meu arquivo, e perceba uma coisa, como desejo criar o arquivo index.ts dentro de uma nova pasta, eu preciso pegar o nome do componente que foi colocado na CLI, e para isso coloco seu nome(component_name) entre colchetes duplos. Como desejo que a pasta siga o padrão PascalCase, coloco essa informação com espaço antes do valor que desejo formatar.
templateFile: 'plop/component/index-template.hbs': o caminho do arquivo de template que será usado para criar esse arquivo.

Criando nossos templates de arquivos

Para usar o código abaixo crie o arquivo index-template.hbs na raíz de plop/component/.

//index-template.hbs
export { {{pascalCase component_name}} } from './{{pascalCase component_name}}'

Os valores obtidos no preenchimento pela CLI também estão disponíveis aqui, e também com funções de formatação.

//component-template.hbs
import * as React from 'react'

export type {{pascalCase component_name}}Props = {
  name: string;
}

export const {{pascalCase component_name}} = ({ name }: {{pascalCase component_name}}Props) => (
  <p>
    { name }
  </p>
)

//stories-template.hbs
import * as React from 'react'
import { ComponentStory, ComponentMeta } from '@storybook/react'

import { {{pascalCase component_name}} } from './{{pascalCase component_name}}'
import type { {{pascalCase component_name}}Props } from './{{pascalCase component_name}}'

export default {
  title: 'Components/{{pascalCase component_name}}',
  component: {{pascalCase component_name}},
} as ComponentMeta<typeof {{pascalCase component_name}}>

const Template: ComponentStory<typeof {{pascalCase component_name}}> = (args: {{pascalCase component_name}}Props) => (
  <{{pascalCase component_name}} {...args} />
)

export const Default = Template.bind({})
Default.args = {
  name: 'João Banana',
}

//test-template.hbs

import * as React from 'react'
import { render, screen } from '@testing-library/react'

import { {{pascalCase component_name}} } from '.'
import type { {{pascalCase component_name}}Props } from '.'

const defaultProps = {
  name: 'João Banana',
}

const selectors = {
  name: (name = defaultProps.name) => screen.getByText(name),
}

const renderComponent = (props: MyComponentProps = defaultProps) =>
  render(<MyComponent {...props} />)

test('should render the component correctly', async () => {
  renderComponent()

  expect(selectors.name()).toBeInTheDocument()
})

useEffect vs useLayoutEffect

Allan Ramos — Thu, 03 Feb 2022 12:16:14 +0000

Esse artigo é uma tradução do artigo original useEffect vs useLayoutEffect criado por Kent C. Dodds.

Ambas opções podem ser usadas para fazer a mesma coisa, mas elas tem casos de uso ligeiramente diferentes. Então, aqui estão algumas regras para você considerar ao decidir qual React Hook usar.

useEffect

99% das vezes é esse que você precisará usar. Quando seus hooks são estáveis e você refatora as suas class components para hooks, aos poucos você irá mudar códigos de componentDidMount, componentDidUpdate e componentWillUnmount para useEffect.

O único problema dele é ser apenas executado após o React renderizar seu componente, garantindo que ele não bloqueie a renderização do navegador. Isso é diferente do comportamento de class components onde componentDidMount e componentDidUpdate rodam de forma síncrona após a renderização. É mais eficiente dessa maneira e na maioria das vezes é isso que você precisará.

Entretanto, se o uso desse hook estiver mudando o DOM(via DOM node ref) e a mutação do DOM alterar a aparência do nó do DOM entre o momento que ele é renderizado e o momento que seu hook o altera, então você não deseja usar o useEffect. Você na verdade quer usar o useLayoutEffect. Caso contrário, o usuário poderá ver uma mudança rápida na interface quando suas mudanças do DOM forem realizadas. Essa é praticamente a única vez que você deseja evitar useEffect e usar useLayoutEffect em vez disso.

useLayoutEffect

Executado de forma síncrona imediatamente após o React fazer todas as alterações no DOM. Pode ser útil se você precisar fazer medições DOM (como obter a posição de rolagem ou outros estilos para um elemento) e depois fazer alterações no DOM ou acionar uma nova renderização síncrona atualizando o estado.

No que diz respeito ao momento, ele funciona da mesma forma que componentDidMount e componentDidUpdate. Seu código é executado imediamente após o DOM ser atualizado, mas antes que o navegador tenha a chance de "renderizar" essas alterações (o usuário não vê as atualizações até que o navegador tenha re-renderizado).

Resumo

useLayoutEffect: Se você precisar alterar o DOM e/ou precisar realizar medições.
useEffect: Se você não precisa interagir com o DOM ou suas alterações no DOM não são observáveis (sério, na maioria das vezes você deve usar isso).

Um caso diferente

Um caso onde você possa querer usar useLayoutEffect ao invés de useEffect é quando você está atualizando um valor(como ref) e você quer ter certeza de que está atualizado antes que qualquer outro código seja executado. Exemplo:

const ref = React.useRef()
React.useEffect(() => {
  ref.current = 'valor qualquer'
})

// depois, em outro hook ou algo do tipo
React.useLayoutEffect(() => {
  console.log(ref.current) // <-- isso aqui loga o valor antigo pois é executado primeiro!
})

Em casos como esse, use useLayoutEffect.

Conclusão

É tudo sobre padrões. O comportamento padrão é permitir que o navegador renderize novamente com base nas atualizações do DOM antes que o React execute seu código. Isso significa que seu código não bloqueará o navegador e o usuário verá as atualizações do DOM mais cedo. Portanto, fique com useEffect na maioria das vezes.

Explicando a coerção de tipos em Javascript

Allan Ramos — Thu, 15 Apr 2021 14:44:12 +0000

Esse texto é uma tradução livre do artigoJavaScript type coercion explaineddeAlexey Samoshkin.

[Edit 02/05/2018]: Esse post estádisponível em Russo. Palmas aSerj Bulavykpor seus esforços.

Coerção de tipos (type coercion)é o processo de conversão de um valor de um tipo, para outro (como a conversão de uma string para um número, um objeto para um booleano e etc). Qualquer tipo, seja primitivo ou um objeto, é um sujeito válido para coerção de tipo. Para recordar, os primitivos são: number, string, booleano, null, undefined + Symbol (adicionado no ES6).

Como um exemplo de coerção de tipo em prática, veja o linkJavaScript Comparison Table, que mostra como o operador de igualdade==se comporta para diferentes tipos. Essa matriz parece assustadora devido à coerção de tipo implícita que o operador==faz, e dificilmente será possível lembrar de todas essas combinações. E você não precisa fazer isso — apenas aprenda os princípios básicos da coerção de tipos.

Esse artigo vai a fundo de como a coerção de tipos funciona no Javascript, e irá prepará-lo com o conhecimento básico para que você possa sentir-se confiante ao explicar sobre as expressões. Ao final do artigo, mostrarei as respostas e as explicarei.

true + false
12 / "6"
"number" + 15 + 3
15 + 3 + "number"
[1] > null
"foo" + + "bar"
'true' == true
false == 'false'
null == ''
!!"false" == !!"true"
[‘x’] == ‘x’
[] + null + 1
[1,2,3] == [1,2,3]
{}+[]+{}+[1]
!+[]+[]+![]
new Date(0) - 0
new Date(0) + 0

Sim, essa é uma lista boba de coisas que você pode fazer como desenvolvedor. Em 90% dos casos é melhor evitar a coerção de tipos implícita. Considere essa lista como exercícios para aprendizagem para testar seu conhecimento de como a coerção de tipos funciona. Se estiver entendiado, você pode encontrar mais emwtfjs.com.

A propósito, você pode encontrar perguntas disso em entrevistas para vagas de Javascript. Então continue lendo 😄.

Coerção Implícita vs Explícita

Coerção de tipos pode ser explícita ou implícita.

Quando um desenvolvedor deseja converter um tipo escrevendo algo como,Number(valor), isso é chamado de*coerção de tipos explícita(explicit type coercionoutype casting.*

Já que o Javascript é uma linguagem fracamente tipada (weakly-typed language), valores também podem ser convertidos entre diferentes tipos automaticamente, e isso é chamado de*coerção de tipos implícita (implicit type coercion).*Isso acontece quando você atribui operados para valores de diferentes tipos, como1 == null,2/’5',null + new Date(), ou isso pode decorrer do contexto, como usarif (value) {…}, ondevalueé forçado a retornar um booleano.

Um operador que não desencadeia a coerção de tipos implítica é===, que é chamado de operador restrito de igualdade (strict equality operator). O operador de igualdade==por outro lado, faz a comparação e ativa a coerção de tipos, se necessário.

Coerção de tipo implícito é uma faca de dois gumes: é uma grande fonte de frustração e defeitos, mas também um mecanismo útil que nos permite escrever menos código sem perder a legibilidade.

Três tipos de conversão

A primeira regra que precisamos saber é que existem apenas 3 tipos de conversão no Javascript:

para string;
para boolean;
para number.

A segunda, é que a lógica para conversão de tipos primitivos e objetos funcionam de forma diferente, mas ambos só podem ser convertido nessas 3 maneiras.

Vamos começar primeiro com os primitivos.

Conversão de String

Para indicar a conversão explícita de valores para string use a funçãoString(). A coerção implícita é ativada pelo operador binário+, quando qualquer operando é uma string:

String(123) // explícito
123 + ''    // implícito

Todos os valores primitivos são convertidos em strings naturalmente, como você poderia esperar:

String(123)                   // '123'
String(-12.3)                 // '-12.3'
String(null)                  // 'null'
String(undefined)             // 'undefined'
String(true)                  // 'true'
String(false)                 // 'false'

A conversão de Symbol é um pouco complicada, porque só pode ser convertida explicitamente, mas não implicitamente. Leia mais nas regras de coerção de tipos doSymbol.

String(Symbol('my symbol'))   // 'Symbol(my symbol)'
'' + Symbol('my symbol')      // TypeError é lançado

Conversão de Boolean

Para indicar a conversão explícita de valores para boolean use a funçãoBoolean(). A conversão implícita ocorre no contexto lógico ou é ativada por operadores lógicos (||&&!) .

Boolean(2)          // explícito
if (2) { ... }      // implícito devido ao contexto lógico
!!2                 // implícito devido ao operador lógico
2 || 'hello'        // implícito devido ao operador lógico

Observação: Operadores lógicos como||e&&fazem conversões booleanas internamente, masna verdade retornam o valor dos operandosoriginais, mesmo que eles não sejam booleanos.

// retorna o número 123 ao invés de true
// 'hello' e 123 são convertidos para boolean internamente para calcular a expressão
let x = 'hello' && 123;   //x === 123 é true

Assim que houver apenas dois resultados possíveis da conversão booleana:trueoufalse, é mais fácil lembrar a lista de valores falsos (falsy values).

Boolean('')           // false
Boolean(0)            // false     
Boolean(-0)           // false
Boolean(NaN)          // false
Boolean(null)         // false
Boolean(undefined)    // false
Boolean(false)        // false

Qualquer valor não inserido nessa lista ao ser convertido serátrue, incluindo objetos, funções,Array,Date, tipos definidos pelo usuário e assim por diante. Symbols são considerados como valores verdadeiros (truthy values). Objetos vazios e arrays também:

Boolean({})             // true
Boolean([])             // true
Boolean(Symbol())       // true
!!Symbol()              // true
Boolean(function() {})  // true

Conversão Numérica

Para uma conversão explícita aplique a funçãoNumber(), assim como feito comBoolean()eString().

A conversão implícita é complicada, pois é acionada em mais casos:

operadores de comparação (comparison operators)(>,<,<=,>=)
operadores bitwise (|&^~)
operadores aritméticos (-+*/%). Saiba que usar+não irá ativar a conversão numérica quando qualquer operando for uma string.
operador unário+
operador de igualdade==(incl.!=).\ Perceba que==não ativa a conversão numérica quando ambos operandos são strings.

Number('123')   // explícito
+'123'          // implícito
123 != '456'    // implícito
4 > '5'         // implícito
5/null          // implícito
true | 0        // implícito

Abaixo como valores primitivos são convertido para números:

Number(null)                   // 0
Number(undefined)              // NaN
Number(true)                   // 1
Number(false)                  // 0
Number(" 12 ")                 // 12
Number("-12.34")               // -12.34
Number("\n")                   // 0
Number(" 12s ")                // NaN
Number(123)                    // 123

Ao converter uma string em número, a engine primeiro remove os espaços em branco com os caracteres\ne\t, retornandoNaNse a string tratada não representar um número válido. Se a string estiver vazia, retornará0.

nulleundefinedsão tratados de forma diferentes:nullvira 0, enquantoundefinedse tornaNaN.

Symbols não podem ser convertidos em números nem explicitamente nem implicitamente. Além disse,TypeErroré lançado ao invés de silenciosamente converter paraNaN, como acontece paraundefined. Veja mais sobre as regras de conversão de símbolo no MDN.

Number(Symbol('my symbol'))    // TypeError é lançado
+Symbol('123')                 // TypeError é lançado

Existem*duas regras especiais*para relembrar:

Quando aplicamos==paranullouundefined, a conversão numérico não ocorre.nullé apenas igual anullouundefined, e não é igual a mais nada.

null == 0               // false, null is not converted to 0
null == null            // true
undefined == undefined  // true
null == undefined       // true

2.NaNnão é igual a nada que não seja ele mesmo:

if (value !== value) { console.log("we're dealing with NaN here") }

Coerção de tipos para objetos

Até agora, analisamos a coerção de tipos para valores primitivos. Isso não é muito empolgante.

Quando isso ocorre com objetos, e a engine encontra expressões como[1] + [2,3], primeiramente será preciso converter o objeto para um valor primitivo, que é então convertido pro tipo final. E ainda assim existem apenas três tipos de conversão: numérico, string e booleano.

O caso mais simples é a conversão para booleano: qualquer valor não primitivo sempre será convertido paratrue, não importa se um objeto ou array está vazio ou não.

Objetos são convertidos para primitivos através da função[[ToPrimitive]], que é responsável pela conversão numérica e string.

Abaixo uma pseudo implementação do método[[ToPrimitive]]:

function ToPrimitive(input, preferredType){

  switch (preferredType){
    case Number:
      return toNumber(input);
      break;
    case String:
      return toString(input);
      break
    default:
      return toNumber(input);  
  }

  function isPrimitive(value){
    return value !== Object(value);
  }

  function toString(){
    if (isPrimitive(input.toString())) return input.toString();
    if (isPrimitive(input.valueOf())) return input.valueOf();
    throw new TypeError();
  }

  function toNumber(){
    if (isPrimitive(input.valueOf())) return input.valueOf();
    if (isPrimitive(input.toString())) return input.toString();
    throw new TypeError();
  }
}

[[ToPrimitive]]é invocado passando dois argumentos:

input: valor a ser convertido;
preferredType: Tipo escolhido para conversão, podendo serNumberouString. Esse argumento é opcional.

Ambas conversões, número e string fazem uso de dois métodos do objeto de entrada (input):valueOfetoString. Ambas funções são declaradas noObject.prototypee, portanto, disponível para qualquer tipo derivado, comoDate,Array, e etc.

Em geral, o algoritmo é o seguinte:

Se o input já é do tipo primitivo, retorne-o;
Chame a funçãoinput.toString(), se o resultado for do tipo primitivo, retorne-o;
Chame a funçãoinput.valueOf(), se o resultado for do tipo primitivo, retorne-o;
Se nem a funçãoinput.toString()ouinput.valueOf()retornar um tipo primitivo, lanceTypeError.

Conversões numéricas primeiro chamam a funçãovalueOf(3) com o fallbacktoString(2).

A conversão de string faz exatamente o oposto:toString(2) seguido devalueOf(3).

A maioria dos tipos internos(built-in) não possui a funçãovalueOf, ou possuivalueOfretornando o próprio objeto, então é ignorado por não ser do tipo primitivo. É por isso que a conversão de tiposnumberestringpodem funcionar da mesma forma — ambos acabam chamandotoString().

Operadores diferentes podem acionar a conversão numérica ou de string com a ajuda do parâmetropreferredType. Mas existem duas exceções: o comparador de igualdade abstrato==e a opção binária+acionam modos de conversão padrão (preferredTypenão é especificado, ou igual adefault). Nesse caso, a maior dos tipos internos(built-in) assumirão uma conversão numérica como default, excetoDateque fará uma conversão de string.

Segue abaixo um exemplo de como se comporta uma conversa deDate:

let d = new Date();

// obtém a representação em string
let str = d.toString();  // 'Wed Jan 17 2018 16:15:42'

// obtém a representação numérica, número em milisegundos desde a época do Unix
let num = d.valueOf();   // 1516198542525

// comparara com uma representação de string
// é true, pois "d" foi convertido para a mesma string
console.log(d == str);   // true

// compara com a representação numérica
// false, pois d não foi convertido para um número usando valueOf()
console.log(d == num);   // false

// O resulado é 'Wed Jan 17 2018 16:15:42Wed Jan 17 2018 16:15:42'
// '+' funcional igual ao '==', aciona o modo padrão de conversão
console.log(d + d);

// O resultado é 0, pois o operador '-' aciona explicitamente a conversão numérica, não a padrão
console.log(d - d);

Você pode sobrescrever os métodos padrãotoString()evalueOf()para conectar-se à lógica de conversão objeto para primitivo(object-to-primitive).

var obj = {
  prop: 101,
  toString(){
    return 'Prop: ' + this.prop;
  },
  valueOf() {
    return this.prop;
  }
};

console.log(String(obj));  // 'Prop: 101'
console.log(obj + '')      // '101'
console.log(+obj);         //  101
console.log(obj > 100);    //  true

Observe comoobj + ‘’retorna'101'como uma string. O operador+dispara um modo de conversão padrão, e como dito anteriormente,Objectassume a conversão numérico como padrão, usando portanto, o métodovalueOf()ao invés dotoString().

Método do ES6 - Symbol.toPrimitive

No ES5 você pode conectar a lógica de conversão de objeto a primitivo(object-to-primitive) substituindo os métodostoStringevalueOf.

No ES6 você pode ir mais longe, podendo substituir completamente a rotina interna[[ToPrimitive]]implementando o método[Symbol.toPrimtive]em um objeto.

class Disk {
  constructor(capacity){
    this.capacity = capacity;
  }

  [Symbol.toPrimitive](hint){
    switch (hint) {
      case 'string':
        return 'Capacity: ' + this.capacity + ' bytes';

      case 'number':
        // convert to KiB
        return this.capacity / 1024;

      default:
        // assume numeric conversion as a default
        return this.capacity / 1024;
    }
  }
}

// 1MiB disk
let disk = new Disk(1024 * 1024);

console.log(String(disk))  // Capacity: 1048576 bytes
console.log(disk + '')     // '1024'
console.log(+disk);        // 1024
console.log(disk > 1000);  // true

Exemplos

Sabendo a teoria, agora vamos aos exemplos:

true + false             // 1
12 / "6"                 // 2
"number" + 15 + 3        // 'number153'
15 + 3 + "number"        // '18number'
[1] > null               // true
"foo" + + "bar"          // 'fooNaN'
'true' == true           // false
false == 'false'         // false
null == ''               // false
!!"false" == !!"true"    // true
['x'] == 'x'             // true 
[] + null + 1            // 'null1'
[1,2,3] == [1,2,3]       // false
{}+[]+{}+[1]             // '0[object Object]1'
!+[]+[]+![]              // 'truefalse'
new Date(0) - 0          // 0
new Date(0) + 0          // 'Thu Jan 01 1970 02:00:00(EET)0'

Abaixo, você encontrará explicações para cada expressão.

O operador binário+aciona a conversão numérica gerando o resultadotrueoufalse.

true + false
==> 1 + 0
==> 1

O operador aritmético/aciona a conversão numérico para a string'6':

12 / '6'
==> 12 / 6
==>> 2

O operador+possui uma associação de leitura a partir da esquerda para a direita (left-to-right associativity), portanto a expressão"number" + 15é executada primeiro. Desde que o primeiro operando é uma string, o operador+aciona a conversão para string do número 15. No segundo passo, a expressão"number15" + 3é tratada da mesma forma.

"number" + 15 + 3 
==> "number15" + 3 
==> "number153"

A expressão15 + 3é avaliada primeiro. Já que ambos operandos são numéricos, não é preciso fazer a coerção dos tipos. Mas na segunda expressão, quando18 + 'number'é avalido, ao verificar que um dos operandos é uma string, ele aciona a conversão para string.

15 + 3 + "number" 
==> 18 + "number" 
==> "18number"

O operador de comparação>acionada a conversão numérica para[1]enull.

[1] > null
==> '1' > 0
==> 1 > 0
==> true

O operador unário+tem maior precedência ao operador binário+. Então a expressão+'bar'é avaliada primeiro. O operador unário aciona a conversão numérica para a string'bar'. Já que a string não apresenta um número válido, o resultado seráNaN. Na segunda etapa, a expressão'foo' + NaNserá avaliada.

"foo" + + "bar" 
==> "foo" + (+"bar") 
==> "foo" + NaN 
==> "fooNaN"

O operador==aciona a conversão numérica, a stringtrueé convertida paraNaN, o booleanotrueé convertido para 1.

'true' == true
==> NaN == 1
==> false

false == 'false'   
==> 0 == NaN
==> false

O operador==normalmente aciona a conversão numérica, mas não é o caso quando é colocadonull.nullé igual apenas anullouundefined.

null == ''
==> false

O operador!!converter ambas strings'true'e'false'para o booleanotrue, já que eles não são strings vazias. Então,==apenas verifica a igualdade de dois booleanostruesem qualquer coerção.

!!"false" == !!"true"  
==> true == true
==> true

O operador==aciona a conversão numérica para um array. O método do arrayvalueOf()retorna o próprio array, e é ignorado por não ser um primitivo. A função do arraytoString()converte['x']para a string'x'.

['x'] == 'x'  
==> 'x' == 'x'
==>  true

O operador+aciona uma conversão numérica para[]. A função do arrayvalueOf()é ignorado, pois retorna a si mesmo, cujo valor não é primitivo. A função do arraytoString()retorna uma string vazia.

Na segunda expressão'' + null + 1é avaliada.

[] + null + 1  
==>  '' + null + 1  
==>  'null' + 1  
==> 'null1'

Os operadores lógicos||e&&fazem coerção para booleano, mas retornando os operandos originais — não valores booleanos.0é falso(falsy), enquanto'0'é verdadeiro(truthy), pois não é uma string vazia. Um objeto vazio{}também retorna verdadeiro(truthy).

0 || "0" && {}  
==>  (0 || "0") && {}
==> (false || true) && true  // internamente
==> "0" && {}
==> true && true             // internamente
==> {}

Não é preciso fazer coerção pois ambos operandos são do mesmo tipo. Desde que==verifica a identidade do objeto (object identity), e não sua igualdade (object equality), o resultado seráfalse, por conta dos 2 arrays serem de instâncias diferentes.

[1,2,3] == [1,2,3]
==>  false

Todos os operandos são valores não primitivos, portanto,+inicia a conversão numérica com o item mais a esquerda. A funçãovalueOfde ambos objetos e arrays retornarão a si mesmo, e serão ignorados. O métodotoString()é usado como fallback. A pegadinha aqui é que{}não é considerado um objeto literal, mas sim como um bloco de declaração de estado, então é ignorado. A avaliação começará com a próxima expressão+ [], que será convertido para uma string vazia através do métodotoString(), e então para0.

{}+[]+{}+[1]
==> +[]+{}+[1]
==> 0 + {} + [1]
==> 0 + '[object Object]' + [1]
==> '0[object Object]' + [1]
==> '0[object Object]' + '1'
==> '0[object Object]1'

Esse é mais fácil de explicar, pois o passo a passo de sua resolução se dará de acordo com a precedência do operador.

!+[]+[]+![]  
==> (!+[]) + [] + (![])
==> !0 + [] + false
==> true + [] + false
==> true + '' + false
==> 'truefalse'

O operador-acionará a conversão numérica paraDate. A funçãoDate.valueOf()retornará o número de milissegundos desde a época do Unix.

new Date(0) - 0
==> 0 - 0
==> 0

O operador+acionará a conversão padrão.Dateassumirá uma conversão para string, portanto o métodotoString()será utilizado, ao invés dovalueOf().

new Date(0) + 0
==> 'Thu Jan 01 1970 02:00:00 GMT+0200 (EET)' + 0
==> 'Thu Jan 01 1970 02:00:00 GMT+0200 (EET)0'

Rápidas explicações

O que é um operador unário e binário?

Unário: aquele que interage sobre um elemento. Ex: +, -, ++.
Binário: aquele que interage sobre dois elementos. Ex: +, -, *, /, &, &&.

Referências

Recomendo o excelente livro“Understanding ES6” escrito porNicholas C. Zakas. É uma grande fonte para aprender ES6, não é tão avançado, e não fica muito tempo em partes mais profundas.

E aqui um ótimo livro de ES5 —SpeakingJSwritten porAxel Rauschmayer.

(Russian) Современный учебник Javascript —https://learn.javascript.ru/. Especiallythese twopages on type coercion.

JavaScript Comparison Table —https://dorey.github.io/JavaScript-Equality-Table/

wtfjs — a little code blog about that language we love despite giving us so much to hate —https://wtfjs.com/

https://codeburst.io/javascript-quickie-what-is-type-coercion-74f19df6d16f

https://medium.com/codezillas/let-me-coerce-you-into-liking-javascripts-dynamic-typing-system-3cd22c19cb64

https://medium.com/intrinsic/javascript-object-type-coercion-b2ec176c02c4

https://hackernoon.com/understanding-js-coercion-ff5684475bfc

Um guia para entender JavaScript hoisting 🚩com variáveis usando let e const

Allan Ramos — Thu, 15 Apr 2021 14:42:44 +0000

Esse artigo é uma livre tradução do artigoA guide to JavaScript variable hoisting 🚩 with let and const, porBhuvan Malik

Novos desenvolvedores de JavaScript geralmente têm dificuldade em entender o comportamento exclusivo do hoisting de*variáveis*/funções.

Já que vamos falar sobre declarações devar, leteconstmais tarde, é importante entender o içamento (hoisting) de variáveis em vez do içamento (hoisting) de funções. Vamos mergulhar!

O que é içamento de variável (variable hoisting)?

A engine do Javascript trata todas as variáveis declaradas comvarcomo se fossem declaradas no topo do escopo de uma função (se colocadas dentro de uma), ou no topo do escopo global (se declaradas fora de uma função), independentemente de onde a declaração real ocorrer. Isso essencialmente é “hoisting”.

Então, variáveis podem realmente estar disponíveis antes de sua declaração.

Vamos ver essa parada em ação…

// Saída (Output): undefined
console.log(shape);

var shape = "square";

// Saída (Output): "square"
console.log(shape);

Se você está vindo de linguagens baseadas em C, você estava esperando que um erro fosse lançado ao chamar o primeiroconsole.log, já que a variávelshapenão foi definida naquele momento. Entretanto, o interpretador do Javascript vai além, e iça (hoists) todas as declarações de variáveis pro top, e a suas inicializações permanecem no mesmo local.

É isso que acontece por baixo dos panos:

//a declaraçã da variável é içada (hoisted)
var shape;

// Saída (Output): undefined
console.log(shape);

shape = "square";

// Saída (Output): "square"
console.log(shape);

Abaixo está outro exemplo, dessa vez no escopo de uma função para deixar as coisas mais claras:

function getShape(condition) {
// shape existe aqui com o valor "undefined"
// Saída (Output): undefined
console.log(shape);

if (condition) {
        var shape = "square";
        // outro código qualquer
        return shape;
    } else {
        // shape existe aqui com o valor "undefined"
        return false;
    }
}

Perceba que no exemplo acima a declaração deshapeé içada (hoisted) para o topo da funçãogetShape. Isso acontece pois os blocosif/elsenão criam escopos locais como vemos em outras linguagens. O escopo local é essencialmente o escopo de um função em JavaScript. Portanto, “shape” é acessível em todos os lugares fora do bloco if e dentro da função com um valor “undefined”.

Esse comportamento padrão do JavaScript tem suas vantagens e desvantagens. Não entender completamente isso pode levar a bugs sutis, mas perigosos, em nosso código.

Declarações no Nível do Bloco (Block-Level Declarations)

O*ES6*introduziu escopos no nível de bloco (block-level scoping) para prover aos desenvolvedores maior controle e flexibilidade sobre o ciclo de vida de uma variável.

Declarações no Nível do Bloco (Block-Level Declarations) são feitas em blocks/escopos léxicos que são criadas dentro do block{}.

Declaração com “let”

Essa syntax é similar avar, apenas troquevarporletpara declarar uma variável para que seu escopo fique apenas naquele bloco.

Coloque a declaração do seuletno topo do bloco para que ele esteja disponível para o bloco inteiro.

Exemplo:

function getShape(condition) {
// shape não existe aqui
// console.log(shape); => ReferenceError: shape is not defined
if (condition) {
        let shape = "square";
        // algum có
        return shape;
    } else {
        // shape também não existe
        return false;
    }
}

Perceba comoshapeexiste apenas dentro do block doif, e como um erro é lançado quando é feita a tentiva de acesso for dele, lançando umundefinedcomo vimos anteriormente quando usamosvar.

Observação:Se um identificador já foi definido dentro do escopo comvar, usando o mesmo identificador comoletdentro desse escopo lançará um erro. Além disso, nenhum erro será mostrado se uma declaraçãoletcriar uma variável com o mesmo nome de uma variável em seu escopo externo. (Este caso é o mesmo ao usarconst).

Por exemplo:

var shape = "square";

let shape = "rectangle";

// SyntaxError: Identifier 'shape' has already been declared

var shape = "square";

if (condicao) {
    // não lança um erro
    let shape = "rectangle";
    // mais código
}

// Sem erro

Declaração com “const”

A syntax dessa declaração é similar alet&var, o ciclo de vida(lifecycle) é o mesmo que o dolet, mas você precisa seguir certas regras.

Todaconsté tratada como*constantes*, e, portanto, ela não pode ter seu valore reatribuído após ser definida. Devido a isto, todaconstdeve ser inicializada no momento da declaração.

Exemplo:

// válido 
const shape = "triangle";
// syntax error: missing initialization

const color;
// TypeError: Assignment to constant variable

shape = "square"

Entretando, propriedades de um objeto podem ser alteradas!

const shape = {
    name: "triangle",
    sides: 3
}

// FUNCIONA
shape.name = "square";
shape.sides = 4;

// SyntaxError: Invalid shorthand property initializer
shape = {
    name: "hexagon",
    sides: 6
}

No exemplo acima podemos ver que as propriedades do objetoshapepuderem ser alteradas pois nós mudamos apenas o que ela contém, e não o que está vinculado, como em uma string, por exemplo.

Podemos resumir dizendo queconstimpede a modificação da ligação(binding) como um todo — não o valor ao qual ela está vinculada.

Observação: Propriedades podem ser alteradas. Para uma real imutabilidade user Object.Freeze, Immutable.js ou Mori.

A zona temporal morta

Agora sabemos que acessar uma variável comletouconstantes de ser declarada lançará umReferenceError. Esse período entre a entrada do escopo e a declaração de onde eles não podem ser acessados é chamado de Zona Temporal Morta (Temporal Dead Zone).

Perceba que a “Zona Temporal Morta” não é formalmente mencionada nas especificações do ECMAScript, é apenas um termo popular entre os programadores.

Eu pessoalmente recomendo que sempre useconst, pois gera menos bugs. Atualmente eu raramente encontro uma situação onde precise usar ovar.

Como regra geral, useletsomente para contadores de loop ou se você realmente precisará alterar o valor da variável depois. Pra qualquer outro caso, vá deconst. Pessoalmente eu abandonei loops para usar filter (), map () & reduce (). Você deveria também.

Fica esperto e veja a 2a parte em “Function Hoisting & Questões importantes de hoisting em processos seletivos”.

https://medium.freecodecamp.org/function-hoisting-hoisting-interview-questions-b6f91dbc2be8

Cliqueaquipara ver meus artigos sobre as úteis features do ES6 relacionadas a funções.

O que é Hoisting em Javascript?

Allan Ramos — Thu, 15 Apr 2021 14:42:14 +0000

Esse artigo é uma tradução livre deWhat is Hoisting in Javascript?, porSunil Sandhu.

Uma das muitas peculiaridades do Javascript é algo conhecido como*hoisting*.

Se você começou a desenvolver recentemente com Javascript, é bem provável que você ainda não esteja escrevendo seu código perfeitamente. Então, por causa disso, é altamente provável que seu*hoisting*não esteja perfeito também.😉

O que é hoisting?

Basicamente, quando o Javascript compila todo seu código, todas as declarações de variáveis usandovarsão hoistiadas(abrasilerei)/levadas ao topo de suas funções/escopo local (se declaradas dentro de uma função), ou ao topo do escopo global (se declaradas fora de uma função) independentemente de onde a declaração foi feita. Isto é o que queremos dizer com “hoisting”.

As declarações de funções também são hoistiadas, mas elas irão para a parte mais alta do escopo, por isso ficará acima de todas as declarações de variáveis.

Chega de conversinha, vamos ver alguns exemplos básicos para demonstrar o impacto do hoisting.

Se escrevermos o seguinte código:

console.log(meuNome);

var meuNome= 'Bob';

Pop quiz! O que o comandoconsole.logmostrará?

1.Uncaught ReferenceError: meuNome is not defined

2.Bob

3.undefined

A terceira opção é realmente a resposta correta.

Como falei anteriormente, as variáveis são movidas pro topo de seus escopos\
quando seu Javascript compila em tempo de execução ( que — se excluirmos o NodeJS — de uma forma bem básica é quando sua página está carregando). Entretanto, uma coisa importante a notar é que a única coisa que é movida para o topo são as declarações de variáveis, não o valor real delas.

Para clarear as ideias, se tivermos um pedaço de código, e na linha 10 tivermos umvar name = 'Sunil', quando o Javascript for compilado,var nameserá movido ao topo de seu escopo, enquantoname = 'Sunil'permanecerá na linha 10 (ou possivelmente na linha 11 sevar namefor levada para a linha 1).

Com isso em mente, vamos olhar pro código que coloquei anteriormente, mas vamos ver como o Javascript irá devolver a saída em tempo de execução:

var meuNome;

console.log(meuNome);

meuNome= 'João';

É por isso que oconsole.logdevolveráundefined,pois ele reconhece que a variável*meuNome*existe, porém ela não teve um valor inserido até a terceira linha.

Também mencionamos brevemente anteriormente que funções também são hoistiadas (levadas)para o topo (logo acima, onde as declarações de variáveis são hoistiadas).

Então se olharmos para o código abaixo:

function hey() {
    console.log('Iae ' + name);
};

hey();

var name = 'João';

A função hey() retornará undefined mesmo assim, pois o interpretador do JavaScript compilará o código em tempo de execução para o seguinte:

function hey() {
    console.log('Iae ' + name);
};

var name;

hey();

name = 'João';

Então, no momento em que a função é chamada ela sabe que uma variável chamadanameexiste, mas a variável não possui um valor atribuído. Existem algumas variantes para isso que ocorrem ao usar expressões variáveis (variable expressions) de IIFE(clique aqui se você quiser saber mais), mas tentar obter um controle mental de tudo isso de uma vez não é o ideal, então eu irei deixá-lo pesquisar o hoisting a respeito de function expressions e IIFE’s.

Tendo falado isso, tudo que mencionei anteriormente deve ajudá-lo a entender como o hoisting funciona.

O conceito de hoisting é a razão pela qual você pode, às vezes, se deparar com o código de outras pessoas, no qual as variáveis são declaradas logo no topo e, em seguida, recebem valores posteriormente. Essas pessoas estão simplesmente tentando fazer com que seu código se assemelhe ao modo como o interpretador irá compilá-lo, a fim de ajudá-lo a minimizar possíveis erros.

Se você gostou desse artigos, envie muitos claps e se inscreva em minha publicação Javascript In Plain English.

Tecnologia, negócios, otimização prematura e dívida técnica

Allan Ramos — Thu, 15 Apr 2021 14:24:28 +0000

Foi em 2017, logo após sair de meu antigo trabalho que entrei em um projeto com um colega dessa mesma empresa. A ideia era criar uma startup(mais uma?) que fornecesse uma plataforma web do ramo de logística.

Planejando a aplicação

Estava trabalhando como front há pouco tempo e mexia com PHP nas horas vagas. Queria fazer algo mais separadinho, mesmo que a API fosse um grande monolito.

Olhando para a imagem colocada acima, o que ela está dizendo para mim?

Tempo: No projeto sou o único de tecnologia e meu colega na parte de negócio. Sou uma pessoa inexperiente, e a plataforma não terá pouco conteúdo, mesmo para um MVP. O resultado disso será eu tendo que manter 2(duas) aplicações. Se algo novo surgir, alteração nas 2(duas).

Refleti e percebi que eu estava caindo no famoso caso de otimização prematura - Otimize hoje, para não precisar otimizar amanhã -. Eu estava desenvolvendo algo, por mais legal ou interessante que fosse, que poderia ser menor: um monólito com a parte de back e front. O tempo que eu gastaria no desenvolvimento de ambas as aplicações geraria um novo problema, que falarei mais pra frente.

Como falei, a segunda forma que pensei para desenvolver a plataforma foi:

Monólito na sua forma mais pura. Sem API, sem front consumindo. Uma única aplicação que faz tudo.

Com esse cara aqui eu ganho uma vantagem/desvantagem em relação ao modelo anterior:

Tempo: O recurso mais escasso que todos nós temos, e que neste modelo eu teria uma redução. Usando um framework como Laravel eu já faço uma consulta e mando os dados direto pra minha view renderizar. Sem precisar construir 2(duas) aplicações diferentes. O problema é que futuramente sustentar uma aplicação inteira em um único lugar ficaria inviável.

Refletindo, de novo, esse caso já foi pra outra ponta, caí no caso dedívida técnica- Pense nela como um empréstimo. Você conseguirá o que precisa, mas precisará pagar juros depois -, eu abdiquei de uma qualidade, gerando uma dívida tecnológica, para conseguir desenvolver rápido.

Esquerda ou direita?

No primeiro caso percebi que estava construindo uma aplicação que não era o ideal, mas dividia a lógica da visualização da manipulação de dados. No segundo caso eu ganhei tempo, deixando tudo junto, no grande monolito emLaravel, mas gerando um problema de manutenção no futuro.

Se você percebe, ambas acabam esbarrando no problema de tempo. E o que essas duas abordagens têm em comum?

Time to market!

Time to market é o tempo para colocar um produto no mercado. Nesse caso o tempo é meu pior inimigo, pois como querotestar o MVP, meu lindo negócio ainda não nasceu, e tenho que conseguir validá-lo o mais rápido possível.

Se eu escolher minha primeira abordagem(otimização prematura), terei uma curva para entregar o MVP maior, mas no futuro isso se estabiliza. Indo para o outro lado(dívida técnica), eu conseguirei lançar o MVP muito mais rápido, mas isso terá um custo que ficará cada vez maior conforme o tempo passar.

Então tá aí a resposta, né?

Abrace a dívida técnica para crescer, mas saiba deixá-la quando tiver crescido.

Minha talk

Coisas que você pode fazer para melhorar a qualidade do seu código

Allan Ramos — Thu, 15 Apr 2021 14:22:11 +0000

Como diminuir os WTFs por minuto.
Esse post é uma tradução livre do artigo Things That You Can Do to Improve Code Quality, escrito por Daan.

Um código mal escrito pode ser um baita desastre. Quando a bagunça nele aumenta, o tempo para mexer em algo também irá :/. No pior caso, o código ninguém consegue mexer no código, e aos poucos o projeto vai morrendo.

Para prevenir esse tipo de caso, você vai precisar de um código de qualidade. Você deve investir seu tempo para desenvolvê-lo. E pense que em longo prazo ele vai se pagar, tranquilamente.

Qualidade não tem dono, é tarefa de todo mundo. Não interessa se você é gerente, um tester ou desenvolvedor. Entregar um código de alta qualidade e funcionando deve ser a meta em todo o processo de desenvolvimento.

Vou mostrar uma lista de 6 coisas que podem ser feitas para melhorar a qualidade do código.Alguns desses pontos você consegue fazer sozinho, e outras o time precisará se empenhar.

Como mensurar um bom código: WTFs por minuto. Fonte: https://hackernoon.com/the-book-every-programmer-should-read-33b5ef2e532a

1. O Princípio dos 4 olhos(Four-Eyes Principle)

O princípio dos 4 olhos é algo fácil de ser entendido e executado. Ele precisa de duas pessoas, a que fez o código, e outra que possa revisá-lo. Um dos métodos atuais mais conhecidos para fazer isso é o pull request.

Pull requests permite que você informe aos outros as mudanças que você fez na sua branch em um repositório do Github. Assim que ele é aberto, você pode discutir e revisar algumas mudanças de código com seus colegas antes que suas mudanças sejam mergeadas na branch base.

—Github.com

Durante o review de código, algumas coisas devem ser levadas em conta. Uma delas é verificar se parte do código quebra/infringe alguma convenção de código estipulada pelo time. Isso pode ser automatizado através do uso de um linter, mas algumas vezes essa verificação ainda é feita manualmente.

Outras coisas que podem ser feitas, mas não de forma automática, e analisar a manutenabilidade do código e como é feito o tratamento de erros(error handling). Por último, mas não menos importante, o código deve ser verificado quanto à integridade. Esse trecho de código contém o escopo da funcionalidade solicitada?

2. Integração Contínua(Continuous Integration)

“Mas funciona no servidor de desenvolvimento”, ou ainda pior: “Na minha máquina funciona”.

Problemas e discussões dessa natureza são o que você deseja que não aconteçam. É exatamente aí que a integração contínua(CI) pode desempenhar um papel importante.

Integração Contínua é uma prática de desenvolvimento de software onde os membros do time juntam seus trabalhos de forma frequente, normalmente cada pessoa faz isso diariamente — chegando a múltiplas integrações por dia. Cada integração é verificada por um build automático(incluindo os testes) para detectar erros de integração o mais rápido possível.

— Martin Fowler

A sacada da integração contínua é dar aos desenvolvedores um feedback rápido que informe o que ele colocou com o que já existe.

A integração contínua funciona quando você segue esses 2 princípios básicos:

Mantenha o build rápido. Não existe nada mais desanimador que um build que demora 1h.
Corrija os builds quebrados o mais rápido possível. Toda a ideia de CI é que você está sempre desenvolvendo algo numa base de código estável.

O CI melhora a qualidade do código pois fornece um feedback rápido aos desenvolvedores. Se um teste quebra, o build vai falhar, e o desenvolvedor será notificado. Além disso, é bom que seja adicionado um linter ao script the build, para sempre verificar as convenções de código estipuladas. Isso também aumenta a qualidade do código.

3. Convenções de Codificação(Coding Conventions)

É importante existir uma lista das convenções de código estipuladas. Mantes antes de você começar a fazê-la, todos no time precisam estar alinhados. Isso vai demandar tempo, e precisará ser conversado com pessoa a pessoa, com muita discussão sobre quais convenções escolher.

Faça uma lista das convenções especificando como as variáveis devem ser declaradas, e alguns convenções para nomeclatura, e etc. O número de regras que você pode colocar nessa lista é infinita, e elas podem variar. Apenas tenha as regras que fazem sentido pro seu time. Sinta-se livre para adicionar novas regras se o time gostar.

Depois de ter essa lista, é garantir que ela será cumprida. Como falei anteriormente, o melhor modo de verificar que essas convenções estão sendo seguidas, é através de um linter uma pipeline de CI, já que não é preciso nenhuma ação manual — hoje já é possível você ter extensões em seu editor de texto que verifiquem o código em tempo real e te dê avisos na interface. Sempre se certifique de usar o lint regularmente, pra deixar os commits certinhos. Isso vai aumentar a legibilidade e manutenibilidade da base de código, já que o código estará uniforme.

Um código de alta qualidade pode acelerar o desenvolvimento de software a longo prazo, pois pode ser reutilizado e os desenvolvedores não precisam gastar muito tempo corrigindo bugs antigos e fazendo melhorias nele. Sem contar que também facilita a entrada de novas pessoas no projeto.

4. Teste, Teste, Teste

Quanto menos erros o código tiver, maior será sua qualidade. O teste completo filtra bugs críticos, garantindo que o código funcione da maneira esperada.

Ter uma estratégia de teste é essencial quando o assunto é ter um código de qualidade. No mínimo, seu código deve ter testes de unidade. Se quiser fazer outros, como testes de integração, regressão, será ainda melhor.

De acordo com a pirâmide de testes, a maior quantidade de testes que um software deveria ter, são os de unidade. A razão para isso é que são os mais baratos e mais rápidos. Existe uma porrada de ferramentas disponíveis para te ajudar na criação de testes de unidade e também para relatórios de cobertura de código(code coverage).

https://blog.octo.com/en/the-test-pyramid-in-practice-5-5/

Executar a bateria de testes e criar um relatório da cobertura de testes é algo que pode ser feito de forma automática através do CI. É possível você fazer o build falhar caso a cobertura de código seja inferior ao percentual configurado.

5. Analise Bugs

Ter bugs é inevitável. O modo como eles são tratados é muito importante. Se você deseja evoluir como desenvolvedor, esse é um ponto chave, para que você aprenda com seus erros. É por isso que você deve analisar os bugs.

Quando um bug ocorre, entenda seu impacto. É um bug de alta ou baixa prioridade? Se for um bug de alta prioridade, corre pra resolver.

Quando a análise do bug for feita, é importante se fazer algumas perguntas. O que aconteceu de errado? Pq não testamos isso(da forma certa)? Onde mais isso acontece? E mais importante: Como podemos fazer com que isso não ocorra novamente:

Claro, ferramentas são importantes para te ajudar a rastrear esses bugs. Existem muitas ferramentas no mercado. Pegue uma que se encaixe em sua necessidade.

O único e real erro é aquele com o qual não aprendemos nada

— Henry Ford

6. Comece a mensurar(Measuring)

Quando se trata de mensurar, existem várias métricas que você pode usar para quantificar a qualidade do seu código.

Métrica de defeito(Defect metric)

O número de defeitos e a severidade deles é uma métrica importante de qualidade. Se você deseja manter um rastro desses defeitos, você pode usar um bug burndown chart, por exemplo. Ele é funciona como um burndown chart do desenvolvimento ágil. A única diferença é que nesse você vai contar a quantidade de bugs que não foram consertados, ao invés dos pontos das histórias.

Métrica de complexidade(Complexity metrics)

A complexidade é frequentemente medida com a métrica de complexidade ciclomática. É uma medida quantitativa do número de caminhos linearmente independentes através do código fonte de um programa.

Existe uma correlação entre o número de complexidade ciclomática e a frequência de defeitos:

Vários estudos investigaram a correlação entre o número de complexidade ciclomática e a frequência de defeitos que ocorrem em uma função ou método. Alguns estudos encontram uma correlação positiva entre a complexidade e os defeitos ciclomáticos: funções e métodos que têm a maior complexidade tendem a conter também o maior número de defeitos. No entanto, a correlação entre complexidade ciclomática e tamanho do programa (normalmente medida em linhas de código) foi demonstrada muitas vezes.

—Wikipedia

Ter um código menos complexo, deveria, em teoria, gerar menos bugs.

Processos em containers não devem ser executados como root

Allan Ramos — Thu, 15 Apr 2021 14:18:51 +0000

Esse artigo é uma tradução livre deProcesses In Containers Should Not Run As RootporMarc Campbell.

tldr;

Um processo dentro de um container não deve rodar com privilégios de root, assuma isso como verdade.

Ao invés disse, crie um usuário em seuDockerfilecom um conhecidoUIDeGID, e execute seu processo usando esse usuário. Imagens construídas sobre esse padrão são mais fáceis de serem executadas de forma segura por limitar o acesso a determinados recursos.

Overview

Sistemas bem arquitetados aderem aoprincípio do menor privilégio. Esse princípio diz que um aplicativo deve ter acesso apenas aos recursos necessários para executar a função necessária. Isso é muito importante quando desejamos fazer um sistema seguro. Seja malicioso ou por causa de erros, um processo pode ter consequências inesperadas em tempo de execução. Um dos melhores modos de se proteger contra qualquer acesso inesperado é conceder o mínimo privilégio para que um processo seja executado.

A maior dos processos containerizados são serviços de aplicações, sendo assim, elas não precisa de acesso comoroot. Enquanto oDocker precisa ser executado como root, os containers em si, não. Imagens Docker bem escritas, seguras e reutilizáveis não devem ser executadas como root e devem fornecer um método previsível e fácil para limitar o acesso.

Por que isso é importante?

Lembre-se que um processo em execução em um container não é diferente de outro processo em execução no Linux, exceto que ele tem um pequeno pedaço de metadata informando que ele está sendo executado em um container.

Os containers são tão seguros quanto sua máquina host, portanto, qualquer coisa executada em um container deve ser tratada com a mesma consideração que qualquer coisa executada no próprio host.

Assim como você não faria (ou não deveria) executar qualquer coisa como root em seu servidor, você não deveria executar nada como root em um container em seu servidor. Executar binários que foram criados em outro lugar requer confiança, e o mesmo é verdadeiro para binários em containers.

Se um processo dentro de um container for executada como root por default, é possível mudar ouidegidquando o container for iniciado. Sendo o criador da imagem, você deve usar como padrão um usuário diferente e facilitar a limitação de acesso para ele. Criando um usuário em seuDockerfile, você está tornando não apenas ele seguro por padrão, mas também mais fácil de continuar seguro.

O exemplo abaixo mostrará o risco de executar um container comoroot. Vamos criar um arquivo no diretório/root, impedindo qualquer um diferente dorootvê-lo:

marc@srv:~$ sudo -s
root@srv:~# cd /root
root@srv:~# echo "top secret stuff" >> ./secrets.txt 
root@srv:~# chmod 0600 secrets.txt
root@srv:/root# ls -l
total 4
-rw------- 1 root root 17 Sep 26 20:29 secrets.txt
root@srv:/root# exit
exit
marc@srv:~$ cat /root/secrets.txt
cat: /root/secrets.txt: Permission denied

Agora eu tenho um arquivo/root/secrets.txtque só orootconsegue ver. Estou logado como um usuário normal(não root). Vamos criar uma imagem Docker a partir desse Dockerfile:

FROM debian:stretch
CMD ["cat", "/tmp/secrets.txt"]

E finalmente, vamos executar esseDockerfile, montando um volume a partir do/root/secrets.txtque não possa ler o arquivo/tmp/secrets.txtdentro do container.

marc@srv:~$ docker run -v /root/secrets.txt:/tmp/secrets.txt <img>
top secret stuff

Mesmo sendomarc, o container está rodando comoroote, portanto, tem acesso a tudo que oroottem acesso neste servidor. Isso não é o ideal; A execução de containers dessa maneira significa que todos os containers que você acessa do Docker Hub podem ter acesso total a tudo em seu servidor (dependendo de como você o executa).

Recomendação

A recomendação é criar um usuário com umuidconhecido noDockerfilee rodar a aplicação usando esse usuário. O começo doDockerfiledeve seguir o seguinte padrão:

FROM <base image>
RUN groupadd -g 999 appuser && \
    useradd -r -u 999 -g appuser appuser
USER appuser
... <rest of Dockerfile> ...

Usando esse padrão é fácil executar um container no contexto do usuário/grupo com o mínimo de privilégios necessários.

Por exemplo, adicionarei isso ao meuDockerfilede cima, e o executarei novamente. Meu arquivo ficou assim:

FROM debian:stretch
RUN groupadd -g 999 appuser && \
    useradd -r -u 999 -g appuser appuser
USER appuser
CMD ["cat", "/tmp/secrets.txt"]

Executando esse container com o mesmo comando de antes:

marc@srv:~$ docker run -v /root/secrets.txt:/tmp/secrets.txt <img>
cat: /tmp/secrets.txt: Permission denied

Agora, o comportamento padrão do container é que ele não terá privilégios derootno host.

Reusando outras imagens

Imagens Docker são incríveis por serem reutilizáveis, mas quando oFROMde uma imagem é executado através de um usuário normal, seu container herdará esse usuário. Se você precisar criar sua própria imagem ou executar operações comoroottenha certeza queUSER rootesteja próximo do topo de seuDockerfile. EntãoFROM appuserpara torná-lo utilizável.

Executando outros containers como usuários normais (non-root)

Imagens Docker são feitas para serem portáteis, e é normal obter outras imagens do Docker Hub. Algumas delas (imagens oficiais) seguirão as melhores práticas e serão executadas como usuários normais (non-root), mas muitas imagens não fazem isso. Muitas simplesmente executam as coisas comoroote deixam pra você descobrir como executar as coisas com segurança. Existem opções que permitirão você rodar uma imagem de forma segura que não foi criada por você.

Criando outra imagem

Primeiro, uma opção é criar outra imagem usando a imagem original com a camadaFROM. Então você poderá criar um usuário, e copiar oENTRYPOINTorigin e diretrizes doCMDpara sua própria imagem. Isso resultará em uma nova imgem que seguirá as boas práticas citadas aqui, garantindo que sua execução ocorra de forma segura. O que pode incomodar nesse ponto é que você precisará rebuildar sua imagem quando a imagem base for atualizada. Você terá que configurar um processo para fazer esse rebuild quando a imagem base for rebuildada.

Especificando um uid quando iniciando um container

Finalmente você pode criar um usuário no host e passar ouidpro Docker quando o container for iniciado. Por exemplo, revisitando o exemplo doDockerfile:

FROM debian:stretch
CMD ["cat", "/tmp/secrets.txt"]

Eu consigo executar esse container com ou sem o parâmetro user_id e ver os diferentes resultados(o user_id 1001 representa minha conta atual nesse servidor):

$ docker run --user 1001 -v /root/secrets.txt:/tmp/secrets.txt <img>
cat: /tmp/secrets.txt: Permission denied

$ docker run -v /root/secrets.txt:/tmp/secrets.txt <img>
top secret stuff

Isso funciona e é a mesma coisa que criar um usuário noDockerfile, mas requer que o usuário opte por executar o container com segurança. Especificar um usuário normal (non-root) noDockerfilefará com que o container seja executado com segurança por padrão.

Para leitura futura

Understanding how uid and gid work in Docker containers

Official reference to the Docker Run command (Docker)

Docker Security

— -

Se você está usando Docker para lançar uma aplicação SaaS, você deveria verificarwww.replicated.compara poder lançar uma versão corporativa e instalável do seu produto.

Uma lista comovente de links para estudar tecnologia

Allan Ramos — Wed, 14 Apr 2021 20:50:13 +0000

Você teria links pra quem está começando com programação?— disse alguém.

Você teria links para pessoas que desejam ser devs? — disse outra pessoa.

Gente, o que vocês acompanham de blogs?— disse eu a meus colegas.

Vai e vem, e vou montando uma mega lista. Aproveitando isso, achei melhor colocar tudo isso em uma postagem, já que você, assim como eu e muitos, podem precisar das referências aqui presentes.

Observação: Não coloquei e não colocarei meetups por ser algo regional.

Livros

Em português

Em inglês

Canais

Brasileiros

Internacionais

Podcasts

Brasileiros

Internacionais

Blogs

Brasileiros

Internacionais

Dicas extras

Para gerenciar esse mar de blogs utilizo o Feedly, uma platataforma onde você assina o feed desses sites, e categorizar cada assinatura, deixando tudo organizado para acompanhar diversos artigos relacionados de uma vez.

E para podcasts, no meu celular utilizo o Podcast Addict.