Au fur et à mesure que l'échelle de l'application devenait plus grande, la description du fichier application.scss devenait plus longue, j'ai donc décidé de séparer le fichier pour chaque contrôleur cette fois. J'ai eu beaucoup de mal et j'ai beaucoup appris, alors j'ai décidé d'écrire un article pour ne pas l'oublier.
Ruby 2.5.7 Rails 5.2.4
Je n'écrirai d'abord que la réponse.
application.scss
// require_tree .
// require_self
erb:application.html.erb
<head>
...
<%= stylesheet_link_tag 'application' %>
...
</head>
Tout ce que vous avez à faire est de créer un fichier .scss avec cette description et chaque nom de contrôleur dans app / assets / stylesheet /!
J'expliquerai un peu le contenu d'ici.
Au début, j'ai fait de application.scss un fichier de style commun et j'ai essayé de correspondre à toutes les pages avec deux fichiers de contrôleur name.scss de chaque page. La description à ce moment-là est la suivante.
application.scss
// require_self
erb:application.html.erb
<head>
...
<%# application.Chargement de scss%>
<%= stylesheet_link_tag 'application' %>
<%#Nom du contrôleur.Chargement de scss%>
<%= stylesheet_link_tag params[:controller] %>
...
</head>
Le // require_tree . dans le fichier application.scss est une description qui lit tous les fichiers .scss dans app / assets / stylesheet, supprimez-le donc une fois.
Au lieu de cela, si vous écrivez les paramètres [: controller] dans le stylesheet_link_tag de application.html.erb, vous pouvez obtenir le chemin du contrôleur comprenant le répertoire, donc même si le contrôleur est divisé en répertoires, cette méthode d'écriture peut être utilisée.
Cependant, cette méthode convient aux fichiers .css, mais elle provoque une erreur pour .scss.
.scss ne peut être pris en charge par les navigateurs qu'en le compilant au format .css. En d'autres termes, il ne peut normalement pas être affiché au format .scss.
Et le fichier .scss précompilé (fichier .css) est stocké sous app / public / assets dans l'environnement de production, et le nom du fichier est changé au format de hachage.
En d'autres termes, le fichier css ne peut pas être récupéré par <% = stylesheet_link_tag params [: controller]%> décrit dans application.html.erb.
Même si le nom du fichier est changé au format de hachage, si vous spécifiez le hachage tel qu'il est dans stylesheet_link_tag, cela fonctionnera, mais ce hachage n'est pas réaliste car il change à chaque fois que le fichier est mis à jour.
Je ne pouvais pas vraiment comprendre comment le fichier .scss que je voulais faire était divisé par contrôleur, alors je suis passé à la description au début.
Si application.scss a // require_tree ., cela signifie que tous les fichiers .scss sous assets / stylesheet seront lus.
Cela ne devrait pas arriver trop souvent, mais si vous spécifiez le style alors que le nom de classe du sélecteur css est couvert, celui décrit plus loin sera prioritaire, vous ne pouvez donc pas le changer comme vous le souhaitez. Au fait, il existe un risque de créer des dépendances.
application.scss
// require_tree .
// require_self
Si vous écrivez comme au début, application.scss sera chargé une fois que tous les fichiers .scss auront été chargés.
De plus, l'ordre du contenu de // require_tree . est dans l'ordre du dictionnaire, et ils sont lus dans l'ordre du nom de fichier a → z.
Inévitablement, plus l'initiale du nom de fichier est proche de z dans l'arborescence., Plus il sera lu tard, donc il a tendance à avoir une priorité plus élevée.
Avant cela, jetons un coup d'œil aux variables .scss.
Dans scss, les propriétés et les valeurs peuvent être utilisées comme variables. Pour l'instant dans mon cas
_variables.scss
//Animation de hamburgers
$hamburger-transition: 0.3s;
//Couleur du thème
$thema-color1: #fff9f9;
$thema-color2: #ffefef;
$thema-color-font: #555;
//Requête média
$media-sp-max: 450px;
$media-pc-min: 1024px;
$media-tb-min: $media-sp-max + 1px;
$media-tb-max: $media-pc-min - 1px;
//Exemple
Nom du sélecteur{
background: $thema-color1;
}
Avec cela, vous pouvez changer la couleur du thème, la largeur de la requête multimédia, la transition du menu hamburger, etc. pour chaque fichier à la fois.
Vous pouvez définir une variable en commençant par $ puis en entrant la valeur. Lors de l'appel, écrivez simplement le nom de la variable à la place de la valeur.
Cependant, en l'état, la variable n'est pas définie dans chaque fichier, il est donc nécessaire d'importer le fichier contenant uniquement cette variable dans le fichier .scss de chaque nom de contrôleur.
Nom du contrôleur.scss
@import "variables";
...
En écrivant `@import" nom de fichier ", dans ce cas, les variables écrites dans _variables peuvent être utilisées.
La question s'est posée ici.
"Application.scss décrit // require_tree .. Chaque fichier .scss décrit l'importation de fichiers de variables, donc chaque fois que chaque fichier est lu au moment de la compilation, le fichier de variables est également décrit. Est-il lu comme un fichier .css? "
Je peux dire qu'il n'y a pas de problème même s'il est lu, mais je pensais qu'il y avait beaucoup de gaspillage, alors j'ai enquêté plus loin.
Le résultat était que je l'évitais sans le savoir. Lol
J'ai fait un nom de fichier en me référant à la façon de créer un fichier variable en regardant un article, mais il semble qu'il ne sera pas compilé en ajoutant un trait de soulignement "_" au début du nom de fichier lol En d'autres termes, _variables.scss utilisé cette fois est exclu de la précompilation car il s'agit d'un nom de fichier commençant par un trait de soulignement. Si vous y réfléchissez bien, il est vrai qu'un fichier qui n'écrit que des variables ne stylise pas directement, il est donc inutile de le convertir en .css, et lors de la conversion d'autres fichiers en .css, remplacez la partie variable par le contenu. J'étais étrangement convaincu que si je pouvais faire cela, le fichier de variables suffirait.
Je reviendrai sur la méthode de mise en œuvre au début, mais pour le moment, je pense la faire fonctionner de cette manière.
application.scss
// require_tree .
// require_self
...
_variables.scss
$Nom de variable:valeur;
...
Chaque nom de contrôleur.scss
@import "variables";
...
erb:application.html.erb
<head>
...
<%= stylesheet_link_tag 'application' %>
...
</head>
Jusqu'à présent, j'ai écrit le style uniquement dans application.scss et j'ai fait un bloc en écrivant le nom du contrôleur en utilisant pleinement les commentaires, mais je me demande s'il sera plus facile à maintenir même si le fichier est séparé pour chaque contrôleur. Je pense. Dans le cas peu probable où le nom de la classe serait couvert, nous le décrirons visuellement de manière facile à comprendre en utilisant l'imbrication de sélecteurs, qui est également une fonctionnalité de .scss. (Le nom de la classe à réutiliser (flex, grid, btn, etc.) est décrit séparément dans le fichier application.scss.)
Je vous serais reconnaissant si vous pouviez m'apprendre comment précompiler le fichier .scss pour chaque contrôleur sans utiliser // require_tree .!
De plus, si vous avez des questions, des différences d'interprétation ou un inconfort dans la méthode de description, nous vous serions reconnaissants de bien vouloir le signaler dans les commentaires.
Merci d'avoir lu jusqu'au bout!
Rails Guide-Asset Pipeline Web Design Leaves - SASS [CSS HappyLife - Apprenons Sass! Vol.7] Diviser les fichiers pour une gestion plus facile (partielle)](http://css-happylife.com/archives/2012/0124_1850.php) HACK NOTE --Sass: gérons les variables dans un fichier séparé
Recommended Posts