<p>dva 2.0</p>

tsのネイティブサポートはどうですか？

モデルを解除するときに、未使用の状態データを破棄するためにレデューサーを渡すことをサポートすることを検討しますか？ https://github.com/dvajs/dva/issues/769

dva-cliの名前をroadhogに変更するのはどうですか？概念が混乱しないようにしてください。

個人的には、tsのネイティブサポートに同意しません。フレームワークは、他の無関係なテクノロジースタックからバインドを解除し、純粋に保ち、より少なくする必要があります。たとえば、アンマウントモデルの状態の問題は、既存のAPI、およびreact-router計画は、react-router-dvaなどの独立したコンポーネントに分割することです。rnのreact-navigation-dvaを作成することもできます。

エクスプレスミドルウェアメカニズムと同様に、 dva.use(reselect)などのプラグインの形式でもサポートできる最適化スキームもあります。静的プラグインのみが組み込まれており、その他は個別にサポートされます。 、そして佐賀も利用できます。

@nihgwu私は間違っていました。つまり、antdと同様に、tsで記述され、ユーザーを制限しません。これには、タイプファイルを常に手動で同期して公開する必要がないという利点があります。

プラグインソリューションに同意します。これを行うことは可能ですか？

view - dva-core - [插件]

それらの中で、現在のdvaに等しい部分は次のとおりです。

• dva-core
• dva-saga
• ルーター

最後の2つはプラグインです。

dvaは、ビューとデータの関係を表現することに焦点を当てたライブラリとして位置付けることができますか？ビューはどのようなフレームワークであり、データソースはどのような方法で、すべて置き換え可能になっていますか？次に、1.0でスムーズにアップグレードするために、dvaをdva-coreとsagaのデフォルトの組み合わせとして定義しますか？

基になるカプセル化がインスタンスタイプのディスパッチタイプをサポートするのに便利かどうかわかりませんか？

dispatch({
  type: model => model.product.loadAll,
})

文字列を覚えるのも面倒で、名前空間を書くのを忘れがちです。ドロップダウンプロンプトがある場合は、再構築するのも便利です〜

状態のすべてのデータに対してデフォルトで一連のレデューサーを提供できるかどうかはわかりません
ほとんどのシナリオでは、フィールドに値を割り当てるだけのレデューサーを手動で作成する必要があるため、デフォルトで既製の単一フィールドセットメソッドを提供できれば、それは非常に良いことです。

レデューサーをツリーとして実装できますか？今のように、ns splitはロジックをフラット化するように強制されます。モデルはレデューサーのルートに対応し、下にぶら下がっているレデューサーが多すぎます。

@xufei sagaをコアにすべきだと思いますが、sagaのない現在の

@xufei申し訳ありませんが、tsで書くことも参考にすべきだと感じましたが、必要ないと思います。結局、dvaのインターフェースもシンプルで、tsで書き直すことはできません。ファイルを入力します。

@sorrycc sagaの分離例も示します

Immutable.jsはサポートできますか？

Immutable.jsをサポートします。Immutable.jsはパフォーマンスの最適化において重要な役割を果たします

Roadhogパッケージングは​​、パフォーマンスが高すぎます。最適化できるかどうかを確認してください。可能であれば、可能な限り最適化してください。サーバーがプロジェクトをビルドする前に、他のコンテナーを停止する必要があります。そうしないと、サーバーがスタックします。

Immutable.jsは非推奨です。lodash操作とspread操作を組み合わせることで、不変の効果を実現することもできます。そして、lodashは基本的に組み込まれています。

実際、dva 1.xの開発経験は、Immutable.js、split saga、native support tsをサポートするかどうかと同様に、すでに非常に優れています。不要だと感じ、すべて開発者の自己愛に属しています。実際の開発効率と経験に影響を与えます。

個人的には、dva2.xで考慮する必要のある4つのポイントがあります。

1. サービスレイヤーの最適化は、モデルに抽出して統一された方法でパッケージ化できるかどうかにかかわらず、基本的にrequest気にせず、デフォルトでネットワーク例外処理を提供します。これで基本的に必要になります。自分でrequest.jsを書く。

2. これは、ビューレイヤーのエフェクトコールバックの問題です。ビジネスロジックをモデルデータに完全に分離してエフェクトで処理するのは非現実的（面倒すぎる）であるため、この領域ではより洗練されたソリューションが必要です。

3. dvaの周辺コミュニティの構築です。現在、足場の種類は豊富ですが、さらに構築が必要であり、角度のあるコミュニティ自体のリソースレベルに到達することが目標のように感じます。

4. ビルドツール、パフォーマンス、機能など（現在はモック）の強化はまだ少し面倒です

私にとって最も懸念されるのは、 routerの分離です。 dvaに含める必要があるのはredux + redux-sagaだけだと思います。 reduxコミュニティは、できる限り少ないことを提唱しているため、1.xパッケージreact-routerとfetch 、および上記のImmutableは不要だと感じています。これは開発者の好みに属します。メンテナとして傾いてはいけません。開発者の好みのために、プラグインの形でサポートできます。サービス層の問題もあります。必要に応じて、あなたが書くことができるplugin自分自身、それはに含めるべきではありませんdva-core

@nihgwuルーターを抽出する目的は何ですか？

@nikoguはやりすぎで、初心者は途方に暮れるでしょう。原則が何であるかわかりません。しかし、ドキュメントが詳細である場合、それも可能です

ルーターを削除する目的は何ですか

@nikogu

現在、dvaの適用範囲は少し狭く、ビューを含む反応コミュニティと強く結びついており、react-routerとも強く結びついています。しかし、それを使用した後、ワイヤレスマルチページアプリケーションなどのルーターを必要としない場所、react-nativeなどのreact-routerが適用できない場所、ノードなどのreactを必要としない場所があることがわかりました。 、電子およびアプレット。

dvaはもっとできると思います。

@nikoguは、さまざまなルーターを使用できるため、ルーターから離れます。たとえば、RNではreact-navigationを使用でき、react-navigationはwebもサポートします。これは、プラグインで完全にサポートされ、より適切なカスタマイズを実現できます。

dvaは、ノードの既存のAPIを使用してWebサーバーの基本機能を提供するexpressなどのWeb開発フレームワークの完全なセットを提供するのではなく、reduxとsagaのコードとロジックを新しい形式で編成することを理解しています。あなたはボディ、クッキーを扱っていますか、そしてあなたが選ぶテンプレートエンジンはミドルウェアを通してカスタマイズすることができます

完全なソリューションが必要な場合dva-ant = dva-core + dva-plugins 、自分で使用する

dvaの組み合わせは、reduxとsagaの組み合わせである必要があります。これは、これら2つがデータ状態フローのコアであり、その他はデータに基づいて構築された周辺機器と見なすことができ、プラグインまたは他の方法でサポートできるためです。 ExpressとDjangoを比較できます。これは、少ないことと多いことの典型的な違いであり、大きくて完全なものが好きな人もいますが、jsコミュニティは小さいながらも美しいものを尊重しています

reduxを直接使用する場合、dvaを使用する主な理由は、dvaがreduxのコード構造とロジックを簡素化し、生産効率を向上させることができるためです。これは、reduxに基づくdvaのコアでもあります。

やみくもにもっとや​​ると、dvaのアプリケーションシナリオはどんどん狭くなっていきます。たとえば、react-routerはRNでは使用できません（v4はすでにサポートされていますが、非常に基本的です）、RNにはフェッチも付属しており、他にも強力なバインディングがあります。 。ライブラリもアップグレードの依存関係の問題を引き起こします。それはまだreact-routerです。V4はRNをサポートしますが、dvaはまだV2です。dvaがreact-routerをアップグレードするのを待ってから使用する必要があります。プラグインの場合-独立してアップグレードすれば、そのような問題はありません。NS

上記のdva-coreの意味するところは、スモールコアをdva-coreとして扱い、ルーターなどを使用して、ミドルオフィスとバックオフィス向けに、社内の統合バージョンなど、いくつかのデフォルトの統合スキームを開発することです。 、およびH5の場合、小さなプログラム、サーバー側のレンダリングなど。

2:00：
1.実際の開発では、ビジネスロジックがモデルに実装されており、ファイルが大きすぎます。他のサービスとサービスの関係はどのようなものですか。 サービスまたはリクエストを組み込むことができます
2. react-routerをシステム独自のプラグインなどに変更します。目的は、依存関係を解放することです。

2.0はいつ開始されますか？

プラグ可能なssrソリューションは、ルーターの管理を抽象化します。サーバー側は、最初のルーティングリクエストを引き継ぎ、共有dva（）を使用して状態ツリーを初期化できます。dvaがアップグレードを続けると、サーバーのレンダリングが弱くなるように感じます。新機能の適用。

TypeScriptとRN。より良いサポートを得ることを願っています

別のものを考えて、デフォルトのnamespace提供します

dvaを使用する過程で、 reducerがプレフィックスを必要としない場合が常にあり、dvaの現在の実装はnamespace提供する必要があるため、 namespaceは提案があります。 default （またはglobal 、 * ）、我々はそれが考えるmodelの下にreducers接頭辞なしです

個人的にいくつかの点を考えてください：

• redux-sagaに依存しないため、いくつかの機能（非同期/待機サポートなど）を簡単に追加できます。
• 複数の小さなモジュールに分割する（たとえば、単一のストア、単一のルーター）
• ネストされたモデルをサポート

最近、 redux基づいてvuexをモデル化し、参照ポイントを作成しました： https ：

サーバーをサーバー側でレンダリングし、フロントエンドとバックエンドを一緒に書き込むことができるようにすることをお勧めします。

ルートディレクトリの名前を設定できますか？たとえば、コンテナを使用します
実際、カタログを機能ごとに分割し、モデル、サービス、コンテナーをまとめたいと思います。そうしないと、複数のカタログにジャンプすると、心臓の流れが損なわれます。崇高な上のタブで開いたuser.jsが何であるかを知るために、私はすでに次のように名前を付けています：user.jsx、user.model.js、user.service.js。 user / model.js、service.js、container.jsをまとめます

@zheeengのようなディレクトリ編成がサポートされるようになり、dvaにはディレクトリ編成に関する制限がありません。

@xufei
@sorrycc

モデルを解除するときに、未使用の状態データを破棄するためにレデューサーを渡すことをサポートすることを検討しますか？

手動制御は面倒なので、GCのセットを直接実装することをお勧めします

pathToRegexpをアップグレードしてください。その解析メソッドとコンパイルメソッドは直接使用できません。

合意は構成よりも優れており、他のプロジェクトやテクノロジースタックとの結合を減らします。

エフェクトビジネスは重すぎて、model-extendのアイデアはかなり良いです

@nihgwuは、「

@sorrycc dva 2.0には最新のリリース計画がありますか？

dva-cliがTypeScriptボイラープレートの生成を選択できることを強く望んでいます

dva-coreはすでにWeChatアプレットで使用できます

@yautahはそれを試しましたか？あなたがそれを試した後、あなたは計画を共有することができます。

dva-coreは、他のプラグインをプラグインの形で提供できるか、パッケージングやルーティングスキームなど、ユーザーがそれらを選択する方がよいかどうかにかかわらず、reduxデータストリームの再カプセル化を提供するだけでよいと思います。

スタイラスをサポートするためにdva-cliをサポートしたい

ssrをサポートしていません。

HRMの設定方法、APIの記述は比較的少ない