🤙🏽 ☝🏾 🐑 Notes de début n ° 1 🎃 🏷️ ◀️

Dans cet article, vous trouverez quelques petites notes sur le frontend. Parfois, ils seront courts parce que le sujet est pleinement révélé en quelques phrases, et parfois parce que l'auteur n'a pas assez d'expérience et de connaissances pour les révéler plus complètement. Si vous l'aimez, j'écrirai de plus en plus en détail, avec des liens et des recherches.

L'idée d'écrire un article est née en relisant la correspondance avec un ami, un chef d'équipe, un front-end (Lyokha, bonjour!), Qui partage toujours généreusement ses connaissances, ses idées et ses problèmes avec moi.

Tout ce qui est écrit est l'opinion personnelle d'un petit groupe de personnes et ne prétend guère être vrai. Commençons.

Essayez de ne pas utiliser la transition: tout

Beaucoup de gens le savent, mais je suis récemment tombé sur une autre raison pour laquelle vous devriez être extrêmement prudent lorsque vous utilisez la valeur all avec la propriété de transition.

Imaginons que nous ayons un conteneur avec une propriété de transition:

.content{
  color: red;
  transition: 1s;
}

Au survol, la couleur change:

.content:hover {
  color: blue;
}

Si nous enveloppons ce conteneur, par exemple, svg, dont la propriété fill sera égale à currentColor , alors au survol, la lumière de l'image changera. Mais que se passe-t-il si nous spécifions une telle propriété quelque part pour tous les svg?

svg {
  transition: 1s;
  fill: currentColor;
}

En survol, le remplissage ne changera pas 1 seconde, mais environ 2, car d'abord la transition sera appliquée pour changer la couleur, et si je comprends bien, pour chaque changement de couleur de l' extérieur, un changement de l'intérieur sera déclenché, mais si quelqu'un a une explication plus précise, je serai heureux de la lire.

Solution: spécifiez explicitement transition: fill pour svg (si vous spécifiez la couleur , la situation ne changera pas, d'où la sortie ci-dessus).

svg {
  transition: fill 1.5s;
  fill: currentColor;
}

Maintenir les proportions des blocs

J'ai toujours pensé que tout le monde, tous les développeurs front-end expérimentés, connaissait l'ancien hack qui vous permet de maintenir les proportions du bloc, il s'est avéré que ce n'est pas tout.

La propriété padding , si elle est spécifiée en pourcentage, est basée exactement sur la largeur, ce qui nous permet de faire cette astuce:

.image-container {
  height: 0;
  position: relative;
  /*       */
  padding-top: calc(100% * 9 / 16 );
}

Maintenant, nous pouvons mettre une image dans ce conteneur, dont la hauteur sera calculée par la largeur du conteneur.

.img {
  position: absolute;
  height: 100%;
  width: 100%;
  top: 0;
  left: 0;
  object-fit: cover;
}

ratio d'aspect

Il n'y a pas si longtemps, la propriété de rapport hauteur / largeur a été ajoutée, ce qui vous permet de créer tout ce que vous voyez d'en haut sur une seule ligne.

.image {
  aspect-ratio: 16 / 9;
}

Les principales, à mon avis, les différences et la commodité de cette propriété sont les suivantes:

Nous n'avons pas besoin d'un conteneur
Si la largeur OU la hauteur est spécifiée, la deuxième valeur sera calculée en fonction de la valeur du rapport hauteur / largeur
Si width AND height est donné, alors la propriété est ignorée

La prise en charge du rapport hauteur / largeur est encore loin des 95% chéris, donc à utiliser avec prudence

Ne remettez pas la pagination à plus tard

Cela semble, bien sûr, étrange, mais en tant que personne qui a fait une façade de plusieurs produits à partir de zéro, je dirai qu'il y a toujours une tentation de "marquer" sur la pagination des listes, les options dans les sélecteurs, les tableaux, etc. J'ai décidé moi-même de ne jamais mettre cela en veilleuse, car dès que les utilisateurs commencent à générer des données, les pages commencent à ralentir, la recherche des causes des freins, bien sûr, n'est pas trop difficile, mais quand il s'agit de la recherche, la situation nécessite une solution immédiate et c'est des nerfs, du code de merde et une perte de crédibilité auprès du département de développement.

Contrôle de l'apparence des composants via des variables css

Les variables en CSS sont déjà aimées et respectées par beaucoup, mais l'expérience des entretiens a montré que peu de gens les utilisent, et encore moins de gens connaissent le véritable pouvoir de l'héritage. La plupart d'entre eux sont restés dans la partie de la documentation où ils parlent de : root (et ce n'est qu'une pseudo-classe - un alias pour la racine de l'arbre, le plus souvent pour le html).

Alors, imaginez que nous ayons un composant bouton avec des styles étendus (dans l'exemple, j'utilise Vue.js), qui a les styles suivants:

.button {
  color: var(--text-color, #000);
  background-color: var(--bg-color, #444)
}

Et puis nous pouvons simplement définir la classe .dark dans le composant parent:

.dark {
    --text-color: #fff;
    --bg-color: #333
}

Et passez cette classe au composant bouton:

<my-button class="dark"/>

Et maintenant, un contrôle de style aussi simple sans remplacer les styles CSS dans le parent est disponible à l'aide d'un puissant mécanisme d'héritage de variables.

Bugs drôles et atroces

Je veux résumer cet article avec une histoire de petits mais désagréables bogues de première ligne que mes collègues et moi avons attrapés.

Insertion d'images dans l'éditeur wysiwyg

Dans les éditeurs de texte du navigateur (nous utilisons quill), il est possible d'insérer une image d'un autre site en utilisant ctrl + v. Nous n'y avons pas pensé, que tout le monde utilise le mécanisme implémenté pour insérer des images, mais les utilisateurs sont de tels utilisateurs. Un site, particulièrement sensible à l'emprunt d'images, a déterminé d'où venait la demande, et si le domaine n'était pas le sien, a donné une bannière publicitaire de son propre produit, ce qui est vrai, bien sûr, mais cela nous a surpris. Donc, si vous développez / utilisez wysiwyg, regardez quoi et où insérer =)

Vue SSR + Cloudflare = <3

Le problème dont le camarade m'a parlé plus tôt.

Ce n'est que lorsque vous accédez à une page qui a été générée et donnée par SSR et la navigation SPA ultérieure, toutes les demandes adressées à l'API ont été dupliquées. Pendant longtemps, ils n'ont pas pu comprendre quel était le problème. Après une recherche minutieuse, il s'est avéré que le pied de page contient un champ standard avec l'e-mail de l'entreprise, mais cloudflare obscurcit l'e-mail (pour se protéger contre les scrapers). Lorsque Vue sur le serveur collecte un arbre dans js, puis obtient un autre arbre sur le client (avec un courrier non conforme), la réhydratation de Vue s'est cassée et s'est écrasée, créant une nouvelle instance de vue, mais ne supprimant pas l'ancienne instance incomplète. En conséquence, dans certaines circonstances, 2 instances Vue s'exécutaient sur la page en même temps.

C'est tout. Commentaires, souhaits, critiques sévères - je serai heureux de lire tout cela et de tirer des conclusions.

Notes de début n ° 1