Atom-リアクティブアプリケーションの最小限のブリック

こんにちは、私の名前はDmitry Karlovskyと私はクライアント側の開発者です。 未知のオンラインストアからYandexのような巨人まで、さまざまなサイトやWebアプリケーションを8年間サポートしています。 そしてこの間ずっと、私は本番で考えているだけでなく、テクノロジーの最先端にいるようにaを研ぎ澄ませています。 そして今、あなたが私が山から来た西洋ワサビではないことを知っているとき、私が過去1年間使用してきた1つの建築技術について話させてください。



この記事では、変数間の追跡依存関係を自動化し、その値を効果的に更新するように設計された「原子」抽象化について読者に紹介します。 Atomは任意の言語で実装できますが、記事の例はJavaScriptで記述されます。



注意：読書は脳の脱臼、ホリバーの攻撃、リファクタリングの眠れぬ夜を引き起こす可能性があります。

単純なものから複雑なものまで

この章では、かなり単純なアプリケーションの典型的な進化について簡単に説明し、読者を徐々にアトムの概念に導きます。



まず、このような単純なタスクを想像してみましょう。ユーザーにウェルカムメッセージを書き込む必要があります。 これを実装することは難しくありません：

this.$foo = {} $foo.message = ', !' $foo.sayHello = function(){ document.body.innerHTML = $foo.message } $foo.start = function(){ $foo.sayHello() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、名前でユーザーに連絡するのは良いことです。 ユーザー名がlocalStorageに保存されている場合、実装はもう少し複雑になります。

  this.$foo = {} $foo.userName = localStorage.userName $foo.message = ', ' + $foo.userName + '!' $foo.sayHello = function(){ document.body.innerHTML = $foo.message } $foo.start = function(){ $foo.sayHello() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、初期化中にuserNameとメッセージの計算が行われますが、sayHelloが呼び出されるまでにその名前がす​​でに変更されている場合はどうでしょうか？ あまり良くない古い名前で彼に挨拶することがわかります。 したがって、実際に表示する必要がある場合にのみメッセージが計算されるようにコードを書き直しましょう。

  this.$foo = {} $foo.userName = function( ){ return localStorage.userName } $foo.message = function( ){ return ', ' + $foo.userName() + '!' } $foo.sayHello = function(){ document.body.innerHTML = $foo.message() } $foo.start = function(){ $foo.sayHello() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メッセージとuserNameフィールドのインターフェースを変更しなければならないことに注意してください-これらは値自体を保存するのではなく、それらを返す関数を保存します。

論文1：インターフェースを変更する際に、自分自身や他の開発者が退屈なリファクタリングに陥らないように、すぐに内部実装を自由に変更できるインターフェースを使用してみてください。

Object.definePropertyを使用して関数呼び出しを非表示にできます 。

  this.$foo = {} Object.defineProperty( $foo, "userName", { get: function( ){ return localStorage.userName } }) Object.defineProperty( $foo, "message", { get: function( ){ return ', ' + $foo.userName + '!' } }) $foo.sayHello = function(){ document.body.innerHTML = $foo.message } $foo.start = function(){ $foo.sayHello() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、次の理由から明示的な関数呼び出しをお勧めします。



* IE8は、domノードのObject.definePropertyのみをサポートします。

*関数は、$ foo.title（ 'Hello！'）.UserName（ 'Anonymous'）の形式のチェーンに配置できます。

*関数はどこかにコールバックとして渡すことができます：$ foo.userName.bind（$ foo）-プロパティ全体が転送されます（ゲッターとセッターの両方）。

*フィールドの関数は、グローバル識別子から検証パラメータまで、さまざまな追加情報を保存できます。

*存在しないプロパティに目を向けると、暗黙的にundefinedを返すのではなく、例外が発生します。



しかし、メッセージを表示した後にユーザー名が変わったらどうしますか？ 永久に、この点を追跡してメッセージを再描画する必要があります。

  this.$foo = {} $foo.userName = function( ){ return localStorage.userName } $foo.message = function( ){ return ', ' + $foo.userName() + '!' } $foo._sayHello_listening = false $foo.sayHello = function(){ if( !$foo._sayHello_listening ){ window.addEventListener( 'storage', function( event ){ if( event.key === 'userName' ) $foo.sayHello() }, false ) this._sayHello_listening = true } document.body.innerHTML = $foo.message() } $foo.start = function(){ $foo.sayHello() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、ここでひどい罪を犯しました-sayHelloメソッドの実装は、突然、userNameプロパティの内部実装を知っています（値の取得元を知っています）。 例ではわかりやすくするために近くにあることに注意してください。 実際のアプリケーションでは、そのようなメソッドはさまざまなオブジェクトにあり、コードはさまざまなファイルにあり、さまざまな人々によってサポートされます。 したがって、1つのプロパティがパブリックインターフェイスを介して別のプロパティの変更をサブスクライブできるように、このコードを書き換える必要があります。 コードを過度に複雑にしないために、jQueryのpub / sub実装を使用します 。

  this.$foo = {} $foo.bus = $({}) $foo._userName_listening = false $foo.userName = function( ){ if( !this._userName_listening ){ window.addEventListener( 'storage', function( event ){ if( event.key !== 'userName' ) return $foo.bus.trigger( 'changed:$foo.userName' ) }, false ) this._userName_listening = true } return localStorage.userName } $foo._message_listening = false $foo.message = function( ){ if( !this._message_listening ){ $foo.bus.on( 'changed:$foo.userName', function( ){ $foo.bus.trigger( 'changed:$foo.message' ) } ) this._message_listening = true } return ', ' + $foo.userName() + '!' } $foo._sayHello_listening = false $foo.sayHello = function(){ if( !this._sayHello_listening ){ $foo.bus.on( 'changed:$foo.message', function( ){ $foo.sayHello() } ) this._message_listening = true } document.body.innerHTML = $foo.message() } $foo.start = function(){ $foo.sayHello() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、プロパティ間の通信は単一のバス$ foo.busを介して実装されますが、個々のEventEmitterが散在することもあります。 原則として、同じスキームは次のようになります。あるプロパティが別のプロパティに依存する場合は、どこかでその変更をサブスクライブする必要があり、変更する場合は、変更に関する通知を送信する必要があります。 また、プロパティ値の追跡が不要になった場合、このコードでは登録解除オプションはまったく提供されません。 グリーティングメッセージでユーザー名を表示するか表示しないかの状態に応じて、showNameプロパティを導入しましょう。 このようなかなり典型的な問題のステートメントの機能は、showName = 'false'の場合、メッセージテキストがuserNameの値に依存しないため、このプロパティをサブスクライブしないことです。 さらに、以前にshowName = 'true'があったため、すでにサブスクライブしている場合、showName = 'false'を受け取った後、userNameからサブスクライブを解除する必要があります。 そして、人生がまったく楽園のように見えないように、別の要件を追加します。localStorageプロパティから取得した値は、再度触れないようにキャッシュする必要があります。 実装は、以前のコードとの類推により、この記事では既にボリュームが大きすぎるため、少しコンパクトな擬似コードを使用します。

  property $foo.userName : subscribe to localStorage return string from localStorage property $foo.showName : subscribe to localStorage return boolean from localStorage property $foo.message : subscribe to $foo.showName switch test $foo.showName when true subscribe to $foo.userName return string from $foo.userName when false unsubscribe from $foo.userName return string property $foo.sayHello : subscribe to $foo.message put to dom string from $foo.message function start : call $foo.sayHello
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、情報の重複が顕著です。実際にプロパティ値を取得する以外に、その変更をサブスクライブする必要があります。一部のプロパティの値が不要であることが判明したら、反対に、その変更をサブスクライブ解除します。 これは非常に重要です。影響を受けていないプロパティから時間内に登録を解除しないと、アプリケーションがより複雑になり、処理されるデータの数が増えると、全体的なパフォーマンスがますます低下するためです。

テーゼ2：影響のない依存関係を時間内にサブスクライブ解除します。そうしないと、遅かれ早かれアプリケーションの速度が低下し始めます。

上記のアーキテクチャは、イベント駆動型と呼ばれます。 そして、これはさらにひどいオプションです-より一般的なケースでは、サブスクリプション、サブスクライブ解除、および値を計算するいくつかの方法がプロジェクトのさまざまな場所に散在しています。 タイムリーなサブスクリプションとサブスクリプションを手動で監視する必要があるため、イベント駆動型アーキテクチャは非常に脆弱です。また、人は怠zyな生き物であり、あまり注意を払っていません。 したがって、最良の解決策は、プログラマーからイベントを配布するメカニズムを隠すことにより、ヒューマンファクターの影響を最小限に抑えることです。これにより、プログラマーは他のユーザーからのデータの取得方法の説明に集中できます。



最低限必要な依存関係情報のみを残して、コードを単純化しましょう。

  property userName : return string from localStorage property showName : return boolean from localStorage function $foo.message : switch test $foo.showName when true return string from $foo.userName when false return string property $foo.sayHello : put to dom string from $foo.message function start : call $foo.sayHello
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

警戒心の強い読者は、手動のサブスクリプション/サブスクライブ解除を取り除いた後、プロパティの説明がいわゆる「純粋な機能」であることに気づいたと思われます。 そして実際、 FRP （Functional Reactive Paradigm）を入手しました。 各用語をさらに詳しく見てみましょう。



機能-各変数は、他の変数の値に基づいて値を生成する関数として記述されます。

リアクティブ-1つの変数を変更すると、それに依存するすべての変数の値が自動的に更新されます。

パラダイム-プログラマーは、アプリケーションの構築の原則を理解し、受け入れるために少し気を配る必要があります。



ご覧のとおり、上記のすべては変数とそれらの間の依存関係を中心に展開しています。 このようなfrp変数を「原子」と呼び、その主な特性を述べます。



1.アトムは、それ自体に値を1つだけ保存します。 この値は、プリミティブまたは例外オブジェクトを含む任意のオブジェクトのいずれかです。

2.アトムは、任意の数の中間関数を介して他のアトムに基づいて値を計算するための関数を格納します。 実行中に他のアトムへのアピールが監視されるため、アトムは常に、他のどの原子がその状態に影響するか、およびどの原子がそれに依存するかの状態に関する最新情報を保持します。

3.アトムの値を変更する場合、それに依存するものはカスケードで更新する必要があります。

4.例外は、アプリケーションの状態の一貫性に違反してはなりません。

5.アトムは、命令型環境と簡単に統合する必要があります。

6.ほとんどすべてのメモリスロットがアトムにラップされているため、アトムの実装は可能な限り高速かつコンパクトにする必要があります。

アトムの実装の問題

1.依存関係を最新の状態に保つ

1つの原子の値を計算するときに、別の原子の値が必要な場合、最初の原子が2番目の原子に依存していると確信を持って述べることができます。 必要でない場合は、直接的な依存関係はありませんが、間接的な依存関係は可能です。 しかし、追跡が必要であり、直接的な依存関係だけで十分です。



これは非常に簡単に実現されます：グローバル変数のどこかで1つの原子の計算を開始した瞬間に、それは現在の原子であることが記憶され、他の原子の値を受け取った瞬間に、実際にこの値を返すことに加えて、それらは互いにリンクされています。 つまり、実際の値のスロットに加えて、各アトムには、先頭のアトム（マスター）とスレーブ（スレーブ）の2つのセットが必要です。



リンクを使用すると、すべてがやや複雑になります。開始時には、先頭の原子のセットを空の原子に置き換える必要があり、計算が完了したら、結果のセットを前の原子と比較して、新しいセットに含まれていない原子をリンクします。



同様に、自動追跡の依存関係はKnockOutJSおよびMeteorJSで機能します。



しかし、原子は値計算をいつ再実行するかをどのようにして知るのでしょうか？ さらにそれについて。

2.一貫した値のカスケード更新

それは簡単だと思われるでしょうか？ 値を変更した直後に、依存原子を調べて更新を開始します。 これはまさにKnockOutJSが行うことであり、それが大量更新中に速度が低下する理由です。 たとえば、1つの原子（A）が他の2つの原子（B、C）に依存している場合、それらの値を連続的に変更すると、原子Aの値が2回計算されます。 ここで、2つではなく2000の原子に依存し、各計算に少なくとも10ミリ秒かかると想像してください。







KnockOutJS開発者にとってthrottl-iniとdebounce-erasはボトルネックに置かれていますが、MeteorJS開発者はより体系的な方法でこの問題に取り組みました：即時の代わりに依存原子を再計算する遅延呼び出しを行いました。 上記の場合、アトムAはその値を正確に1回再カウントし、現在のイベントハンドラーの最後、つまりアトムB、C、およびその他に行ったすべての変更の後にそれを行います。



しかし、これは実際には問題に対する完全な解決策ではありません-アトミック依存性の深さが2を超えると再びポップアップします。これを簡単な例で説明します。原子Aは原子BとCに依存し、CはDに依存します。原子BとDを順番に変更すると、原子AとCが遅れてカウントされ、原子Cの値が変化すると、Aの値の遅延計算が再び開始されます。これは通常、速度にとってそれほど致命的ではありませんが、非常に長い操作、それを倍にすることができます 最も予想外の場所の用途に注ぎます。







問題を理解すると、解決策を思い付くのは簡単です。原子をリンクするときは、リーダーの最大深度プラス1を記憶するだけで十分です。まず、更新のために取っておいた原子を反復処理するときに、より浅い原子を更新します。 このような単純な手法により、原子の値が再計算されるまでに、原子が直接依存するすべての原子が実際の値を持つことを保証できます。

3.例外処理

この状況を想像してください。原子BとCはAに依存します。原子Bは値の計算を開始し、Aに変わりました。また、その値の計算を開始しましたが、その瞬間に例外が発生しました-コードの誤りまたはデータの不足-重要ではありません。 主なことは、アトムAがこの例外を記憶する必要があるが、Bがそれを記憶または処理できるように、それをさらにフロートさせることです。 なぜこれがそんなに重要なのですか？ Cが値の計算を開始してAに変わると、そのために発生するイベントはBの場合と同じになるはずです。Aにアクセスすると、インターセプトおよび処理できる例外がポップアップするか、何も実行せずに例外を実行する必要がありますアトムを実装し、計算されたアトムに保存されているライブラリにキャッチされます。 アトムが例外を記憶していなかった場合、アトムにアクセスすると同じコードが起動され、必然的に同じ例外が発生します。 これはプロセッサリソースの無駄であるため、通常の値のようにキャッシュすることをお勧めします。







もう1つの、さらに重要な点は、カスケード原子の更新中に、これらの値が反対方向に計算されることです。 たとえば、アトムAはBに依存し、それはCに依存し、一般的にはDに依存します。初期化すると、Aはその値の計算を開始してBに変わり、Cに進み、Dに進みます。ただし、状態は逆の順序で更新されます。次にC、次にB、最後にA：







その後、誰かがアトムDの値を変更します。彼は、アトムCにその値がもはや関係ないことを通知します。 次に、アトムCはその値を計算し、前の値と等しくない場合、アトムBに通知します。これは同様にAに通知します。これらの瞬間に例外をキャッチせず、その結果、依存原子に通知しない場合、状況を取得します。アプリケーションが矛盾した状態にあるとき：アプリケーションの半分は新しいデータを含み、半分は古いが、それは新しいものであることが確実であり、3番目の半分は一般的に落ちてデータが変更されるのを待つことができません。

4.循環依存

循環依存の存在は、プログラムの論理エラーを示しています。 ただし、保留中の計算の無限ループでプログラムがフリーズまたはスピンすることはありません。 代わりに、アトムは、その値を計算して例外をスローするためにその値が必要であることを検出する必要があります。



それは簡単に検出されます：計算が開始されると、アトムは計算されていることを記憶し、誰かがその値に戻ると、計算状態にあるかどうかをチェックし、そうであれば例外をスローします。

5.非同期

非同期コードは、ロジックをスパゲッティに変えるため、常に問題になります。スパゲッティの複雑さを追跡するのは難しく、ミスを犯しやすいからです。 JavaScriptで開発するときは、単純で明確な同期コードと非同期呼び出しの間で絶えずバランスを取る必要があります。 非同期の主な問題は、インターフェイスを介してモナドとしてリークすることです。モジュールAの同期実装を記述し、それを使用してモジュールAをモジュールBから非同期に静かに変更することはできません。 このような変更を行うには、それに依存するモジュールB、C、およびDのロジックを変更する必要があります。 非同期性は、すべての抽象化を突破し、内部の実現を押し進めるウイルスのようなものです。



しかし、原子はこの問題を簡単かつ簡単に解決しますが、原子についてはまったく考えていませんでした。すべてが反応性です。 あるアトムが別のアトムに変わると、ある種の答えがすぐに得られ、その間に非同期タスクが開始されます。その後、値が更新され、受信したデータに従ってアプリケーション全体が更新されます。 即時応答には、いくつかのタイプがあります。



a）デフォルト値を返します。 駆動された原子の場合、「1つの値があり、突然変化しました」ように見えますが、表示された実際のデータを理解することはできません。 また、これを知る必要があることがよくあります。たとえば、データがどこにも消えず、ロードされようとしているというメッセージをユーザーに表示するためです。



b）ローカルにキャッシュされたバージョンを返します。 このオプションは、データの変更が比較的まれな場合に適しています。 たとえば、この記事の冒頭のユーザー名は、アプリケーションの起動の間に名前を変更しても大丈夫です。したがって、以前の名前をしばらくの間熟考しますが、ほとんどすぐにアプリケーションの操作を開始できます。 もちろん、このアプローチは重要なデータには適していません。特に、接続に問題がある場合は、更新に非常に時間がかかる可能性があります。



c）正直なところ、データがなく、データがないことを意味する特別な値を返します。 javascriptの場合、これは未定義になります。 しかし、この場合、依存コードのすべての場所でこの値の正しい処理が必要です-これは、間違いを犯しやすいほど十分に大量の同じタイプのコードであるため、このパスを選択することで、Null Pointer Exceptionに備えてください。



d）非同期タスクを開始した後、特別な例外をスローします。これは、上記のように、すべての依存アトムを処理可能なアトムにカスケードします。 たとえば、ユーザーのリストの表示を担当するアトムは、例外をキャッチし、静かに落ちるのではなく、「読み込み中」または「読み込みエラー」というメッセージをユーザーに表示します。 つまり、何らかのリモートアトムから始めて、例外的な状況が非常に規則的になります。 この方法の利点は、データの不足を比較的少数のコード場所でのみ処理でき、これらの場所までは処理できないことです。 しかし、ここで重要なのは、いくつかのアトムによっては、例外が最初にスローされた後に計算が停止し、残りのユーザーはデータが必要であることを知らないことです。 幸いなことに、これらの瞬間はサーバーへの過剰なリクエストによって簡単に検出され、適切な場所にtry-catchを設定することで恥ずかしそうに修正されません。

6.特権コードとの統合

FRPがどんなに美しくても、特効薬ではなく、すべての問題を解決できるわけではありません。さらに、友達になるために必要な多くの命令型ライブラリとネイティブAPIがあります。したがって、まず第一に、アトムの値を変更するという事実に基づいて任意のコードを実行することが可能であるべきです。さらに、上で説明したように、組み込みの関数を介さずに、値を直接変更できる必要があります。ただし、これらの機能の使用は最小限に抑えることをお勧めします。これらの機能を使用するには、注意と実装の精度を高める必要があるためです。



使用戦略に応じて、原子を3つの主要なタイプに分割することが条件的に可能です



。a）状態のソースは、その値を計算する方法を知らない原子です。誰かがそれを具体的に配置した場合にのみ、変更します。

b）中間-遅延状態の原子。アドレスが指定されると、他の原子に基づいて状態が計算されます。しかし、彼らに信者がいない場合、彼らは指導者から退会します。同時に、再び必要になった場合に備えてメモリに残しておくことも、リソースを消費しないように削除することもできます。

c）状態由来-外部の状態の変化を命令的に反映する原子。

7.メモリ消費

ここではすべてがそれほどバラ色ではありません-値が1ビットに収まる場合でも、各アトムは数十バイトの追加情報をそれ自体に格納します。



これは典型的なアトムが保存するものです：



a）実際の値

b）除外のオブジェクト（値と組み合わせることができますが、すべての言語で

はありません）c）現在の状態：関係ない、更新が計画されている、計算が進行中、関連する、エラー...

d）多くの先行アトム

e）駆動アトムのセット

e）最大深さ

e）駆動アトムの数

g）識別子（ポインタで識別できない言語の場合）

h）望ましい動作を実装する関数の束



依存関係グラフの精度にはかなりの費用がかかります。メモリを節約するためのいくつかの戦略があります：



a）1つのアトムに複数の値を保存することで精度を下げます。その結果、近隣のデータが変更されたときにいくつかの誤った通知がありますが、それを調べるには、値の計算を開始する必要があります。これは、AngularJSからの$ダイジェストの類似物を生成しますが、1つのアトムのフレームワーク内でのみであり、単に「できなかった」だけでなく、アトムで何かが変更された場合のみです。



b）中間原子の数を減らします。すべての中間値がキャッシュに適しているわけではありません。そのため、多くの場合、通常の関数が十分に速く実行され、先頭のアトムの変更があまり頻繁に発生しない場合は、通常の関数を使用できます。



c）ソース原子の数を減らします。複数のソースの代わりに、パラグラフ（a）のように1つ持つことができますが、直接アクセスするのではなく、ソースからデータを受け取り、必要な部分のみをチェックする中間アトムを介してアクセスします。このようにして、私たちはもっと悪いことをしているように思えます-例えば、10のソースを1つのソース+ 10の中間に変更しています。ただし、ソースにあるデータを失うことなく、データが不要な場合は中間のものが自己破壊できるため、必要に応じてこれらのアトムをすばやく復元できます。



d）結合の数を最小限にします。いくつかの主要な原子に基づいて値を計算するいくつかの中間原子を導入すると、結合の総数を減らすことができる場合があります。



e）動作を指定する関数は、アトム自体ではなく、サブクラスに配置する必要があります。同じように振る舞うアトムがたくさんある場合は、それらのサブクラスを作成して、振る舞いを指定し、異なるデータのみをインスタンスに保存するのが最善です。

エピローグ

要約すると、原子の界面を次の図の形式で体系化します







。A-原子。内側の円は彼の状態です。そして、外部はそのインターフェースの境界です。

Sはアプリケーションの駆動部分であり、アトムだけでなく、現在のアトムに何らかの形で依存するすべてのものが存在する可能性があります。

Mは、値が依存する主要部分です。



矢印はデータフローを示します。それらのファットエンドは、相互作用のイニシエーターを象徴しています。ユーザー定義関数を使用して動作を指定できるインターフェイスは、赤でマークされています。



そして、インターフェースについての詳細：

get-value request。値が関係ない場合は、プルを起動して更新します。

pullは、原子の値を計算するまさにその機能です。彼は自分の値を更新することを決定すると、この関数を呼び出します。その中で、非同期リクエストを実装し、プッシュインターフェースを介して値をアトムに入れることができます。

push-アトムの新しい値を設定しますが、そのままではなく保存されますが、最初にマージインターフェイスに渡されます

merge-新しい値と現在の値をマージします。正規化、ダーティチェック、検証があります。

notify-変更に関するスレーブへの通知。

fail-エラーに関するスレーブの通知。

set-このインターフェイスを介して、スレーブアトムはマスターに新しい値を提供できます。マージ後の新しい値が現在の値と異なる場合、putが呼び出されます。

put-デフォルトでプッシュしますが、その目的は、リードアトムに新しい状態を提供することです。



これですべてです。この記事はすでにかなり長く、ほとんどが理論的であることが判明しました。続編では、javascriptライブラリ「$ jin.atom」の使用方法がさらに増えます。上記に加えて、どのように機能するか、どの最適化が使用されたかを学びます。そしてもちろん、実用的な例もあります。継続を



見越して、自分で原子を実現しようとすることをお勧めします。次に、ソリューションを比較することは興味深いでしょう。