2016-08-02 11 views
1

Допустим, например, у меня есть гигантский список элементов позволяет назвать его contacts это 1000+ элементов в списке мы имеем кучу фильтров, таких как contact type, contact location, assigned to, filter ASC, фильтр DESC` , То, что пользователь может вводить все, что захочет. Магазин перевождь состоит из контактов в нормализованном объектеReact/Redux выборку и фильтрацию данных

{ 
    "1": { 
    "name": "Home Simpson", 
    "type": "Lead", 
    "location": "California", 
    "created_at": "01/01/16" 
    }, 
    "2": { 
    "name": "Ned Flanders", 
    "type": "Client", 
    "location": "SpringField", 
    "created_at": "05/01/16" 
    }, 
    [...1000+] 
} 

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

Или мы должны сделать еще один запрос на сервер, чтобы получить все контакты, связанные с конкретными фильтрами?

Обратите внимание, что это не просто один параметр, который можно запросить, так как это несколько параметров. Следовательно contact.type ===: «Свинец» || «Клиент» и contact.location === «Spring Field»

Что лучше всего подходит для запроса такого размера и совершает поездки на сервер для всех подходящих контактов, которые стоят дополнительного запроса, или лучше отфильтровать нашу клиентскую сторону магазина redux и не накладывать нагрузку на сервер?

+0

Я должен сказать, что более 1000 предметов отнюдь не считаются большими. Запрашивать и фильтровать на стороне клиента отлично. (Если вы не ориентируетесь на устройства с низким энергопотреблением) – luanped

+0

@luanped yeah Я думал об одном и том же, но проблема в том, что некоторые «пользователи» могут иметь большее количество контактов, говорят, что десять тысяч во всех случаях зависят от пользователя. В среднем я рассчитывал бы на тысячу, но со временем он будет продолжать расти и расти. – Enjayy

ответ

3

С точки зрения Redux: не стесняйтесь делать это на стороне клиента. Такая фильтрация будет очень быстрой, и Redux не собирается замедлять ее.

В общем, это тот тип вещей, который вы не хотите оптимизировать, если не знаете, что это будет проблемой. Когда вы говорите о , возможно, существует вероятность того, что у кого-то есть набор данных слишком много лет спустя, это крайне преждевременная оптимизация - есть, вероятно, десятки вещей, на которые вам лучше работать вместо этого. Насколько вам известно, размер полезной нагрузки может быть гораздо более серьезной проблемой, чем это (насколько велики контактные объекты?)

Но не нужно ни слова об этом никому. Создайте набор данных на целевом устройстве (что бы ваш типичный пользователь использовал? Что относительно наихудшего случая?) И выполняйте тесты производительности, отфильтровывающие выборочные данные. У меня есть ощущение, что вы обнаружите, что подобная фильтрация, которую вы делаете, не будет узким местом, поскольку это просто O (n * 1). Вы фильтруете через n элементов O (n), проверяя одно значение на каждом O (1).

С другой стороны, если у вас есть список очень сложных объектов с очень сложным фильтром, ваш результат может измениться. Например, если вы ищете все контакты, которые знают всех других контактов, которые знают тех же трех конкретных людей, сложность будет расти, и вы с большей вероятностью столкнетесь с узким местом.

В любом случае, я действительно рекомендую попробовать себя, прежде чем тратить массу времени, преждевременно оптимизируя ваше приложение.

+0

Спасибо Nathan Я думаю, что вы правы с преждевременными оптимизациями. Я просто хочу спуститься по правильному пути в первый раз, а не с рефактором. Объекты не являются большими, что приведет к проблеме, возможно, к 20 свойствам, а фильтры в основном относятся к свойствам контактов. Спасибо за совет, я определенно настрою бенчмарк и посмотрю, как он идет! – Enjayy

1

ИМО, правильное место для фильтра данных не непосредственно в редукторах, но в селекторов.

От Redux документы:

Computing Derived Data

Reselect простая библиотека для создания memoized, компонуемые селекторные функции. Селектора повторного выбора можно использовать для эффективного вычисления полученных данных из хранилища Redux.

В настоящее время я использую селекторы для фильтрации и сортировки данных.

  1. Повторное воспроизведение данных в штате. Вам не нужно сохранять копию элементов, отфильтрованных одним конкретным способом.
  2. Те же данные могут использоваться в разных компонентах, каждый из которых использует другую функцию выбора для фильтрации.
  3. Вы можете комбинировать селектор, применяя множество вычислений данных, используя селектор, который у вас уже есть в приложении.
  4. Если вы поступите правильно, ваши селекторы будут чистыми функциями, тогда вы можете легко их протестировать.
  5. Используйте тот же селектор во многих компонентах.