Quais tópicos você deveria saber porque trabalha com o Next.js
Olá a todos, por favor ignorem a escrita que eu adoto. Sinto que no começo da minha carreira sofri muito por direções que incluíam no discurso o famoso "DEPENDE". Portanto, segue aqui os tópicos que acho serem essenciais para quem tá trabalhando ou até começando no framework.
HTML5 semântico e acessibilidade
Era comum no passado a limitação do conhecimento do HTML a certas tags que eram utilizadas para fins de posicionamento de elementos na tela, como exemplo a tag div. Hoje, não dá mais pra competir no mercado sem saber as tags semânticas do HTML5, que aliás, cresce a cada dia e a documentação no MDN está simplismente perfeita. Você sabia que tem uma tag para criar modais ?
Tags como details
, optgroup
, dialog
, section
, article
, footer
etc dão ao seu site o significado que ele precisa para ser corretamente ranqueado e enviado para as pessoas ao redor do mundo. E não é só isso. Cada vez mais vejo vagas para desenvolvedor web pedindo o conhecimento e experiência nos documentos de acessibilidade, como o WCAG. Então além de saber programar, você deverá também fazer o seu aplicativo ser acessível, democrático, e de uso equivalente para todas as pessoas. Portanto, um desenvolvedor web que não conhece sobre esses assuntos, não ficará muito tempo no mercado.
Server Side Rendering
Eu tive a oportunidade de trabalhar com o Next.js desde o começo da minha carreira. E isso foi graças a um longo estudo de 1 ano e meio das tecnologias que hoje domino. Estive a parte do Next na versão 10, 11, 12 e agora 13.
A principal feature deles na minha opinião e para o meu uso, sempre foi Server Side Rendering. O único problema é que a maioria dos aplicativos anteriores a 2020 (data de publicaçao do Next 10) foram criados em React, e quem criava os app naquele tempo (antes do Next) não pensava em uma estrutura de dados feita para servidor.
Existe uma arquitetura milenar e muito comum em projetos mais antigos chamada Flux. Foi através dessa arquitetura difundida e utilizada pela maioria das SPA em React, que estabeleceu-se uma relação da seguinte maneira, os dados vem de um ponto A, e são enviados para um ponto B. Contudo, toda essa operação era feita principalmente com o uso de outra bilioteca chamada Redux, que é client-side. Veja o seguinte case.
Você tinha uma SPA privada criada em React e a partir de agora precisa aumentar sua base de usuários, então boa parte dos conteúdos serão gratuitos e você têm que ter SEO para atrair em pesquisa orgânica. E agora ? o jeito é refatorar.
Não têm como escapar da nova era do data fetching, tudo vai virar server components, e isso é bem claro agora com a associação do React 18 e o Next 13. Recomendo fortemente que comece todos os seus componentes novos como serivdor ou híbrido.
Quem ir por outra linha estará obviamente em anti-pattern com o framework em poucos anos, e dai nada de bom pode vir. Pessoalmente, já tive que refatorar mais de quarenta mil linhas de código por conta de anti-pattern de SCSS em modules importado como CSS global (quebrou numa migração do Next 10 para o 12.
Desenvolvedores possuem opiniões e principalmente, muito ego. Portanto, pessoalmente, recomendo seguir as boas práticas o máximo que der. Porque quando você sair da empresa alguém vai ter que ler seu código, e acredite em mim, ele não vai entender nada. Siga as boas práticas, não seja o dev que inventa biblioteca e sai da empresa.
Estrutura de páginas dinâmicas
O roteamento de aplicações construídas em React era geralmente feito pelo Router DOM. No entanto, a arquitetura de rotas do framework Next.js é um dos destaques da ferramenta, pois mantém cada pedaço da aplicação organizado em pequenas pastas no diretório "pages" ou "app" (dependendo da versão). Isso resulta em uma manutenibilidade mais simples no futuro.
Ao falar de roteamento, não podemos esquecer da criação de páginas estáticas, conhecida como SSG (Static Site Generation). Essa funcionalidade é talvez a mais atrativa para quem busca reduzir os custos relacionados ao consumo de dados e ao cache de CDN.
Quando o site é estático, além de ser rápido, ele economiza dinheiro. Componentes criados no Next 13, quando alocados no diretório "app", são server components, que aplicam o cache estático de forma automática, conforme explicado na documentação do Next.js.
Google Search Console
Essa é uma ferramenta que, infelizmente, poucos desenvolvedores têm acesso. Alguns nem a conhecem, o que justifica a falta de profissionais qualificados em atividades que envolvem a otimização dos motores de busca (SEO). Se você quer se diferenciar no mercado, é interessante procurar empresas que já a utilizem ou, quem sabe, adotá-la em seu trabalho.
É no Search Console que você acompanha o crescimento das suas páginas, identifica quais estão com erros de indexação, redirecionamentos e muito mais. Pessoalmente, acredito que seja um ponto-chave para você pleitear uma promoção. Isso se deve ao fato de que tanto os gráficos quanto os relatórios apresentados são um registro contínuo do seu trabalho de melhorias, e você pode utilizá-los como argumentos em suas reuniões de negociação e planejamento de carreira.
LightHouse, Core Web Vitals e Page Insights
O Google Lighthouse é uma das ferramentas mais famosas na hora de depurar quantos pontos de melhoria o seu site possui. Ele consegue produzir relatórios completos em PDF antes e depois, contendo quais pontos o seu app pode melhorar e como conseguir aumentar essas métricas, como acessibilidade, SEO, desempenho, entre outros. Não há garantias de que, se você tiver entre 90-100 pontos em todas as métricas, irá conseguir o melhor aplicativo; no entanto, é um bom lugar para começar.
As métricas que indicam que seu site, por exemplo, demora para renderizar o primeiro conteúdo (FCP), tem uma movimentação estranha no layout antes de carregar (CLS), ou até mesmo sofre pra renderizar um item grande (LCP), são utilizadas nos relatórios do Core Web Vitals. Para se tornar um especialista em SEO e usar bem o Next.js, você terá que dominar as técnicas que diminuem a ocorrência desses problemas.
O React oferece ferramentas junto com o Next.js para te ajudar nesse caso, como o exemplo do lazy components para code split (dividir seu javascript em partes menores), o next image com priority quando é a maior imagem do site.. e claro, o uso de third-party libraries dentro da tag Script do Next.
O Page Insights, por sua vez, é novidade para mim. Contudo, tenho utilizado para descobrir quanto tempo minha página demora para renderizar os conteúdos e se eles são aceitáveis. E você? Tem algum uso diferente dessas ferramentas?