Всем привет!

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