Quelle est l’utilisation de Jade ou du guidon lors de la création d’applications AngularJs?
Je suis nouveau (ish) dans l’ensemble des applications javascript full stack, et complètement nouveau dans Angular. J’espérais donc que l’autre puisse mettre les choses au clair pour moi ici.
Pourquoi aurais-je besoin d'utiliser un framework de templates comme Jade ou Handlebars lors de l'écriture d'applications côté client à l'aide d'AngularJS.
Je dois dire que je n'ai jamais utilisé aucun de ces frameworks de templates. Donc, je ne connais pas complètement les avantages. Mais quand je regarde le guidon par exemple, il fait beaucoup de choses comme je le ferais dans Angular, comme boucler, etc.
Autant que je sache, il serait plus logique de créer les modèles en Angular en utilisant le code HTML approprié, puis de créer tous les modèles côté client, et de les combiner avec une première approche API utilisant node et mongo par exemple.
La raison de cette confusion est que bon nombre des exemples que je trouve sur GitHub utilisent Jade, et cela semble contre-intuitif pour moi.
S'il vous plaît, éclairez-moi et mettez-moi au clair. J'aimerais apprendre certaines pratiques exemplaires de personnes qui en savent beaucoup plus que moi.
Merci
Ceux qui sans aucun doute préfèrent Jade dans un environnement Angular ne comprennent pas que la logique d'affichage appartient au client et la logique métier au serveur, exactement comme le faisait remarquer le PO.
Ne le faites pas sauf si vous avez une très bonne raison de le faire. En ingénierie, un système avec moins de pièces mobiles est un système plus fiable, et un système où les limites d'interface (client/serveur) sont respecté est plus facile à maintenir sur le long terme, il est donc préférable de s’adapter à l’architecture la plus simple et à une division claire du travail, si possible. Si vous avez des raisons impérieuses, faites ce que vous devez, mais caveat emptor.
Récemment, j’ai passé en revue un code dans lequel la modélisation directe Angular aurait été beaucoup plus efficace que le mixage en Jade, en conservant simplement la simplicité.
Mis à part l'extension du modèle, Jade n'apporte rien de valable à la table que Angular ne fournit pas déjà. Soyons honnêtes: si vous utilisez le principe fondamental "privilégier la composition à l’héritage" (c'est-à-dire les partiels), vous ne devriez jamais besoin extensibilité du modèle. Jade est difficilement "plus facile à analyser" que le HTML. Ils sont mais trivialement différents, alors que Jade ajoute un autre niveau d'indirection - mieux évité.
Il existe un cas valable et spécialisé pour la création de modèles côté serveur: l'optimisation, en se rappelant que l'optimisation prématurée est généralement une mauvaise chose. Lorsque les performances sont véritablement en jeu, et vous avez la capacité du serveur à ménager pour le gérer, la création de modèles côté serveur peut vous aider. Ceci s'applique à des produits tels que Twitter et Basecamp, où le coût de la charge de travail côté serveur est compensé par les gains liés à la réduction des demandes adressées au serveur.
En ce qui concerne le guidon, il n’est pas nécessaire de remplacer le modèle (incroyable) côté client d’AngularJS.
J'utilise Jade pour générer des modèles utilisés par AngularJS parce que je déteste écrire du HTML pur. Cela ressemble à quelque chose comme:
.control-group(
ng-form
name='emailGroup'
ng-class='{"ng-error": emailGroup.$invalid}'
)
label.control-label Email
.controls
input(
type='email'
ng-model='user.email'
required
placeholder='[email protected]'
focus-on='focusEmail'
)
… Ce qui, à mon avis, est beaucoup plus propre que le HTML simple.
Honnêtement, je ne comprends pas pourquoi les gens se soucient de la différence entre ceci:
<html ng-app>
<!-- Body tag augmented with ngController directive -->
<body ng-controller="MyController">
<input ng-model="foo" value="bar">
<!-- Button tag with ng-click directive, and string expression 'buttonText' wrapped in "{{ }}" markup -->
<button ng-click="changeFoo()">{{buttonText}}</button>
<script src="angular.js">
</body>
</html>
et ça:
html(ng-app="ng-app")
// Body tag augmented with ngController directive
body(ng-controller="MyController")
input(ng-model="foo", value="bar")
// Button tag with ng-click directive, and string expression 'buttonText' wrapped in "{{ }}" markup
button(ng-click="changeFoo()") {{buttonText}}
script(src="angular.js")
Sauf que j'en trouve un légèrement plus lisible par l'homme. Légèrement . Je ne comprends pas pourquoi les gens sont si fervents sur le sujet. C'est tout bikeshedding. La différence est négligeable et tout programmeur compétent pourrait facilement traduire l'un après l'autre après cinq secondes sur Google. Utilisez ce que vous voulez et laissez les autres se quereller pour rien. Choisissez vos batailles et engagez des débats sur des sujets importants, tels que réacteurs atomiques;)
- Vous n'avez pas besoin d'utiliser le guidon avec AngularJS car il possède son propre moteur de template.
- La raison pour laquelle ils utilisent Jade, parce qu’il s’agit simplement d’un moteur de rendu de serveur, qui sera compilé en HTML et servi par angularJS plus tard sur le frontal.
Donc, TL; DR, sur le serveur, vous pouvez utiliser n’importe quel langage (jade, haml, ...) pour générer une structure html pour votre application. runtime sur le frontend.
Vous n'êtes pas obligé d'utiliser Jade sur le serveur, et je suggère de ne pas l'utiliser, car cela dérouterait les nouveaux développeurs. Dans les projets que vous voyez, ils n'utilisent Jade que parce qu'il est plus propre et qu'ils y sont habitués. S'il l'utilise avec angularJS, son seul travail est de générer du HTML simple sans aucune logique.
La réponse acceptée est quelque peu unilatérale et néglige le fait que toute configuration de pré-compilateur pour HTML est très utile pour TOUT type de projet HTML: Composition et flexibilité des balises résultantes.
Travailler seul sur un angular angulaire? Essayez Jade.
Jade améliore votre capacité à modulariser le HTML, réduit le temps que vous consacrez au débogage HTML et encourage également la création d'inventaires de balises.
Pendant la phase de conception, il peut y avoir une énorme quantité d'itérations sur les parties HTML. Si la sortie HTML est basée sur un ensemble de fichiers jade, l'équipe peut facilement faire preuve de souplesse face à l'évolution des besoins. En outre, la modification du balisage via la recomposition de jade includes est nettement plus robuste que la réécriture en HTML pur.
Cela étant dit, je reconnais l'aversion générale pour le mélange angular avec le jade en phase de production ou de développement. L'introduction d'un autre ensemble de connaissances syntaxiques requis est une mauvaise idée pour la plupart des équipes et l'utilisation de jade pourrait masquer Gestion de projet inefficace en extrayant certains travaux qui seraient interdits par les principes de DRY (par exemple, être paresseux lors de la préparation du balisage))
J'ai lu toutes les réponses ci-dessus et je suis un peu surpris que personne n'ait mentionné un aspect qui rend l'utilisation de jade par-dessus la génération de modèles AngularJS très utile.
Comme il a déjà été dit, en production, la différence de scénarios réalistes entre la frappe de HTML brut et de Jade est remarquable, mais la chose la plus importante à ne jamais oublier est que nous avons parfois besoin de manière dynamique modifiée et réinitialisée angularjs modèles.
En termes simples, parfois nous devons changer le langage HTML via innerHTML, puis forcer AngularJS à recompiler le contenu. Et c’est exactement le type de tâche lorsque la génération de telles vues via jade peut en bénéficier.
De plus, AngularJS fonctionne bien avec les modèles, dont la structure est par définition bien connue. En fait, il arrive que nous ne connaissions pas la structure exacte (imaginez, par exemple, le moteur de rendu JSON). AngularJS sera assez maladroit ici (même s’il est en train de construire un angular app), alors que jade fera le travail.
Jade est nettement plus proche du html que Haml. Le changement de contexte est donc très minime. Pourtant, il n'est pas complètement absent. Cela n’a aucune importance pour un développeur. Mais lorsque votre concepteur vous demande comment faire fonctionner correctement une balise imbriquée, vous résolvez un problème inutile que vous avez créé.
Le HTML peut toujours être écrit très lisiblement et les partiels peuvent être utilisés pour le rendre plus compréhensible. 500 lignes de n'importe quoi est difficile à lire - que ce soit en Jade ou en HTML.
Voici un modèle de jade
.product-container
.input-group.msB.col-md-5.no-padding
.fnt-light-navyblue.mtB(for='name')
strong Name the sticker
input.full-input(type='text', placeholder='Awesome Batman Sticker')
.clear
.form-group.mmT
label.form-label.fnt-light-navyblue
strong Choose size
.selector-group(ng-repeat="size in sizes", ng-class="{ 'msT': !$first}")
- raw
span.radio
input.radio(name='choose_sticker_size',
ng-model="selectedSize",
type='radio',
value='{{size}}',
id="sticker-{{size}}")
span.fake-radio
label(for='sticker-{{size}}') {{size}} inch
- endraw
// end form-group
.clear
Et l'équivalent HTML
<div class="product-container">
<div class="input-group msB col-md-5 no-padding">
<div for="name" class="fnt-light-navyblue mtB">
<strong>Name the product</strong>
</div>
<input type="text" placeholder="Awesome Batman Sticker" class="full-input" />
</div>
<div class="clear"></div>
<div class="form-group mmT">
<label class="form-label fnt-light-navyblue">
<strong>Choose size</strong>
</label>
<div
class="selector-group"
ng-class="{ 'msT': !$first}"
ng-repeat="size in sizes">
{% raw %}
<span class="radio">
<input
id="sticker-{{size}}"
class="radio"
name="choose_sticker_size"
ng-model="selectedSize"
type="radio"
value="{{ size }}" />
<span class="fake-radio"></span>
</span>
<label for="sticker-{{size}}">{{size}}</label>
{% endraw %}
</div>
</div><!-- end form-group -->
<div class="clear"></div>
</div>
Lorsque je lis lisiblement, je ne vois pas le langage HTML particulièrement désavantagé pour justifier un changement. Effectivement, les crochets angular sont une source de pollution visuelle. Mais je préférerais les avoir, plutôt que de devoir gérer les doutes du concepteur quant au fait que l'indirection que j'ai introduite casse le code HTML. (Peut-être pas. Mais prouver que ce n'est pas un effort digne)
Vous pouvez inclure angular angulaires via Jade.
script(type="text/ng-template", id="admin")
include partials/admin
Pour les modèles de mise en cache, cela me semble beaucoup moins fragile que d'inclure les modèles échappés dans les fichiers javascript.
Voir: https://docs.angularjs.org/api/ng/service/$templateCache
Lorsqu'ils travaillent en équipe, les utilisateurs préfèrent probablement concevoir leurs pages au format HTML statique. La traduction de ce code HTML statique en modèles dynamiques est une source d’erreurs, et l’ajout de jade ajoute cette étape de traduction.
Comme beaucoup d'autres, je privilégie la simplicité!
Tout d’abord, vous avez toujours besoin d’une sorte de modèle côté serveur.
La gabarit pur côté client présente d'énormes inconvénients lors du chargement; il est donc souvent atténué par le rendu de certains éléments statiques sur le serveur. Ainsi, lorsque l'utilisateur charge partiellement une page, il voit déjà certains éléments sur la page.
Et bien, les modèles sont pratiques dans ce cas, bien que les gens utilisent parfois un générateur html statique comme Jekyll à la place.
Il y a une autre raison d'utiliser Jade qui n'est pas mentionnée ici auparavant.
Les espaces blancs.
Si vous écrivez du code HTML maintenable par l'homme avec des indentations et des sauts de ligne, chaque saut de ligne génère un nœud de texte en blanc. Dans certains cas, il peut très bien visser le formatage des éléments en ligne et rendre le code javascript plus étrange.
Vous pouvez lire plus de détails ici: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Whitespace_in_the_DOM
Si vous écrivez du code Jade, il est compilé en HTML sur une ligne et ne présente pas ce problème.