🤘 🆒 🥐 Arquiteturas modernas de front-end (parte 2) 👨🏾‍🔬 🏏 ✅

A segunda parte do artigo " Arquiteturas de front-end contemporâneas ", que discute a arquitetura do front-end em termos de distribuição de fluxos de dados. Comece aqui

Implementação

Algoritmos gerados pelo DOM (algoritmos infundidos no DOM)

A técnica, introduzida e dominada pela biblioteca jQuery , realmente foi o começo da criação de aplicativos clientes em larga escala, embora, de fato, o jQuery não tenha resolvido problemas de arquitetura. Ele foi projetado para facilitar a manipulação da árvore DOM quando havia muitas inconsistências no comportamento do navegador. Isso forneceu uma API independente do navegador.

Não acho que isso tenha sido intencional, mas o jQuery simplificou a API do DOM a tal ponto que era difícil diferenciá-la das APIs da linguagem de programação usual. Isso, por sua vez, permitiu que os desenvolvedores misturassem literalmente o nível da API do DOM ( View ) com a lógica de negócios ( Model ).

Mais uma vez, ainda estamos no contexto do mesmo MVC do lado do servidor. Esta é apenas uma sequela. Não há inversão real de controle. O controle geral sobre visualizações / páginas ainda é determinado pelo código do servidor.

No trecho de código acima, o Modelo, Apresentação e Apresentador / Controlador são de alguma forma combinados em uma estrutura de código monolítica. É o caso quando o Modelo consiste em apenas uma propriedade. Imagine tentar criar um aplicativo Web sem um ciclo de navegação no servidor (como SPA). Seria impossível lidar com tudo isso de qualquer maneira conveniente. O código para interagir com o DOM é penetrado pelo restante da lógica do aplicativo e, portanto, é conhecido como algoritmo com infusão de DOM (não tenho certeza de que exista esse termo oficialmente)

Backbone.js - MV *

Como vimos, no jQuery, ao desenvolver aplicativos, a maneira de estruturar e organizar nosso código está claramente ausente. É aqui que o Backbone.js apareceu como a próxima solução evolutiva. Foi uma das primeiras bibliotecas a trazer os benefícios do estilo MVC do lado do cliente.

Se observarmos o diagrama de fluxo de dados do Backbone, veremos claramente o modelo e a visualização, mas não há objeto equivalente ao controlador. Os modelos estão evoluindo e o MVC do lado do cliente é simplesmente uma evolução das arquiteturas anteriores do MVC. Durante essa evolução, grande parte da comunidade JavaScript concordou com a definição do modelo e da visualização, mas não houve consenso sobre o controlador. Dado o ambiente do cliente, a ideia do Controller não é muito adequada. O controlador é deixado aberto para interpretação.

Quanto ao Backbone, não há controlador nele. Então o que é isso? É MVC, MVP ou MVVM? Tomando emprestado da definição de servidor MVC, o controlador tem duas responsabilidades, a saber: responder às ações do usuário na forma de solicitações HTTP recebidas e controlar o modelo para criar a visualização (página HTML). No caso do Backbone, essas responsabilidades são compartilhadas entre o View e o Router . Mas a noção independente de Controller ou Presenter está ausente.

, Backbone — MVP, View Presenter, Template — View, Model Collection Model.

, Backbone - . , Backbone MVC, MVP. , .

É assim que nasce MV * ou Model-View-Whatever ("o que quer que seja"). Para uma discussão detalhada, é altamente recomendável que você verifique o blog de Addi Osmani.Em

comparação com o jQuery anterior, o Backbone ajudou a criar código mais estruturado.

No começo deste artigo, chamei o Backbone de próxima solução evolutiva. O motivo é que ele simplesmente estendeu o MVC do lado do servidor para complementá-lo. Por exemplo, se nosso servidor é RESTful e implica que o código de front-end é apenas um meio de representar o modelo no lado do servidor, o Backbone está pré-configurado para sincronizar com a API:

Além disso, existem muitas outras pequenas convenções embutidas no Backbone que parecem uma extensão. Concluindo, digo que o Backbone pode não ter sido a única solução na época, mas foi um trabalho verdadeiramente inovador em termos de estrutura e organização do código. Como o jQuery, ele tem sido usado por muitos produtos.

Knockout.js - associação de dados para o front end

Knockout.js é o nosso exemplo mais recente de uso de modelos básicos. Seu objetivo é implementar o MVVM - Model-View-ViewModel para JavaScript. E assim é. Enquanto o Backbone lidava com o problema de organização e estrutura de código, o Knockout é uma implementação eficiente da camada View usando Ligações de Dados Declarativas . As vantagens das ligações declarativas são as mesmas de qualquer construção de programação declarativa:

Fácil de ler: código declarativo ajuda a programar
Encurtando o modelo padrão: as ligações nos permitem atualizar automaticamente o DOM toda vez que o ViewModel é alterado, e também atualizar o ViewModel toda vez que o View é alterado através da entrada do usuário.
Observável: Knockout fornece um nível mais alto de abstração para eventos. Isso permite que o Knockout rastreie automaticamente as dependências entre as propriedades do ViewModel. Se necessário, podemos assinar propriedades Observáveis.

Embora o Knockout forneça construções bem definidas para o View e o ViewModel, ele não diz nada sobre qual deve ser o modelo do aplicativo. Isso torna o Knockout extremamente focado e versátil, pois pode ser usado como uma biblioteca em vez de uma estrutura. Por experiência própria, vi que ele era usado para criar mini-aplicativos SPA, onde um aplicativo da Web consiste em várias páginas e cada página é um pequeno aplicativo Knockout. Esta resposta ao StackOverflow define claramente o escopo do MVVM no Knockout.

Supõe-se frequentemente que, com o modelo, o Knockout esteja no lado do servidor. O ViewModel simplesmente solicita um modelo do lado do servidor usando o Ajax ou equivalente.

O Knockout substitui as soluções jQuery e de modelo, como o Guiador para atualizações do DOM, mas ainda usa o jQuery para animações, Ajax e outros utilitários. Em combinação com o Backbone, ele pode servir como uma implementação completa do modelo MVVM. Teoricamente, isso poderia acontecer, mas antes que isso acontecesse, esses conceitos já estavam desenvolvidos nas ferramentas da próxima geração.

Aqui começa o movimento revolucionário de Angular 1, Aurelia, Ember.js, etc.

Devido à sua estreita conexão com o mundo .NET, o Knockout tem sido amplamente usado no aplicativo ASP.NET MVC. Como o Backbone, era outra solução evolutiva para um problema ligeiramente diferente. E, novamente, a suposição de que o código do lado do cliente é simplesmente uma extensão do padrão MVC do lado do servidor não mudou. O lado do servidor ainda era a arquitetura dominante.

Knockout e Backbone são bibliotecas JavaScript. De uma forma ou de outra, o Backbone era visto como uma estrutura. Por quê? Não há uma resposta definitiva, mas provavelmente estava em perspectiva. O backbone sempre foi tratado com uma abstração de nível mais alto devido à ênfase na estrutura do código. Além disso, o Backbone nunca teve a intenção de substituir o onipresente jQuery (mesmo em 2019, 70% dos 10.000.000 de sites usam jQuery), enquanto o Knockout se sobrepôs ao núcleo do jQuery, ou seja, manipulações DOM, o que naturalmente complicou o Knockout. Assim, a adaptação de Knockout foi limitada em comparação com o Backbone. Mas ainda foi uma das primeiras implementações de ligações de dados declarativas para a comunidade front-end e merece menção especial.

Angular 1 - me dê o controle

O que o jQuery fez com o DOM, o Angular 1 fez com o ecossistema front-end como um todo. Isso mudou para sempre a idéia de criar aplicativos clientes em larga escala. Ele apresentou muitos conceitos como base - um sistema modular, injeção de dependência, inversão de controle, ligação de dados mais fácil, etc.

Agora era e continua sendo uma tarefa difícil escolher as bibliotecas JavaScript corretas e criar a pilha de tecnologia perfeita para o front-end. O Angular 1 simplesmente forneceu uma alternativa mais simples, mas mais coesa. O mesmo pode ser dito sobre o Ember.js e outros sistemas similares, mas a aplicabilidade do Angular 1 estava em um nível qualitativo diferente das alternativas da época.

O Angular 1 é uma solução revolucionária no sentido de marcar claramente um afastamento da idéia de uma simples extensão MVC do lado do servidor com o código do lado do cliente espalhado pelas páginas. O Angular 1 transformou o SPA em uma solução de primeira classe, quase de fato, para criar uma experiência de usuário de última geração.

Estrutura ou biblioteca?

As soluções anteriores eram mais bibliotecas do que uma estrutura. O angular 1 é sem dúvida uma estrutura bem definida. Um fator de distinção necessário entre a plataforma e a biblioteca é o IOC - Inversion of Control. Além disso, para qualificar o Angular 1 como uma estrutura, podemos observar:

MVVMs bem definidas: o Angular 1 possui objetos Model, View e ViewModel desobstruídos.
(DI): Angular 1 DI, Model. Angular 1 (Service). , .
(data binding) : , . , MVVM. . (Angular 1 ). . . MVC. , .
Sistema modular: o Angular 1 apresenta um sistema modular específico para a estrutura. Os módulos são a base para organizar o código para quase todos os idiomas. O JavaScript não tinha um sistema modular até 2015 (os navegadores não eram compatíveis até 2018). A Angular está muito à frente do seu tempo em termos de organização.

Ao mesmo tempo, o Angular 1 também foi criticado pela complexidade que introduziu. A crítica mais importante é que ele foi modelado em designs do lado do servidor. Isso não é típico para desenvolvedores de front-end. Algumas coisas eram francamente ruins:

Colisão de namespace: Embora o DI tenha sido ótimo, ele foi implementado usando o padrão Service Locator que usava o namespace global. Isso tornou o prefixo de serviços quase obrigatório.
. , , , . React . -, .
. , Angular 1, . , Angular 1 $scope, ViewModel, Controller, $scope. , VMFactory . , Angular 1 , .

Havia muitos outros problemas menores. Angular 2, ou apenas Angular, foi uma inovação completa, na medida em que parecia uma estrutura totalmente nova. Não encontro nada em comum entre eles, exceto o nome e alguns conceitos.

Ao longo dos anos, houve pequenas versões do Angular 1, nas quais muitas das pequenas dificuldades de uso foram corrigidas. O mais significativo deles foi a adição do Modelo de Componentes , no qual a maioria das tendências de desenvolvimento front-end convergiu.

O Angular 1 viveu muito e continua a viver entre a comunidade front-end. Com todos os seus prós e contras, ajudou a comunidade a entender a importância da arquitetura de software e forneceu a base para a criação de aplicativos escaláveis. Suas desvantagens e deficiências tornaram-se a base para a solução de problemas para arquiteturas futuras.