Knockout: React.jsとの統合

KnockoutとReactはお互いにうまく適合していないようです。

誰かが特定の統合の提案、またはできればサンプルを持っているなら、私たちに知らせてください！

それまでは、整理整頓のためにこれを閉じます。

私はKnockoutとReactを（別々に）使用しており、それぞれの内部を適切に理解しています。 ライブラリレベルでそれらを組み合わせるためにできることは実際には何もありません。 その理由は、KnockoutがDOMを入力として受け取り、それを管理するためです。 一方、Reactは独自のデータ構造を入力として受け取り、DOMを生成します。 これらは互換性のない実装ですが、コードで一緒に使用できないという意味ではありません。

ユーザーの場合、Reactでいくつかのコンポーネントを記述し、bindingHandlerを使用してそれをKnockoutに組み込むなどのことができます。

var render = function(el, value){
    React.renderComponent(el, MyReactComponent({
        data: ko.unwrap(value),
        onChange: function(newValue){
            if (ko.isObservable(value){ value(newValue); }
        }
    }));
}

// ...

init: function(element, valueAccessor){
    render(element, valueAccessor());
},
update: function(element, valueAccessor){
    render(element, valueAccessor());
}

^{3.0でvalueAccessorがどのように機能するかを忘れているので、これはおそらく間違っています}

他の方法でReact内にKnockoutテンプレートを埋め込むのはより困難です（HTML文字列として必要ですが、実行できます）。

また、非常に強力なKnockoutオブザーバブルを使用してReactアプリケーションに電力を供給することもできます。 ここで、ミックスインは、新しい監視可能な値をコンポーネントの状態に自動的に適用するのに意味がある場合があります。 これにより、必要に応じてReactコンポーネントで既存のビューモデルを使用できるようになります。

多くの場合、reactは非常に高速ですが、Knockoutにも同様の最適化がいくつかあるため、パフォーマンスに目立った問題がない限り、通常はコードを書き直す価値はありません。

それは賢い例です@brigand

ReactとKnockoutを統合するというアイデアについてコメントしたいのですが、このスレッドが示唆しているように、それらが正反対であるかどうかはわかりません。 私は今ReactとFluxアーキテクチャを研究していることを念頭に置いてください。しかし、少なくとも一見すると、Reactはビュー以外のものになろうとはせず、少なくとも原則として、リアクティブ関数型プログラミングに基づいているようです。ノックアウトは、pub / subモデルを使用してビューモデルからの変更を伝播するという意味でリアクティブです。

私はKnockoutを大規模なシングルページアプリケーションで約18か月間使用しており、見つけることができるほぼすべての本やブログを読んでいます。 Reactについては、彼らのサイトにあるすべてのドキュメントを読み、見つけた2冊目の​​本を読み進めています（これは新しいパラダイムであり、出版された本の数は技術的な成熟度の良い指標であることが多いため、リソースは少なくなります）現時点では大規模なプロジェクトにReactを適用していないため、この読み物は専門家にはなりませんが、両方のテクノロジーの背後にある基本的なアイデアを理解するのに役立ちます。

これまでのところ、私の見解はこれです：

1）Reactは、ビューであり、ビューのみになりたいと考えています。 関心の分離、階層構成、そしておそらく実用的な意味で最も重要な、高性能/差分DOM更新に優れています。

2）Fluxアーキテクチャでは、アクション、ディスパッチャー、ストア、およびリアクティブコンポーネントの組み合わせが開発プロセスをガイドする必要があります。ストアは最終的なデータ状態であり、アクションはミューテーションイベントをカプセル化し、ディスパッチャーはアクション/ミューテーションルーティングを調整します。

従来のMVPおよびMVVMとの違いは、主に、モデルの変更が常に、ディスパッチされたイベントであるアトミックアクションを介して行われることです。 ロジックをモデル（またはモデルビュー）から分離し、それらを単方向（悪名高い特異なバグを減らすための永遠の探求）および更新ライフサイクルの一部にすることで、これらの変更を単純にゲートします。

私がこれらのアイデアを正しく吸収したと仮定すると、Knockoutオブザーバブルはこの方程式のディスパッチ/ストア部分と非常に一致しており、Knockoutで使用されるテンプレートモデルはどちらのモデルも壊さずにReactビューに置き換えることができます。

実際、FluxディスパッチャーがKnockoutのpub / subモデルに適切にマッピングされ、オブザーバブルがストアにマッピングされると仮定すると（もちろん、パラダイムの競合を回避するためにサブスクリプションをより慎重に管理する必要があります）、最後に、Reactのビューはノックアウト、これらを全体論的に見る方法があると思います。

私はまだ（概念的な）スイートスポットを見つけるために多くの詳細を検討しており、これらのアイデアをこれまでの小さなプロジェクトにのみ適用していますが、これまでのところ、これら2つのテクノロジー（ノックアウトとReact）が対立しているとは考えていません。 それらは多くの同じ概念を共有しており（観察可能なストア、パブ/サブアクション、テンプレート/ビューは適切に使用すればかなりうまくマップされます）、トリックはアーキテクチャの原則を破ることなくそれぞれの強みを活用することだと思います（これはいつものようにです） 、どちらのテクノロジでも強制されないプログラミングの選択）。

ちなみに、私は昨年KnockoutでD3を使用し、D3が増分DOM更新を実行し、用語の入力/終了データで差分データを処理したいという考えに適応する必要がありました。 Knockoutsの更新呼び出しにフックし、基本的にD3にノックアウトテンプレートが通常行う作業を行わせることで、これをそれほど困難なく行うことができました。 これは、それぞれの長所を活用するために使用する場合、どちらのプログラミングモデルにも妥協または中断のようには見えません。 彼らはいつものように、理解することが重要です。

グーグルからこれを見つけた他の人に関連するかもしれません： https ：

@ claudeduguayknockout.jsでいくつかのプロジェクトをプレイした後、react.jsを使い始めたときに頭に浮かんだアイデアについて、非常によく
ノックアウトがオブザーバブルの変更に対するDOM更新をどのように最適化するかは正確にはわかりませんが、そこではかなり巧妙な作業が行われていると思います（これは素晴らしいライブラリです）。 しかし、その部分を取り出すと、ノックアウトには本当に何が残っているのでしょうか。 巧妙で適切に実装されたオブザーバブルは、リアクションビューにバインドされたモデルの優れた基盤になりますか？ 観察可能な不変の状態はより良い選択ではないでしょうか？ immstructは非常にまともな例です（残念ながら、少し遅すぎました...）

私はより複雑なドメインを持つアプリケーションの基盤を書いています。react.js（バニラコーヒースクリプトBTWを使用）を使用することにしましたが、すべての複雑なコアロジックを使用してモデルレイヤーを構築することから始めました。 テスト可能で、検証、i18n、変更の伝播（EventEmitter）などをサポートします。 モデルレイヤーから始めるのは自然なことです（結局のところ、ドメインモデルはアプリケーションのすべてですよね？！）。 私は、reactコンポーネントは通常、この設計をサポートするための十分な準備が整っていないことに気づいています。 変更が通知されるのではなく、新しい小道具/更新状態が渡されることを期待しています。 私にとって、それはまだ良い解決策を見つけるためのものです。 モデルを奪うために反応したくありません。 そして、TodoItemは間違いなくReact.Classではありません。

申し訳ありませんが、ここで少し話題から外れたかもしれません。 しかし、多分議論は続く…。

mobxを調べましたか？ ノックアウトからいくつかの概念を借用したのは、reactの状態管理者です。 実際には、ノックアウトテンプレートと仮想dom-libを使用したカスタムmobx実装を使用しています。

@kimgronqvistmobxを紹介してくれてありがとう。 それはまさに私が探していたものです。
@mweststrate素晴らしい作品とインタビューをありがとう

あなたたちは本当に私の日を作りました！