React, Flux, состояние и магазины

• Подход звучит довольно солидно. Я бы создал совершенно разные действия для каждого взаимодействия, например. FruitClicked и FruitDragged могут быть действиями, и магазины будут следить за теми, кто им небезразличен.
• AppView должен прослушивать все хранилища, из которых он получает данные. Если вы вызываете setState более одного раза за один и тот же тик, React интеллектуально объединит их, так что на самом деле вы не выполняете рендеринг более одного раза.

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

  _onDestroyClick: function() { 
    TodoActions.destroy(this.props.todo.id); 
  } 
  

• #P2#

  #P3#

  #P4#

  #P5#

• Если вас интересует архитектура Flux, вас может заинтересовать Fluxxor (отказ от ответственности: это написал я), который ( надеюсь) помогает создать приложение на основе потока. У него есть диспетчер, который немного более надежен, и несколько других изменений (например, неглобальные хранилища/действия, примеси React), которые во многих случаях немного упрощают работу.

Трудно сказать, хорош ли подход, не разобравшись в приложении.

Однако мне кажется, что щелчок по фрукту должен обрабатываться FruitStore. То есть плод приобрел активное состояние, стал перетаскиваемым. Если это каким-то образом повлияет на приложение в целом, то, возможно, это вызовет изменение и в AppStateStore. Точно так же перемещение фруктов из одной корзины в другую похоже на домен BasketStore.

Я представляю, как FruitStore содержит частную структуру данных, подобную этой:

var _fruit = {
  1234: {
    id: '1234',
    type: 'apple',
    active: false
  },
  2345: {
    id: '2345',
    type: 'orange',
    active: false
  },
  3456: {
    id: '3456',
    type: 'apple',
    active: false
  }
};

и я представляю себе BasketStore с частной структурой данных, которая выглядит так:

var _baskets = {
  4321: {
    id: '4321',
    name: 'Josephine\'s Basket',
    fruitIDs: [
      1234,
      2345
    ]
  },
  5432: {
    id: '5432',
    name: 'Harold\'s Basket',
    fruitIDs: [
      3456
    ]
  }
};

Таким образом, фруктовое «активное» состояние управляется FruitStore, а содержимое корзин управляется BasketStore.

Таким образом, AppView может прослушивать оба хранилища, если это хорошо работает для вашего приложения. И, как упоминалось выше, повторный вызов метода render() требует очень мало затрат. Это не затрагивает DOM при каждом вызове — это одна из самых сильных сторон React. Вместо этого React будет разумно группировать вызовы и обновлять только «грязные» части DOM, если они существуют.

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

Чтобы ответить на ваш последний вопрос:

Есть ли более полный пример архитектуры Flux или что-то подобное?

Инженеры Facebook сейчас работают над более сложным примером приложения, в котором будет продемонстрировано использование функции waitFor() и постоянного хранилища на стороне сервера. Мы надеемся выпустить это в ближайшее время.