Семантичні імена класів занадто загальні?

31

Від автора: процес іменування в HTML і CSS оманливе складний, але дуже важливий. Наріжними каменями MaintainableCSS є приписи про те, ЯК і НАВІЩО ми повинні іменувати модулі. Не випадково це одна з перших глав у книзі.

У цій главі я розповідаю про те, що ви повинні іменувати модулі за фактом, а не на основі того, як вони виглядають або поводяться. Проблема в тому, що, навіть знаючи це і використовуючи логічні імена, проблема нікуди не дівається.

Навіть якщо ви не будете використовувати стилістичні або поведінкові імена класів, ви все одно заплутаєтеся. Всі ваші кульбіти з іменуванням будуть або занадто загальними або занадто специфічними.

Більшість розробників роблять занадто загальні імена. І це не просто так, принаймні, в теорії. Вони роблять так, тому що чим расплывчатей, тим більше цей елемент можна використовувати повторно. Але в житті все не так просто.

Кращий спосіб продемонструвати це – розібрати приклад разом.

Наприклад, ви створюєте форму авторизації з полями email і пароль. Ви можете іменувати ці елементи наступним чином:

Імена класів специфічні, до того ж вони використовують модуль форми авторизації.

Це можна назвати хорошим прикладом іменування. На це є дві причини. По-перше, ви можете стилізувати цю форму, не зачіпаючи інші форми. По-друге, якщо ви захочете, ви можете додати в цю форму загальні стилі для всіх форм на сайті. Зробити це можна за допомогою декількох селекторів через кому або за допомогою міксина (якщо ви використовуєте препроцесор):

.loginForm,
.someOtherForm {
/* Загальні стилі контейнера */
}
.loginForm-email,
.loginForm-password,
.someOtherForm-someField {
/* Загальні стилі полів */
}

В залежності від сайту стилів буде більше або менше, що не дуже приємно.

Приміром, компонентів .loginForm-email і .loginForm-password можна дати більш загальні імена типу .loginForm-field.

Як на мене, таке іменування все ще досить специфічно, так як поля прив’язані до модулю loginForm. Безліч форм можуть містити такі поля з такими ж стилями. Зрештою, послідовність – важлива частина дизайну.

Ми можемо абстрагувати ці компоненти в свій власний модуль з назвою .formField.

Цікаво те, що всі три класи именованы за принципами MaintainableCSS, але всі по-різному впливають на обслуговування, масштабованість і модульність коду.

Візьмемо цей загальний, повторно використовуваний модуль .formField і знайдемо в ньому можливі проблеми.

Що робити в ситуаціях, коли потрібно злегка змінений модуль .formField з доповненнями? І якщо всім полям з цими доповненнями потрібні додаткові або інші стилі?

Тут нам допоможе modifiers. Потрібно всього лише додати ще один клас елементу і внести необхідні правки.

The hint goes here

У цьому прикладі треба внести трохи змін. Але що робити, якщо зміни більш суттєві, як поле з набором радіокнопок?

Працювати з modifier проблематично, так як в ньому низька спадкування. Коли ми думали про .formField, адже ми не врахували радіокнопки взагалі, так адже?

В принципі, це непогано, у багатьох відносинах навіть добре. Часто ми стикаємося з тим, що, не розуміючи вимог до дизайну, ми не можемо об’єднати різні речі в щось єдине.

Чисто технічно, всі елементи можна назвати .item і все, але це не практично.

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

Ми підійшли до тієї точки, коли стало ясно, що назва .formField занадто загальне. Я точно не хочу оновлювати стилі набір радіокнопок і піклуватися про регрес стилів в текстовому полі. Також я не хочу розробляти якісь загальні стилі, щоб зменшити CSS код.

Так, де ж зупинитися?

Ми почали з дуже специфічного іменування і закінчили надто загальним, а ми ж так старалися.

Якщо .formField – занадто загально, а .loginForm-email і .loginForm-field – дуже специфічно, так в яку сторону рухатися?

Розібравши ці проблеми детально, набагато легше розробити найкращий спосіб іменування. Текстові поля можна назвати .textField, а групи радіокнопок — .radioGroupField. Ці поля можна розглядати, як окремі модулі.

Поля вийшли досить специфічними, щоб ми могли щось у них змінювати, і досить загальними, щоб повторно використовувати їх в інших формах без написання додаткового CSS коду.

Реальна проблема полягає в тому, що ми стикаємося з такими рішеннями весь час. Ми повинні часто і досконально розглядати такі ці проблеми.

Ось чому я більше віддаю перевагу більш специфічне іменування. Я краще напишу трохи більше CSS коду, щоб мати можливість гнучко стилізувати елементи загальними або різними стилями, ніж потраплю в пастку, коли мені доведеться переписувати код. Я не кажу, що мій ідеальний варіант. Але саме з цієї причини я краще буду робити так і буду рекомендувати його іншим.

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

Що потрібно винести з цієї статті? Думати і ставити питання потрібно часто і строго.

1. Якщо модуль використовується в різних місцях, але іноді він повинен відрізнятися на основі положення, контенту і т. д.?

У такому випадку краще використовувати modifier.

2. Якщо компонент може використовуватися дуже часто і в будь-якому місці?

Абстрагируйте у модуль, але не давайте зовсім загального імені.

3. А що якщо ти витрачаєш багато часу на написання безлічі різних модифікаторів або думаєш, що абстрагувати в загальні стилі?

Можливо, елемент має занадто загальна назва. Розділіть клас на окремі модулі.

Висновок

Процес іменування – завдання складне, але, як ви бачите, переваги або наслідки іменування далекосяжні. Плюс в тому, що якщо з самого початку все продумати, то можна уникнути проблем, які будуть з’являтися з-за занадто загальних назв, або з-за дуже специфічних.