Se você se perguntou por que e quando essas estruturas são usadas e se é hora de implementar uma em seu projeto, você não está sozinho. Alguns anos atrás, enquanto trabalhava em um projeto paralelo, Hackterms, meu próprio…
Você provavelmente já ouviu falar sobre estruturas front-end. Nomes como React, Vue e Angular abundam em tutoriais e debates do Hacker News. Se você se perguntou por que e quando essas estruturas são usadas e se é hora de implementar uma em seu projeto, você não está sozinho. Alguns anos atrás, enquanto trabalhava em um projeto paralelo, Hackterms,minha própria frente se tornou desajeitada. Eu tinha uma sensação frouxa de que implementar uma estrutura era o próximo passo, mas eu tinha pouca ideia sobre o que eles fizeram. (Vamos voltar a ser como isso acabou no final do artigo.) Esta é a explicação que eu gostaria que tivesse então. Neste post, vamos ter uma visão de olho de pássaro sobre o problema estruturas front-end estão tentando resolver e quando você pode querer usar um.
Especificamente, vamos revisar:
Como uma frente cresce.
Os problemas de arquitetura que você pode encontrar à medida que ele escala.
Como uma estrutura front-end pode ajudar a lidar com isso.
Outras alternativas que você pode considerar.
Rápido à parte: “front-end framework” recebe um hífen, já que é um adjetivo composto. No entanto, seu aplicativo tem um “front end” — substantivo, sem hífen. Fique nerd comigo.
Alguns termos para revisar
Vamos falar sobre frameworks front-end um monte (você pode ter recebido uma dica do título), então vamos entrar na mesma página em torno da terminologia:
Uma estrutura de software é uma estrutura de aplicativo pré-escrita para você construir em cima. Na prática, é uma coleção de arquivos e diretórios que você adiciona seu próprio código e arquivos. Uma estrutura é feita para ajudá-lo a construir aplicativos mais rapidamente, abordando problemas comuns de desenvolvimento e muitas vezes começa com:
Código caldeiraplata, cobrindo funções que são reutilizadas pela maioria dos aplicativos.
Uma estrutura de diretório, muitas vezes seguindo uma filosofia de design.
Um conjunto de princípios de design que seu tipo de aplicação encontra frequentemente. Quadros que aplicam esses princípios, como Ruby on Rails, são geralmente referidos como opinativos.
Uma frente é a camada de apresentação da sua aplicação. É muitas vezes descrito como todas as coisas que o usuário vê, mas, mais geralmente, é qualquer código que é responsável por exibir dados eficientemente para o usuário. Assim, a front-end inclui a construção de interfaces intuitivas e agradáveis, bem como o armazenamento, apresentação e atualização eficientes de dados recebidos do back-end ou da API.
Uma estrutura frontal é um andaime para construir sua parte frontal. Geralmente inclui alguma maneira de estruturar seus arquivos (por exemplo, através de componentes ou um pré-processador CSS), fazer solicitações AJAX, estilizar seus componentes e associar dados com elementos DOM.
Um aplicativo em crescimento
Você pode construir um frontend simples com apenas três arquivos: HTML, CSS e JavaScript. No entanto, à medida que seu aplicativo escala, seus arquivos crescerão junto com ele, preenchendo com código de espaguete inescrutável e inacompensável.
Como é tradição, vamos olhar para um exemplo bobo: digamos que você está construindo o MySquare, um ranking para jogadores de tabuleiro competitivos. Neste aplicativo, os usuários podem compartilhar os jogos de tabuleiro que jogaram, seus resultados competitivos sancionados pela liga (agora há uma liga, rolar com ele) e avaliações curtas de partidas competitivas. O recurso mais importante do aplicativo é a página do perfil do usuário:
Você constrói a primeira versão desta página de perfil com as três tecnologias básicas, HTML, CSS e JavaScript. Funciona algo assim:
Na carga inicial da página, o back-end inicialmente envia uma página de perfil em branco com estilo mínimo. Em seguida, e para todas as cargas futuras, o front-end solicita dados do usuário via AJAX.
O back-end envia alguns dados do usuário público como JSON, e você usa JavaScript para anexar dinamicamente elementos DOM para crachás de jogo e registros na página.
Quando você decide construir páginas específicas do jogo que listam todos os usuários e seus registros, você cria novos arquivos JavaScript que replicam grande parte do código, já que eles estão se baseando nos mesmos dados do jogo.
Cada crachá de jogo (e crachá de correspondência) usa o mesmo HTML, então você armazena a marcação em uma string JavaScript e descobre uma maneira de injetar dados específicos do jogo lá, ex: “p{{Game Name}}/p”. Em seguida, você anexar o crachá HTML na página para cada jogo.
Quando um usuário atualiza algum valor na página, você pode ler dados do DOM consultando atributos ou anexando os ouvintes de eventos a cada elemento — obtendo os dados lendo-os do DOM.
À medida que o MySquare se torna popular e seu conjunto de dados cresce, essa abordagem rapidamente se torna desordenada:
Você encontra-se anexando dados à página e, em seguida, lendo-os do DOM, capturando div valores ou leitura de ids ou atributos de dados.
O número de balões de arquivos JavaScript e CSS, e há muito código repetido entre eles.
Você está vinculando os ouvintes de eventos a elementos comuns de interface do usuário, como campos de entrada e botões, em seguida, escrevendo funções para atualizar os valores nesses mesmos elementos.
Quando você precisa fazer até mesmo uma pequena mudança, você se preocupa com como isso vai impactar o resto da aplicação.
Quando seu amigo se oferece para ajudar com o trabalho de desenvolvimento (para alguma equidade, é claro), você passa horas explicando como seu código funciona.
Gerenciar esses problemas é viável com baunilha JavaScript e paciência suficiente. Com planejamento e previsão, você pode ser capaz de estruturar seu aplicativo para antecipar alguns desses problemas. No entanto, à medida que sua frente cresce, esses problemas só se aprofundarão — você nunca pode ter certeza de como seu aplicativo vai evoluir.
Você percebe que armazenar seus
.png)
.png)
.png)
.png)