Я намагаюся створити настільний додаток за допомогою Github Електронний каркас, який відокремлює "основний" процес io.js від "рендеринга" процесу JS (BrowserWindow). Я думаю, що процеси "main" / "renderer" аналогічні серверу та клієнту (повідомте мене, якщо це помилково).
Мене бентежить питання, як застосувати шаблон Flux у цій ситуації. Деякі взаємодії з інтерфейсом користувача не вимагають надсилання даних до основного процесу (тобто Приклад списку TODO )
1) Чи означає це, що об'єкт Dispatcher повиненпроживати в процесі візуалізації? 2) Припустимо, основний процес отримує вхідну подію / дію від файлової системи. Для оновлення диспетчера, чи повинен би основний процес реалізовувати ActionCreator для створення дії, а потім надсилати Action через IPC / RPC диспетчеру в процесі рендерингу / клієнта? 3) Якщо (2) відповідає істині, чи означає це, що творці дій та сховища також реалізовані на головній стороні / на стороні сервера?
Дивно відчувати наявність "Першого відповідача" / "Делегата" в контексті процесу візуалізації.
Відповіді:
0 для відповіді № 1Ах, ще якесь читання допомогло мені це зрозуміти. Flux мав бути головним чином шаблоном програми на стороні клієнта.
Наступна схема ілюструє типовий випадок використання та те, як сервер та пов'язаний із ним стан дещо від'єднані від логіки потоку на стороні клієнта.
Іншими словами, Потік на клієнта не вирішуєпроблема управління станом та компонентами на стороні web-api. Для програм на стороні клієнта, які тісно пов'язані з кодом на стороні сервера (наприклад, програми Electron, блокнот iPython, програми NW.js), може мати сенс реалізувати диспетчер, схожий на шаблон делегування Cocoa, а не в потоці інтерфейсу користувача.