Dans ce premier article d'une nouvelle série sur le portefeuille d'actifs dans Rails, j'aimerais aborder quelques concepts de haut niveau qui sont pratiques pour bien comprendre ce que le portefeuille d'actifs peut offrir et ce qu'il fait sous le capot. Les principales tâches qu’il gère pour vous sont la concaténation, la minification et le prétraitement des actifs. En tant que débutant, vous devez vous familiariser avec ces concepts le plus tôt possible..
Les sujets
Pipeline d'actifs?
Organisation
Concaténation & Compression?
Langues de haut niveau
Pipeline d'actifs?
Le portefeuille d'actifs n'est pas une nouveauté pour les gens de l'entreprise, mais pour les débutants, il peut être un peu difficile de comprendre rapidement. Les développeurs ne consacrent pas vraiment beaucoup de temps à leurs tâches en amont, surtout au début. Ils sont occupés par de nombreuses pièces mobiles qui n'ont rien à voir avec HTML, CSS ou les bits JS souvent critiqués.
Le pipeline d’actifs peut vous aider en gérant la concaténation, la minimisation et le prétraitement des actifs, par exemple des actifs écrits dans des langages de haut niveau tels que CoffeeScript ou Sass..
Il s'agit d'une étape importante dans le processus de création des applications Rails. Asset Pipeline peut vous donner un coup de pouce non seulement en qualité et en rapidité, mais également en termes de commodité. Le fait de devoir configurer votre propre outil de construction sur mesure peut vous donner quelques options supplémentaires pour ajuster vos besoins, mais il comporte un temps système qui peut prendre beaucoup de temps pour les débutants, voire même être intimidant. À cet égard, nous pourrions parler du pipeline d’actifs comme solution qui favorise la commodité par rapport à la configuration..
L'autre chose à ne pas sous-estimer est l'organisation. Le pipeline offre un cadre solide pour placer vos actifs. Sur des projets plus petits, cela peut sembler peu important, bien sûr, mais des projets plus importants risquent de ne pas se remettre facilement de la mauvaise direction sur des sujets comme celui-ci. Ce n’est peut-être pas l’exemple le plus courant dans le monde, mais imaginons un projet comme Facebook ou Twitter ayant une mauvaise organisation pour leurs ressources CSS et JS. Pas si difficile d’imaginer que cela créerait des problèmes et que les personnes qui doivent travailler et bâtir sur une telle base n’auraient pas la tâche facile d’aimer leur travail..
Comme dans Rails, il existe une approche conventionnelle de la gestion des actifs. Il est ainsi plus facile d’embarquer de nouvelles personnes et d’éviter que les développeurs et les concepteurs ne soient trop obsédés pour apporter leur propre pâte à la fête..
Lorsque vous vous joignez à une nouvelle équipe, vous voulez pouvoir vous mettre au diapason rapidement et prendre votre envol. Avoir à comprendre la sauce spéciale de la façon dont les autres personnes ont organisé leurs actifs n'est pas vraiment utile avec cela. Dans des cas extrêmes, cela peut même être considéré comme un gaspillage et peut gaspiller de l'argent inutilement. Mais ne soyons pas trop dramatiques ici.
Cet article est donc destiné aux débutants parmi vous, et je vous recommande de jeter un coup d'œil immédiat sur le pipeline et de bien maîtriser ce sujet, même si vous ne vous attendez pas à travailler beaucoup sur le balisage ou les tâches frontales. . C'est un aspect essentiel de Rails et non pas un si gros contrat. De plus, les membres de votre équipe, en particulier les concepteurs qui passent la moitié de leur vie dans ces répertoires, mettront des trucs moins drôles dans votre café si vous avez un terrain d'entente qui ne se contredit pas..
Organisation
Vous avez trois options pour placer vos actifs. Ces divisions sont plus d'un type logique. Ils ne représentent aucune restriction ou limitation technique. Vous pouvez placer des actifs dans n'importe lequel d'entre eux et voir les mêmes résultats. Mais pour une organisation plus intelligente, vous devriez avoir une bonne raison de placer le contenu à sa place..
le app / actifs le dossier est destiné aux ressources spécifiquement destinées à ces images d'application, aux fichiers JS et CSS conçus sur mesure pour un projet particulier.
lib / assets
lib / assets /
le lib / assets Le dossier, en revanche, est la maison de votre propre code que vous pouvez réutiliser d’un projet à l’autre - des éléments que vous avez vous-même extraits et que vous souhaitez transférer d’un projet à l’autre - des actifs que vous pouvez partager entre des applications..
fournisseur / actifs
fournisseur / assets / ├── javascripts feuilles de style
fournisseur / actifs est un autre pas en avant. C'est la maison pour les actifs que vous avez réutilisés d'autres sources externes, plugins et frameworks de tiers.
Ce sont les trois emplacements dans lesquels Sprockets recherchera des actifs. Dans les répertoires ci-dessus, vous devez placer vos actifs dans le répertoire /images, / feuilles de style et / javascripts Dossiers. Mais il s’agit plus d’une chose conventionnelle; tous les actifs dans le */les atouts les dossiers seront parcourus. Vous pouvez également ajouter des sous-répertoires si nécessaire. Rails ne se plaint pas et ne précompile pas leurs fichiers de toute façon.
Il existe un moyen simple d’examiner le chemin de recherche du pipeline d’actifs. Lorsque vous lancez une console Rails avec console de rails, vous pouvez l'inspecter avec la commande suivante:
Terminal
Rails.application.config.assets.paths
Ce que vous obtiendrez est un tableau contenant tous les répertoires d'actifs disponibles et trouvés par Sprockets, c'est-à-dire le chemin de recherche..
La bonne chose à propos de tout cela est facile à manquer. C'est l'aspect d'avoir des conventions. Cela signifie que les développeurs - et les concepteurs - peuvent en fait avoir des attentes précises quant à l'emplacement de la recherche de fichiers. Cela peut être un énorme gain de temps (voix Trump). Lorsqu'un nouveau membre rejoint un projet, il a une bonne idée de la façon de naviguer immédiatement dans un projet..
C'est non seulement pratique, mais cela peut également empêcher des idées douteuses ou de réinventer la roue tout le temps. Oui, la convention sur la configuration peut sembler un peu ennuyeuse à certains moments, mais c'est quand même puissant. Cela nous permet de rester concentrés sur l'essentiel: le travail lui-même et une bonne collaboration d'équipe.
Les chemins d'actifs mentionnés ne sont pas figés, cependant. Vous pouvez également ajouter des chemins personnalisés. Ouvrir config / application.rb et ajoutez les chemins personnalisés que vous souhaitez que Rails reconnaisse. Voyons comment nous ajouterions un custom_folder.
config.application.rb
module TestApp classe Application < Rails::Application config.assets.paths << Rails.root.join("custom_folder") end end
Lorsque vous vérifiez à nouveau le chemin de recherche, vous constaterez que votre dossier personnalisé fait partie du chemin de recherche du pipeline d’actifs. À propos, ce sera maintenant le dernier objet placé dans le tableau:
Pourquoi avons-nous besoin de ça? En bref, vous voulez que vos applications se chargent plus rapidement. Période! Tout ce qui peut aider est le bienvenu. Bien sûr, vous pouvez vous en sortir sans optimisation, mais cela présente trop d'avantages que l'on ne peut tout simplement pas ignorer. Compresser la taille des fichiers et concaténer plusieurs fichiers d'actifs en un seul fichier «principal» téléchargé par un client, tel qu'un navigateur, ne demande pas beaucoup de travail. De toute façon, il est principalement traité par le pipeline.
Réduire le nombre de demandes de rendu de pages est très efficace pour accélérer les choses. Au lieu d’avoir peut-être 10, 20, 50 ou un nombre quelconque de demandes avant que le navigateur n’ait fini d’obtenir vos actifs, vous ne pouvez potentiellement en avoir qu’une pour chaque actif CSS et JS. Aujourd'hui, c'est une bonne chose, mais à un moment donné, cela a changé la donne. Ce type d’amélioration du développement Web ne doit pas être négligé, car nous traitons les millisecondes comme une unité..
Beaucoup de demandes peuvent être très importantes. Et après tout, l'expérience utilisateur est ce qui compte le plus pour la réussite des projets. Demander aux utilisateurs d'attendre un tout petit peu avant de pouvoir voir le contenu rendu sur votre page peut être un énorme casse-tête. La patience n'est pas quelque chose que nous pouvons attendre de nos utilisateurs.
La minification est cool parce qu'elle supprime essentiellement les éléments inutiles dans vos fichiers: espaces et commentaires. Ces fichiers compressés ne sont pas conçus dans un souci de lisibilité humaine. Ils sont purement pour la consommation de la machine. Les fichiers finiront par paraître un peu cryptiques et difficiles à lire, bien que ce soit toujours du code CSS et JS valide, sans aucun espace supplémentaire pour le rendre lisible et compréhensible pour les humains..
La compression JS est cependant un peu plus complexe. Les navigateurs Web n'ont pas besoin de ce formatage. Cela nous permet d’optimiser ces atouts. Le problème à retenir de cette section est qu’un nombre réduit de demandes et une taille de fichier réduite accélèrent les choses et devraient figurer dans votre panier d’astuces. Rails vous offre cette fonctionnalité prête à l'emploi sans configuration supplémentaire.
Langues de haut niveau
Vous en avez peut-être déjà entendu parler, mais en tant que débutant, vous ne savez peut-être pas pourquoi vous devriez apprendre une autre langue, surtout si vous êtes encore occupé à apprendre à écrire du HTML classique et du CSS. Ces langages ont été créés pour traiter les lacunes que les développeurs voulaient aplanir. Ils traitent principalement de problèmes que les développeurs ne souhaitent pas traiter quotidiennement. Développement classique axé sur la paresse, je suppose.
Les «langages de haut niveau» semblent plus sophistiqués qu'ils ne le sont - ils sont radicaux, cependant. Nous parlons de Sass, CoffeeScript, Haml, Slim, Jade et ainsi de suite. Ces langages nous permettent d’écrire dans une syntaxe conviviale (généralement) qui peut être plus pratique et plus efficace. Tous doivent être précompilés pendant un processus de construction.
Je mentionne cela parce que cela peut se produire dans les coulisses sans que vous ne le remarquiez. Cela signifie que ces actifs sont transformés en CSS, HTML et JS avant leur déploiement et peuvent être rendus par le navigateur..
Toupet
Sass signifie «feuilles de style syntaxiquement impressionnantes» et est bien plus puissant que le CSS pur. Cela nous permet d’écrire des feuilles de style plus intelligentes contenant quelques outils de programmation. De quoi parle-t-on ici, exactement? Vous pouvez déclarer des variables, imbriquer des règles, écrire des fonctions, créer des mixins, importer facilement des partiels et de nombreux autres éléments que les programmeurs souhaitaient disposer tout en jouant avec les styles..
Il est devenu un outil assez riche à présent et est excellent pour organiser des feuilles de style - pour de grands projets, je dirais même qu'il est essentiel. Ces jours-ci, je ne suis pas sûr de ne pas rester à l'écart d'une application volumineuse qui n'utilise pas un outil comme Sass ou tout autre framework non centré sur Ruby à offrir à cet égard..
Pour vos préoccupations actuelles, il existe deux versions de syntaxe de Sass que vous devez connaître. La version CSS de Sassy, alias SCSS, est la plus largement adoptée. Il reste plus proche de CSS simple mais offre à tous les développeurs d'extensions fantaisistes et les concepteurs en sont venus à aimer jouer avec les feuilles de style. Il utilise le .scss extension de fichier et ressemble à ceci:
Visuellement, ce n'est pas si différent du CSS, c'est pourquoi c'est le choix le plus populaire, en particulier chez les designers. L'un des aspects vraiment sympas et pratiques du SCSS, et du Sass en général, est l'aspect de nidification. Il s’agit d’une stratégie efficace pour créer des styles lisibles, tout en réduisant considérablement les déclarations répétitives..
SCSS
#main couleur: bleu; taille de police: 0.3em; a police: poids: gras; famille: serif; &: hover background-color: #eee;
Comparez l'exemple ci-dessus avec la version CSS respective. Semble bien amincir ces styles avec imbrication, non?
CSS
#main couleur: bleu; taille de police: 0.3em; #main a font-weight: bold; famille de polices: serif; #main a: hover background-color: #eee;
La syntaxe Sass en retrait a la .toupet extension de fichier. Celui-ci vous permet d'éviter de traiter tous ces accolades et points-virgules ridicules que les développeurs paresseux aiment éviter.
Comment ça fait ça? Sans les crochets, Sass utilise l'indentation, essentiellement des espaces, pour séparer ses propriétés. C'est assez rad et a l'air vraiment cool aussi. Pour voir les différences, je vais vous montrer les deux versions côte à côte..
.toupet
#main couleur: bleu taille de police: 0.3em une police: poids: gras famille: serif &: survol couleur de fond: #eee
.scss
#main couleur: bleu; taille de police: 0.3em; a police: poids: gras; famille: serif; &: hover background-color: #eee;
Assez sympa et compact, hein? Mais les deux versions doivent être traitées avant de devenir des CSS valides que les navigateurs peuvent comprendre. Le pipeline d'actifs s'en occupe pour vous. Si vous frappez les navigateurs avec quelque chose comme Sass, ils n'auraient aucune idée de ce qui se passe..
Personnellement, je préfère la syntaxe indentée. Cette syntaxe Sass respectant les espaces est moins répandue que la syntaxe SCSS, ce qui n’en fait peut-être pas le choix idéal pour des projets autres que personnels. C'est probablement une bonne idée de choisir le choix le plus populaire parmi votre équipe, en particulier avec les concepteurs impliqués. Imposer l’intensité des espaces blancs aux personnes qui ont passé des années à apprivoiser toutes les accolades et les points-virgules semble être une mauvaise idée..
Les deux versions ont les mêmes astuces de programmation. Ils sont excellents pour rendre le processus d’écriture des styles beaucoup plus agréable et efficace. Heureusement pour nous, Rails et Asset Pipeline facilitent grandement le travail avec l'un ou l'autre.
Slim & Haml
Des arguments similaires peuvent être avancés sur les avantages d'utiliser quelque chose comme Slim et Haml. Ils sont très pratiques pour créer un balisage plus compact. Il sera compilé en HTML valide, mais les fichiers que vous traitez sont beaucoup plus réduits.
Vous pouvez vous épargner le problème de la rédaction des balises de fermeture et utiliser des abréviations intéressantes pour les noms de balises, etc. Ces rafales plus courtes de balisage sont plus faciles à parcourir et à lire. Personnellement, je n'ai jamais été un grand fan de Haml, mais Slim n'est pas seulement chic et pratique, c'est aussi très intelligent. Pour les personnes qui aiment la syntaxe Sass en retrait, je recommanderais certainement de jouer avec. Jetons un coup d'oeil:
Svelte
#content .left.column h2 Bienvenue sur notre site! p = informations_impression .right.column = render: partial => "sidebar"
Haml
#content .left.column% h2 Bienvenue sur notre site! % p = informations_impression .right.column = render: partial => "sidebar"
Les deux résultats dans le code HTML amélioré par ERB suivant dans Rails:
Bienvenue sur notre site!
<%= print_information %>
<%= render :partial => "sidebar"%>
En apparence, les différences ne sont pas si grandes, mais je n'ai jamais vraiment compris pourquoi Haml veut que je vous écrive tous ces extra % pour ajouter des balises. Slim a trouvé une solution pour s'en débarrasser et c'est pourquoi je salue l'équipe! Pas une grande douleur, mais un ennuyant quand même. Les autres différences sont sous le capot et ne sont pas dans la portée de cette pièce aujourd'hui. Je voulais juste vous mettre en appétit.
Comme vous pouvez le constater, les deux préprocesseurs réduisent considérablement la quantité d’écriture nécessaire. Oui, vous devez apprendre une autre langue et la lecture est un peu étrange au début. En même temps, j'estime que la suppression de ce fouillis en vaut la peine. En outre, une fois que vous saurez écrire le code HTML à base d'ERB, vous pourrez utiliser n'importe lequel de ces préprocesseurs assez rapidement. Aucune science de fusée - la même chose vaut pour Sass, d'ailleurs.
Au cas où cela vous intéresserait, il existe deux gemmes pratiques pour l’utiliser dans Rails. Faites-vous une faveur et vérifiez-les quand vous en aurez marre d'écrire toutes ces étiquettes d'ouverture et de fermeture fastidieuses.
gemme "slim-rails" gemme "haml-rails"
CoffeeScript
CoffeeScript est un langage de programmation comme un autre, mais il a cette saveur Ruby pour écrire votre JavaScript. Grâce au prétraitement, il compile un vieux code JavaScript simple que les navigateurs peuvent gérer. Le bref argument en faveur de l’utilisation de CoffeeScript est qu’il a permis de surmonter certaines des lacunes de JS. La documentation indique qu'elle vise à exposer «les bonnes parties de JavaScript de manière simple». C'est suffisant! Regardons rapidement un exemple et voyons de quoi nous avons affaire:
Lit juste un peu plus gentil sans toutes les curlies et points-virgules, non? CoffeeScript essaie de s’occuper de certains éléments gênants de JavaScript, vous permet de taper moins, rend le code un peu plus lisible, offre une syntaxe plus conviviale et gère plus agréablement l’écriture de classes. Définir des classes a été un avantage considérable pendant un certain temps, en particulier pour les personnes venant de Ruby qui n’aimaient pas beaucoup le traitement de JavaScript pur. CoffeeScript a adopté une approche similaire à Ruby et vous offre un bon morceau de sucre syntaxique. Les classes ressemblent à ceci, par exemple:
Classe
classe Constructeur de l'agent: (@firstName, @lastName) -> name: -> "# @ first_name # @ last_name" introduction: (name) -> "Mon nom est # @ last_name, # name "
Cette langue était assez populaire au pays Ruby pendant un certain temps. Je ne suis pas sûr du taux d'adoption actuel, mais CoffeeScript est la version JS par défaut de Rails. Avec ES6, JavaScript prend désormais également en charge les classes - une raison importante pour ne pas utiliser CoffeeScript et jouer à la place avec JS. Je pense que CoffeeScript se lit toujours mieux, mais beaucoup des raisons moins esthétiques de l’utiliser ont déjà été traitées avec ES6. Je pense que c'est toujours une bonne raison de tenter le coup, mais ce n'est pas ce que vous êtes venu chercher ici. Je voulais juste vous donner un autre apéritif et vous expliquer un peu pourquoi le pipeline d’investissements vous permet de travailler avec CoffeeScript dès la première utilisation..
Dernières pensées
Le pipeline d’actifs a fait ses preuves bien au-delà de mes attentes lorsqu’il a été introduit. À l’époque, cela faisait vraiment beaucoup de bruit et c’était un grave problème pour les développeurs. Bien sûr, il s’est toujours établi et s’est établi comme un outil sans friction et sans effort qui améliore la qualité de vos applications..
Ce que j’aime le plus, c’est le peu de tracas que cela implique de le faire fonctionner. Ne vous méprenez pas, des outils comme Gulp et Grunt sont également impressionnants. Les options de personnalisation sont nombreuses. Je ne peux tout simplement pas ébranler le sentiment confortable que me procure Rails lorsque je n'ai pas à composer avec une configuration avant de commencer. Les conventions peuvent être puissantes, surtout si elles donnent un résultat homogène et sans tracas.
Share
Accentsconagua
