Флюс без действий и диспетчера?

Question

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

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

Для приложения чата:

{
   unreadMessages: 0,
   messages: [{
      from: myUser,
      to: toUser,
      text: "hi"
   }, ...],
   hasUnreadMsgs: () => { unreadMessages !== 0 },
   newMsg: (fromUser, toUser) => {unreadMessages++; -and insert msg-},
   getMsgs: () => messages,
   subscribe: (callback) => {...}
}

Единственный недостаток, который я вижу - этот объект может стать слишком большим. Чтобы решить эту проблему, мы можем легко разделить хранилище на несколько объектов, а затем присвоить их обратно с помощью Object.assign(). Например, у нас может быть UserStore и MessagesStore отдельно, а затем объединить их перед инициализацией нашего хранилища.

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

Но, насколько я понимаю, у Redux есть один магазин, и один магазин работает хорошо. Так почему бы нам не избавиться от действий и диспетчера и просто использовать этот магазин для небольшого / среднего проекта?

Answer 1

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

Приложения Flux состоят из трех основных частей: диспетчер, хранилища и представления (компоненты React).

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

Примечание: иногда нам нужно общаться между компонентами, не имеющими общего родителя. Для таких сценариев мы должны использовать диспетчер или использовать небольшую библиотеку pub-sub.

Простейшая реализация pub / sub может быть такой:

var Notifier = (function() {
  var callbacks = {};
  return {
    subscribe: function(name, cb) {
      callbacks[name] || (callbacks[name] = []);
      callbacks[name].push(cb);
    },
    notify: function(name, data) {
      if (!callbacks[name]) {
        return;
      }
      callbacks[name].forEach(function(cb) {
        cb(data);
      });
    },
    unsubscribe: function(name) {
      if (!callbacks[name]) {
        return;
      }
      delete callbacks[name];
    }
  }
})();

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

Кроме того, большое количество людей приняли потоки и редуксы, и если вы используете их, вы получите отличную экосистему (плагины / расширения основаны на этой архитектуре).

Наконец все сводится к личному выбору.

Answer 2

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

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

Может быть, что-то вроде MobX может лучше соответствовать вашему стилю программирования? Это похоже на то, что вы описываете, но у него есть способ обнаружить то, что изменилось, и уведомить все заинтересованные стороны.