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

Розмови про UnoCSS зосереджені на тому, як він відрізняється від утилитарних фреймворків, таких як Tailwind під капотом — це рушій, а не фіксоване набір класів — тому словник зосереджений на попередніх налаштуваннях, правилах і моделі генерації на запит.

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

** Атомний рушій ** — основна концепція UnoCSS: замість того, щоб надіслати вам заздалегідь визначений набір інструментів, програма використовує рушій правил, який генерує CSS за потреби з будь- яких назв класів, які дійсно з’ являються у вашій розмітці.

• “Не існує жодного фіксованого набору інструментів для навігації — атомарний рушій створює саме той CSS, який вимагає ваша розмітка, нічого попередньо визначеного і нічого не використаного.” *

** Preset ** — з’ єднаний, обмінний набір правил і скорочень (наприклад, сумісний з Tailwind набір правил), який надає UnoCSS певний словник інструментів без обов’ язкового кодування його у ядрі. “Ми не заблоковані в назвах інструментів Tailwind — змінюємо набір, якщо хочемо інший словник інструментів, оскільки UnoCSS не цікавить, який ми використовуємо.”

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

** Правило ** — одне зображення з шаблону назв класів у вивід CSS, з якого складаються основні набори блоків. “Додати нетипове правило для цього одноразового значення інтервалу замість того, щоб щоразу використовувати утиліту з довільним значенням — це збереже назву інтента і можливість пошуку.”

** Скорочення ** — псевдонім з назвою, який розширюється до поєднання інших інструментів, використовується для уникнення повторення одного і того ж довгого рядка інструменту у багатьох елементах.

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

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

• «Чи це генерується на запит, або ми все ще відправляємо статичний лист інструментів і очищаємо після цього?»
• Чи є це нестандартним правилом, чи існує вже достатньо близька до нього програма?
• Чи є цей довгий рядок утиліту достатньо повторюваним в інших місцях, щоб заслуговувати на те, щоб стати скороченням?
• «Які набори ми насправді використовуємо тут, і чи відповідає це словникові в інших частинах коду?»

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

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

Перегляд повторюваних рядків інструментів: “Ця точна кількість інструментів з’ являється у шести різних компонентах — саме для цього існує скорочення, тому давайте назвемо його один раз.”

Обговорення виводу збирання: “Не потрібно турбуватися про крок очищення — генерація на запит означає, що вивід вже містить тільки класи, які з’ являються де- небудь у сканованих файлах.”

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

• Введіть концепцію ** атомарного рушія ** на початковому етапі — вона перетворює UnoCSS на генератор, а не на фіксовану словникову базу, що запобігає плутанині під час обміну настановами пізніше.
• Будьте чіткими щодо того, які ** набори** використовує проект — команди, що переходять з Tailwind, вважають, що назви інструментів фіксовані і здивовані, коли вони залежать від наборів.
• Покладайтеся на побудову на запит як на перевагу при обговоренні розміру збірки — немає жодного кроку очищення, який можна налаштувати або неправильно налаштувати.
• Заохочуйте ** скорочення ** для будь- якої комбінації інструментів, що повторюються у декількох компонентах — це найчистіший спосіб дати назву інтенції без введення нетипового CSS.

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

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

Розробка технології: розробка технології в рамках проекту

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

Одним з найчастіших викликів є отримання коментарів перегляду коду. Замість простої оборонної реакції («Це працює!»), Розробник повинен сформулювати * чому * щось працює і визнати потенційні проблеми. Типовий коментар може звучати так: « Це здається трохи довгим; чи не могли б ми дослідити більш коротке рішення? » Ключовим тут є не просто вказати проблему, а запропонувати запрошення до обговорення. Ви можете відповісти: « Я дякую за ваші відгуки щодо кількості слів. Я прагнув до максимальної зручності читання у цьому конкретному контексті, враховуючи мету набору параметрів. Чи були б ви відкриті до обговорення альтернативних підходів, які зберігають ясність, мінімізуючи розмір?»  Продемонструвати готовність розглядати різні перспективи є критичним — це показує, що ви цінуєте експертизу команди і присвячені спільному результату. Аналогічно, коли ви описуєте зміни у запиті на завантаження, уникайте нечітких вказівок на зразок « Виправлено проблему з CSS ». Замість цього, надайте конкретні відомості: « Впроваджено нове попереднє налаштування UnoCSS для заокруглених кутів, зменшивши дублювання коду у багатьох компонентах приблизно на 15% »

Крім того, розмови Slack часто вимагають короткості і точності. Запит на пояснення можна сформулювати так: « Чи можете ви розібратися у призначеннях цієї певної змінної? » Хороша відповідь буде уникнути жаргонізму, якщо це не є абсолютно необхідним, і натомість ясно пояснити: « Добре, щоб пояснити, ми використовуємо цю змінну переважно для керування радіусом тіні наших основних кнопок — параметром, який безпосередньо впливає на навички користувача. Нам потрібно забезпечити послідовність усіх настанов. » Цей рівень деталізації запобігає нерозумінням і забезпечує, що всі будуть розуміти одне й те саме.

Нарешті, пам’ятайте, що документація не просто про створення визначення; це про пояснення * чому * речі робляться певним чином. Під час документування нового набору параметрів або змінної, поясніть її обґрунтування, потенційні наслідки і всі обмеження. Це допоможе іншим користувачам зрозуміти ваші рішення щодо розробки і дозволить їм з повною впевненістю змінювати код у майбутньому.

uno c --output-format json --preset rounded-corners --variables { "borderRadius": "0.5rem" } > button_style.json

За допомогою цієї команди можна скористатися uno (CLI UnoCSS) для створення файла JSON (button_style.json ), у якому містяться стилі CSS для заокруглених кутів, визначені за допомогою прапора --preset rounded-corners, а також за допомогою нетипової змінної для радіусу межі. У цьому файлі показано, яким чином ви можете описати цей процес у технічному обговоренні або оновленні документації.