Англійська для Tailwind CSS v4

Tailwind v4 переніс налаштування з файлу JavaScript в сам CSS, що змінює не тільки те, як проект налаштовується, але і словник, який використовується для його опису — «змінні теми» замінюють «об’єкт конфігурації», і знання різниці має значення при обговоренні оновлення або рішення про дизайн-токен.

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

** CSS- first configuration ** — підхід v4 до визначення значень тем безпосередньо у файлі CSS за допомогою @theme, замінюючи об’ єкт JavaScript tailwind.config.js, який був потрібний у попередніх версіях. “Ми перенесли нашу палітру кольорів з tailwind.config.js в блок @theme в app.css — це CSS-перша конфігурація, яку очікує v4.”

** Theme variable ** — нетипова властивість (наприклад, --color-brand-500 ), визначена всередині @theme, яку Tailwind перетворює як на клас інструментів, так і на змінну CSS, об’ єднуючи токени дизайну і інструменти у одне джерело. “Оскільки --spacing-18 є змінною теми, p-18 працює як клас утиліти, і ми також можемо посилатися на var(--spacing-18) безпосередньо в нетиповому CSS.”

** Oxide engine ** — новий рушій збирання на основі Rust у v4, який замінює старий конвеєр на основі PostCSS, відповідальний за значно швидше збирання і перезбирання. “Повний перебудови впав з близько трьох секунд до менше ніж 200 мс після оновлення двигуна Oxide - варто згадати в PR, оскільки CI часи також поліпшились.”

** Утиліта запиту контейнера ** — вбудовані варіанти стилів @container і @sm:, @md:, які дозволяють змінювати стиль компонента відповідно до розміру контейнера, а не лише до розміру вікна перегляду, додатків не потрібно.

• “Замість точки зупинки, заснованої на вікні перегляду, ми використовували запит контейнера, щоб розкладка картки адаптувалась за шириною батьківської комірки ґратки, а не за шириною всієї сторінки.” *

** Автоматично виявлення вмісту ** — типова поведінка v4, яка сканує проект на наявність назв класів без вимог явного масиву content у налаштуваннях, використовуючи .gitignore для пропуску незначних каталогів. “Ми повністю вилучили вручну підтримуваний список content glob — автоматичне виявлення вмісту просто працює тепер, і раніше це було поширеним джерелом помилок « відсутніх стилів ». ”

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

• Чи це тема змінної визначена в @theme, або одноразове довільне значення?
• Чи бачимо ми різницю в швидкості збирання від двигуна Oxide, чи це щось інше?»
• “Should this be a container query, or does it actually need to respond to the viewport?”
• Чи не відсутній цей клас у збірці через сканування контенту, або ж є помилка в назві класу?»
• «Чи ця конфігурація все ще використовує старий конфігураційний файл JS, або вона перейшла на CSS-перший?»

Приклади висловлювань

Пояснення міграції в PR: “Перенесено тему до налаштувань CSS- first: кольори і інтервали тепер знаходяться у @theme замість tailwind.config.js, і ми вилучили додаток, який ми використовували для запитів контейнерів, оскільки v4 підтримує їх наявність.”

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

Обговорення перемоги з командою: “Локальні перебудови розробників майже миттєві тепер, коли ми на рушії Oxide — це одне зробило оновлення v4 вартим запланованого цього спринту.”

Професійні поради

• При обговоренні v4 скажіть theme variable, а не «config value» — це сигналізує, що значення є як нетиповою властивістю CSS, так і джерелом класу утиліти, що має значення для того, як на нього посилаються в інших місцях.
• Покращення швидкості збирання атрибутів для Oxide рушія, зокрема у звітах — це справді інший рушій, а не просто зміна налаштування, і варто назвати його для тих, хто порівнює версії.
• Використовуйте інструмент ** container query **, якщо розкладка компонента має залежати від його контейнера, а не від сторінки — об’ єднання цих двох компонентів у обговоренні проектування призведе до помилок у відповіді.
• Якщо щось не генерує очікувані стилі, перевірте ** автоматичне виявлення вмісту ** і взаємодію .gitignore перед тим, як приймати за помилку в написанні назви класу — це поширена і не очевидна причина.

Практичні вправи

1. Напишіть речення, у якому пояснюється, що таке змінна теми і як її визначено.
2. Описує, коли використовувати запит контейнера замість стандартної відповідної точки зупинки.
3. Поясніть автоматичне визначення вмісту вашими словами.

Навігація та зв’язок

Будьмо чесними - навіть з таким фантастичним інструментом, як Tailwind CSS v4, комунікація завжди є найбільшим викликом. Ви можете створити найелегантнішу бібліотеку компонентів у світі, але якщо ви не зможете чітко сформулювати свої наміри, пояснити свої рішення або ефективно відповісти на зворотній зв’ язок, це не буде мати значення. У цьому розділі описано, як удосконалювати важливі взаємодії на робочому місці, пов’ язані з оновленням, і використовувати точну термінологію для кращого співробітництва.

Поширеним сценарієм є отримання коментаря перегляду коду, який виглядає нечітким або вимагає. Замість того, щоб реагувати оборонно («Чому ви змінили це?»), Цілуйтеся ясністю. Хорошою відповіддю може бути: « Дякую за вказівку на невідповідність інтервалів. Я хотів би, щоб поле було більшим, але я можу змінити його, щоб відповідати стилю команди — чи можете ви надати приклад бажаного інтервалу? » Зауважте використання таких фраз, як « невідповідність інтервалів », « намагатися » і « запитувати * приклад * ». Вони демонструють розуміння і готовність пристосуватися, а не негайну незгоду. Аналогічно, під час написання опису Запиту на завантаження, не вказуйте просто « виправлена помилка ». Замість цього поясніть * чому * виправлення було необхідним: « Розв’ язано проблему, коли тінь кнопки переливалась на сусідній вміст через неправильне використання box-shadow. Ця зміна забезпечує належне візуальне розділення за найкращими практиками для адаптивного дизайну. ”

Інша часто зустрічається ситуація виникає в розмовах Slack, обговорюючи технічні проблеми під час процесу оновлення. Припустимо, що розробник бореться з контейнерними запитами: « Я стикаюся з проблемами, щоб отримати макет, щоб правильно адаптуватися з цими контейнерними запитами - я не впевнений, як правильно обмежити вміст в межах різних розмірів екрану. » Більш професійна відповідь, що включає в себе специфічну термінологію, буде: « Чи ви намагалися використовувати властивість aspect-ratio у поєднанні з вашими контейнерними запитами? Це часто може забезпечити більш передбачуване і надійне рішення для керування відповідністю макету. Також, двічі перевірте, що ваші точки зупинки правильно визначені і що ви використовуєте min(), max(), або clamp() відповідно, щоб забезпечити вміст залишається в межах бажаних розмірів. ”

Нарешті, розуміння нюансів обговорення продуктивності є ключовим. Не просто скажіть “це повільно”. Замість цього, сформулюйте його з точки зору вимірюваних показників: «Початковий час завантаження для цього компонента збільшився приблизно на 15% після оновлення Tailwind v4 через додаткові витрати нового рушія і обробки запитів контейнера - ми повинні дослідити потенційні оптимізації»

Ось приклад того, як ви можете скористатися npx tailwindcss для створення прикладної таблиці стилів за допомогою основного запиту контейнера:

npx tailwindcss init -p

Ця команда створить файл tailwind.config.js і типові налаштування Tailwind. Після цього ви можете змінити його, щоб додати бажані вами стилі і контейнерні запиту, що надає вам змогу експериментувати з різними підходами у контрольованому середовищі перед тим, як реалізувати їх у вашому проекті. Не забувайте використовувати цей інструмент як початкову точку для розуміння впливу цих змін.