Англійська для розробників інтерфейсу Radix

Розмови Radix UI використовують точні терміни для того, як нестилізовані, доступні компоненти збираються — примітивні, композиція, asChild — і розробник, який звик до повністю стилізованих компонентних бібліотек, може змішати їх з загальною «компонентною» мовою таким чином, що робить обговорення дизайну системи неясними.

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

Primitive — нестилізований, доступний компонент будівельного блоку, наприклад Dialog або Dropdown Menu, який обробляє поведінку і семантику ARIA, але залишає всі візуальні стилі для користувача.

• “Ми використовуємо діалоговий примитив Radix і накладаємо на нього шари стилів нашої власної системи дизайну, замість того, щоб писати логіку лову фокусу самостійно.” *

Композиція — шаблон побудови складного компонента з декількох менших підкомпонентів, таких як Dialog.Trigger, Dialog.Content, і Dialog.Close, кожен з яких відповідає за одну частину поведінки. “Це не один великий компонент Dialog — це композиція частин Trigger, Content і Close, тому ми можемо змінювати розмітку без втрати доступності.”

** asChild prop** — шаблон Radix, який надає змогу примітиву об’ єднати свою поведінку і підказки з нетиповим дочірнім елементом замість відтворення власного вузла DOM- оболонки, уникаючи небажаних вкладених елементів. “Використовуйте asChild тут, щоб тригер відтворювався як наш існуючий компонент Button безпосередньо, замість того, щоб обгортати його в додатковий <button> від Radix.”

** Контрольований проти неконтрольованого стану ** — чи відкритий/ закритий або вибраний стан примітиву керується зовнішньо через властивості, такі як open і onOpenChange, або внутрішньо самим компонентом, коли такі властивості не передаються. “Переключити це на контролюване спадне меню, оскільки нам потрібно закрити його програмно ззовні, коли відбудеться інша дія — неконтрольована версія не може бути керована ззовні.”

** Portal ** — шаблон Radix для відтворення вмісту компонента, наприклад, накладання діалогового вікна або підказки, у іншій частині дерева DOM, зазвичай, щоб уникнути обрізання батьківських елементів за допомогою overflow: hidden.

• “Відображати вміст підказки через портал — інакше його буде обрізано прокручуваним контейнером, у якому він вбудований.” *

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

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

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

Пояснення рішення щодо дизайну системи:

• “Ми побудували діалогове вікно нашої системи дизайну на основі діалогового примітиву Radix, тому ми отримуємо правильну фокусну перехоплення і атрибути ARIA безкоштовно, і нам потрібно лише володіти візуальним стилем.” *

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

Перегляд вади з контролем стану: “Це спадне меню не закривається, коли користувач надсилає форму, тому що воно неконтрольоване — нам потрібно підняти відкритий стан і керувати ним за допомогою open і onOpenChange.”

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

• Використовуйте primitive замість « component », коли ви обговорюєте нестилізовані блоки Radix — це означає, що поведінка доступності оброблена, і залишається лише додати візуальні елементи.
• Описувати складний інтерфейс користувача як композицію названих підчастин у документації і оглядах — це пояснює, якій частині належить яка поведінка, замість того, щоб розглядати все як одну чорну скриньку.
• Рекомендуємо asChild явно, коли з’ являється помилка вкладеного елемента або дублікат- семантики — надання назви шаблону прискорює виправлення для будь- кого, хто знайомий з Radix.
• Роз’ яснення ** контролюваного проти неконтрольованого ** на початку, коли компонент повинен керуватися зовнішньою логікою — перебудова контролю після збирання неконтрольованого часто означає більший перепис, ніж початок контролю.

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

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

Національний гідрографічний інститут: Відповідь і відповіді

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

Розглянемо такий сценарій: Ви надіслали запит на прив’ язку, який вводить новий компонент кнопки за допомогою примітиву button з інтерфейсу користувача Radix. Під час перегляду коду, старший розробник залишає коментар на вашій гілці: «В цілому це виглядає добре, але чи можемо ми дослідити використання asChild тут? Це може спростити обробку доступності і зменшити потенційні конфлікти з нашим існуючим стилем. Це не обов’ язково негативна оцінка * вашої * роботи. Рецензент пропонує рекомендації - пропонує більш надійне рішення, засноване на їхньому досвіді і розумінні принципів дизайну Radix UI. Прямий переклад «Це потрібно поліпшити» не передав би намірів, а також не запропонував би продуктивної дискусії. Замість цього, відповісти щось на зразок: “Дякую за пропозицію! Я не розглядав використання asChild — чи можете ви розглянути, як це спрощує доступність?» демонструє залученість і бажання вчитися. Аналогічно, в Slack, замість того, щоб сказати «Це пошкоджено», більш корисним повідомленням може бути: «Я бачу проблему з відтворенням кнопки; вона не відображається правильно. Я перевірив CSS і JavaScript - є якісь ідеї? “Розглядання проблем як розслідувань показує володіння і заохочує інших робити внесок у свою експертизу.

Крім того, при написанні описів PR, чіткість є найважливішою. Уникайте нечітких тверджень на зразок « Виправлено ваду ». Замість цього, докладно описуйте, * що * було виправлено, * чому * виникла проблема, і * як * її було вирішено. Наприклад: «Розв’язана проблема #1234 — неправильне оформлення кнопок на мобільних пристроях через недостатню кількість точок зупинки медіа-запитів. Впроваджено адаптивний CSS з використанням calc() і одиниць перегляду для послідовного зміни розмірів на різних розмірах екранів. ” Цей рівень деталізації надає контекст для переглядачів і майбутніх супровідників, зменшуючи неоднозначність і спрощуючи процес перегляду. Це про те, щоб продемонструвати ретельне розуміння проблеми і ваш підхід - показати вашу технічну компетентність.

// Example: Using CSS calc() to create responsive button styling
// (Illustrative - not directly related to Radix UI, but demonstrates responsive design principles)
echo "button {
  width: calc(100% - 20px); /* Adjust for padding */
  padding: 10px 20px;
}

@media (max-width: 768px) {
  button {
    font-size: 14px;
  }
}" > responsive_button.css

Врешті-решт, освоєння професійної англійської мови в контексті розвитку стосується навчання ефективно спілкуватися - не тільки точно, але з емпатією і повагою до досвіду ваших колег. Це про перетворення технічних викликів на можливості для спільного зростання.