Je veux faire une réserve tout de suite que cet article n'est pas destiné à ceux qui ont le développement frontend l'activité principale. Ce message est destiné aux développeurs de backend qui avaient un besoin urgent de fixer l'interface utilisateur Web ou à ceux qui sont simplement intéressés par de nouveaux domaines, ainsi qu'aux développeurs fullstack.
Passons donc au problème. Je me souviens d'
un article , et aussi, dans les espaces ouverts de Habr, il y en avait plusieurs autres similaires. Ils sont tous présentés comme des bandes dessinées, mais comme on dit «dans chaque blague, il y a un grain de vérité», et ici ce n'est même pas un peu ... Mais voici la question, à quel point tous ces cadres sont-ils utiles, sont-ils nécessaires?
La question que je voudrais soulever concerne principalement le montage. C'est à ce stade que la communauté js propose un nombre incroyable d'outils dont le besoin n'est pas du tout évident. Par exemple, la communauté offre diverses options pour travailler avec des modules, ce qui était logique à l'époque, mais pour le moment, la spécification d'
importation /
exportation est prise en charge par tous les navigateurs modernes, et même pas par le navigateur de bord. Comme nous avons mentionné précédemment que nous n'avons aucune raison de travailler avec les anciennes bibliothèques, nous allons examiner les spécifications d'importation / exportation. Mais ce dont nous avons vraiment besoin, c'est d'une sorte de travail avec des dépendances.
Je vais faire une petite digression pour expliquer le choix des technologies qui seront utilisées dans l'exemple pour le frontend lui-même. Afin de ne pas nous plonger dans la multitude de cadres, passons d'un merveilleux
standard . Donc, tout devient assez simple, il n'y a pas de DOM virtuel, il y a des composants web. Cela pourrait être terminé, mais toujours js. Si nous décidons de nous débarrasser des js
purs , alors nous devrons résoudre les problèmes d'infrastructure, se débarrasser du code de la chaudière, etc. En d'autres termes, pour rendre votre vélo un peu ... Pour ne pas le faire, je voudrais prendre quelque chose où tout a déjà été fait et est de assez bonne qualité. En conséquence, mon choix s'est
porté sur
Polymer - un framework de Google, qui a poussé les composants Web dans la norme.
Retour à l'assemblée. Beaucoup d'entre vous (développeurs Java en tout cas) sont habitués à un outil tel que maven et gradle, et vous avez probablement réussi à découvrir qu'ils font un excellent travail avec la manipulation des ressources (pour maven c'est bien sûr un peu pire, mais pour gradle il n'y a aucun problème du tout quoi que ce soit). La communauté frontend nous propose de prendre npm, pour lequel nodeJs est nécessaire, mais cela ne suffit pas, webpack est également au top. Et ils doivent encore comprendre et mettre à la disposition de chaque développeur. Hum ... Je voudrais simplement dégonfler le dépôt, faire construire gradlew et commencer à travailler, alors arrêtons-nous au gradle habituel.
Bien sûr, nous ne pouvons pas nous passer du tout de npm, au moins nous avons besoin d'un référentiel d'où obtenir les bibliothèques js et que npm le fournit, mais l'utilitaire est facultatif. Vous pouvez trouver de bonnes solutions comme
celle-ci , mais ils téléchargent toujours nodeJs et exécutent des tâches npm. Une option, mais je voudrais minimiser la communication avec npm avant d'interagir avec le référentiel et plus encore. Comme solution, écrivez votre propre plugin pour gradle. Bien que l'écriture de plugins pour gradle soit assez simple, en raison de la grande variété d'options pour spécifier les versions du référentiel npm, la tâche est un peu plus compliquée. Heureusement, il existe une
documentation claire à ce sujet.
Écrivons donc un script gradle pour charger les dépendances. Il est utilisé par kotlin dsl pour la raison que la réécriture en groovy dsl est assez banale, mais au contraire, cela aurait pris du temps s'il n'y avait pas d'expérience précédente.
repositories { mavenLocal() jcenter() } dependencies { classpath("com.github.artfable.gradle:gradle-npm-repository-plugin:0.0.3") } apply(plugin = "artfable.npm") configure<GradleNpmRepositoryExtension> { output = "$projectDir/src/libs/" dependencies = mapOf( Pair("@polymer/polymer", "3.0.5"), Pair("@polymer/app-layout", "3.0.1"), Pair("@polymer/paper-toolbar", "3.0.1"), Pair("@polymer/paper-icon-button", "3.0.1"), Pair("@polymer/iron-icons", "3.0.1"), Pair("@webcomponents/webcomponentsjs", "2.1.3") ) }
Ce
plugin nous ajoutera
npmLoad . Pour laisser le groupe IDE bien, définissez-le dans un groupe
tasks["npmLoad"].group = "frontend"
Très bien, vous pouvez essayer d'écrire du code pour notre frontend. Le serveur Intellij intégré vous indiquera par défaut que la
méthode non autorisée tente de connecter des scripts via l'importation. Pour éviter cela, cochez la case
Autoriser l'utilisation des requêtes . (dans les dernières versions il fonctionne sans).
Essayons de commencer maintenant, et ... Pourtant, rien n'a fonctionné. Les dépendances à l'intérieur des composants en polymère se sont effondrées. Le fait est que de nombreuses bibliothèques js poussent les importations dans l'attente d'une sorte de transpilateur comme babel. Une telle importation ressemble à ceci:
import '@polymer/polymer/polymer-legacy.js';
Cette importation de syntaxe n'est pas correcte, car pour un navigateur, le chemin ne doit commencer que par '/', './' ou '../'. De plus, sous cette forme, il ne peut être pris ni comme relatif ni comme absolu, car ici le calcul est fait pour le début à partir de la racine du répertoire de la bibliothèque. Par conséquent, ces chemins doivent être corrigés et pour ne pas le faire vous-même, vous pouvez prendre un
plug-in préparé.
Selon
classpath("com.github.artfable.gradle:gradle-js-import-fix-plugin:0.0.1")
apply(plugin = "artfable.js.import.fix") configure<GradleJsImportFixExtension> { directory = "$projectDir/src/libs" }
La tâche
jsImportFix sera
ajoutée, ce qui mettra toutes les importations en ordre.
Juste comme ça, et sans avoir à faire face à une montagne de nouveaux outils, vous pouvez mettre en place un front. Mais regardons à nouveau la question des styles. Franchement, les composants Web peuvent se débarrasser d'un passe-partout, et les variables en CSS qui sont déjà dans la norme ouvrent de nombreuses possibilités, donc des choses comme Sass ne sont plus nécessaires. Mais soudain, par exemple, vous avez beaucoup aimé le
bootstrap et avez voulu faire un design sur cette base.
Trouver un plug-in pour construire sur ce sujet n'est pas un problème, fondamentalement, ils prennent tous
libsass comme base et il y a un wrapper en java -
jsass . Le seul problème pour tout le monde (au moins au moment où je les ai considérés) est la duplication des fichiers dépendants.
Un exemple:
Fichier a:
@import “b”; @import “c”;
Fichiers _B et _c:
@import “d”;
En conséquence, nous obtenons dans le fichier principal 2 blocs identiques du fichier _c. Vous pouvez tout simplement le corriger, si vous ajoutez l'
importateur à jsass, api le permet. En fait, donc, je suis à nouveau avec ma décision
ici (s'il n'y a pas de telles exigences, alors il vaut mieux utiliser une autre solution).
Ajouter des dépendances npm à la liste
Pair("bootstrap", "4.1.3")
Dépendance du plugin
classpath("com.github.artfable.gradle:gradle-sass-plugin:0.0.1")
apply(plugin = "artfable.sass") configure<GradleLibsassPluginExtension> { group(delegateClosureOf<GradleLibsassPluginGroup> { sourceDir = "src/sass" outputDir = "src/css" } as Closure<Any>) } tasks.create("processResources")
La fausse tâche processResources
devra être créée si le plug-in java n'est pas connecté (et nous n'en avons pas besoin ici). C'est bien sûr un défaut, alors je vais définitivement le corriger.
Veuillez noter que le fichier css résultant ne doit pas être connecté à la
tête , car à l'intérieur du composant, il ne sera pas visible, mais directement dans le modèle du composant lui-même.
La dernière étape consiste à modifier légèrement le script pour obtenir le répertoire de
construction habituel, avec un projet prêt à l'emploi qui peut être déployé sur prod.
Le code complet a été téléchargé sur github (vous devrez probablement migrer vers gitlab plus tard ...).
J'espère que l'idée de base est claire, et ensuite vous pourrez ajouter tout simplement tout ce que vous voudrez. Merci d'avoir lu.