Какие пропсы стоит закладывать у компонентов дизайн-системы — только то, что нужно сейчас, или с запасом на будущее?

Введение в проблему

Проектирование API компонентов дизайн-системы — это всегда поиск компромисса. С одной стороны, хочется предусмотреть все возможные сценарии использования, чтобы разработчики не писали кастомные стили. С другой — каждый лишний пропс делает компонент тяжелее, сложнее в поддержке и тестировании. Классический принцип YAGNI (You Aren't Gonna Need It) говорит, что не стоит добавлять функциональность до того, как она реально понадобится. Однако в дизайн-системах важно думать на шаг вперед, так как изменение API после массового внедрения — это дорогостоящая операция.

Практический подход

Рекомендуется начинать с минимального набора пропсов, которые покрывают реальные кейсы из текущих макетов и требований. При этом архитектура должна быть гибкой: используйте композицию (children, render-props) и дефолтные значения, чтобы расширять функциональность без ломающих изменений. Например, вместо добавления пропса iconPosition лучше позволить передавать иконку как часть children или использовать слоты.

// Плохо: слишком много пропсов для простой кнопки


// Хорошо: минимальный набор, расширяемый через children

   Нажми меня

Ключевые принципы

• Минимализм: каждый пропс должен иметь четкое назначение и использоваться хотя бы в одном реальном сценарии.
• Композиция: предпочитайте вложенность и children вместо множества конфигурационных пропсов.
• Дефолты: задавайте разумные значения по умолчанию, чтобы упростить использование.
• Документация: четко описывайте каждый пропс и его влияние на поведение.

Вывод

В итоге, лучший подход — это баланс: закладывайте только то, что нужно сейчас, но проектируйте компонент так, чтобы его можно было легко расширить без ломающих изменений. Это позволяет сохранить простоту и скорость разработки, одновременно обеспечивая долгосрочную устойчивость дизайн-системы.