Comment choisir un moteur de modèle web front-end (recommandé)

Le contenu de cet article explique comment choisir un moteur de modèle frontal Web (recommandé). Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.

Le moteur de modèles est responsable de l'assemblage des données et de la présentation des données sous une autre forme ou apparence. La page du navigateur est l'expression finale du moteur de modèle Web.

Que vous utilisiez le moteur de modèles directement ou non, les modèles Web ont toujours été là, non pas dans le front-end mais dans le back-end. Leur émergence remonte même à avant la création formelle du balisage hypertexte. Norme HTML du langage.

Moteur de modèles côté serveur

Le premier moteur de modèles Web que je connaisse est PHP, qui est officiellement né en 1997 et fonctionne côté serveur. Jetons un coup d'œil à l'introduction officielle de PHP :

Les HPers conviennent généralement que PHP lui-même est le moteur de modèles PHP le plus naturel et le plus natif, car c'est le cas. Il existe de nombreux moteurs de modèles reconditionnés dans le monde PHP, le plus célèbre étant smarty.

De nombreux autres langages côté serveur disposent de moteurs de modèles HTML, tels que JSP et Mustache.

Il ne fait aucun doute que le résultat final généré par ces moteurs de modèles côté serveur est une chaîne HTML (XML) et que la logique du flux de traitement est implémentée en utilisant la syntaxe du langage hôte lui-même.

Leur point commun : le HTML n'est qu'une chaîne de caractères, et le résultat final peut nécessiter un nettoyage ou une correction avec des outils de validation comme Tidy.

Voici une question : est-il nécessaire d'avoir un smarty encapsulé secondaire ?

Moteur de modèles côté navigateur

Le plus ancien que je connaisse Le moteur de modèle frontal est jCT, hébergé sur Google Code et né en 2008. Le langage hôte est JavaScript et fonctionne dans le navigateur.

Si vous recherchez un moteur de modèles JavaScript dans OSC aujourd'hui, vous obtiendrez plus de 100 résultats :

Léger : tpl.js, T.js
Conscience : arttemplate, moustache.js, doT.js, handlebars.js, pug
Basé sur un arbre DOM : domTemplate, transparence, plaques
Basé sur VDOM : htmltemplate-vdom, virtual-stache, html-patcher
Frameworks populaires : Vue.js, ReactJS, riot
Real-DOM : PowJS

Leur point commun : tous supportent l'interpolation.

Voici également une comparaison de la popularité des moteurs de création de modèles, et même un vote pour les meilleurs moteurs de création de modèles Javascript et les raisons des avantages et des inconvénients.

Comment choisir

Je pense que l'existence est raisonnable. Chaque moteur et chaque framework a toujours du mérite, du moins dans votre application, à une certaine époque, donc cet article le fera. Je ne commenterai pas ce qui ne va pas avec un certain moteur, car cela ne serait pas objectif. Maintenant, pour répondre à la question évoquée précédemment : est-il nécessaire d’exister ? Ma réponse est : oui. La raison est très simple, cela dépend de la personne pour laquelle il est utilisé et du contexte général. Pour les applications où le front-end et le back-end ne sont pas séparés, ou où le personnel front-end n'est pas suffisamment familier avec le langage back-end, ou où les responsabilités professionnelles l'exigent, il est réaliste que le personnel front-end maîtrise une syntaxe de modèle (langage) plus courante. Au contraire, laissez PHPer utiliser smarty tout seul. C'est un tel gaspillage de compétences.

Voici des suggestions générales pour la sélection du moteur :

Le principe est que le moteur sélectionné peut répondre aux besoins de rendu des données et n'entre pas en conflit avec les dépendances existantes. moteur, alors vous avez déjà votre réponse.

S'agit-il d'une exigence ponctuelle du projet ? Si tel est le cas, choisissez simplement le modèle léger avec la complexité d'apprentissage la plus faible. Voulez-vous développer des composants ?

Le moteur prend en charge les résultats précompilés, vous n'avez donc pas besoin de les compiler en temps réel à chaque fois

Voulez-vous être multiplateforme ? ? Il existe des moteurs officiels qui fournissent un support, et le moteur React-JSX ou un moteur VDOM pur.

Choisissez celui qui est le moins complexe à apprendre ou à maintenir Comme nous le savons tous, les développeurs détestent passer plus de temps à déboguer qu'à écrire du code.

La dernière étape est la comparaison des performances. La comparaison des performances est une tâche très détaillée, et les résultats de la comparaison d'autres personnes ne correspondent pas nécessairement à votre scénario.

Je pense que la comparaison des styles de grammaire devrait être affaiblie. Les préférences ne sont pas comparables. Certaines grammaires ont même des raisons de fond particulières.

Pourquoi la comparaison des performances est-elle la dernière chose ?

Les performances sont en effet importantes, mais si les performances n'affectent pas votre expérience d'application, ignorez-les. Il est difficile de simuler véritablement des scénarios d'application. Habituellement, cela ne peut être testé qu'à travers des scénarios réels. Les outils de test actuels ne peuvent pas obtenir cet effet.

Certaines des questions susmentionnées ont des réponses fixes. Discutons des questions restantes : comment prendre en compte le développement de composants, la prise en charge de la pré-compilation et la complexité ?

Développement de composants

Le développement de composants n'est plus une question de choix d'un moteur de modèle, c'est une question de sélection d'environnement écologique. Si votre application doit être complétée plus rapidement, alors le temps est la première priorité, choisissez un framework populaire qui contient suffisamment de composants pour que vous puissiez l'utiliser ou vous y référer. Si votre application dispose d'un environnement écologique indépendant et nécessite une sélection technologique pour une maintenance à long terme, continuez à lire ci-dessous.

Pré-compilation

La pré-compilation doit avoir :

Le résultat de la compilation ne nécessite plus de processus de compilation dans l'environnement cible.
Compilez les résultats pour le débogage, ce qui signifie que les résultats doivent contenir du code ECMAScript natif plutôt que des descriptions de données pures.
Tout le monde sait que React-JSX prend en charge la pré-compilation. La déclaration officielle est que React Without JSX signifie qu'il est toujours construit.

Certains moteurs basés sur le traitement de chaînes prennent également en charge la précompilation. Si vous avez besoin d'une pré-compilation, il est recommandé d'abandonner le moteur dont le résultat de la compilation est toujours basé sur la concaténation de chaînes. Il est préférable de ne pas pré-compiler. C'était une méthode technique avant que HTML5 ne soit largement supporté.

Au moins, il doit y avoir un résultat compilé comme React-JSX pour être déboguable. Remarque : Vue.js prend en charge plusieurs moteurs de modèles pour obtenir le même effet.

Code ReactJS original, qui utilise la technologie Web Components :

class HelloMessage extends React.Component {
  render() {
    return <p>Hello <x-search>{this.props.name}</x-search>!</p>;
  }
}

Après compilation :

class HelloMessage extends React.Component {
  render() {
    return React.createElement(
      "p",
      null,
      "Hello ",
      React.createElement(
        "x-search",
        null,
        this.props.name
      ),
      "!"
    );
  }
}

De nombreux moteurs VDOM peuvent également compiler des effets similaires, tels que htmltemplate - vdom.

  <script>
        var id = 3;
        var env = {
            people: [
                {
                    id: &#39;id1&#39;,
                    name: &#39;John&#39;,
                    inner: [{ title: &#39;a1&#39; }, { title: &#39;b1&#39; }],
                    city: &#39;New York&#39;,
                    active: true
                },
                {
                    id: &#39;id2&#39;,
                    name: &#39;Mary&#39;,
                    inner: [{ title: &#39;a2&#39; }, { title: &#39;b2&#39; }],
                    city: &#39;Moscow&#39;
                }
            ],
            githubLink: &#39;https://github.com/agentcooper/htmltemplate-vdom&#39;,
            itemClick: function(id) {
                env.people.forEach(function(person) {
                    person.active = String(person.id) === String(id);
                });
                loop.update(env);
            }
            // Omitted ....
        };
    </script>

Complexité

Il est difficile d'utiliser un seul critère pour juger lequel des deux moteurs est le moins complexe. Cela est dû aux différents modes de pensée des utilisateurs. Par exemple, les différences d'utilisation et les résultats précompilés des moteurs répertoriés ci-dessus sont différents selon les utilisateurs. C'est la rationalité et la valeur de l'existence de différents moteurs.

Certains utilisateurs pensent que les modèles de chaînes peuvent répondre aux besoins de ce scénario d'application et sont légers et suffisants.
Certains utilisateurs pensent que le moteur de modèles de la technologie d'épissage de chaînes n'est pas assez puissant ni assez moderne.
Certains utilisateurs pensent que la POO est assez rationnelle, assez logique et assez abstraite.
Certains utilisateurs pensent que le HTML natif est appelé front-end.
Certains utilisateurs pensent que VDOM a une applicabilité plus large.

Ces jugements ont leurs propres raisons, avec des orientations et des normes différentes. Mais on peut néanmoins considérer leur complexité à partir de leurs points communs.

Les modèles de chaînes sont généralement très légers et dépassent le cadre de cette section. Quels sont les critères courants pour juger de la complexité des modèles sans chaîne ? Je pense que la complexité de la liaison des données peut être prise en compte.

La liaison de données mentionnée dans cet article n'est pas seulement une interpolation, mais inclut également le contexte et les événements, et même l'environnement hôte de l'ensemble du runtime.

En fait, un moteur qui atteint au moins le niveau VDOM doit avoir cette capacité, car VDOM peut être mappé sur de vrais nœuds DOM.

Il existe probablement plusieurs modes (combinaisons) :

1. Le paramètre d'entrée est un Objet, et la variable x dans le modèle est l'attribut .x de l'objet, par exemple : virtuel -stache-example
2. Syntaxe ou attributs spécifiques, tels que : ceux de Vue.js..., les attributs calculés, les méthodes
3. Attributs sémantiques abstraits, tels que : actif de Vue.js. pour une variété de scénarios et est facile à comprendre. Et il n'y a aucune ambiguïté
4 Il n'est pas responsable de la liaison. Les utilisateurs doivent être très familiers avec les méthodes natives et utiliser des méthodes natives pour la liaison, telles que : PowJS

Ces modes ne sont que des problèmes théoriques de conception de moteur de modèle à résoudre. Pour les utilisateurs, il est préférable de demander directement :

1. Le fichier console.log(context) le plus simple peut-il être écrit directement dans le modèle HTML pour le débogage

2. Arbre DOM de couche ? Ou transmettre différents paramètres de contexte ?
3. Le nœud généré est-il accessible vers le haut dans l'arborescence DOM multicouche ?

L'équipe du moteur de modèle vous donnera la bonne solution, mais généralement elle est lié au problème. Les objectifs littéralement décrits varient. Je pense que c'est la clé de votre jugement de choix, de votre reconnaissance de la bonne méthode donnée par l'officiel.

Intégré dans DOM

Intégré dans HTML

PowJS est implémenté comme ceci :

Instructions qui doivent être implémentées pour implémenter le modèle

Pré- compilé Sortie du code ECMAScript natif
La structure syntaxique du modèle est cohérente avec la méthode d'écriture des fonctions ECMAScript
En fin de compte, écrire des modèles PowJS est comme écrire des fonctions ECMAScript.

Écrire dans l'index GoHub

<template>
  <details>
    <summary>{{ctx.Description}}</summary>
    <p>
      </p>
<p>{{pkg.Import}}</p>
    
  </details>
  <dl>
    <details>
      <summary>{{rep.synopsis}}</summary>
    </details>
  </dl>
</template>

La plupart des moteurs de modèles implémenteront if et each instructions Le modèle PowJS ci-dessus contient également :

Les objets globaux sont, sel

. Dépôt de dénomination de modèle (fonction), liste
Données de paramètre d'entrée de modèle (fonction)
Variable locale personnalisée ctx
Dérivation de paramètre formel de modèle inférieur (fonction) data.sha->sha
Traverser la valeur vers la dérivation du paramètre de modèle inférieur (ctx.Package,val-pkg)->pkg, (data.content,val-rep)->rep
Opération du nœud DOM this.renew, this.appendTo, ceci est directement rendu à l'arborescence DOM de la page
Rupture de contrôle de processus
Pseudo nœud if="':';", le nœud p n'est pas du tout généré lors du rendu, c'est un pseudo nœud, équivalent au symbole de code de bloc "{ }"
La clé est que toute la structure du modèle, la sémantique des instructions sont exactement les mêmes que celles des fonctions ECMAScript :

Il n'y a pas de liaison de données, vous écrivez une fonction ECMAScript, transmettez simplement les paramètres, quoi liaison voulez-vous ?

Il n'y a pas de liaison d'événement, chaque nœud est réel, écrivez simplement addEventListener directement
Pour déboguer, trouvez simplement un do ou if ou let et insérez _=console.log(x), et le l'expression virgule peut être presque éliminée Toutes les instructions natives sont insérées de manière transparente
Toute la logique métier est écrite par l'utilisateur, et PowJS est uniquement responsable de les coller dans une fonction
La vue exportée est le code source ECMAScript L'image suivante. est tiré de la démo My Folders

Alors PowJS est-il le choix final ? Le concept de PowJS est la natif, le DOM natif et l'ECMAScript natif.

Le natif est aussi le problème avec PowJS. Tous les utilisateurs n'aiment pas le natif. Je crois que certains utilisateurs préfèrent un style plus abstrait à leurs yeux, le natif est toujours un peu "original".

Natif signifie que vous pouvez l'étendre et introduire d'autres bibliothèques pour la correspondance, mais PowJS n'aura jamais d'observateur implémenté par définir setter/getter, ce qui dépasse la portée du moteur de modèle. S'il existe, il doit s'agir d'un projet indépendant. .

Enfin, mon point est toujours le même : vos besoins sont la clé pour choisir un modèle, et celui qui vous convient est le meilleur.

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!