Будет ли использование селекторов для вычисления производных данных от вызова API работать лучше, чем в редукторе? (для этого варианта использования) - PullRequest
0 голосов
/ 01 марта 2020

Скажем, у меня есть музыкальное приложение c, где пользователь ищет гитары. При начальной загрузке страницы я получаю несколько разновидностей гитар для отображения: (acousti c, electri c и бас). Страницы гитарных результатов возвращаются вместе из одного вызова API, но никогда не будут отображаться вместе. Следовательно, они должны быть отфильтрованы в какой-то момент. Чтобы просмотреть разные категории гитар, пользователь переключает категорию, которую он просматривает, из компонента реагирования.

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

В Стратегия 1, я фильтрую данные по категории, когда они поступают, и сохраняю их отдельно в хранилище редуксов. Когда я хочу получить данные, я указываю категорию в селекторе.

В Стратегии 2 все входящие данные API хранятся в сводном списке «все». Когда я хочу получить определенную категорию гитар, я использовал селектор для фильтрации и отображения агрегированных данных.

СТРАТЕГИЯ 1:

// REDUCER
export const GuitarReducer = (state, action) => {
    const { payload, type } = state; 

    switch (type) {
        case "acoustic": {
            let existing = // GET EXISTING
            return state.set("acoustic",
                existing.concat(payload.filter(result => (result.category === "acoustic")))
            )
        }
        case "electric": {
            let existing = // GET EXISTING
            return state.set("electric",
                existing.concat(payload.filter(result => (result.category === "electric")))
            )    
        }
        case "bass": {
            let existing = // GET EXISTING
            return state.set("bass",
                existing.concat(payload.filter(result => (result.category === "bass")))
            )
        }
    }
}

// SELECTOR
export const selectCategory = createSelector(
    [getCategory, getGuitarReducer],
    (category, guitarReducer) => {
        return GuitarReducer.get(category);
    }
);

СТРАТЕГИЯ 2:

// REDUCER
export const GuitarReducer = (state, action) => {
    const { payload, type } = state;
    ...
    let existing = // GET EXISTING
    ...
    return state.set("all",
        existing.concat(payload)
    )
}

// SELECTOR
export const selectCategory = createSelector(
    [selectAllGuitars],
    (category, guitars) => {
        return guitars.filter(guitar => (guitar.category = category));
    }
);

Будет ли один шаблон давать лучшую производительность, чем другой? Какой шаблон лучше следует передовой практике для редукса?

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

1 Ответ

1 голос
/ 01 марта 2020

Я думаю, selectors в основном сфокусирован на том, чтобы не пересчитывать производные данные в ваших компонентах (и на преимуществах повторного их использования в других компонентах).

Оба в вашем примере - хорошие практики, поэтому я бы перефразировал это следующим образом. Хотите, чтобы ваше хранилище данных выглядело как в первом или втором варианте (оригинальный ответ API). Вы хотите, чтобы он лениво загружался (вариант два) или загружал категории для всех гитар.

Выбор 1

Плюсы

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

Минусы

  • Нет доступа к исходному ответу API.
  • Выполняет фильтрацию и категоризацию по запросу API, а не лениво (Честно говоря, не большая проблема).

Выбор 2

За *

  • Повторное вычисление при изменении категории. (Примечание. reselect имеет размер кеша только 1).
  • Для запоминания также требуется дополнительная память.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...