Но, честно говоря, мне кажется что дублирование всех списков для разных языков – немножко избыточно и уводит нас от единообразия данных в ответе, и лучше чтобы локализация для значений enumerates была реализована уже на фронтенде
Но, наверное, но для каких-то случаев это действительно могло бы стать преимуществом
Да, Content History действительно работает только для изменений через Content Manager
И да, при всем желании можно было бы самому сделать какой-то плагин, с помощью которого хранились бы все состояния сущности (даже при обновлении через entityService и т.д.), но помимо кастомизации хуков еще бы потребовалась кастомизация интерфейса Strapi
В целом, теперь это решение как минимум предоставлено "из коробки" и можно быть уверенным в его поддержке от версии к версии
CMS – это все-таки более широкий функционал, чем 20-30 строк кода на пыхе
Проект на Strapi может успешно функционировать вообще без написания кода разработчиками — весь код генерируется автоматически на основе коллекций, создаваемых через UI
Strapi же предоставляет возможность гибко кастомизировать функционал по мере необходимости
Одним из преимуществ деструктуризации массива, в отличие от деструктуризации объекта, является возможность использования произвольных названий переменных
У объекта тоже можно. В который раз убеждаюсь, что об этом немногие знают :)
Встроенной такой функции нет, только через кастомизацию и добавление переводов каждому слову
https://forum.strapi.io/t/unable-to-add-a-new-language-for-the-admin-ui/14251/6
Да, такого пока тоже не появилось
Но, честно говоря, мне кажется что дублирование всех списков для разных языков – немножко избыточно и уводит нас от единообразия данных в ответе, и лучше чтобы локализация для значений enumerates была реализована уже на фронтенде
Но, наверное, но для каких-то случаев это действительно могло бы стать преимуществом
Да, Content History действительно работает только для изменений через Content Manager
И да, при всем желании можно было бы самому сделать какой-то плагин, с помощью которого хранились бы все состояния сущности (даже при обновлении через entityService и т.д.), но помимо кастомизации хуков еще бы потребовалась кастомизация интерфейса Strapi
В целом, теперь это решение как минимум предоставлено "из коробки" и можно быть уверенным в его поддержке от версии к версии
CMS – это все-таки более широкий функционал, чем 20-30 строк кода на пыхе
Проект на Strapi может успешно функционировать вообще без написания кода разработчиками — весь код генерируется автоматически на основе коллекций, создаваемых через UI
Strapi же предоставляет возможность гибко кастомизировать функционал по мере необходимости
Мы решили использовать Strapi из-за его популярности и более развитого комьюнити
Но обязательно обратим внимание на Directus, спасибо за предложенную альтернативу!
У объекта тоже можно. В который раз убеждаюсь, что об этом немногие знают :)