Reactの人気により、多くの大企業のフロントエンドにはReact関連の知識が必要であり、成熟したフレームワークでさえ実稼働環境に適用されています。今日は、Reactの上級ユーザーが頻繁に遭遇するMirrorXの書き込みの問題について説明しますが、前任者が作成したコンポーネントを見てみると、混乱してしまいます。実際のケース：単純なパラメーターを変更するために、フロントエンドの開発エンジニアは、コードの後に少なくとも4〜5時間を費やします。そこで、この記事は、高度なプロセスにいるフロントエンドエンジニアが、MirrorXがRESTfulリクエストを処理してコンポーネントに到達し、コンポーネントを再レンダリングするように刺激する方法をすばやく理解できるようにするために作成しました。この記事は、フロントエンド開発には欠かせません。
読者に適しています：React基盤を持つプログラマー、UCF開発者、Antd開発者。
1.コンセプトの質疑応答
1. MirrorXとは何ですか？
MirrorXはReduxパッケージに基づくステートマシンです。たとえば、実際の使用で、バックグラウンドから製品インターフェイスを読み取り、インターフェイスから返されたデータを処理し（たとえば、割引が割引されている場合、フロントエンドが割引額を計算する）、処理されたデータをインターフェイスに表示するとします。考えてみてください。多くのコードを使用する必要があり、コンポーネントクラスに配置する必要がありますか？
フレームワークがある場合、コンポーネントのコードは1行しか解決できません。これにはMirrorXを使用します。
2.どうすれば1行で解決できますか？
オブジェクト指向プログラミングを学んだことのある人は、カプセル化によって制御層のコードをより簡潔にすることができることを知っているはずです。しかし、Reactで述べたばかりのことに対処したい場合は、状態と小道具の制御だけでなく、行き来するコンテキスト（現在のユーザーが誰であるか、VIPレベルが何であるかなど）も必要であり、何がReactプログラマーを最も不快にしますか、現在のユーザー情報はUserViewコンポーネントにあり、現在のGoodsViewコンポーネントはUserViewコンポーネントにアクセスできません。したがって、コンポーネントの障壁を克服し、この情報を格納し、このメカニズムをカプセル化して1行のソリューションを実現するには、統一された場所が必要です。
3.具体的なメカニズムは何ですか？
Reduxに関するインターネット上の記事はたくさんあります。Reduxを読んだ後、MirroXを検索して特定のメカニズムを知ることができます。簡単に言うと、システムにはいくつかのステートウェアハウスがあります。ユーザー情報や製品情報などのコンテキスト変数をさまざまなウェアハウスに配置できます。これらの変数は、配置されると、製品情報の読み取りなどのアクションを呼び出すことによってすべて実装されます。製品の数量を変更します。アクションはサービスを呼び出すかどうかを選択できます。フロントデスクが製品の数を変更した場合、サービスを呼び出さずにステータスウェアハウスの値を直接変更できます。サービスが呼び出された場合、関数は通常サーバーとの対話を必要とします。
2. MirrorXを使用して機能を完了する方法
これは、製品リストを読むように背景に要求する例です
1.環境の準備
まず、npm iでmirrorx、react、axiosがインストールされていることを確認してください。この記事はベストプラクティスであるため、インストール方法の詳細には触れません。
2.単純なサービス（サービス）を作成する
service.jsファイルを記述します（多くのコメントがあり、コードは実際には数行ではありません）
import request from "axios";
const URL={
GET_GOODS:"api/template/GetGoods" // 声明要访问的后台接口地址
}
// 暴露出一个名为GetGoodsApi的函数，入参params是Object类型，代表提交给后台的参数列表
// 这个函数会返回一个Promise对象
export const GetGoodsApi = (params) => {
return request(URL.GET_GOODS, {
method: "post",params})
}
// 你还可以暴露出其他函数，一个Service可以export const多个函数
// export const GetMember = (params) => {
// return request(URL.GET_MEMBER, {method: "post",params})
//}
3.単純なモデルレイヤー（アクションとモデルを含むモデル）を記述します。
model.jsを記述します（多くのコメント、コードは実際には数行ではありません）
import {
actions } from "mirrorx";
import * as api from "./service"; // 把刚才的service.js引入进来，名称定为api
export default {
name: "GoodsManager", // 这里写的名字将会成为状态仓库的名称
initialState: {
// 这里可以写初始化时状态机里的初始状态
userId: "0001"
},
// reducer：状态机处理函数
reducers: {
// 这个updateState是默认的，它用来主动更新状态机里的各种状态
// state和data都是Object对象
// state是框架传入的，开发者调用的时候，data才是对应的第一个参数
// ...是ES6的对象扩展运算符，后面...data会自动覆盖...state的同名属性
updateState: (state, data) => ({
...state, ...data })
// 后面还可以写其他的reducer，切记第一个参数一定是state
},
effects: {
// 动作处理函数：获取商品
// param是对象，getState是框架传入的函数对象，用来方便获取当前状态机的状态
// 开发者调用的时候，不用给getState形参赋值
async GetGoods(param, getState) {
// Promise的同步操作运算，获取Axios返回的data
let {
data } = await api.GetGoodsApi(param);
// 调用当前状态机的updateState方法（也就是上面写的那个函数）
// 由调用可见，只放了一个Object类型的参数
actions.GoodsManager.updateState({
goods: data.data });
}
}
};
4. MirrorXでホストされるコンポーネントを変換します
最初のステップは、プロジェクトのエントリを追加することです（たとえば、app.jsのメモリにステートマシンを作成するコードを追加します）。
// 引入MirrorX的组件
import mirror from 'mirrorx';
// 引入刚刚写的model，注意路径
import model from './model';
// 调用MirrorX，根据模型创建状态机
mirror.model(model);
ステップ2：ステートマシンによって管理されるコンポーネントのコードを変更する
// 增加对MirrorX的引用
import {
connect} from 'mirrorx';
// 这里面GoodsView就是当前受状态机托管组件的class名称，GoodsManager就是第二步里name写的名字
export default connect(state => state.GoodsManager)(GoodsView);
5.呼び出す必要がある場所に次のコードを記述します。
ここでは、GoodsViewが読み込まれるとすぐに製品のリストを表示する必要があるため、コンストラクター（props）関数でコードを記述できます。
// 组件上需要引入MirrorX的actions
import {
actions} from 'mirrorx';
// 在constructor(props)函数里写上以下调用即可
actions.GoodsManager.GetGoods({
user:props.userId
});
次に、レンダリングインターフェイスでレンダリングインターフェイスのレンダリングインターフェイスのフロントエンドコードをprops.goods（3番目のステップGetGoodsメソッドがupdateStateメソッドが呼び出されたときにupdateStateメソッドを呼び出し、現在のコンポーネントをプロップから接続する必要があるため、商品と呼ばれる）から書き込み、テストを開始できます。
3、補足説明
- ステートマシン内のすべての状態値は、管理対象コンポーネントのプロップに自動的に書き込まれます。変更が発生した場合は、プロップから取り出すこともできるため、コンポーネントの状態を取得または更新しないでください。
- ステートマシンの値が変更される限り、マネージコンポーネントはrenderメソッドを再実行して、自動更新を実現します。
- 実際の開発では、コンポーネントの入れ子、コンポーネント要素の属性値が状態マシンの状態名と競合するため、さまざまな難病が発生します。私の分析とAntdやUCFなどの成熟したフレームワークの実際の戦闘に基づいて、大規模なシステムには一般に5つ以下のmodel.jsとservice.jsがあり、それらのほとんどには命名規則があるという結論に達しました。
- 他の人のコードを見る場合は、順番に調べれば、フロントエンドの神のコードを理解するのは難しくありません。