Datagrid для вложенных конечных точек в Reaction-Admin

Question

Я пытаюсь понять, как правильно подходить к вложенным конечным точкам, давайте предположим, что у меня есть отношение ко многим books и authors, и API, который предоставляет api/authors, api/books иapi/authors/{id}/books.Это общий шаблон проектирования.

CRUD на api/authors прекрасно работает в реагирующем администраторе.Тем не менее, под авторами <Show> я хочу показать <Datagrid> всех книг с разбиением на страницы и сортировкой, которые мой API делает доступными под api/authors/{id}/books.

Каков правильный подход для создания сетки данныхтакой вложенной конечной точки?

Я рассмотрел <ReferenceManyField>, который хорошо работает в контексте один ко многим, но не позволяет получить доступ к вложенным конечным точкам, а только фильтрует конечную точку.

В идеале я хотел бы что-то вроде:

<Show {...props}>
    <TabbedShowLayout>
        <Tab label="Books">
            <NestedResourceField reference="books" nestedResource={`authors/${props.record.id}/books`} pagination={<Pagination/>} >
                <Datagrid>
                    <TextField source="name" />
                </Datagrid>
            </NestedResourceField>
        </Tab>
    </TabbedShowLayout>
</Show>

Обратите внимание, что <NestedResourceField> - это гипотетический компонент, который будет иметь поведение, очень похожее на <ReferenceManyField>, но приметвложенная конечная точка в nestedResource вместо target.

Я изо всех сил пытаюсь понять, какой должна быть стратегия проектирования для гипотетического <NestedResourceField>, чтобы повторно использовать как можно большую часть реагирующей административной структурынасколько это возможно.

Было бы просто "вручную" сделать выборку самостоятельно и вывести список содержимого, но тогда я потерял бы всю нумерацию страниц, фильтрацию, сортировку и т. д.mes с response-admin и тем фактом, что books является уже определенным ресурсом.

Мой вопрос похож на эти оставшиеся без ответа вопросы:

пользовательские маршруты в activ-admin

пользовательский путь для маршрута ресурса в реагировать-администратор

Редактировать

Оказывается, почти идентичный вопрос, который я не нашел ранее, был размещен здесь: Поддержка вложения ресурсов

Answer 1

Поэтому я решил решить эту проблему с помощью взлома dataProvider.

В соответствии с приведенным выше примером и использованием акций ReferenceManyField:

<Show {...props}>
    <TabbedShowLayout>
        <Tab label="Books">
            <ReferenceManyField reference="books" target="_nested_authors_id" pagination={<Pagination/>} >
                <Datagrid>
                    <TextField source="name" />
                </Datagrid>
            </ReferenceManyField>
        </Tab>
    </TabbedShowLayout>
</Show>

Затем я изменил свой dataProvider, который является форком ra-jsonapi-client . Я изменил index.js под case GET_MANY_REFERENCE с этого:

      // Add the reference id to the filter params.
      query[`filter[${params.target}]`] = params.id;

      url = `${apiUrl}/${resource}?${stringify(query)}`;

к этому:

      // Add the reference id to the filter params.
      let refResource;
      const match = /_nested_(.*)_id/g.exec(params.target);
      if (match != null) {
        refResource = `${match[1]}/${params.id}/${resource}`;
      } else {
        query[`filter[${params.target}]`] = params.id;
        refResource = resource;
      }

      url = `${apiUrl}/${refResource}?${stringify(query)}`;

Так что в основном я просто переназначаю параметры в URL для особого случая, когда target соответствует жестко заданному регулярному выражению.

ReferenceManyField обычно вызывал бы вызов dataProvider api/books?filter[_nested_authors_id]=1, и эта модификация вместо этого вызывает вызов dataProvider api/authors/1/books. Это прозрачно для реакции-admin.

Не элегантно, но работает и, похоже, ничего не ломает в передней части.