問題タブ [rxjs]

次のコードが非同期で実行されることを期待します。

しかし、そうではありません。大きな範囲の数値を処理するにはしばらく時間がかかり、完了したときにのみ実行が再開されます。ここでコードを試すことができます。

RxJS が同期的または非同期的に動作する時期について、私は混乱しています。使用方法に依存しますか？私の以前の考えは、Observables/Observer の世界に入ると、Promise の仕組みと同様に、その中のすべてが非同期で実行されるというものでした。

rx ガイドラインでは、可能な場合は副作用を回避し、避けられない場合は do() (js では doAction) 句に入れます。

ただし、UI の非常に一般的な副作用は、(子ウィジェットによって) ダウンストリームで参照されるリソース (<div> など) を作成することです。これらのリソースを渡すことができるように、これらのリソースのハンドルを取得する必要があります。たとえば、それぞれに div が必要なデータの配列がある場合、それぞれに div を作成し、これらの div のハンドルを子に渡します。

ただし、doAction() は副作用の戻り値を破棄するため、作成されたオブジェクトのハンドルを取得できません。select() で副作用を実行する必要があります。

私はこれをすべて間違って見ていますか？作成されるリソースは状態であり、副作用があります。ストリームに状態が必要ですが、禁忌である select() に副作用を入れずにストリームに入れることはできません。

特定の時間までに Observable の値を生成する最も慣用的な方法は何でしょうか? たとえば、大きな配列から作成された Observable があり、2 秒ごとに値を生成したいとします。intervalとの組み合わせがselectMany最善の方法ですか?

配列を保持するストリームがあり、その各要素には ID があります。これを ID ごとにストリームに分割する必要があります。これは、ソース ストリームが ID を保持しなくなったときに完了します。

たとえば、これらの 3 つの値を持つ入力ストリーム シーケンス

3 つのストリームを返す必要があります

id がなくなったので a は 3 番目の値で完了し、id が現れたので c は 2 番目の値で作成されました。

私はgroupByUntilを試していますが、少し似ています

そのため、ID でグループ化し、入力ストリームに ID がなくなったらグループを破棄します。これは機能しているように見えますが、入力の 2 つの使用法は私には奇妙に見えます。たとえば、単一のストリームを使用して groupByUntil の入力とグループの破棄を制御すると、奇妙な順序の依存関係が生じる可能性があります。

より良い方法はありますか？

アップデート

実際、ここには奇妙なタイミングの問題があります。fromArray はデフォルトで currentThread スケジューラを使用します。これにより、その配列からのイベントが入力からのイベントとインターリーブされます。グループの破棄条件は、間違った時点で (前の入力からのグループが処理される前に) 評価されます。

考えられる回避策は、fromArray(.., rx.Scheduler.immediate) を実行することです。これにより、グループ化されたイベントが入力と同期されます。

rxjsアプリをどのように構築しますか? 約 100 のおもちゃのイントロの例がありますが、アプリケーション全体のデータ フローを示す、ウィジェット、サブウィジェットなどを含む完全なアプリの例は 1 つもありません。

たとえば、ある状態のオブザーバブルがあるとします。ウィジェットに渡す必要があります。そのウィジェットには、その状態の一部を必要とするサブウィジェットがあります。購読はしていますか？

「ウィジェット」はモナドの外にあります。サブウィジェットは状態に対して監視可能なメソッドを使用できません。副作用としてウィジェットを実行すると、同じ問題が発生します。

それで、ストリームをウィジェットに渡しますか？もしそうなら、あなたは何を返しますか？

ウィジェットは状態にサブスクライブし、使い捨てを返しますか? 状態から派生したストリームを返しますか? もしそうなら、何が入っていますか？すべてのウィジェット/サブウィジェット/サブサブウィジェットからすべてのストリームをまとめて収集し、selectMany(identity) を多用して、サブスクライブする最終的なアプリケーション ストリームを取得して、すべてを開始しようとしますか?

また、ウィジェットが状態に基づいてオンデマンドでサブウィジェットを作成する場合、ウィジェットはそのサブウィジェットをどのように管理するのでしょうか? サブウィジェットごとにグループを持つ groupBy() を使用して解決策を試し続けていますが、ネストされたオブザーバブルからすべてのサブスクリプションまたはストリームを管理することは、信じられないほどの悪夢です。

アプリケーション全体の 1 つの例でも役に立ちます。

rxjs コードを構造化する方法 のフォローアップ、rx を使用するときにサブウィジェットを使用してウィジェットを構造化する方法について、サブウィジェットがデータ駆動型である rx コードをどのように構造化しますか?

おもちゃの問題として、値、高値、安値などを含む、監視する株式のリストをストリーミングする外部ソース (Web サービスなど) があるとします。つまり、次のような Observable ストリームがあるとします (時間は経過します):

銘柄ごとにウィジェットを作成する必要があります。したがって、前の質問のパターンを変更する必要があります。子は 1 つではなく、入力ストリームに基づいて子が作成/破棄されます。たとえば、最初のイベントで「csco」の子を作成します。2 番目のイベントで、「csco」の子が更新され (低: 8)、「aapl」の子が作成されます。

サブウィジェットの作成をサブスクライブに移動できます。

これにより、順序付けの問題が発生します。子は、それを作成する原因となったイベントを取得しません。state.repeat(1)、またはのようなことを行うことでこれを回避できますstate.startsWith(s).select(...)が、少し奇妙に見えます。

子もストリームを返しているとします。たとえば、ユーザーが子を操作してさまざまな位置をモデル化する可​​能性があるため、子から計算を取得して、全体の合計またはその他のメトリックをウィジェットに表示する必要があります。

widget() でサブジェクトを作成し、子からのストリームをプッシュしますか? お気に入り

これはすべてかなり不格好に思えます。それを整理するためのより良い方法はありますか？子ごとに 1 つのストリームのストリームとしてモデル化し、出力をマージしてみました。これはうまくいきませんでした。内部サブスクリプションを追跡したり、子から複数のストリームを出力したりするのは困難でした。

Reactive Extensions for Javascript (RX-JS) を使用して、ここに投稿しているのと同じ効果を達成しようとしています。私はそれを行う方法について少し戸惑っています。ここにページがあります：

mouseDown、mouseMove、および mouseUp イベントのオブザーバブルを作成する必要があると思います。

しかし、それらを組み合わせる方法がわかりません。マウスダウンの観察を開始し、マウスアップが発生するまですべての動きを収集し、その間に、開始点からマウス移動中にマウスがある現在の点までの線を再描画する必要があると思います。あなたはなにか考えはありますか？どうもありがとう。

°°°°°°°°°°°°°°°°°°°°°EDIT°°°°°°°°°°°°°°°°°°°°°°°°° °°°°°°°°°

Brandonによる回答の後の私のコードは次のとおりです。

他の「FRP」ライブラリとは異なり、Rx はグリッチ (時間の不一致データで呼び出されるコールバック) を防止しません。これを回避する良い方法はありますか？

例として、単一のストリームから派生した一連の高価な計算があるとします (たとえば、以下の _.identity の代わりに、並べ替えまたは ajax フェッチを行います)。高価なものの再計算を避けるために、distinctUntilChanged を実行します。

2 番目のイベントは、多数のグリッチ状態を引き起こすことになります。1 つではなく 3 つのイベントが発生するため、大量の CPU が浪費され、不一致のデータを明示的に回避する必要があります。

この特定の例は、distinctUntilChanged を削除し、入力が変更されていない場合に前の結果を通過するように不安定な scan() 関数を作成することで回避できます。次に、combineLatest を使用する代わりに、結果を圧縮できます。不器用ですが、実行可能です。

ただし、どこかに ajax 呼び出しなどの非同期性がある場合、zip は機能しません。ajax 呼び出しは同期 (キャッシュされている場合) または非同期で完了するため、zip は使用できません。

編集

より簡単な例で望ましい動作を明確にしようとしています:

a と b の 2 つのストリームがあります。b は a に依存します。b は非同期ですが、ブラウザはそれをキャッシュする可能性があるため、a とは独立して更新することも、a と同時に更新することもできます。したがって、ブラウザ内の特定のイベントによって、次の 3 つのいずれかが発生する可能性があります。b 更新; a と b の両方を更新します。望ましい動作は、コールバック (たとえば、render メソッド) を 3 つのケースすべてで 1 回だけ呼び出すことです。

a または b が単独で発火すると、zip からコールバックが得られないため、zip は機能しません。a と b が同時に起動すると、2 つのコールバックが発生するため、combineLatest は機能しません。