👫 👎🏽 🖕🏿 Architectures frontales modernes (partie 2) 💆🏻 🏣 🏼

La deuxième partie de l'article " Architectures frontales contemporaines ", qui traite de l'architecture du front-end en termes de distribution des flux de données. Commencez ici

la mise en oeuvre

Algorithmes générés par DOM (algorithmes infusés par DOM)

La technique, introduite et maîtrisée par la bibliothèque jQuery , était vraiment le début de l'écriture d'applications clientes à grande échelle, bien qu'en fait jQuery n'ait pas résolu les problèmes architecturaux. Il a été conçu pour faciliter la manipulation de l'arborescence DOM lorsqu'il y avait trop d'incohérences dans le comportement du navigateur. Cela a fourni une API indépendante du navigateur.

Je ne pense pas que c'était intentionnel, mais jQuery a simplifié l'API DOM à tel point qu'il était difficile de le distinguer des API habituelles du langage de programmation. Cela, à son tour, a permis aux développeurs de mélanger littéralement le niveau de l'API DOM ( View ) avec la logique métier ( Model ).

Encore une fois, nous sommes toujours dans le contexte du même MVC côté serveur. Ce n'est qu'une suite. Il n'y a pas de véritable inversion de contrôle. Le contrôle général sur les vues / pages est toujours déterminé par le code côté serveur.

Dans l'extrait de code ci-dessus, le modèle, la présentation et le présentateur / contrôleur sont en quelque sorte combinés en une seule structure de code monolithique. C'est le cas lorsque le modèle se compose d'une seule propriété. Imaginez que vous essayez de créer une application Web sans cycle de navigation sur le serveur (comme SPA). Il serait impossible de gérer tout cela de manière pratique. Le code d'interaction avec le DOM est pénétré par le reste de la logique d'application, et il est donc connu comme l'algorithme infusé par le DOM (je ne suis pas sûr qu'il existe officiellement un tel terme)

Backbone.js - MV *

Comme nous l'avons vu, dans jQuery, lors du développement d'applications, la manière de structurer et d'organiser notre code est clairement absente. C'est là que Backbone.js est apparu comme la prochaine solution évolutive. Ce fut l'une des premières bibliothèques à apporter les avantages du style MVC côté client.

Si nous regardons le diagramme de flux de données Backbone, nous verrons clairement le modèle et la vue, mais il n'y a aucun objet équivalent au contrôleur. Les modèles évoluent et MVC côté client est simplement une évolution des architectures MVC précédentes. Au cours de cette évolution, une grande partie de la communauté JavaScript était d'accord avec la définition du modèle et de la vue, mais il n'y avait pas de consensus sur le contrôleur. Compte tenu de l'environnement client, l'idée de Controller n'est pas très adaptée. Le contrôleur est laissé ouvert pour l'interprétation.

Quant à Backbone, il n'y a pas de contrôleur. Alors qu'est-ce que c'est? Est-ce MVC, MVP ou MVVM? Empruntant à la définition de serveur MVC, le contrôleur a deux responsabilités, à savoir: répondre aux actions de l'utilisateur sous forme de requêtes HTTP entrantes et contrôler le modèle pour créer la vue (page HTML). Dans le cas de Backbone, ces responsabilités sont partagées entre View et Router . Mais la notion indépendante de contrôleur ou de présentateur fait défaut.

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

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

C'est ainsi qu'est né MV * ou Model-View-Wthing ("que ce soit"). Pour une discussion détaillée, il est fortement recommandé de consulter le blog d'Addi Osmani.

Comparé à jQuery précédent, Backbone a aidé à créer un code plus structuré.

Plus tôt dans cet article, j'ai appelé Backbone la prochaine solution évolutive. La raison en est qu'il a simplement étendu le MVC côté serveur pour le compléter. Par exemple, si notre serveur est RESTful et implique que le code frontal n'est qu'un moyen de représenter le modèle côté serveur, Backbone est préconfiguré pour se synchroniser avec l'API:

Et en plus, il existe de nombreuses autres petites conventions intégrées à Backbone qui ressemblent à une extension. En conclusion, je dis que Backbone n'était peut-être pas la seule solution à l'époque, mais c'était vraiment un travail révolutionnaire en termes de structure de code et d'organisation. Comme jQuery, il a été utilisé par de nombreux produits.

Knockout.js - liaison de données pour le frontal

Knockout.js est notre dernier exemple d'utilisation de modèles de base. Il vise à implémenter MVVM - Model-View-ViewModel pour JavaScript. Et c'est comme ça. Alors que Backbone a abordé le problème de l'organisation et de la structure du code, Knockout est une implémentation efficace de la couche View avec des liaisons de données déclaratives . Les avantages des liaisons déclaratives sont les mêmes que pour toute construction de programmation déclarative:

Facile à lire: le code déclaratif aide à la programmation
Raccourcir le modèle standard: les liaisons nous permettent de mettre à jour automatiquement le DOM à chaque fois que le ViewModel change, et également de mettre à jour le ViewModel à chaque fois que le View change via l'entrée utilisateur.
Observable: Knockout fournit un niveau d'abstraction plus élevé pour les événements. Cela permet à Knockout de suivre automatiquement les dépendances entre les propriétés ViewModel. Si nécessaire, nous pouvons souscrire à des propriétés observables.

Alors que Knockout fournit des constructions bien définies pour View et ViewModel, il ne dit rien sur ce que devrait être le modèle d'application. Cela rend Knockout extrêmement ciblé et polyvalent, car il peut être utilisé comme bibliothèque au lieu d'un cadre. D'après ma propre expérience, j'ai vu qu'il était utilisé pour créer des mini-applications SPA, où une application Web se compose de plusieurs pages, et chaque page est une petite application Knockout. Cette réponse à StackOverflow définit clairement la portée de MVVM dans Knockout.

On suppose souvent qu'avec le modèle, Knockout se trouve côté serveur. ViewModel demande simplement un modèle côté serveur utilisant Ajax ou son équivalent.

Knockout remplace jQuery et les solutions de modèles comme les poignées pour les mises à jour DOM, mais utilise toujours jQuery pour les animations, Ajax et d'autres utilitaires. En combinaison avec Backbone, il peut servir d'implémentation complète du modèle MVVM. Théoriquement, cela pourrait arriver, mais avant cela, ces concepts étaient déjà développés dans les outils de la prochaine génération.

Ici commence le mouvement révolutionnaire d'Angular 1, Aurelia, Ember.js, etc.

En raison de sa connexion étroite avec le monde .NET, Knockout a été largement utilisé dans l'application ASP.NET MVC. Comme Backbone, c'était une autre solution évolutive à un problème légèrement différent. Et encore une fois, l'hypothèse selon laquelle le code côté client est simplement une extension du modèle MVC côté serveur n'a pas changé. Le côté serveur était toujours l'architecture dominante.

Knockout et Backbone sont des bibliothèques JavaScript. D'une manière ou d'une autre, Backbone était considéré comme un cadre. Pourquoi? Il n'y a pas de réponse définitive, mais c'était probablement en perspective. Le backbone a toujours été géré avec une abstraction de niveau supérieur en raison de son accent sur la structure du code. De plus, Backbone n'a jamais été destiné à remplacer l'omniprésent jQuery (même en 2019, 70% des 10000000 principaux sites Web utilisent jQuery), tandis que Knockout chevauchait le noyau jQuery, c'est-à-dire les manipulations DOM, ce qui compliquait naturellement Knockout. Ainsi, l'adaptation de Knockout était limitée par rapport à Backbone. Mais c'était toujours l'une des premières implémentations de liaisons de données déclaratives pour la communauté front-end, et elle mérite une mention spéciale.

Angular 1 - donnez-moi le contrôle

Ce que jQuery a fait avec le DOM, Angular 1 l'a fait avec l'écosystème frontal dans son ensemble. Cela a changé à jamais l'idée de créer des applications clientes à grande échelle. Il a présenté de nombreux concepts comme base - un système modulaire, l'injection de dépendances, l'inversion de contrôle, une liaison de données plus facile, etc.

Il était alors et reste aujourd'hui une tâche difficile de choisir les bonnes bibliothèques JavaScript et de créer la pile technologique parfaite pour le frontend. Angular 1 a simplement fourni une alternative plus simple mais plus cohérente. La même chose peut être dite à propos d'Ember.js et d'autres systèmes similaires, mais l'applicabilité d'Angular 1 était à un niveau qualitatif différent de ses alternatives de l'époque.

Angular 1 est une solution révolutionnaire dans le sens où elle a clairement marqué un départ par rapport à l'idée d'une simple extension MVC côté serveur avec du code côté client dispersé sur plusieurs pages. Angular 1 a fait de SPA une solution de première classe, presque de facto, pour créer une expérience utilisateur de nouvelle génération.

Framework ou bibliothèque?

Les solutions précédentes étaient plus des bibliothèques qu'un framework. Angular 1 est sans aucun doute une structure bien définie. IOC - Inversion of Control est un facteur de distinction nécessaire entre la plate-forme et la bibliothèque . De plus, pour qualifier Angular 1 en tant que framework, nous pouvons noter:

MVVM bien définis: Angular 1 a des objets Model, View et ViewModel clairs.
(DI): Angular 1 DI, Model. Angular 1 (Service). , .
(data binding) : , . , MVVM. . (Angular 1 ). . . MVC. , .
Système modulaire: Angular 1 introduit un système modulaire spécifique au framework. Les modules sont la base de l'organisation du code pour presque toutes les langues. JavaScript n'a pas eu de système modulaire avant 2015 (les navigateurs ne l'ont pas supporté avant 2018). Angular est bien en avance sur son temps en termes d'organisation.

Dans le même temps, Angular 1 a également été critiqué pour la complexité qu'il a introduite. La critique la plus importante est qu'elle a été modelée sur des conceptions côté serveur. Ce n'est pas typique des développeurs frontaux. Certaines choses étaient franchement mauvaises:

Collision d'espace de noms: bien que DI soit génial, il a été implémenté à l'aide du modèle Service Locator qui utilisait l'espace de noms global. Cela a rendu le préfixe des services presque obligatoire.
. , , , . React . -, .
. , Angular 1, . , Angular 1 $scope, ViewModel, Controller, $scope. , VMFactory . , Angular 1 , .

Il y avait de nombreux autres problèmes mineurs. Angular 2, ou tout simplement Angular, était une percée complète dans la mesure où il ressemblait à un tout nouveau cadre. Je ne trouve rien de commun entre eux, à part le nom et quelques concepts.

Au fil des ans, il y a eu de petites versions d'Angular 1, dans lesquelles de nombreuses petites complexités de son utilisation ont été corrigées. Le plus important d'entre eux a été l'ajout du modèle de composants , dans lequel la plupart des tendances de développement initiales ont convergé.

Angular 1 a vécu longtemps et continue de vivre au sein de la communauté front-end. Avec tous ses avantages et ses inconvénients, il a aidé la communauté à comprendre l'importance de l'architecture logicielle et a fourni la base pour l'écriture d'applications évolutives. Ses inconvénients et ses lacunes sont devenus la base de la résolution des problèmes des futures architectures.