КонтекстКак/где внедрить коммуникацию сервера в рабочий процесс Flux?
Мы строим поток на основе веб-приложение, где клиент (Flux/React/машинопись) взаимодействует с сервером (C#) через WebSockets (не через HTTP GET).
Когда выполняется действие на стороне клиента, мы отправляем запрос команды серверу через соединение с веб-сокетом.
Сервер всегда реагирует быстро с первым ответом Start (указывая, может ли он выполнить запрошенное действие), а затем отвечает на 1 или более ответов на процесс (может быть несколько сотен ответов, которые содержат информацию о ходе выполнения действие). Когда действие на сервере будет завершено, последний ответ Progress будет иметь долю прогресса 100% и статус ошибки «ОК».
Обратите внимание, что некоторые действия сервера могут занимать всего 100 мс, но другие могут занимать до 10 минут (следовательно, ответы о ходе работы, поэтому клиент может показать что-то о действии для пользователя).
В клиенте, мы имеем:
- функция sendCommandRequest, которую мы называем отправить запрос команды на сервер через WebSocket
- функцию обработчика handleCommandResponse (который вызывается в WebSocket OnMessage обратного вызова)
Вопрос, который у нас есть, - это лучший способ вставить серверную связь в приложение на основе Flux? Где мы должны посылать вызовы на websocket и как мы должны перейти от обратного вызова веб-памяти обратно в цепочку Flux?
Предложение
Допустим, мы изменяем параметр визуальных эффектов в графическом интерфейсе клиента (число с плавающей точкой, установите в поле текстовое поле), и это вызывает действие на сервере, который генерирует новое изображение. Это действие занимает 1 секунду для выполнения на сервере.
Теперь, как это происходит, обработчик GUI отправит на диспетчер действие Flux, которое вызывает обратные вызовы зарегистрированных в нем магазинов, а затем хранилища обновляют свои данные на основе полезной нагрузки действия, и запускать различные компоненты посредством обратных вызовов событий изменения, которые используют setState с новыми данными хранилища для запуска повторной обработки.
Мы можем позволить магазинам отправлять командные запросы через websocket на сервер в момент их изменения (например, новое значение параметра). В этот момент у магазина будет новое значение параметра, тогда как изображение остается последним полученным изображением (результат предыдущей команды).
С этого момента сервер начинает отсылать ответы о ходе работы клиенту, которые поступают в обратный вызов websocket onMessage, а окончательный ответ Progress будет содержать новое изображение (через 2 секунды).
В обратном вызове websocket onMessage мы можем отправить второе диспетчерское действие Flux с передачей загруженного нового изображения, и это заставит магазины обновлять свои данные новым изображением, что вызовет прослушивание компоненты для повторной обработки.
Проблема с этим:
- флюса магазин может частично обновленные данные: пока сервер не посылает назад конечный результат, магазин будет иметь новый параметр, но до сих пор старый image
- Нам нужно 2 действия с потоком: один используется графическим интерфейсом, чтобы сигнализировать пользователю о внесении изменений, а один используется обратным вызовом веб-сокета, чтобы сообщить, что какой-то результат получен
- если что-то пошло не так на стороне сервера, новый параметр уже установлен в хранилище Flux, в то время как мы никогда не получим новое изображение, поэтому данные в хранилище будут приходит поврежденным
Есть ли лучшие способы вписаться в связь с сервером в поточном потоке? Любые советы/рекомендации?
Спасибо за содержательный ответ! Я перевариваю это и посмотрю, что применимо к моему прецеденту. –