Yustas Alexu

Если кратко и максимально просто:
Состояние:
Redux это один большой javascript-объект с полями, которые представляют собой стейт - состояние (initial state - начальное состояние), которое может меняться. Эти поля (состояния) запрещено обновлять напрямую.
Редюсеры:
Обновляется состояние с помощью функций которые называются редьюсерами. Это обычные функции, отличие только в том, что они должны быть чистыми. Задача редюсера принять на вход старый стейт и отдать на выход новый стейт (часть стейта). Редьюсер обычно создается под каждое новое поле в стейте.
Таким образом, когда нужно обновить стейт, вызывается редюсер.
Функция dispatch:
Но редюсер тоже вызывается не напрямую, а через функцию dispatch. Функция dispatch вызывается и в нее передается объект называемый экшеном (action).
Экшен:
Action это обычный js-объект, у которого должно быть поле type с типом экшена и другие поля с какими-нибудь данными (обычно поле data).
Этот экшен-объект передается от dispatch в редьюсер. Как редьюсер будет вычислять новое состояние зависит от разработчика. Но обычно редюсер просто смотрит на тип экшена и на его основе и на основе входных данных возвращает новое состояние.

Сам компонент обновляется путем обертывания его в функцию connect. Функция connect пробрасывает нужные поля из стейта в компонент в виде props (mapStateToProps).

Стратегия такая, отдавать предпочтение локальному стейту. Могу сказать по своему опыту, в большинстве случаев глобальный стейт не нужен. Типичный случай когда используют глобальный стейт это авторизация.

О чём он? Как хуки позволяют это сделать?

Полагаю, что Дэн имеет в виду кастомные хуки, которые можно выносить в отдельные файлы вместе с логикой, оставляя в компоненте только простую логику.

Делите ли вы свои компоненты на глупые и умные?

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

Отдельные объекты обычно получают по его id отдельным запросом на сервер. Почему?

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

Кроме того, в настоящем приложении страница с одним объектом должна работать независимо от того, заходил ли пользователь до этого на страницу списка или нет. То есть каждая страница должна получать все нужные данные независимо от других страниц.

export default function Reducer(state = initialState, action) {
  switch (action.type) {
    case RESET_TYPE_ID:
      return {
        ...state,
        filter_models: {
          ...state.filter_models,
          type_id: null
        }
      };

P.S. Но в вашем случае это плохая идея, потому что делать сброс значения на каждый пустой фильтр это не очень эффективно. Как вариант можно полностью переписывать filter_models при каждом изменении фильтра изначально отбрасывая фильтры без значений. В этом может помочь pickBy из lodash:
const filters = _.pickBy(filterSet, _.identity);