Sanity удобен, пока не превращает контент-модель в свалку полей и ролей

Sanity удобен, пока не превращает контент-модель в свалку полей и ролей

У Sanity сильная сторона — гибкость. Но именно она чаще всего ломает проект: редакторы видят десятки input’ов, разработчики плодят reusable-блоки без правил, а через пару месяцев никто не понимает, где хранится что и почему один и тот же текст заведён в трёх местах.

За неделю в репах обычно всплывают одни и те же ошибки:
— нет единого принципа именования полей и документов;
— блоки переиспользуются без ограничений по контексту;
— preview и validation не настроены, поэтому мусор уезжает в прод;
— права доступа слишком широкие, и редактор может случайно сломать схему контента.

Sanity лучше всего раскрывается, когда модель строится от сценариев, а не от абстрактной “гибкости”. Сначала фиксируете типы страниц, потом набор блоков, потом правила: где блок можно вставлять, какие поля обязательны, что показывать в превью, а что скрывать. Для контент-сайта это экономит время редакции. Для mid-стека — снижает число багов на фронте. Для лендинга — не даёт превратить простую страницу в CMS-конструктор без контроля.

Есть наблюдение которое стоит проверить: Sanity особенно хорош там, где важны структурированные данные, а не просто “заполнить текстовое поле”. Если проекту нужны каталоги, FAQ, авторские страницы, мультиязычность и аккуратный preview, он часто удобнее более тяжёлых CMS. Но если нужен один шаблон и пять полей, его гибкость может быть лишней.

Если берёте Sanity в проект, сначала рисуйте карту контента, потом интерфейс редактора. Иначе вы купите не CMS, а право долго разгребать собственную свободу.