Почему Redux так популярен?

Question

[Максим Золотой]

Долго уже работаю с проектом на React + Mobx и тут решил для общего развития посмотреть Redux потому что он часто в вакансиях мелькает. Начал смотреть и понял что по сравнению с Mobx это просто какое то адское днище, очень много телодвижений, условий и кода что бы работать с состоянием. Почему вообще его используют так много?

Comments

[Вадим Иванов]

Посмотрите на Effector

Answer 1

[camelCaseVlad]

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

Для меня редакс родная гавань, но это приходит со временем, как и во всем.

Однако сейчас много тракции получают Стейт Машины, хотя концепт и не новый.

Если и учить что то новое, я бы советовал учить их. Вот реактовский рецепт.

Comments

[Максим Золотой]

Да, как раз собирался разобраться с хуками. Это тоже спрашивают на собеседованиях. Просто Mobx кажется настолько удобным по сравнению с Redux что даже время тратить на его узучение не хочется без особой на то необходимости

[camelCaseVlad]

Плохо ссылка встала, проскрольте по ссылке вверх Максим Золотой

Answer 2

[Алексей Николаев]

1. Очень прост (кто бы что ни говорил, его концепция очень понятна и близка к стандартной концепции самого Реакта, Flux)
2. Саги (киллер-фича, мобх не может предложить такой мощи)

Answer 3

[AlexCraft]

Коллега прав, потому что Redux стал стандартом, хорошо документирован, популярен. Но мы используем Context API на новых проектах.

Comments

[Дмитрий Свиридов]

В случае Redux всякие сайд-эффекты типа запросов к API делаются в экшенах. А где при использовании Context API их правильно делать?

[Sergiu Mitu]

Дмитрий Свиридов, Вообщето "В случае Redux всякие сайд-эффекты типа запросов к API" НЕ "делаются в экшенах." Для них используется middleware.

[Дмитрий Свиридов]

Sergiu Mitu, окей, спасибо, но вопрос остается в силе)

[Sergiu Mitu]

Дмитрий Свиридов, это как раз одна из причин почему люди выбирают redux, все есть из коробки и не надо изобретать свои костыли. Однозначного ответа на ваш вопрос нет так как реализации бывают разные, одна из них, каждый делает по своему, у каждого свой костыль. А редакс это стандарт, любой после вас разберется в коде за пару минут. Возможно AlexCraft поделится своим решением.

[AlexCraft]

Решение очень похожее на предложенное Sergiu Mitu, за исключением того, что для передачи состояния оборачивается не весь App, а только отдельные Rout-ы в routes.js. Создаем state, reducers, context для отдельных частей проекта (Articles, Documents, например) и через отдельные роуты передаем State (контекст и редьюсеры тоже работают через State).

Вот такой примерно получается файл routes.js:

// тут импорты всего нужного - React, Switch, Route
// + импорты компонентов для маршрутов
// + импорт State-ов для разных частей нашего проекта (в нашем конкретном случае это ArticlesState)

// дальше нам понадобится вот такой примерно массив (он может понадобиться не только здесь, 
// поэтому экспортируем его)

export const routes = [
  {
    path: '/articles',
    Component: Articles,
    name: 'Статьи',
    exact: true
  },
  //... и т.д.
]

// при помощи метода .map генерируем маршруты:

const Routes = () => {
  return (
    <Switch>
      {routes.map(({ path, Component, exact }, key) => (
        <Route
          path={path}
          key={key}
          exact={exact}
          render={props => {

            /* тут могут передаваться разные полезные штуки */

            /* возвращаем компонент, и если надо - передаем ему состояние, и всё, */
            /* больше никаких оберток не надо, ни в App.js, ни внутри компонентов */

            return Component === Articles || Component === Article ? (
              <ArticlesState>
                <Component {...props} />
              </ArticlesState>
            ) : (
              <Component {...props} />
            )
          }}
        />
      ))}
    </Switch>
  )
}
export default Routes

На первый взгляд похоже на костыль, но, друзья мои, Context API - это не костыль, это очень мощное решение, оно будет развиваться и поддерживаться в дальнейшем. Основной профит от этого всего то, что мы применяем функциональный подход к разработке, что в свою очередь позволяет на полную мощь юзать React Hooks. О преимуществах функционального подхода и React Hooks почитайте в документации React ). Конечно же, основное - это устранение "ада оберток" и очень удобная и понятная архитектура проекта. P.S.: надеюсь, что это кому-то из вас поможет и, может быть, будет полезным.

[AlexCraft]

Предвижу вопрос про 'отдельные части проекта' - можно (и нужно) использовать и глобальный стейт, для этого создайте в папочке context соответствующий раздел App и туда выносите всё что будет работать для всего приложения (isLoading, error и т.д.). Ну и вот как раз этот стейт придется передавать в App.js и оборачивать там. Но это одна обёрточка, и она особо не замусорит там ничего.

Answer 4

[Mikhail Osher]

"Адское днище" сразу видно уровень. Не разобрались в библиотеке, и сразу её дискриминируете.

- есть redux toolkit
- есть очень гибкая модель сайд-эффектов через middleware
- есть DI через thunks
- вагон проектов уже написаны на redux (справедливости ради, 90% проектов можно на чистом реакте писать), следовательно, в работе нужно знать его и уметь работать с ним

Популярен он стал за счёт своего простого и расширяемого API, а также, за счёт того, что на момент его создания из альтернатив был только flux. Вот и пихают куда попало его.

Answer 5

[Дмитрий Беляев]

Он просто оказался первым подобным решением которое распиарили. И это реально решает.
Просто у много кого уже есть проекты на нем написанные, это все надо поддерживать - вот и количество вакансий.
А еще у многих, особенно у менагеров, есть стереотипы вроде "если за этим большая корпорация, то это будут поддерживать вечно" и "чем древнее инструмент - тем он стабильнее и надежнее".

И да mobx удобнее и функциональнее. Просто по тому, что не может быть полезной библиотека на несколько килобайт, весь функционал которой пишется любым +/- способным разработчиком в максимум 50 строк кода. Хотя +/- способных разработчиков в веб-разработке очень мало, на фоне макак способных лишь приворачивать еще одну библиотеку к единственному фреймворку.