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

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

Вот оно; Главное в флюсе, на мой взгляд, это:

Мы можем пометить любой фрагмент кода во внешнем приложении, основанном на потоках, одной из следующих 3 меток:

  • Данные (хранения, действия, создатели действий, редукторы и т. д.)
  • Обработчики событий (созданные пользователем или другими агентами)
  • Потребители данных (представления, саги и другие агенты)

От обработчиков событий к хранилищу(ам)

Внешние агенты запускают обработчики событий в наших приложениях. Мы запускаем бизнес-логику в этих обработчиках (либо полностью в нашем приложении, либо делегируя другим внешним агентам) и отображаем какой-то результат на экране. Процесс повторяется снова и снова. Основным внешним агентом является Пользователь.

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

Аналогичным образом мы можем проверить запрос на выборку, сделанный браузером. API-сервер, который обрабатывает запрос, также представляет собой объект с черным ящиком, внешний агент, который будет что-то делать сам по себе, без нашего ведома, как он это сделал. Мы получаем ответ так же, как и от пользователя, через обработчик событий.

Несколько примеров событий, которые генерируются внешними агентами:

  • Пользовательские события мыши и клавиатуры, изменение размера и ориентации браузера
  • События состояния Ajax и получение сообщений сокета

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

Да, браузер является фактическим привратником, который выполняет всю работу между кодом приложения и другими приложениями/объектами, но, поскольку его поведение всегда одинаково, мы можем рассматривать его как среду выполнения, а не единственную. внешний агент.

От магазина (ов) к потребителям данных

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

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

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

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

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

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

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

Магазины — это точки останова в потоке

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

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

Аналогичным образом мы можем протестировать технические объекты и убедиться, что они отправляют правильный тип действий в зависимости от того, что они делают — например, изменение размера окна, изменение ориентации, фокусирование поля ввода, сбой запроса ajax и т. д.

Вывод

Мышление в Flux упростило мои представления о сложных приложениях. Он уложил все в эти 3 категории (данные, вещи, которые изменяют данные, вещи, которые используют данные) и значительно упростил модульное тестирование.

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