Как избежать дублирования логики в таблице реагирующих данных

Question

Я ищу помощь в структурировании компонента таблицы данных объекта в реакции.

Я использую реагирующую виртуализацию и пытаюсь определить, как инкапсулировать шаблонную функциональность, используемую для сортировки / фильтрации / разбиения на страницы / удаления строк на стороне сервера / т. Д.

Я начал с простого, автономного компонента, который требовал только пути API, и сам обрабатывал все с локальным состоянием.

Чтобы иметь возможность обновлять / удалять / добавлять / обновлять записи извне компонента таблицы, я переместил состояние / логику таблицы в компонент контейнера, который управляет таблицей, а также некоторые кнопки и модальные окна.

Однако теперь, когда все обработчики для сортировки / фильтрации / разбиения по страницам находятся в этом контейнере, кажется, что все они должны были бы быть продублированы, чтобы их можно было использовать повторно для других таблиц с немного отличающимися требованиями, но с точно такой же сортировкой / фильтрацией / пейджинга.

Как я могу содержать шаблонную логику таблицы в компоненте таблицы, а также иметь возможность обновлять / удалять / добавлять / обновлять записи извне компонента?

Чтобы визуализировать это, вот надуманный пример, где вся логика и состояние инкапсулированы в компоненте TableWithFilter:

<SomeEntityList>
    <TableWithFilter apiPath={this.props.apiPath}>
        <FilterBar />
        <Table /> 
    <TableWithFilter>
</SomeEntityList>

метод и состояние фильтра могут находиться в TableWithFilter:

TableWithFilter._handleFilter() {
    // get filter, inject filter into api path, get records, update state 
}

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

<SomeEntityList>
    <EditRowModal />
    <TableWithFilter>
        <FilterBar />
        <Table />
    <TableWithFilter>
</SomeEntityList>

Затем необходимо переместить состояние и метод фильтра в компонент SomeEntityList, чтобы модал мог изменить записи в таблице:

SomeEntityList._handleFilter() { 
    //get filter, inject filter into api path, get records, update state 
}

SomeEntityList._editRow() { 
    // make update call, update state 
}

Предполагая, что у меня будут десятки различных SomeEntityListA / SomeEntityListB / SomeEntityListC с различной разницей (некоторые имеют модальности редактирования записей, некоторые имеют кнопки для добавления новых записей и т. Д.), Как избежать дублирования логики фильтрации в десятках мест?

Answer 1

Хорошо, через некоторое время я решил вернуться к этому, чтобы помочь кому-то еще.

С тех пор я перешел к включению в проект избыточности (по многим причинам). По этой теме у меня теперь есть функция CreateSearchableTable, которая действует как фабрика для создания пространственных имен редукторов SearchableTable. Это позволяет повторно использовать всю логику извлечения / бесконечной прокрутки / пейджинга / фильтрации / сортировки. В настоящее время я работаю над поиском лучшего способа удаления дублированных создателей действий.

Answer 2

Как я вижу, у вас есть два варианта.

• Если логика для многоразовых фильтров работает, вы, вероятно, могли бы полностью удалить их из компонентов и поместить их в каталог utils или что-то в этом роде.
• Использовать компоненты высшего порядка .

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

Почему бы вам просто не передать фильтр в качестве параметра?