Search
Write a publication
Pull to refresh

Comments 10

В простом приложении Redux не нужен. В сложном же приложении он неудобен.

Не могли бы вы подсказать альтернативу.
Я как раз ищу что-то удобное, и есть подозрения, что приложение разрастётся.

Не могли бы вы подсказать альтернативу

MobX разумеется, в 2017 году уже это было очевидно.

Причем это не просто альтернатива, это единственное решение из всех что есть, для связки с React'om где у вас не будет кровь из глаз идти, где вы будете писать минимально возможно кол-во кода и т.д. и т.п. И MobX нужно использовать и как глобальное состояние и как локальное(у компонента).

Спойлер:

interface IMyComponentProps {
  color: 'black' | 'white';
  count: number;
}

export const MyComponent = observer((props: IMyComponentProps) => {
    const [state] = useState(() => new MyComponentLocalStae(props));
    state.props = props;
    
    return <div onClick={state.incr}>Hello world ${state.counter}</div>
});

class MyComponentLocalStae {
  counter = 1;
  
  constructor() {
    makeAutoObservable(this);
  }

  incr = () => {
    this.counter++;
  }
}

К сожалению, state.props = props; очень не понравится mobx, если в MyComponentLocalState будет зависимость от этих пропов или геттеры - скажет, что синхронно менять значения при рендере нельзя. Поэтому придется использовать useEffect

Не делал ни когда computed'ы зависящие от props'ов, но да и правда warning вылезает в консоли, правда только один раз и в при этом ничего не сломалось, но в целом да, чтобы этого избежать можно это в useEffect поместить. Спасибо что осветили данный нюанс.

Проверочный стэнд:
https://stackblitz.com/edit/vitejs-vite-fxmdw8?file=src%2Fpages%2Fmain%2Findex.tsx&terminal=dev

А с конфигом с автобатчингом этого эффекта нет:
https://stackblitz.com/edit/vitejs-vite-dnuzdw?file=src%2FmobxConfig.ts&terminal=dev

Спасибо за статью. Вы не подскажите, если мне нужно поднять два экземпляра сложной логики, стейт которой хранится в редаксе, то как я могу это сделать?

addToCart: (state, action) => {
  const product = action.payload;
  const existingItem = state.items.find((item) => item.id === product.id);

  if (existingItem) {
    existingItem.quantity += 1;
  } else {
    state.items.push({ ...product, quantity: 1 });
  }

  state.totalItems += 1;
  state.totalPrice += product.price;
},

1) Тут же явное дублирование информации - ручная синхронизация totalItems и totalPrice и как следствие возможные баги. Если сделать totalItems / totalPrice селекторами (или computed в терминологии Mobx), то не нужно будет при добавлении / удалении из корзины вручную синхронизировать. Must have для сложных приложений, где содержимое корзины может поменяться из 5-10 разных мест.

2) Классно что благодаря Immer код стал более читабельный. Это позволяет писать

quizz.questions[0].answers.push(newAnswer)

вместо

const newState = {
  ...quizz,
  questions: quizz.questions.map((question, index) =>
    index === 0
      ? {
          ...question,
          answers: [...question.answers, newAnswer],
        }
      : question
  ),
};

Другое дело, что на Mobx люди так пишут лет 8 уже. Может проще сразу на Mobx?

Redux идеален, если у вас сложное приложение с кучей состояний

3) Как раз таки в сложном большом приложении Redux создаёт проблемы. Представьте админку на 100 страниц. Централизованный стор означает, что код бизнес-логики для всех страниц инициализируется сразу. Из коробки нет возможности сделать ленивое создание сторов под страницы. Я бывал на проектах, где разработчики пытались изворачиваться и делали Redux стор с динамическими ключами, чтобы не держать 100 ключей в глобальном сторе. Работало это плохо, и были проблемы с типизацией. У модульных сторов этой проблемы нет.




Redux идеален, если у вас сложное приложение с кучей состояний

Как бы всё ровно наоборот, вам так не кажется? Зачем людей в заблуждение вводить?

Есть такая штука, с которой у вас вообще не будет проблем от слова со всем, как в громадных приложениях, так и в мелких, начинается на M, заканчивается на X .Есть догадки?)

Я согласен, что MobX более удобен для больших приложений, однако, даже там, если начать перегружать store, могут возникнуть проблемы. Для Redux слишком много действий, на мой взгляд, а если не хочется использовать context для маленьких приложений, я бы выбрал что-то вроде Zustand.

Sign up to leave a comment.