Всем привет!
Сегодня я расскажу про еще несколько новых компонентов, а именно EditableObject и связанные с ним EditableView, DefaultView и TextField.
EditableObject нужен для того, чтобы можно было создавать новые записи и редактировать существующие. Поясню: раньше front-editor был практически полностью "только на чтение", то есть можно было сформировать запросы и вывести полученные данные, но это касалось только существующих данных (пользователей, топиков и т.п.), но создавать новые или редактировать существующие было нельзя. Теперь же с новыми компонентами можно и создавать новые записи и редактировать существующие.
Вот я записал довольно подробный видеоролик на 30+ минут: https://youtu.be/HDBLMVvbJmo (сорри, что он без озвучки, но в целом должно быть понятно что к чему). В нем подробно продемонстрировано не только создание/редактирование объектов, но и создание отдельного раздела сайта со своими УРЛами.
Итак, основной принцип действия.
В интерфейсах записи (объекты) могут находиться в двух состояниях: в режиме редактирования (Editable) и в обычном состоянии (Default). Вполне логично, что в этих двух состояниях интерфейсы могут отличаться (в режиме редактирования могут просто быть перечислены текстовые и прочие редактируемые поля, обновляющие те или иные свойства объекта), а в обычном состоянии у нас может быть индивидуально оформленный интерфейс. Вот для управления этими состояниями (и еще ряда сопутствующих задач) и служит EditableObject.
Вообще этот компонент фронт-редактора выводит довольно старый и полезный компонент EditableView и бОльшая часть логики идет именно оттуда, поэтому если вы заходите больее подробно изучить функционал изнутри, смотреть надо будет именно его. И именно он используется практически во всех активных интерфейсах сайта, включая редактор топиков, форму авторизации, страницу профиля и т.д. и т.п.
Если пользователю доступно редактирование объекта, появляется кнопка с иконкой карандашика. При клике по этой кнопке объект переходит из состояния Default в состояние Editable. Это очень важный момент, чтобы понимать как этот компонент оформляется. EditableObject при выводе прямых потомков руководствуется следующими правилами:
- В режиме Default выводит всех потомков, кроме класса EditableView.
- В режиме Editable выводит всех потомков, кроме класса DefaultView.
- Классы Query использует для формирования API-запросов (можно добавить сразу два Query-объекта (create и update)).
- Все остальные компоненты выводятся как есть в обоих состояниях.
То есть классическая структура следующая:
- EditableObject
-- Query create
-- Query update
-- other components
-- DefaultView
-- EditableView
-- other components
Если объект изменен и есть что сохранять, то будет гореть красная кнопка "Сохранить". При клике по ней произойдет следующее: если есть объект и у него есть значение id, то считается, что объект уже существующий и надо отправить запрос на обновление его (update), иначе запрос будет на создание его (create).
Откуда берутся эти create/update запросы? Они берутся из прямых потомков класса Query. Вот запрос на создание, используемый в примере:
mutation create (
$data:TestCreateInput!
){
response: createTestProcessor (
data:$data
){
success
message
errors{
key
message
}
data {
...test
}
}
}
fragment test on Test @prismaCmsFragmentAllFields{
id
}
А вот запрос на обновление:
mutation update (
$where:TestWhereUniqueInput!
$data:TestUpdateInput !
) {
response: updateTestProcessor(
where:$where
data:$data
) {
success
message
errors {
key
message
}
data {
...test
}
}
}
fragment test on Test @prismaCmsFragmentAllFields{
id
CreatedBy {
...user
}
}
fragment user on User @prismaCmsFragmentAllFields {
id
}
Здесь есть три важных правила:
1. create/update запросы должны быть именно processor-based, чтобы они возвращали поля success, message и т.п. Просто create/update запрос тоже выполнится, но не будет тогда подсветки ошибок по отдельным полям, автоматического редиректа на заданный УРЛ при создании объекта и т.п.
2. Обязательно надо задавать имя запроса, то есть mutation create или mutation update. При попытке сохранить объект компонент EditableObject в запросах Query ищет именно по этому имени, и если не найдет, то запроса реального не будет. Вот здесь вот как раз есть эпизод, когда я забыл прописать запрос и что при этом происходило: https://youtu.be/HDBLMVvbJmo?t=1181
3. В запросе надо обязательно прописывать псевдоним response, иначе запрос будет выполняться и сохраняться все будет, но часть логики сломается, потому что компонент пытается в ответе найти объект response, а если не прописать алиас, то этого объекта не будет и компонент не сможет проверить полную успешность выполнения запроса, ошибки проверки полей и т.п.
Ну вроде все основное описал. Если возникнут вопросы, спрашивайте. И обязательно изучите шаблоны в примере: https://front-editor.prisma-cms.com/components-demo/tests