Англійська для розробників Tailwind CSS

Tailwind CSS пересунув багато дискусій зі стилю з CSS-специфічного словника на нову спільну мову навколо класів, варіантів і налаштувань. Вміння говорити про це точно допомагає в перегляді коду, де “просто використовуйте клас утиліти” і “витягніть клас компонента” представляють справді різні компроміси, а не взаємозамінні фрази.

Ключовий словник

Клас корисності Одноцільовий клас CSS, як pt-4 або text-center, який застосовує одну певну властивість стилю, призначений для складання разом безпосередньо в розмітку, а не написаний як нетиповий CSS. Приклад: “Замість написання власного класу для цього інтервалу, ми склали його з існуючих класів flex, gap-4, і items-center.”

Утилитаризм на першому місці Загальний підхід до створення інтерфейсу користувача, який полягає у створенні невеликих класів у розмітці, замість написання семантичних нетипових назв класів і визначення їх стилів окремо.

• Приклад: « Цей компонент з самого початку був розроблений з урахуванням універсальності, отже, немає окремої таблиці стилів, яку слід було б синхронізувати з розміткою. » *

** Варіант (відповідний/ становий варіант) ** Префікс класу інструменту, наприклад, md: або hover:, який застосовує інструмент лише за певних умов, наприклад, за точки зупинки або стану взаємодії.

• Приклад: « Ми додали варіант md:flex-row, тому цей стек перемикається з розкладки стовпчиків на розкладку рядків тільки над середньою точкою зупинки. » *

** Маркер проектування (в контексті Tailwind) ** Значення, визначене у налаштуваннях Tailwind, наприклад, певний інтервал, колір або розмір шрифту, на який посилаються класи інструментів, зберігаючи значення послідовними у всьому проекті. Приклад: “Замість довільного значення пікселів, ми використовуємо знак spacing-6, тому він відповідає решті шкали інтервалів у системі дизайну.”

** Довільне значення ** Одноразове значення, записане безпосередньо у класі інструментів за допомогою синтаксису квадратних дужок, наприклад, w-[137px], яке використовується, якщо жоден з існуючих токенів у налаштуваннях не відповідає конкретній потребі. Приклад: “Це довільне значення, ймовірно, має бути справжнім символом, якщо ми використовуємо 137px більше ніж в одному місці — додамо його до конфігурації замість цього.”

** Очищення / сканування вмісту ** Процес збирання, за допомогою якого Tailwind перевіряє файли проекту на наявність назв класів, які було використано, створюючи остаточну таблицю стилів, яка виключає всі невикористані класи інструментів. Приклад: «Цей клас не буде створено у виводі збирання, оскільки файл, у якому він знаходиться, не включено до налаштувань сканування вмісту.»

** Клас компонента ( @apply ) ** Нетиповий клас CSS, визначений за допомогою директиви @apply програми Tailwind, для поєднання набору класів інструментів під однією семантичної назвою, використовується, коли шаблон повторюється достатньо часто, щоб виправдати абстрагування. Приклад: “Ми повторюємо цей стиль кнопок в десятках місць — це розумний випадок для витягування класу компонентів, заснованого на @apply.”

Звичайні фрази

** В обзорах коду: **

• «Цей список класів стає досить довгим, щоб пошкодити читабельність — чи це шаблон, який повторюється в інших місцях і отримає користь від класу компонентів?»
• «Ми використовуємо довільне значення тут для кількості інтервалів, що вже має близьке збіг у дизайн-токенах — чи можемо ми використовувати існуючий токен замість цього?»
• «Цей файл не включений в наш контент сканування glob, тому будь-які класи, використовувані тільки тут, будуть очищені з виробничої збірки.»

В стоячих позах:

• «Вчора я витягнув наш повторюваний стиль картки в клас компонентів, заснований на @apply; сьогодні я оновлюю десятки місць, які використовували сирий список утиліт»
• «Я заблокований на проблемі збирання, де деякі класи інструментів не з’являються в виробництві — я підозрюю прогалини конфігурації сканування контенту»
• «Я закінчив заміну декількох довільних значень пікселів відповідними знаками інтервалів, тому цей компонент тепер відповідає масштабу системи дизайну»

** У обговореннях проекту: **

• «Утилита-перший добре працює для одноразових макетів, але як тільки шаблон повторюється достатньо, видобування класу компонента зазвичай читає краще, ніж довгий список класів всюди»
• «Ми повинні додати цей колір до дизайну токенів в конфігурації, а не досягати довільного значення кожного разу, коли ми його потребуємо.»
• «Реакційні варіанти дозволяють нам виразити зміни макету безпосередньо в розмітку, без написання окремих блоків медіа-запитів»

Фрази, яких слід уникати

** Використання « просто додайте клас » без вказівки класу інструменту проти класу компонента. ** Замість цього скажіть: « додайте ці класи безпосередньо » або « витягніть це до класу компонента » — ці дві команди представляють різні компроміси у підтримці, і нечітка мова не дозволяє визначити, яку з них ви насправді рекомендуєте.

** Сказав “стилі не збудовано” для проблеми очищення. ** Замість цього скажіть: « класи було очищено, оскільки цей файл не було включено до списку для сканування вмісту » — це стосується певного, виправляного розриву у налаштуваннях, а не загадкової помилки збирання.

** Використання « просто використовувати довільне значення » як типового звички. ** Замість цього скажіть: «перевірте, чи існуючий токен покриває це перед досягненням довільного значення» — звичайні довільні значення підривають послідовність, яку повинна забезпечити система дизайну, заснована на токенах.

Краткий справочник

Term	How to use it
utility class	”We composed the layout from small utility classes directly in markup.”
variant	”The md: variant changes this utility only above the medium breakpoint.”
design token	”Use the spacing token instead of an arbitrary pixel value.”
arbitrary value	”This one-off arbitrary value should probably become a real token.”
content scanning	”This file isn’t covered by content scanning, so its classes get purged.”
component class	”We extracted a repeated utility pattern into an @apply component class.”

Ключеві моменти

• Відрізняти класи інструментів від класів компонентів у оглядах — вони представляють різні компроміси у підтримці, а не взаємозамінні варіанти.
• Діагностувати відсутні стилі виробництва як розрив конфігурації сканування вмісту, а не як неясну « проблему збирання »
• Типово, надавати перевагу існуючим знакам проектування перед довільними значеннями, резервуючи довільні значення для справжніх одноразових.
• Використовувати варіантний словник (md:, hover: ) для точного опису рішень щодо стилю, які залежать від відповіді або стану, у розмітках.
• Витягувати клас компонента після того, як шаблон інструменту повторюється достатньо часто, щоб довгий список класів став заважати читання, але не раніше.

Розширення вашого лінгвістичного набору інструментів: англійська для передового розвитку Tailwind

Ядро ​​вдосконалення Tailwind CSS не тільки в тому, щоб знати, як використовувати text-center або bg-blue-500. Це ефективне спілкування в команді розробників, документування вашого вибору і співпраця при прийнятті складних проектних рішень. Це часто означає використання точної технічної мови і розуміння нюансів у фразуваннях, що можуть значно вплинути на перегляд коду, розмови Slack і описи Pull Request. Давайте зосередимося на створенні словника навколо таких концепцій, як дизайн-токенів, класів утиліти і конфігурації - областей, де навіть досвідчені розробники можуть отримати користь від більш відшліфованого володіння англійською мовою.

Одним з поширених розчарувань під час перегляду коду є неоднозначність. Уявіть, що ви отримали коментар: «Це виглядає… не так». Це неймовірно непотрібно! Замість цього, ти хочеш сформулювати, чому це не так. Кращий підхід буде таким: «Я помітив, що font-size в цьому компоненті значно менший за базовий розмір шрифту, визначений в наших дизайн-токенах. Чи можемо ми збільшити його, щоб вирівняти з іншими елементами програми?» Зауважте, що ця фраза негайно визначає проблему (невідповідність розміру шрифту), посилається на певний технічний елемент (токен дизайну) і пропонує рішення — зміну значення. Аналогічно, коли ви описуєте свою роботу над запитом на завантаження, простого опису « Додано деякі стилі » недостатньо. Ефективнішим описом буде: « Реалізовано клас rounded-lg для згладжування кутів кнопки, дотримуючись знаку дизайну для « button_ radius », визначеного у керівництві зі стилів. » Це покращує візуальну послідовність у всій програмі. » Ключовим моментом є точність і зв’ язок ваших дій з встановленими стандартами.

Іншою областю, де мова має значення, є обговорення конфігурації - особливо при роботі з перевищеннями, специфічними для середовища. Припустимо, вам потрібна інша палітра кольорів для мобільної версії вашого веб- сайту. Ви не просто випадково змінюєте кольори; вам потрібно пояснити як ви зробили цю зміну. Хорошою фразою буде: « Щоб врахувати мобільний дизайн, я створив новий файл налаштування середовища ( tailwind.config.mobile.js ), який перезаписує color дизайн- токен зі значеннями, визначеними в активі « mobile_ palette ». » Це демонструє розуміння того, як працює система налаштування Tailwind — використовуючи окремі файли для різних середовищ і націлюючись на конкретні дизайн- токени.

Нарешті, пам’ятайте, що коротке і чітке спілкування є найважливішим. Надто багатослівні пояснення можуть викликати плутанину. Спробуйте ефективно передати свою думку, при цьому надавши достатньо контексту. Не бійтеся використовувати технічні терміни правильно; краще продемонструвати експертну здатність, ніж задурювати речі простішою лексикою.

// tailwind.config.mobile.js
module.exports = {
  theme: {
    extend: {
      colors: {
        'blue': {
          500: '#1e3a8a', // Mobile-specific blue color
        },
      },
    },
  },
}