Контракт для разработки
Что делаем: дописываем в README.md контракт: на что разработчик может опираться, а на что нет.
Что обещает документация
Разработчик подключает компонент и начинает на него опираться: вешает обработчики, ищет элементы по классам, переопределяет переменные. Если вы не сказали, что стабильно, он решит, что стабильно всё. Тогда любая правка CSS что-нибудь сломает.
Две короткие таблицы-списка
Можно опираться на то, что вы готовы поддерживать: класс .button и модификаторы, нативные атрибуты type, disabled и aria-label, токены вроде --color-primary.
Нельзя опираться на то, что может измениться: внутреннюю вёрстку, порядок правил, служебные классы .is-hover и .is-focus, всё с пометкой @deprecated.
Чем короче первый список, тем свободнее вы меняете компонент. Контракт — это не запрет, а способ договориться.
Скрипты и классы оформления
Для скриптов не используйте классы оформления: они меняются при перекраске. Для JavaScript заведите отдельный атрибут вроде data-action — и перекраска не заденет логику.
Источники
- Атрибуты data-*: пользовательские данные для скриптов.
- Semantic Versioning: что считать ломающим изменением публичного интерфейса.