Я положил Tailwind‑классы в базу. После сборки половина стилей исчезла

[crymans]

Да, если контент меняется через Git и деплой, файлы были бы проще базы — спорить не буду.

У меня HTML является только одним полем сущности. Рядом лежат slug, порядок, статус публикации, цена, категории и остальные данные, которые редактируются через админку. Если перенести это на диск, придётся отдельно решать запись из приложения, конкурентное редактирование, persistent volume, резервные копии и работу нескольких экземпляров.

Поэтому база нужна не ради хранения строки HTML, а ради модели управления контентом. Для статического сайта с техническим редактором я бы действительно выбрал файлы.

[Keeper12]

HTML в базе — плохая идея

Дарю идею. База данных тоже не нужна. HTML можно хранить прямо в файлах на диске.

[supercat1337]

Видимо автор хотел снизить количество обращений к файлам. С тем же успехом мог бы положить сайт в оперативку.

[crymans]

Да, если контент меняется через Git и деплой, файлы были бы проще базы — спорить не буду.

У меня HTML является только одним полем сущности. Рядом лежат slug, порядок, статус публикации, цена, категории и остальные данные, которые редактируются через админку. Если перенести это на диск, придётся отдельно решать запись из приложения, конкурентное редактирование, persistent volume, резервные копии и работу нескольких экземпляров.

Поэтому база нужна не ради хранения строки HTML, а ради модели управления контентом. Для статического сайта с техническим редактором я бы действительно выбрал файлы.

[danilovmy]

Можно же использовать <component is="wanted_component_name" > тогда достаточно передать только имя компонента, без кода. И фейковые html будут не нужны для тайлвинда. Поздно конечно, уже ж реализовано.

[crymans]

Да, это хороший следующий шаг. Тогда в базе хранится не HTML, а что-то вроде { "type": "price", "props": {...} }, а Tailwind видит все классы внутри обычного Vue-компонента ещё во время сборки.

Минус в том, что каждый новый тип блока сначала нужно реализовать и задеплоить. HTML я оставил как быстрый вариант для редких уникальных вставок, но для повторяющихся блоков ваш подход действительно лучше. И не поздно: можно добавить blocks рядом с body_html, постепенно мигрировать контент, а HTML оставить временным fallback.

[jiroler]

Почему бы при сохранении не прогнать html через тот же tailwind на сервере для генерации нужных стилей?

[crymans]

Можно, и для редких сохранений это вполне рабочий вариант: принять HTML, прогнать его через Tailwind CLI и сохранить результат вместе с готовым CSS.

Я отказался от этого из-за цены операции и сложности эксплуатации. Tailwind — сборочный инструмент: на каждое сохранение пришлось бы запускать отдельную сборку, изолировать пользовательский ввод, ограничивать время и память, кешировать результат и разбираться с параллельными запусками. Если контент редактируется часто, получается небольшой build-сервис внутри обычного backend.

Но для CMS с небольшим числом публикаций я бы сейчас действительно рассматривал такой подход. Особенно если сохранять CSS по хешу содержимого и пересобирать его только при изменении набора классов. В моём случае safelist оказался проще, но ваш вариант универсальнее.