Как избежать цепей действия

Question

Я пытаюсь понять шаблон потока.

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

В Flux есть специфические для домена магазины, инкапсулирующие данные и логику домена. Возможно, они могут быть повторно использованы в другом приложении для того же домена.

Я предполагаю, что также должны быть приложения, в которых хранятся состояние приложения и логика. Это клей.

Теперь я пытаюсь применить это к воображаемой "GPS Tracker" приложение:

...

Когда пользователь нажимает кнопку [Stop Tracking], соответствующий ViewController поднимает STOP_CLICK.

• AppState.on(STOP_CLICK):

  • dispatch(STOP_GEOLOCATION)
  • dispatch(STOP_TRACKING)

• GeolocationService.on(STOP_GEOLOCATION):

  • stopGPS(); this.on = false; emit('change')

• TrackStore.on(STOP_TRACKING):

  • saveTrack(); calcStatistics(); this.tracking = false; emit('change')
  • dispatch(START_UPLOAD)

Итак, у меня есть снежный ком событий.

Говорят, что в Flux одно действие не должно поднимать другого. Но я не понимаю, как это можно сделать.

Я думаю, что действия пользователя не могут перейти непосредственно в магазины домена, поскольку они должны быть UI-агностиками. Скорее AppState (или везде, где работает логика приложения) должен переводить действия пользователя в действия домена.

1. Как переделать этот поток Flux?
2. Куда должна следовать логика приложения?
3. Правильно ли пытаться сохранить магазины домена независимо от логики приложения?
4. Где находится место для «услуг»?

спасибо.

Answer 1

Вся логика приложения должна храниться в магазинах. Они решают, как они должны реагировать на конкретное действие, если вообще.

В магазинах нет сеттеров. Единственный путь в магазины - через отправленное действие, через обратный вызов магазина, зарегистрированного в диспетчере.

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

Это выглядит очень похоже сеттер -thinking мне:

отправка (STOP_GEOLOCATION)

диспетчерская (STOP_TRACKING)

Вместо этого отправьте сообщение о том, что на самом деле произошло: STOP_TRACKING_BUTTON_CLICKED (или TRACKING_STOPPED, если вы хотите быть агностиком UI). А потом пусть магазины выясняют, что с этим делать. Все магазины получат это действие, и все они могут ответить на него, если это необходимо. Код, который вы отвечаете на два разных действия, должен отвечать на одно и то же действие.

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