EditableObject

Fi1osof
28 мая 2019 г., 4:17

EditableObject

Всем привет!

Сегодня я расскажу про еще несколько новых компонентов, а именно 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

Добавить комментарий