Githubを使ってデスクトップアプリを構築しようとしています 電子フレームワークこれは、「メイン」io.jsプロセスと「レンダリング」JSプロセス（BrowserWindow）を分離します。 "メイン" / "レンダラー"プロセスはサーバーとクライアントに似ていると思います（これが間違っていたら教えてください）。
この状況でFluxパターンをどのように適用するかについて混乱しています。UIとのやりとりの中には、メインプロセスにデータを送信する必要がないものもあります。 TODOリストの例 ）
1）それはDispatcherオブジェクトがするべきことを意味しますかレンダラープロセスと共存しますか。 2）メインプロセスがファイルシステムから入ってくるイベント/アクションを受信したとします。ディスパッチャを更新するには、メインプロセスでActionCreatorを実装してアクションを作成し、次にIPC / RPC経由でActionをレンダラ/クライアントプロセスのディスパッチャに送信する必要がありますか。 3）（2）が当てはまる場合、それはアクションクリエイターとストアもメイン/サーバー側で実装されているということですか？
レンダラープロセスのコンテキスト内で "First Responder" / "Delegate"があるのは不思議に感じます。
回答：
回答№1は0ああ、もう少し読んで私はそれを把握するのに役立ちました。 Fluxは主にクライアントサイドのアプリケーションパターンを意図していました。
次の図は、一般的な使用例、およびサーバーとその関連状態がクライアント側のFluxロジックからどのように切り離されているかを示しています。
言い換えれば、クライアント上のフラックスは解決しませんweb-api側で状態とコンポーネントを管理する問題。サーバー側のコードと密接に関連しているクライアント側のアプリケーション（Electronアプリケーション、iPythonノートブック、NW.jsアプリケーションなど）の場合は、UIスレッドではなくCocoaの委任パターンに似たディスパッチャを実装するのが合理的かもしれません。