Пастка кращих практик.
Хочеш бути кращим інженером? Використовуй KISS! DRY! YAGNI! та інші, не менш цікаві, абревіатури. І водночас, коли багато хто переконливо пояснюють нам чому нам обовʼязково потрібно дотримуватись усіх цих практик, дуже мало голосів намагаються розібратися, коли їх дотримуватись не треба.
Не так давно, розмірковуючи про Good Enough Code, я зауважив, що на 100% відсотків дотримуватися усіх "кращих практик" просто фізично неможливо. З однієї простої причини — вони порушують одне одного. В цей аспект заглиблюватись не буду, я сьогодні про інше.
Тут днями в нашому чаті почалася розмова про ту саму "перевикористовуваність" компонентів, яку багато розробників перевели хто в статус державної релігії, а хто й карґо-культу.
Основна ідея реюзабельности проста як двері — ваш компонент не повинен бути заточеним під один-єдиний юзкейс, і його можна використати в іншому сценарії. Звучить круто, так? Менше коду, взяв готове, і вперед.
Однак це відкриває провалля до пекла. І починається воно з того, що розробники не бачать межу між компонентами, які можна перевикористати, і тими, які в принципі за своєю суттю є одноразовими. І тоді починається цікаве. Ось такий базовий компонент починає всотувати в себе одноразові кейси, потроху роздуваючись до непристойних розмірів та обростаючи додатковими прапорцями й налаштуваннями.
Далеко ходити не треба. Кожен з нас бодай раз, але таки створював компонент кнопки. Спочатку це маленький милий пухнастий компонентик, який ховає під собою тільки стилі. Проте потім у нього починають відростати додаткові стани і пропси до них: іконка зліва, іконка справа, стан завантаження, варіанти стилю, розміри і тому подібне.
І ось на нас вже сумно дивиться з потойбічної Безодні щось хтонічне, поряд із чим навіть Ктулху поводиться чемно.
Чи можна було цього уникнути? Абсолютно. В першу чергу, величезна кількість "станів" в кінці кінців зводиться до того, що під капотом на кнопку вішається якийсь клас. То чому ж не дати розробнику самому цей клас навісити?
Чи ті самі іконки? Просто кладіть іконку в кнопку явно на потрібне місце. CSS давно вміє застосовувати стилі на основі позиції та присутності чи відсутності певних елементів.
Похідні стилі? CSS змінні та calc до ваших послуг.
І так далі, і тому подібне. Ми настільки звикли робити ось ці універсальні комбайни, що тулимо їх там, де рішення може бути настільки простим, наскільки лише можна. І виходить, що та сама кнопка, задача якої або натискатися, або не натискатися, розростається в складний заплутаний клубок пропсів.
Не все має бути перевикористовуваним. Не все має бути універсальним. Ба більше, не все має бути ідеальним.
Коли у вас виникає спокуса додати до компонента ще одне налаштування, що один пропс, покрити ще один кейс, ставте собі просте запитання: "Що я цим вирішую?".
Чи не краще замість чергового isLoading в базовій кнопці створити
AsyncButton з тим же pending станом? Більшість з вас, звичайно, зараз обурено вдихнули — це що таке я раджу? А раджу я не конкретний рецепт, а ідею, думку, варту того, аби над нею подумати: замість монструозних універсальних систем мати шар базових, тупих як пересічний росіянин, компонент, і шар більш спеціалізованих, успадкованих від базових, компонент, які покривають специфічніші задачі (я прямо відчуваю хвилю гніву, що котиться до мене з табору реактщиків).
І мова не лише про UI. Спробуйте цю ідею. Іноді найкращі речі — найпростіші речі. А принципу наслідування й розширення рочків вже побільше ніж мені, певно.
@babichdev
З вас вподобайка, репост і раптова підписка. Гарного початку тижня, і не городіть хєрні в коді!