Все, что вы собираетесь фильтровать, должно быть включено в это <List>
. В вашем случае ваш Resource
/ endpoint
должен возвращать dateEnd
(истек или нет). И здесь могут работать два шаблона проектирования:
Во-первых, вы можете использовать filterDefaultValues
проп. tl; dr Используйте запрос по умолчанию (status
), переключите expired
/ not_expired
(можно использовать Tabs
для рендеринга).
Это отвечает на ваши два вопросов:
- "Возможно ли это как-то создать запрос в URL?"
- Есть какие-нибудь идеи, как я могу показать список просроченных или не просроченных сущностей?
<List
{...props}
// Do you want your users to start by seeing "expired" or "not expired"?
// You can place it within `filterDefaultValues`
filterDefaultValues={{ status: 'not_expired' }}
sort={{ field: 'date_added', order: 'DESC' }}
perPage={10}
>{ Children }</List>
Затем получите компонент children
, чтобы обновить это поле status
с помощью Tabs
, например. Эти Tabs
обновят ваш state
, который можно распространить до List
status
реквизита, используя class methods
или Hooks
.
Второй, вы можете использовать filters
проп. Интересно, это то, что вы имели в виду, но это побеждает то, что вы хотели. tl; dr Первоначально верните оба expired
& not expired
и предоставьте пользователю запрос через filters
.
При таком подходе вы обычно визуализировать List
как expired
, так и not expired
. Затем предоставьте filters
реквизит, чтобы позволить пользователю просеивать то, что он хочет видеть.
<List
{...props}
// So you'd place your `MessageFilter` within `filters`
filters={<MessageFilter />}
sort={{ field: 'date_added', order: 'DESC' }}
perPage={10}
>{ Children }</List>
Даже здесь вы все равно будете запрашивать эти данные, но без значений по умолчанию. Таким образом, пользователь сначала увидит длинный список всех ваших записей.
Исходя из ваших данных, первый подход будет работать лучше всего. Но оба props
могут фактически использоваться одновременно в зависимости от вашей цели.