redux-thunkの役割、知識、理解について
この記事を読む前に、いくつかの
redux-thunkチュートリアルを見たことがあれば、コードを単純化するだけでなく、増やすために、最終的にどの役割が使用されたのか、それほど混乱していませんか？最初の私の疑問のいくつかと後で狂ったBaiduに基づいて、私はそれを要約しました
最初にコード例を示します
非同期リクエストがある場合は、ページに表示されているデータを取得します。reduxがすでに書かれていると仮定します。リクエストフェーズのみをシミュレートします
// App.js
import React, {
Component } from 'react'
import store from './store/index'
import axios from 'axios'
class App extends Component {
constructor(props) {
super(props)
this.state = store.getState()
// store 监听更新，并且自动赋值到页面上
store.subscribe(() => this.setState(store.getState()))
}
// 在页面组件挂载后，请求一个模拟的接口，获取一个todoList列表
componentDidMount() {
axios
.get('http://rap2.taobao.org:38080/app/mock/246209/todoList')
.then(res => {
store.dispatch({
type: 'GET_LIST', value: res.data.data })
})
.catch(res => {
})
}
render() {
return (
<ul>
{
this.list.map((item, index) => {
return <li key={
index}>{
item}</li>
})}
</ul>
)
}
}
export default App
まず、このコードの何が問題になっているのかを見てみましょう。
-
ライフサイクル関数でインターフェースが要求されます。このページのレンダリングに複数のインターフェースが必要な場合、ライフサイクルコードは非常に大きくなります（これらの要求をメソッドに抽出し、ライフサイクル内のメソッドのみを呼び出して簡潔にすることができます）アップ）。そうです、メソッドを書くことは本当に私たちがしなければならないことです
-
テストには役立ちません。メソッドを作成する前に、このインターフェイスを単体テストして一部のデータをシミュレートする場合、ライフサイクルでシミュレートすることは困難です。
redux-thunkコードを最適化するために使用します
新しいjsファイルを作成して、リクエスト/操作のコードを一律に配置します
getTodoListメソッドを定義します
// src/store/actionCreators.js
// 这个方法看上去像一个闭包。因为redux-thunk是可以接收一个函数的，所以我们来返回一个函数
export const getTodoList = () => {
return dispatch => {
axios
.get('http://rap2.taobao.org:38080/app/mock/246209/todoList')
.then(res => {
console.log(res.data.data)
dispatch({
type: GET_LIST, value: res.data.data })
})
.catch(res => {
})
}
}
- App.jsページで使用
// App.js
import React, {
Component } from 'react'
import store from './store/index'
// ! 异同 ! 这里我们不在需要引入axios。而是引入我们的方法
import {
getTodoList } from './store/actionCreators'
class App extends Component {
constructor(props) {
super(props)
this.state = store.getState()
// store 监听更新，并且自动赋值到页面上
store.subscribe(() => this.setState(store.getState()))
}
componentDidMount() {
// ! 异同 ！ 这里还是在生命周期获取数据。
// 不过这里我们执行 getTodoList() 返回的是一个函数
store.dispatch(getTodoList())
}
render() {
return (
<ul>
{
this.list.map((item, index) => {
return <li key={
index}>{
item}</li>
})}
</ul>
)
}
}
export default App
対照的に、2つのコードに違いはありませんが、いくつかのコードのように見えるので、以下で詳細に分析してみましょう。
redux-thunkの役割は何ですか
redux-thunkallowsは
store.dispatch関数が受信/オブジェクトミドルウェアになる可能性があります
- redux-thunkソースコード
function createThunkMiddleware(extraArgument) {
return ({
dispatch, getState }) => next => action => {
if (typeof action === 'function') {
return action(dispatch, getState, extraArgument)
}
return next(action)
}
}
const thunk = createThunkMiddleware()
thunk.withExtraArgument = createThunkMiddleware
export default thunk
オブジェクトのみを受け入れることができるstore.dispatchがオブジェクト/メソッドを受け入れることができるようにし、メソッドが受信されると、そのメソッドはreduxのストア更新をトリガーせずに自動的に実行されます。
これは少し紛らわしいです、写真を撮りましょう：
そして、redux-thunkは、関数の実行後に戻ることができますdispatch。redux-thunkソースコードの4行目。次に、非同期コールバックの直後にそれを取得してdispatch、イベントのreduxを配布し続けるstore.dispatchことができます。非同期関数の抽象化は、プロセスをトリガーするために使用する方法になりました。
たとえば、ショッピングカート機能を追加するためのインターフェースがあります。商品の詳細にショッピングカートを追加したり、ショッピングカートに商品の数量を追加したりできます。その後、このインターフェースを再利用できます。削除後は、次のことができます。これを異なるinterfaces.interfaceで一緒に呼び出します。コードの再利用を実現するために
redux-thunkが非同期コードの再利用用である場合、メソッド呼び出しを定義して、redux-thunkを使用する必要があるのはなぜですか？
パブリック関数を記述してから、その関数にsotreを導入するのは良くありませんか？このようにして、すべてのメソッドがストアオブジェクトを取得でき、store.dispatchメソッドを呼び出してイベントをディスパッチすることもできます。
redux設計から開始までこのこと：
-
它强制了 store 必须是一个单例：これは、サーバー側のレンダリングには非常に不向きです。これは、ユーザーやリクエストごとに別のストアが必要になるためです。 -
不易于测试：外部参照ストアを使用しているため、テスト用にストアを簡単にモックすることも、ストアの状態を制御することもできません。
ps：上記の2つの短い単語は以下から抜粋されています：なぜredux-thunkを使用するのか。上の写真を含めて、この大男の海賊でもあります。
総括する
redux-thunkの機能紹介はこちらです。私が最初に学び始めたとき、理解するのは本当に困難でした。明らかに、コードは単純化されておらず、追加のプラグインが引用されていました。画像は何ですか？
すべてがコードの再利用のためのものです。コードの量が少なく、利点が見えない場合があります。同じコードを複数の場所で使用すると、コードの再利用がいかにクールであるかがわかります。次に、redux-thunkはストアを強化します。ディスパッチメソッド。そしてredux、强制store必须是一个单例ルールに従いました。部分テストにも便利です