Explication détaillée des problèmes liés aux moteurs de modèles front-end-tutoriel HTML-php.cn

Le moteur de modèles front-end doit être transparent pendant le développement

La transparence signifie qu'après avoir configuré l'environnement de développement, je peux écrire du code et actualiser le navigateur Vous pouvez voir les derniers effets sans exécuter de commandes supplémentaires ni attendre un processus.

Ainsi, tous les moteurs de modèles qui reposent sur le processus de compilation ne sont pas adaptés à une utilisation frontale. La compilation ne peut être qu'une fonctionnalité du moteur de modèles, pas une condition préalable à son utilisation

Plus strictement parlant. , en utilisant FileWatch, etc. Les méthodes permettant de détecter les modifications de fichiers et de compiler automatiquement n'entrent pas dans le cadre de ma considération, car cela entraînera une attente supplémentaire

De cela, on peut en déduire que le moteur de modèle frontal. devrait être équipé de qui peut être utilisé dans le front-end pur. La possibilité d'utiliser dans l'environnement est analysée.

Le moteur de modèles front-end doit avoir de bonnes capacités de débogage d'exécution

En raison de l'incertitude du comportement des utilisateurs, de l'incertitude de l'environnement d'exécution et de l'incertitude de divers scripts tiers Impact, etc., il est difficile pour le front-end d'assurer une gestion et un suivi complets des erreurs, ce qui conduit également au fait que le front-end doit directement résoudre les problèmes en ligne

Et quand le le problème se produit au niveau du moteur de modèle, des modèles sont nécessaires Le moteur offre de bonnes capacités de débogage

De manière générale, les capacités de débogage des fonctions compilées sont plus faibles que celles des fragments de modèle originaux écrits manuellement, car les fonctions générées automatiquement sont essentiellement illisible et avoir des points d'arrêt

Par conséquent, à ce stade, un moteur de modèle destiné à une utilisation frontale devrait avoir le mode permettant de passer de "l'exécution de la fonction compilée pour obtenir du HTML" à "l'analyse du modèle d'origine". puis exécuter la fonction pour obtenir du HTML" dans certaines circonstances. , c'est-à-dire qu'il doit prendre en charge la commutation entre les deux modes

ou mieux encore, une fonction compilée et générée par un puissant moteur de modèle frontal peut être directement mappé au fragment de modèle d'origine à l'aide de Source Map ou d'autres moyens personnalisés, mais il n'existe actuellement aucun moteur de modèle qui implémente cette fonction

Les moteurs de modèles front-end doivent être conviviaux pour la fusion de fichiers

Avant que HTTP/2 ne devienne populaire, la fusion de fichiers était encore une performance frontale. Un moyen important d'optimisation, les modèles, en tant que partie du fichier, doivent encore être fusionnés

Dans le modèle moteur qui fournit une fonction de compilation, nous pouvons utiliser la compilation pour transformer le modèle en code source JavaScript, puis en JavaScript faire essentiellement la fusion de fichiers

Mais si nous voulons conserver les fragments du modèle d'origine pour des raisons telles que les capacités de débogage mentionnées ci-dessus, le moteur de modèle lui-même doit prendre en charge la fusion de fragments de modèle en un seul fichier

La plupart des moteurs qui prennent uniquement en charge l'analyse d'une chaîne d'entrée en tant que modèle n'ont pas cette capacité. Ils sont intrinsèquement incapables de diviser une chaîne entière en. plusieurs fragments de modèle, et ne peut donc pas prendre en charge la fusion de fichiers au niveau des fragments de modèle

Il est nécessaire d'implémenter la prise en charge de la fusion de fichiers. La meilleure façon est de baser la syntaxe du modèle sur des "fragments"

<.>

Le moteur de modèles front-end doit être responsable de la prévention des XSS

Du point de vue de la sécurité, le front-end a des exigences strictes pour le contrôle XSS

Un plus approprié La façon pour le front-end d'empêcher XSS est d'utiliser la politique de liste blanche "d'échappement par défaut"

Sur cette base, un moteur de modèle raisonnable

doit prendre en charge l'échappement par défaut, c'est-à-dire toutes les données la sortie est traitée par la logique d'échappement par défaut et les symboles clés sont convertis en symboles d'entité HTML correspondants afin d'éliminer le chemin d'intrusion de XSS à partir de la racine

Bien sûr, tout le contenu ne doit pas être échappé. Dans le système, les utilisateurs ont inévitablement besoin de saisir du texte riche, une syntaxe spécifique doit donc être prise en charge pour générer du texte enrichi, mais faites toujours attention au cas particulier de la sortie sans échappement. Par défaut, il doit s'agir d'une sortie d'échappement <.>

Le moteur de modèles front-end doit prendre en charge la réutilisation des fragments

Ce n'est pas une exigence du moteur de modèles front-end. En fait, tout moteur de modèles devrait prendre en charge. la réutilisation de fragments tels que Velocity, Smarty, etc. ont tous cette fonction

La soi-disant réutilisation de fragments devrait avoir les niveaux d'application suivants :

Le moteur de modèle frontal doit prendre en charge le traitement lorsque les données sont sorties

Le soi-disant traitement de sortie de données signifie qu'une donnée doit être traitée lorsque sortie Effectuez des conversions supplémentaires, les plus courantes telles que les opérations de découpage de chaîne, les plus techniques telles que la conversion de démarque, etc.

Il est vrai que la conversion des données peut être complètement traitée via la logique JavaScript avant de transmettre les données au moteur de modèles. , mais cela entraînera beaucoup de code laid et redondant, et aura également un impact négatif sur la réutilisabilité de la logique elle-même

Habituellement, les moteurs de modèles utilisent des filtres pour effectuer un traitement supplémentaire sur les données, similaire à la logique des pipelines dans bash. La mise en œuvre et l'enregistrement des filtres auront également des conceptions différentes.Par exemple, moustache enregistre en fait l'usine fitler, tandis que d'autres moteurs de modèles enregistreront directement le filtre lui-même.Différentes conceptions ont des considérations différentes, et il nous est difficile de dire qui est bon. et qui est mauvais

Cependant, une fois que le moteur de modèle prend en charge le traitement de sortie des données, cela nous entraînera un nouvel enchevêtrement dans le processus de codage, c'est-à-dire quel traitement de données doit être implémenté par le filtre du moteur de modèle et lequel les données doivent être implémentées par le moteur de modèle avant d'être transmises au moteur de modèle. Implémentez votre propre logique. Ce sujet est une longue discussion. S'il n'est pas pertinent pour le sujet actuel, ignorez-le

Le moteur de modèle frontal doit prendre en charge les données dynamiques

Dans. le processus de développement En fait, beaucoup de données ne sont pas statiques. Par exemple, EmberJS fournit le concept de propriété calculée et Backbone peut le réaliser déguisé en réécrivant la méthode get de Model

. Bien que la prise en charge d'ES5 Getter soit directement fournie au niveau du langage, nous n'utilisons toujours pas cette fonctionnalité du langage dans la plupart des scénarios de développement front-end. Au lieu de cela, nous choisissons d'encapsuler les données dynamiques dans les méthodes d'obtention d'une sorte d'objet

<.>Le moteur de modèles doit également y prêter attention lors de la conversion de données en fragments HTML, et avoir un bon support pour ces données calculées dynamiquement

Pour le dire plus clairement, le moteur de modèles ne doit pas simplement accepter Pure Object (Plain Objet) en entrée, mais devrait être plus ouvert pour accepter des données dynamiques avec la méthode get

Une logique plus raisonnable est que si un objet a une méthode get (le moteur de modèle détermine cette interface), les données sont obtenues via cette méthode. Dans d'autres cas, l'objet d'entrée est considéré comme un objet simple et une logique d'acquisition d'attributs standard est utilisée

Le moteur de modèle frontal doit être étroitement intégré au processus asynchrone

Un exemple très courant est que nous avons un module AMD qui stocke les constantes utilisées globalement, et le moteur de modèles doit utiliser ces constantes. Bien sûr, nous pouvons laisser JavaScript obtenir ce module de manière asynchrone avant d'utiliser le moteur de modèle, puis transmettre les constantes sous forme de données au moteur de modèle, mais c'est une manière de coupler le métier et la vue Par trouble obsessionnel-compulsif, je. ne pense pas que ce soit un beau design, nous espérons donc que la sortie du modèle

lui-même deviendra une méthode asynchrone, au lieu de renvoyer directement une chaîne comme c'est le cas maintenant
En analysant la dépendance du modèle aux opérations asynchrones, la logique d'épissage de la chaîne entière est divisée en plusieurs asynchrones
Asynchrone nécessite une attente, et l'attente est inconnue. Du point de vue des performances, devez-vous envisager une sortie de style Stream pour compléter un paragraphe et fournir un paragraphe
devrait-il fournir plusieurs asynchrones fixes intégrés ? logique, ou prendre en charge une logique asynchrone personnalisée basée sur Promise ? , pour trouver un équilibre entre complexité et praticité

Jusqu'à présent, je n'ai pas complètement compris la méthode et l'interface de combinaison de modèles avec des modèles asynchrones, et il n'y a aucun moyen d'explorer davantage ce sujet

Le moteur de modèles front-end devrait prendre en charge différents modèles de développement

Depuis le développement du front-end, il existe de nombreux modèles différents modèles de développement, tels que :

La page HTML la plus courante, utilisant des événements tels que DOMContentLoaded pour ajouter de la logique et actualisant partiellement la page sous des interactions spécifiques
Utilisation du modèle MVC traditionnel pour le développement d'une seule page
Utilisation de la méthode MVVM pour développer avec des données comme noyau et une liaison de direction de données et d'affichage
Développement basé sur des données immuables pour la comparaison des données, mise à jour Diff vers DOM (qui peut inclure une introduction virtuelle du DOM)

C'est un très grand défi pour un moteur de modèles de prend en charge de nombreux modes différents, en particulier la prise en charge de la liaison bidirectionnelle. Jusqu'à présent, presque tous les frameworks de développement prenant en charge la liaison bidirectionnelle sont livrés avec un moteur de modèles dédié. En effet, la liaison bidirectionnelle a deux exigences majeures pour les modèles :

peut. L'extraction des méta-informations sur "les données dont dépend ce modèle" du modèle
peut savoir de quelle partie du modèle se trouve un moteur de modification de données, sans actualiser l'intégralité de

Les moteurs de modèles généraux fournissent rarement ces deux fonctionnalités, il n'y a donc aucun moyen de prendre entièrement en charge différents modèles de développement front-end

Depuis l'implémentation du moteur de modèles lui-même, une méthode Il expose directement l'AST -comme une structure après l'analyse du modèle pour que d'autres frameworks puissent le traiter de manière raisonnable, et fournit en même temps une fonction de rafraîchissement partiel pour le modèle (il peut également être considéré avec le fragment de modèle mentionné ci-dessus), mais la plupart des moteurs de modèles pour les performances Si vous pensez à ce sujet, il n'analysera pas une structure grammaticale similaire à AST

Le moteur de modèles front-end doit avoir une isolation entre les instances

Dans les projets front-end à grande échelle , en particulier dans un projet d'une seule page, il y aura un nombre totalement inconnu de fragments de modèle existant en même temps. Si ces fragments ont des noms (pour des raisons de réutilisation), il est facile de provoquer des conflits de noms

Pour la logique au même niveau (par exemple, tout le monde travaille sur le code de la couche métier, ou tout le monde travaille sur le code de la couche de contrôle), les conflits de noms peuvent être résolus grâce à certaines conventions de développement. Mais entre les différentes couches, en raison des exigences d'encapsulation, l'extérieur ne devrait pas connaître les noms de certains fragments qui ne sont utilisés qu'en interne. Si malheureusement les noms entrent en conflit avec d'autres couches, la situation pourrait même devenir plus gênante. Ce n'est pas facile à suivre et entraîne souvent beaucoup de perte d'énergie et de temps

Par conséquent, un bon moteur de modèles doit avoir plusieurs instances, et les différentes instances doivent être isolées les unes des autres pour éviter une telle imprévisibilité.

Si vous étudiez ce sujet plus en profondeur, vous constaterez qu'un simple isolement ne suffit pas. En plus de la nécessité de ne pas conflit entre les différentes couches, il y a également la nécessité d'une réutilisation des fragments. Certains fragments fixes peuvent être partagés entre les instances du modèle, de sorte que la relation entre chaque instance du moteur de modèle est une combinaison de dépendances mais avec une encapsulation et une isolation de base, c'est tout.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!