MobXライブラリがWebアプリケーションの状態管理にどのように役立つか。 Yandexでの講義

Webアプリケーションに依存関係がないと、インターフェースでエラーが発生し、パフォーマンスが低下します。 Yandexのインターフェース開発部門の責任者であるAzat razetdinovは、MobXライブラリが最小限の変更セットの追跡を支援し、アプリケーション状態の一貫性を維持する方法を示しています。

手で不変データを操作しようとしているという事実はオプションです。 アプリケーションの不変の状態は、別のビュー、別のビュー、別のディスプレイです。 常に生きているモデルを使用して、いつでもそのフラットな投影を取得できます。

-私の名前はAzat Razetdinovです。メール、ディスク、カレンダー、パスポート、アカウント管理などのYandexパーソナルサービスを代表しています。 苦労せずにWebアプリケーションの状態を管理することについてお話ししたいと思います。



アプリケーションの状態は何ですか？ これは、Webアプリケーション全体のアーキテクチャの中心的な概念です。 他のコンポーネントが依存するものはすべてそこに保存されます。 たとえば、最も明らかなものはディスプレイであり、アプリケーションの状態をハウスツリーの形で表し、ブラウザに表示されます。



これは最大の部分ですが、多くの人はまだ他の部分があることを忘れています。 アドレスバーの現在のURLは、アプリケーションの状態にも依存します。 ユーザーがアプリケーションの任意のページのurlをコピーして友人に送信し、すべてが同じように開くことが非常に重要です。 現在のURLは常に現在の状態に対応し、それを反映する必要があります。



ほとんどの場合、サーバー上のアプリケーション状態の同期があります。 クライアントで変更したすべてのものが何らかの形でサーバー上にあることを常に確認することが重要です。



リポジトリにローカルな変更を保存して、そこから変更を取得したい場合があります。 ブラウザに直接保存します。 これには、多くの場合、アプリケーションの状態をローカルストレージと同期する必要があります。 実際、アプリケーションの状態に依存する多くの部分があります。

ここで問題は何ですか？



原則として、アプリケーションの状態は、多くのデータがあるツリーであり、いくつかのリスト、オブジェクト、ハッシュ、プリミティブデータがあります。 大規模な階層構造。



問題は、それが階層的であるということではなく、生きていることであり、常に変化しているということです。 ある場所で変化し、次に別の場所で変化します。 どのような問題を解決したいですか？



あなたが長い間フロントエンドにいたなら、あなたはおそらく変更への手動サブスクリプションのようなパターンに精通しているでしょう。



現在の状態を取得し、それをコンポーネントの初期表示に使用してから、変更をサブスクライブしてそれらに対応します。



古いフレームワークを思い出すと、擬似コードではこのように見えました。



まず、現在の状態を使用し、変更をサブスクライブし、変更ごとにいくつかのアクションを実行します。 以前はファッショナブルだったので、家の要素を個別に変更するか、現在ファッショナブルであるためレンダリング全体を再起動します。



このアプローチには2つの問題があります。



ツリー内のノードを変更するためにサブスクライブする場合、ほとんどの場合、実行しているアクションが多すぎます。 最も可能性が高いのは、現在のコンポーネントがアプリケーションのツリーの状態全体に依存しておらず、不要な操作が多すぎることです。 そのため、この場所では通常、何らかの最適化を開始し、コンポーネントまたはアクションが依存するアプリケーションステータスフィールドのみを選択しようとします。



しかし、このアプローチにも問題があります。



手動でこれを行うため、しばらくの間存在しているプロジェクトでは、遅かれ早かれどこかで何かを忘れ、リファクタリングし、一部のフィールドに依存関係を追加しないと状態が発生し、コンポーネントの表示に影響する可能性があります。



ここで何が起こったのですか？ 同志は彼のプロフィール写真を更新しましたが、どこでも更新されませんでした。 大きなアバターが変更され、ツイート内の小さなアバターはユーザーのアバターの変更を購読せず、この変更を受け取らず、自分自身を更新しなかったことが判明しました。 これは、手動サブスクリプションの最大のマイナスです。



この場所でMobXが役立ちます。 使用するアプリケーションステータスフィールドに正確にサブスクリプションを実装します。



これを示すには、内部からどのように機能するかを説明する必要があります。



デコレータを使用します。 恐れてはいけません。デコレータの助けを借りて書かれたものはすべて、ラッパーの通常の機能を使用して書くことができます。 デコレータは、明確さと簡潔さのためだけにあります。



そのようなクラスを宣言しましょう-人、男。 そして、3つのフィールドを宣言し、観察可能なデコレータでマークします。 名前、姓、ニックネーム。



MobXについて話すとき、Excelで類推することは非常に便利です。



観測可能なフィールドは、セル内の生データにすぎません。



他の概念が自分自身を追跡できるようにします。



Computedは、変更をフォローしているユーザーに通知することもできるという点でobservableに似ていますが、値を内部に保存せず、他の観察可能なフィールドに基づいて計算します。



この場合、名前と姓をスペースで連結するだけです。



Excelで類推するために、これは数式を持つセルです。 これまでのところとても簡単に思えます。



これはおそらくReduxから知っているアクションではありませんが、非常によく似ています。



MobXの観点では、アクションは単なる関数です。 ここではメソッドですが、必須ではありません。 アクションはクラスメソッドである必要はありません。アプリケーション内のどこにでも存在できます。主なことは、アクションデコレータでマークされていることです。 この関数内で、以前にマークした監視可能フィールドを変更できます。



すべてが明確な間、メソッドはnickNameを設定します。



今、魔法が始まります。



MobXの最も重要な概念は反応です。



これらは計算に似ており、内部でいくつかの観測可能フィールドまたは計算フィールドも使用しますが、値を返しません。 代わりに、副作用があります。



最も重要なのは、元のデータが変更されるたびに反応がトリガー、実行、または再開されることです。 この場合、いずれかではなく、各特定の反応に依存するもののみ。



最も単純な反応は、MobXライブラリの自動実行機能です。



コンソールに特定の式を表示するだけの関数が渡される単純な自動実行を書きましょう。



Excelとの良い類似性は得られません。反応は値を返すために必要ではなく、何らかの副作用をもたらします。 大まかに言って、これはセル内の別の数式です。



Autorunは、呼び出すとすぐに、関数を初めて実行し、引数で渡しました。



この関数を実行すると、観察可能なフィールド、この場合はまずnickNameにアクセスします。 これがMobXマジックの機能です。実際、通常のフィールドの代わりにobservableを宣言すると、このフィールドに対してゲッターが宣言されました。



呼び出すと、観察可能なフィールドnickNameがそれ自体に増分を設定します。そう、自動実行でラップされた関数の新しいリスナーを取得しました。



私にとって何かが変わったとき、この変更についてこのリスナーに知らせる必要があります。 NickNameは空なので、ここではPerson fullNameの呼び出しが行われます。 このフィールドの変更を申し込んでいます。 FullNameは計算フィールドであり、firstNameおよびlastNameフィールドに内部的にアクセスするゲッターです。



これで関数の実行が完了し、その時点でMobXは自動実行に渡した関数がnickName、fullName、firstName、lastNameの4つのフィールドに依存していることを認識します。



依存関係ツリーは次のようになります。 最初の列の監視可能なフィールドを変更すると、自動実行が再開されます。



私たちの小さな男にニックネームVasekを尋ねることにしたとしましょう。



このメソッドはアクションであり、それ自体で割り当て操作を実行します。



この操作を呼び出すと、セッターがトリガーされ、その内部でサブスクライバーのリストを調べてすべてのユーザーに通知します。変更したため、何らかの方法で状態を検証する必要があります。



自動実行は何かが変更されたという通知を受け取ります。再起動する必要があります。 関数の実行を開始し、nickNameフィールドにアクセスします。



今回は空ではありません。 これで機能が終了します。



監視対象フィールドのリストがどのように変更されたかを確認してください。 nickNameフィールドのみにアクセスしたため、依存関係のリストに残ります。 依存関係のリストにある他の3つのフィールドもすべて飛び出します。 木を見ると、このようになっています。



コードはnickNameが空になるまでfullNameフィールドに到達しないように設計されているため、nickNameが変更されるまで、autorunは通常、firstNameおよびlastNameフィールドへの変更を無視します。



各実行での反応が依存関係のリストを再構築することを理解することは非常に重要です。 コンポーネントまたは副作用が依存するフィールドのリストは静的に収集されるのではなく、作成するコードには収集されません。 追跡する必要があるフィールドの配列-実行中のコードの分析に基づいて動的に組み立てられます。 サブスクリプションの最小セットは、実行時に収集された場合にのみ取得できます。



自動実行だけが反応の例ではありません。 反応オブザーバーがいます。 これはReactのヘルパーです。



サンプルをReactコンポーネントとして書き換えると、次のようになります。



オブザーバーデコレーターを使用します。 ここで、通常のラッパーを使用できます。 renderメソッド内で、最初にnickNameにアクセスします。 空の場合は、fullNameに。 まったく同じロジック。 唯一のことは、オブザーバーを使用する場合、自動実行機能を実行しないことです。代わりに、サブスクライブするフィールドを変更すると、コンポーネントのリダイレクトが開始されます。



コンポーネントとオブザーバーの自動サブスクリプションにより、Reactコンポーネントの再描画の回数を劇的に最小限に抑えることができます。



renderメソッドの最初にチェックする何らかのフラグがある場合、しばしば観察可能なコードがあります。 失敗した場合は、単にnullを返します。 ここでReact Magicが本当に役立ちます。 変更が偽である限り、オブザーバーは、多くのコードが記述されている以下で使用されるフィールドへの変更を無視します。 ただし、フラグが点灯するとすぐに、次のレンダラーで次のコードが実行され、そこで使用されるフィールドへの変更がサブスクライブされます。



Reactがハウスオペレーションを節約する場合、MobXはバーチャルハウスオペレーションを節約します。 仮想住宅でも再描画が少ないほど、アプリケーションは高速になります。



MobXに組み込まれている別の最適化、計算キャッシュについて説明します。



ここで、fullNameは単純ですが、一般的に非常に複雑です：いくつかのフィルター、削減、複雑な計算。 問題が発生します：毎回このゲッターを使用する場合、同じ操作を実行するたびにこれらの操作をすべて不必要に実行する必要はありませんか？ キャッシュに入れられないのはなぜですか？



計算が使用するデータが変更されるまで、計算は初めて計算を実行し、値をキャッシュに入れ、誰かがそれにアクセスするたびに、すぐにキャッシュから値を与えます。



ただし、nickNameフィールドを設定し、fullNameから自動登録解除すると、その時点でfullNameはサブスクライバーがなくなったことを認識すると、キャッシュを破棄します。キャッシュは、ガベージコレクターによって収集され、通常のゲッターのように機能します。



キャッシングは常にサブスクライバの可用性に依存し、サブスクライバは常に複数になる場合があります。



このアプローチで非同期データを操作する方法の小さな例。



手動でロードメソッドを起動し、フラグisLoading TrueまたはFalseを実行できますが、MobXにはfromPromiseというヘルパーがあります。



特定のフィールドを宣言し、fromPromiseヘルパーで非同期操作をラップすると、このフィールドに2つのサブフィールド（状態と値）が表示されます。



Reactコンポーネントでは、最初にその状態が保留中であることを確認できます。 次に、ある種の負荷を示します。 いっぱいになったら、値フィールドに戻り、コンポーネントをさらに描画します。



合計、さらにMobX。



すでに聴衆から質問があります。 私はこの男をReduxmanと呼びます。これはReduxで多くのコードを書いた人です。 彼はどんな質問をしていますか？





しかし、ネタビリティについてはどうですか？ しかし、メソッドを使用してモデルフィールドを直接変更できますか？ さて、イチジクではありません。



しかし、タイムトラベルはどうですか？ メソッドを備えたモデルは必要ありませんが、元に戻す、やり直し、その他のおいしいことを支援できるように、単純なプレーンなJavaScriptオブジェクトが必要です。



ユーザーが実行したアクションを再現できるように、私が既に慣れているお気に入りの開発ツールはどうですか？



Reduxについて少し説明します。 彼が開発者の頭で行った主な変更。



彼はOOPから関数型プログラミングに移行しました。 モデルの代わりに、不変の構造が使用され始めました。 メソッドの代わりに、アクションとリデューサーがあります。 通常の接続の代わりに、モデル間のリンクに正規化とセレクターが追加されました。



そして、これは非常にクールで、Reduxも大好きです。しかし、気になる点が1つあります。多くの定型文、手で書かなければならないことがたくさんあります。 何らかの種類のアクションを追加する必要がある場合、アクション、レデューサーがあります。多くの場合、セレクターがまだ必要です。 そして、私は猿の仕事をしているという感覚があります。



ReduxがMobXとどう違うのか考え始めたとき、私はそのようなアナロジーを持ちました。







誰もがこの漫画が好きですか？ そして、若い世代が見ている漫画はどうですか？ 彼らはそのようなものです。







違いは何ですか？ このように描かれた「トムとジェリー」は、フレームを取り、それぞれを個別に描いた。



何にも似ていませんか？ Reduxアプリケーションの不変ストア。 手で作成するインプリントがあるたびに、不変またはObject.assignまたはspreadオペレータライブラリを使用します。 アプリケーションの現在の状態を手で描くたびに。 ロールバックする必要がある場合は、取得してロールバックします。 これはすべてクールで、多くのコードのみが取得されます。 コードを書くのは好きではなく、削除するのが好きです。 コードは悪です。 最速のコードは、実行されないコードです。



そして、新しい漫画はこのように描きます。







3次元モデルを描画し、プログラムで回転し、フレームを取り、逆に回転させ、フレームを取ります。 彼らは生きているモデルを制御し、それから単純にスクリーンに投影します。



手で不変データを操作しようとしているという事実はオプションです。 アプリケーションの不変の状態は、別のビュー、別のビュー、別のディスプレイです。 常に生きているモデルを使用して、いつでもそのフラットな投影を取得できます。



その方法を示しましょう。 MobXの作成者は、このような別個の部分を作成しています。 これは、アプリケーションの作成方法を決定する、より説得力のあるアプローチですが、見返りに多くの利点があります。



小さなストアを作成して、Todoクラスを宣言しましょう。このために、モデルメソッドを持つ型ヘルパーを使用します。 空の間に。



タイトルを追加します。



ここでは、それが文字列であることを宣言します。



オプションのブールフィールドisCompletedを追加します。 ちなみに、短く書く機会があります。 何らかの種類のプリミティブを割り当てると、mobx-state-treeは、これがデフォルト値を持つオプションのプリミティブフィールドであることを理解します。



参照を追加します。 これは、フォルダーが他のオブジェクトのIDを含むことを意味しますが、mobx-state-treeモデルを作成するとき、このIDは特定のストアからこのオブジェクトを取得し、このフィールドに配置します。 少し後で例を示します。





すべての魔法が機能するには、Folderクラスを宣言する必要があります。このクラスには、types.identifier型のidが必要です。 これは、リンクをストアオブジェクトに識別子で関連付けるためです。



メインルートのTodoStoreを宣言します。ここには、todosとfolderの2つの配列があります。 ここでは、types.arrayの使用方法を確認できます。クラスを引数として渡すと、MobXはこのクラスのインスタンス配列であることを理解します。



ゲッターを宣言すると、前に見たように、MobXの用語から自動的に計算されます。 ここには、完了したTodosゲッターがあります。これは、完了したすべてのTodoのリストを単に返すだけです。 キャッシュされ、少なくとも1つのサブスクライバーがある限り、常にキャッシュされた値を返します。 このように書くこと、複雑な式を書くことを恐れないでください。これはすべてキャッシュされます。



これがアクションの作成方法です。 宣言の最初のオブジェクトはプロパティであり計算され、2番目のオブジェクトはアクションをリストします。 ここでは、それらを既に宣言する必要はありません。mobx-state-treeはデフォルトで、2番目のオブジェクトに渡すものはすべてアクションであると信じています。



ストアを作成してみましょう。 データがあります。たとえば、サーバーからのもので、正規化された形式であり、フォルダーに1があり、フォルダーリストに識別子1のオブジェクトがあるとします。



作成、使用します。



最初の行-すべては問題ありません。todoオブジェクトのtitleフィールドを使用します。



2行目はすでに魔法です：フォルダーは参照として宣言されているため、モデルの作成時にMobXはまずフォルダーをフォルダー配列に入れ、todoモデルに参照によって、識別子によって、このオブジェクトへのリンクを追加します。 Reduxのセレクターは、ここでそのまま使用できます。 リンクのネストされたフィールド、参照に安全にアクセスできます。 そして、それは機能します。セレクターや他のプロップへのマップ状態なしでコンポーネントを書くことは非常に便利です。



ある種の3Dモデルを作成しました。 実行してみましょう。 カメラ、モーター。



まず、モデルに入れたデータを取り戻そうとします。 これにはgetSnapshotヘルパーがあります。 モデルをそこに転送し、すべての編集者が好むように、通常のJSオブジェクトの形式でスナップショットを取得します。 受信し、受信しましたが、私のモデルは絶えず変化しています。どのように変更にサブスクライブしますか？



非常に簡単：モデル内の任意のフィールドを変更するためにサブスクライブできるonSnapshotヘルパーがあり、パラメーターとして、生成する新しいスナップショットを常に渡しますが、そうではなく、そうでない場合は毎回新しいオブジェクトを生成するのは愚かなことです。 Reactと同様に、不変を使用します。



一部の部品が変更された場合、彼はそれらを再利用し、構造共有メカニズムを開始します。



変更されたため、新しいオブジェクトを作成します。



タイムトラベルの作り方は？ 履歴を見て、ある種のスナップショットをモデルに適用したいと思います。 applySnapshotヘルパー、パスモデル、パス、スナップショットがあります。 送信したものと現在モデルにあるものを比較し、差分を取り、変更された部分のみを更新します。



同時に、識別子が一致する場合、モデルを再利用します。 id = 1のフォルダーがモデル内にある場合、id = 1のフォルダーもスナップショットに転送されますが、上書きしようとするのではなく、フォルダー自体のデータが変更された場合は更新されます。



識別子を正しく設定した場合、モデル内のインスタンスは上書きされません。



おそらく、ライブモデルとスナップショットがどのように機能するかの最も印象的なイラストでしょう。



生きているモデルがあり、いつでもスナップショットを取得できます。



最後に、特に編集者にとってのボーナス。 Reduxを操作するためのアダプターがあります。 , Redux style, store mobx-state-tree store reduxStore asReduxStore.



ReduxDevtools, connectReduxDevtools, , store mobx-state-tree, .



- immutable-. -, , , . - , .



. , . Todo.folder.parent , . , , .



, . , React. , . — Redux Store Redux Devtools.



, MobX — React, . , :

• MobX
• mobx-state-tree
• Becoming fully reactive: an in-depth explanation of MobX
• MobX vs. Redux Performance
• An artificial example where MobX really shines and Redux is not really suited for it

.