公式ドキュメントとhackernewsの例では、モデルのサブスクリプションで一致する履歴URLをリッスンする方法を使用して、次のようにページの初期データをロードします。
//摘自api文档
app.model({
namespace: 'todo',
// ...
subscriptions: {
setup({ history, dispatch }) {
// Subscribe history(url) change, trigger `load` action if pathname is `/`
return history.listen(({ pathname }) => {
if (pathname === '/') {
dispatch({ type: 'load' });
}
});
},
},
});
ポータル: dva-hackernewsの同様に書かれた
これは、ページコンポーネントのライフサイクル中にデータをロードすることとは異なります。たとえば、同じhackernewsの例では、ListPageのcomponentWillMountまたはcomponentDidMountで対応するエフェクトアクションをディスパッチしてリクエストを行うことを選択できます。サーバーレンダリングの観点。、この種のページの初期データ依存性の宣言を担当するライフサイクル(next.jsのgetInitPropsなど)を追加できます。
ページの初期データ依存関係をモデルのサブスクリプションに入れる現在の方法について、次の質問があります。
もちろん、dvaはどちらの方法を使用するかを制限しません。dvaでページコンポーネントのライフサイクルを使用することは完全に実行可能ですが、実証効果のある公式文書や例は別の方法を使用していると思います。考慮事項がわからないので、以前にWeChatグループの質問を追加しましたが、答えを得ることができませんでした(友人は、dvaがページコンポーネントも機能コンポーネントであることを望んでいるためだと言っていましたが、それは確かにポイントですが、あまり説得力がないようです)ので、問題をオープンしました。ご迷惑をおかけしましたことをお許しください。
@sorrycc
モデルのinithook
邮箱:[email protected]
署名はNetEaseMail Masterによってカスタマイズされました。2017年12月17日の16:30に、Qin Junwenは次のように書いています。公式ドキュメントとhackernewsの例では、モデルのサブスクリプションで一致する履歴URLをリッスンする方法を使用して初期データをロードします。ページの場合は次のようになります。
// APIドキュメントから
app.model({
名前空間: 'todo'、
//..。
サブスクリプション:{
setup({履歴、ディスパッチ}){
//サブスクライブ履歴(url)の変更、パス名が/
場合、 load
アクションをトリガーします
戻り値history.listen(({パス名})=> {
if(パス名=== '/'){
dispatch({type: 'load'});
}
});
}、
}、
});
ポータル:dva-hackernewsの同様に書かれたアイテムモデル
これは、ページコンポーネントのライフサイクルでデータを読み込むときに通常表示されるものとは異なります。たとえば、同じhackernewsの例では、ListPageのcomponentWillMountまたはcomponentDidMountで対応するエフェクトアクションをディスパッチしてリクエストを行うことができます。 、サーバーレンダリングの観点から考えることもできます。、このページの初期データ依存関係の宣言を担当するライフサイクル(next.jsのgetInitPropsなど)を追加できます。
ページの初期データ依存関係をモデルのサブスクリプションに入れる現在の方法について、次の質問があります。
URL一致ロジックの繰り返し:URLパラメータを解析してビジネスロジックに転送するのはルーターの責任です。hackernewsの例から、それらの一部が繰り返されており、比較的「低レベル」であることがわかります。 pathToRegexなどのライブラリ(react-router / expressの背後)URLの照合と解析にも使用されます)
職務の分離:異なるプラクティスは異なるセマンティクスに対応します。ページはページが依存するデータを宣言しますか、それともモデルはデータの読み込みを実行するURLを宣言しますか?
ページはリクエストの制御を失います。リクエストが成功または失敗した後にページが特定のロジックを実行したい場合、ページ自体がサーバーレンダリングの処理方法をデータをロードするアクションを認識しないため、実装がより困難になります。 / isomorphicシナリオ。実際には、3の続きです。サーバーレンダリングでは、「ページが依存するデータを最初にロードしてから、ページレンダリングを実行する」必要があり、リクエストのステートメントがページレベルでは、これを行うのはもっと面倒です。
サブスクリプションの設計はelmの影響を受けているようですが、elmでのサブスクリプションは実際にはあまり使用されておらず、WebSocketなどのシナリオを処理するためにのみ使用されます。最初のリクエストは引き続きpageステートメントのinitを介して行われます。
もちろん、dvaはどちらの方法を使用するかを制限しません。dvaでページコンポーネントのライフサイクルを使用することは完全に実行可能ですが、実証効果のある公式文書や例は別の方法を使用していると思います。考慮事項がわからないので、以前にWeChatグループの質問を追加しましたが、答えを得ることができませんでした(友人は、dvaがページコンポーネントも機能コンポーネントであることを望んでいるためだと言っていましたが、それは確かにポイントですが、あまり説得力がないようです)ので、問題をオープンしました。ご迷惑をおかけしましたことをお許しください。
@sorrycc
-このスレッドを購読しているため、これを受信しています。このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。
{"api_version": "1.0"、 "publisher":{"api_key": "05dde50f1d1a384dd78767c55493e4bb"、 "name": "GitHub"}、 "entity":{"external_key": "github / dvajs / dva"、 "title ":" dvajs / dva "、" subtitle ":" GitHubリポジトリ "、" main_image_url ":" https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png " 、 "avatar_image_url": " https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png "、 "action":{"name": "Open in GitHub"、 "url": " https://github.com/dvajs/dva "}}、 "updates":{"snippets":[{"icon": "DESCRIPTION"、 "message": "[ディスカッション]-概要ページデータ依存関係の問題(#1402) "}]、" action ":{" name ":" View Issue "、" url ":" https://github.com/dvajs/dva/issues/1402 "}}}
@ yangbin1994
モデルのinithookは何ですか?
モデルドキュメントには表示されませんでした。
このフックがあると仮定すると、サブスクリプションでそれを行うことと本質的に異なるようには見えません。上記の1〜4の質問はまだ存在します。
この問題は、最近のアクティビティがないため、自動的に古いものとしてマークされています。 それ以上のアクティビティが発生しない場合は閉じられます。 貢献していただきありがとうございます。