#технологии

Часть 2

Продолжаем рассказывать о критериях, по которым мы определяем, нужно ли выводить новую функциональность в пропс. Часть 1 тут

③ Универсальный пропс > монофункциональный пропс. Яркий пример — валидация. Зачастую нас просят добавить валидацию, например на корректность почты. Доработка хорошая, но зачем ограничиваться почтой, если можно добавить пропс validationRules и дать возможность разработчику самому определять правила валидации. Тут нужен и важен баланс, иначе можно прийти к одному объектному пропсу, в который нужно будет прокидывать конфигурацию для всего компонента.

④ Непродуктовая фича. Важно найти оптимальное сочетание между навешиванием рычагов на вообще всё и абсолютно неповоротливым, заточенным под один продукт, компонентом. Яркий пример перегиба в одну сторону — компонент InputDate. В какой-то момент мы поняли, что у нас около 40 пропсов. Добавить легко, удалить сложно. Удаление пропса или изменение его нейминга неизбежно ведет к breaking changes и обновлению мажорной версии. Должны быть очень веские аргументы, для того, чтобы мы добавили к нему новый параметр в текущей версии. Клепать часто мажоры нельзя, поэтому мы подготавливаем список семантических и функциональных изменений к новой версии и начинаем внедряем декоратор deprecated.

Похожим образом, мы выводим критерии и ищем свой дзен, проектируя дизайн-токены. Подробнее о токенах в нашем канале расскажет Денис Плешаков — продакт Дизайн-системы Ростелекома.