非同期の長い耳

React開発者は機能的なアプローチに引き寄せられますが、MobXの登場により、多かれ少なかれおなじみのOOPスタイルで状態を操作することが可能になりました。 Mobxは、通常のオブジェクトと同様に、アーキテクチャを強制しないようにして、リアクティブ状態で動作できるようにします。 同時に、彼はC = A + Bを書くのに十分なときに計算の自動リンクを行い、 C = A + B更新AとCも更新されるようにします。

HelloWorldではシンプルに見えますが、フェッチを追加し、ダウンロードステータスとエラー処理を表示すると、多くのコピーペーストが取得され、fromPromiseまたはlazyObservableなどのヘルパーがコードにリークし始めることがわかります。 そして、非同期性がないかのようにコードを書くことはすでに不可能です。 MobXのいくつかの同様の例を解析し、疑似同期のアイデアを開発することにより、その基本概念を改善したいと考えています。

データの読み込み

MobXとReactの最も簡単なTo Doリストを検討してください。

 const {action, observable, computed} = mobx; const {observer} = mobxReact; const {Component} = React; let tid = 0 class Todo { id = ++tid; @observable title; @observable finished = false; constructor(title) { this.title = title; } } function fetchSomeTodos(genError) { return new Promise((resolve) => setTimeout(() => { resolve([ new Todo('Get Coffee'), new Todo('Write simpler code') ]) }, 500)) } class TodoList { @observable todos = []; @computed get unfinishedTodoCount() { return this.todos.filter(todo => !todo.finished).length; } @action fetchTodos() { fetchSomeTodos() .then(todos => { this.todos = todos }) } } const TodoView = observer(({todo}) => { return <li> <input type="checkbox" checked={todo.finished} onClick={() => todo.finished = !todo.finished} />{todo.title} </li> }) TodoView.displayName = 'TodoView' @observer class TodoListView extends Component { componentDidMount() { this.props.todoList.fetchTodos() } render() { const {todoList} = this.props return <div> <ul> {todoList.todos.map(todo => <TodoView todo={todo} key={todo.id} /> )} </ul> Tasks left: {todoList.unfinishedTodoCount} </div> } } const store = new TodoList() ReactDOM.render(<TodoListView todoList={store} />, document.getElementById('mount')) 

フィドル

単純な場合、コンポーネントはcomponentWillMountを介してデータのロードを開始する必要があります。 todoListを使用する新しいコンポーネントを作成するたびに、プログラマはtodoList.todosをロードする必要があることに留意する必要があります。 これが行われない場合、誰がすでにこのデータをアップロードしたことを保証しますか？

もちろん、起動のためにcomponentWillMountを使用せずに状態とUIをより適切に分離できます。 MobXの著者であるMichel Weststrateが記事「状態とUIを分離する方法」で述べていること。 ページを開くと、そのレンダリングに必要なすべてのデータがサーバーから要求されます。 そして著者は、このダウンロードを初期化する責任をルーターに移すことを提案しています。

 import { createHistory } from 'history'; import { Router } from 'director'; export function startRouter(store) { // update state on url change const router = new Router({ "/document/:documentId": (id) => store.showDocument(id), "/document/": () => store.showOverview() }).configure({ notfound: () => store.showOverview(), html5history: true }).init() } 

このアプローチには問題があります。ルーターは、開くページに表示されるコンポーネントに必要な特定のデータを知る必要があります。 コードのこの時点でstore.showOverviewメソッドを呼び出すと、カプセル化に違反します。 リファクタリング中に、サーバーから何かを取得する必要があるページに新しいコンポーネントが追加されても、ダウンロードがルーターに追加されない場合はどうなりますか？ ストアでの作業の詳細はアプリケーション内のさまざまな場所に広がっているため、ここで間違いを犯すのは簡単です。

fetchTodos（）の呼び出しはcomponentWillMountにある必要はありません。 redux-sagaの例のように、一部のボタンでonClickを呼び出した後、index.jsで直接呼び出された後でも、ルーターの背後でHOCに変装することができます。

 ... import rootSaga from './sagas' const store = configureStore(window.__INITIAL_STATE__) store.runSaga(rootSaga) ... 

store.runSaga(rootSaga)は、アプリケーションの動作に必要なすべてのデータのダウンロードをすぐに開始します。

一番下の行は、プログラマーがダウンロードを開始するコード内の場所があるということです。 そして、この場所はモデルの外、またはモデルの代わり（sagasなど）になりますが、初期化呼び出しの事実の意味はネットワークでの作業の内部詳細にすぎません。 非同期性を削除すると、不要になります。 さらに、そのようなソリューションでのロードは、コンポーネントがこのデータにアクセスするという事実ではなく、事前に行われます。

非同期読み込みエラー処理

MobXでは、エラーとダウンロードステータスはそれ自体ではインターフェイスに到達しません。 それらを表示するには、ロードされる各エンティティのストアにエラープロパティを作成する必要があります。 todoList.todosを使用する各コンポーネントでは、このプロパティの処理を行う必要があります。ほとんどの場合は同じです。devモードでラベルまたはスタックトレースを表示します。 プログラマがそれらの処理を忘れると、ユーザーには何も表示されず、「何かがおかしい」という碑文も表示されません。

 class TodoList { @observable todos = [] @observable error: ?Error @observable pending = false @action fetchTodos(genError) { this.pending = true this.error = null fetchSomeTodos(genError) .then(todos => { this.todos = todos; this.pending = false }) .catch(error => { this.error = error; this.pending = false }) } } @observer class TodoListView extends Component { componentWillMount() { this.props.todoList.fetchTodos() } render() { const {todoList} = this.props return <div> {todoList.pending ? 'Loading...' : null} {todoList.error ? todoList.error.message : null} ... </div> } } 

フィドル

fromPromiseを使用します

前の例には、ストアとコンポーネントの両方に多くの定型コードがあります。 コピーと貼り付けを減らすには、 mobx-utilsの fromPromiseヘルパーを使用できます。このヘルパーは、値とともにこの値のダウンロードステータスを提供します。 これが彼の作品のデモンストレーションの例です：

 class TodoList { @observable todoContainer constructor() { this.fetchTodos() } // ... @action fetchTodos(genError) { this.todoContainer = fromPromise(fetchSomeTodos(genError)) } } const StatusView = ({fetchResult}) => { switch(fetchResult.state) { case "pending": return <div>Loading...</div> case "rejected": return <div>Ooops... {JSON.stringify(fetchResult.value)}</div> } } const TodoListView = observer(({todoList}) => { const todoContainer = todoList.todoContainer return <div> {todoContainer.state === 'fulfilled' ? ... : <StatusView fetchResult={todoContainer}/> } ... </div> }) 

フィドル

値とステータスを含むtodoContainerプロパティが既にあります。 コンポーネントでの処理はすでに簡単です。 上記の例では、TodoListスタックのコンストラクターでfetchTodosの呼び出しが行われます。 ルーティングの例とは異なり、これにより、fetchTodosを外部に公開せずに実装の詳細をより適切にカプセル化できます。 fetchTodosメソッドは、TodoList実装のプライベート部分のままです。

このアプローチの短所：

1. 読み込みのnew TodoList()が壊れ、 new TodoList()がサーバーにリクエストを送信します
2. コンポーネントでは、ダウンロードステータスのチェックを挿入し、対応するメッセージを表示する必要があります。
3. さて、コンポーネント内にのみある場合。 実際のアプリケーションでは、多くのデータソースが存在する可能性があり、それらのすべてがコンポーネントに直接ロールされるわけではなく、計算された値を介して変換されるものもあります。 このような各値では、データを使用したアクションの前に、常にステータスを確認する必要があります。 上記の例のunfinishedTodoCountメソッドのように

 class TodoList { //... @computed get unfinishedTodoCount() { return this.todoContainer.value ? this.todoContainer.value.filter(todo => !todo.finished).length : [] } //... } 

lazyObservableを使用する

（新しいTodoListではなく）コンポーネントをレンダリングするときに、最後の例の遅延をロードするには、fromPromiseをmobx-utilsのlazyObservableヘルパーにラップします。 ダウンロードは、コンポーネントでtodoContainer.current（）が実行された後に開始されます。

 class TodoList { constructor() { this.todoContainer = lazyObservable(sink => sink(fromPromise(fetchSomeTodos()))) } @computed get unfinishedTodoCount() { const todos = this.todoContainer.current() return todos && todos.status === 'fulfilled' ? todos.filter(todo => !todo.finished).length : [] } } const StatusView = ({fetchResult}) => { if (!fetchResult || fetchResult.state === 'pending') return <div>Loading...</div> if (fetchResult.state === 'rejected') return <div>{fetchResult.value}</div> return null } const TodoListView = observer(({todoList}) => { const todoContainer = todoList.todoContainer const todos = todoContainer.current() return <div> {todos && todos.state === 'fulfilled' ? <div> <ul> {todos.value.map(todo => <TodoView todo={todo} key={todo.id} /> )} </ul> Tasks left: {todoList.unfinishedTodoCount} </div> : <StatusView fetchResult={todos}/> } <button onClick={() => todoContainer.refresh()}>Fetch</button> </div> }) 

フィドル

lazyObservableヘルパーは、遅延の問題を解決しますが、コンポーネントの定型コードからあなたを救いません。 そして、 lazyObservable(sink => sink(fromPromise(fetchSomeTodos())))は、 fetchSomeTodos().then(todos => this.todos = todos)ように見えるのはそれほど簡単ではありませんfetchSomeTodos().then(todos => this.todos = todos) 、リストの最初のバージョンのfetchSomeTodos().then(todos => this.todos = todos)

代替案

「非同期性がないかのように書く」という考えを覚えておいてください。 MobXよりも先に進むとどうなりますか？ 誰かがこれをすでにできますか？

これまでのところ、 mol_atomは最も進んでいます。 このライブラリは、 ヴィンテージのmolフレームワークの一部です。 ここで、ハブで、著者は彼と彼の仕事の原則（ Objective Reactive ProgrammingまたはPIUなど）について多くの記事を書いています。 モルは、他のどこにも見られない彼のオリジナルのアイデアに興味を持っています。 問題は、独自のエコシステムがあることです。 mol_atomを使用して、react、webpackなどのプロジェクトで使用を開始することはできません。したがって、私は独自の実装lom_atomを作成する必要がありました。 実際、これは、mol_atomの適応であり、reactで使用するためにシャープ化されています。

遅延更新

lomのtodoリストを使用した同様の例を考えてみましょう。 まず、コンポーネントのある側を見てみましょう。

 /** @jsx lom_h */ //... class TodoList { @force $: TodoList @mem set todos(next: Todo[] | Error) {} @mem get todos() { fetchSomeTodos() .then(todos => { this.$.todos = todos }) .catch(error => { this.$.todos = error }) throw new mem.Wait() } // ... } function TodoListView({todoList}) { return <div> <ul> {todoList.todos.map(todo => <TodoView todo={todo} key={todo.id} /> )} </ul> Tasks left: {todoList.unfinishedTodoCount} </div> } 

フィドル

ここでは次のことが発生します。

1. レンダリングされたTodoListView。
2. このコンポーネントはtodoList.todosに変わり、 get todos()が機能し、サーバーからデータをロードするコードが実行されます。
3. データはまだ到着していないので、すぐにコンポーネントを表示する必要があります。 ここで、デフォルト値を返すか、例のように例外をスローすることができます： throw new mem.Wait() 。
4. memデコレータはこれをインターセプトし、todosにはTodoListViewのプロキシが付属しています。
5. そのプロパティのいずれかにアクセスすると、TodoListView内で例外がスローされます。
6. オーバーライドされたcreateElementがこのコンポーネントをラップし、このラッパーが例外をキャッチするため、ライブラリ設定によって設定されるErrorableViewが表示されます。
7. サーバーからデータが送信されると、 this.$.todos = todos （this。$- set todos() {}呼び出しをバイパスしてキャッシュに書き込むことを意味します）。

ErrorableViewには次のようなコンテンツが含まれます。

 function ErrorableView({error}: {error: Error}) { return <div> {error instanceof mem.Wait ? <div> Loading... </div> : <div> <h3>Fatal error !</h3> <div>{error.message}</div> <pre> {error.stack.toString()} </pre> </div> } </div> } 

どのコンポーネントとどのデータが使用されていても、デフォルトの動作はすべてのユーザーで同じです。例外を除き、ねじれ（mem.Waitの場合）またはエラーテキストが表示されます。 この動作により、コードと神経が大幅に節約されますが、場合によっては再定義する必要があります。 これを行うには、カスタムErrorableViewを指定できます。

 function TodoListErrorableView({error}: Error) { return <div>{error instanceof mem.Wait ? 'pending...' : error.message}</div> } //... TodoListView.onError = TodoListErrorableView 

フィドル

try / catch todoList.todosでラップすることで、TodoListView内で例外を簡単にキャッチできます。 コンポーネントでスローされた例外は、コンポーネントのみをドロップし、ErrorableViewを描画します。

 function TodoView({todo}) { if (todo.id === 2) throw new Error('oops') return <li>...</li> } 

フィドル

この例では、2番目のタスクの代わりに致命的エラーのみが表示されます。

このような例外アプローチには、次の利点があります。

1. 例外は自動的に処理され（TodoListにはthis.errorはなくなりました）、ユーザーにエラーメッセージが表示されます。
2. 例外はアプリケーション全体を破壊するのではなく、発生したコンポーネントのみを破壊します。
3. 例外と同様に、ダウンロードステータスは自動的に処理されます（TodoListにはthis.statusはなくなりました）。
4. アイデアは非常に単純なので、非同期コードを擬似同期コードに変換するためにfromPromiseやlazyObservableなどのヘルパーは必要ありません。 すべての非同期操作はget todos()ハンドラーにカプセル化されます。
5. コードはほぼ同期しているように見えます（フェッチを除きますが、その上で、擬似同期形式で記述できるラッパーを作成できます）。

MobXと比較して、ボイラープレートははるかに小さくなっています。 各行はビジネスロジックの行です。

ノンブロッキングダウンロード

そして、1つのコンポーネントにロードされた複数のエンティティを表示すると、つまり、todoに加えて、たとえばユーザーがまだいる場合はどうなりますか。

 class TodoList { @force $: TodoList @mem set users(next: {name: string}[] | Error) {} @mem get users() { fetchSomeUsers() .then(users => { this.$.users = users }) .catch(error => { this.$.users = error }) throw new mem.Wait() } //... } function TodoListView({todoList}) { const {todos, users} = todoList //... todos.map(...) users.map(...) } 

フィドル

TodoListViewの最初のレンダリングで、todosとユーザーがロードされていない場合、代わりにプロキシオブジェクトがコンポーネントに届きます。 つまり、 const {todos, users} = todoList 、 get todos()およびget users()が実行され、それらの並列ロードが開始され、mem.Waitがスローされ、memがプロキシで例外をラップします。 コンポーネントでは、todos.mapプロパティまたはusers.mapにアクセスすると、mem.Wait例外がスローされ、ErrorableViewがレンダリングされます。 ロード後、コンポーネントは再びレンダリングされますが、実際のデータはTodoとユーザーに表示されます。

これはmolが同期コードと呼んでいますが、非ブロッキング要求です。

このアプローチには本当にマイナスがあります。最初にtodoListからtodoとユーザーを削除してから作業する必要があります。そうしないと、順次読み込みが行われ、最適化が失敗します。

キャッシュ管理

上記の例は非常に単純です。 memデコレータは非常にスマートなキャッシュです。つまり、todoが1回起動された場合、2回目にmemがキャッシュからそれらを返します。

キャッシュがあるため、 set todosハンドラーをバイパスして、キャッシュに書き込むことができるはずです。 そのため、キャッシュの無効化の問題があります。 依存関係が変更された場合、値を自動的にリセットする方法が必要です。また、ボタンを押すなどしてデータを再ストレッチする必要がある場合は、値を手動でリセットできる必要があります。

依存関係が変更され、コンポーネントの更新がMobXと同様に処理される場合のクリーンアップ。 また、手動のキャッシュ管理の問題は、強制デコレーターによって解決されます。 彼の仕事は次の例で示されています。

 class TodoList { @force forced: TodoList // .. } function TodoListView({todoList}) { return <div> ... <button onClick={() => todoList.forced.todos}>Reset</button> </div> 

フィドル

[リセット]ボタンをクリックすると、todoList.forced.todosが要求されます。これにより、 get todosが無条件に実行され、キャッシュが補充されます。 todoList.forced.todosに値を割り当てると、 set todosハンドラーをバイパスして、値がキャッシュに書き込まれます。

上記のコードを覚えておいてくださいthis.$.todos = todos ？

 /** @jsx lom_h */ //... class TodoList { @force $: TodoList @mem set todos(next: Todo[] | Error) {} @mem get todos() { fetchSomeTodos() .then(todos => { this.$.todos = todos }) .catch(error => { this.$.todos = error }) throw new mem.Wait() } // ... } 

キャッシュへの書き込みは、プライベートのget todosアイテムです。 fetchがデータを受信すると、 set todos呼び出しをバイパスして、キャッシュに直接書き込みます。 外部からtoList。$。Todosへの書き込みは許可されていません。 ただし、キャッシュのフラッシュ（todoList。$。Todosの読み取り）は、外部から開始して要求を繰り返すことができます。

現在の力で見える方法は最も直感的な解決策ではありませんが、コードにヘルパーを導入することはなく、クラスプロパティのインターフェイスを実際に歪めることはありません（メソッドですべてを行う必要はありません）、つまり控えめなままです。 また、MobXのようなアプローチで必然的に発生するタスクのクラス全体を非常に簡単に解決します。 ここでの主なことは、いくつかのルールを理解することです。

• todoList.todosの読み取りはキャッシュから取得されます。
• キャッシュ値をリセットする場合は、 todoList.$.todosからtodoList.$.todos 。
• 新しい値を書き込み、 set todosが実行されるようにしたい場合（異なるAPI、検証にデータを保存できます）、 todoList.todos = newTodosます。
• set todosを実行せずに値をキャッシュに直接書き込みたい場合は、todoList。$。Todosを実行します。 これはget/set todos内でのみ実行できます。

辞書

MobXのように、lom_atomにはオブジェクトプロパティと配列の観測可能なラッパーはありません。 しかし、単純なキーと値の辞書があります。 たとえば、各todoがプロパティの代わりにtodoIdの説明を個別にアップロードする必要がある場合、最初の引数が説明がキャッシュされるキー、2番目が説明自体であるメソッドを使用できます。

 class TodoList { // ... @force forced: TodoList @mem.key description(todoId: number, todoDescription?: Description | Error) { if (todoDescription !== undefined) return todoDescription // set mode fetchTodoDescription(todoId) .then(description => this.forced.description(todoId, description)) .catch(error => this.forced.description(todoId, error)) throw new mem.Wait() } } function TodoListView({todoList}) { return <div> <ul> {todoList.todos.map(todo => <TodoView todo={todo} desc={todoList.description(todo.id)} reset={() => todoList.forced.description(todo.id)} key={todo.id} /> )} </ul> // ... </div> } 

フィドル

todoList.description(todo.id)を実行すると、メソッドはget todosと同様にゲッターとして機能しget todos 。
メソッドは1つしかなく、関数2はget / setなので、内部にブランチがあります。

 if (todoDescription !== undefined) return todoDescription // set mode 

つまり、 todoDescription !== undefined場合、メソッドはセッターとして呼び出されます： todoList.description(todo.id, todo) 。 キーは任意のシリアル化可能なタイプにすることができ、オブジェクトと配列はパフォーマンスの低下を伴うキーにシリアル化されます。

なぜMobXなのか？

最初にMobXについて話し始めたのはなぜですか？ 事実、通常、ビジネス要件では非同期性については何もありません-これらはデータ処理の実装の個人的な詳細であり、ストリーム、約束、非同期/待機、ファイバーなどを通じて可能な限りあらゆる方法で抽象化しようとします。邪魔になりません。 たとえば、async / awaitはpromiseよりも邪魔になりません。これは言語構造であり、通常のtry / catchが機能するため、then / catchに関数を渡す必要はありません。 つまり、非同期/待機コードは非同期性のないコードのように見えます。

このアプローチの反対として、RxJSに言及できます。 ここでは、関数型プログラミングに突入し、重いライブラリを言語に持ち込み、そのAPIを学習する必要があります。 膨大な数のライブラリ拡張ポイントに挿入して単純な計算のストリームを作成するか、すべての操作を関数に置き換えます。 ただし、RxJSがまだ言語標準に含まれていた場合、それに加えて、プルストリーム、ビーコン、ラムダ、その他多くの類似したスタイルが存在します。 また、それぞれにFPの実装に関する独自の仕様があり、ビジネスロジックを書き直さなければ変更できなくなります。

Mobxは、観測可能な構造を記述するための新しい仕様を導入していません。 ネイティブクラスはそのままで、デコレータは透過的に機能し、インターフェイスを歪めません。 そのAPIは、自動データバインディングによりはるかに単純であり、データに対する目に見えるラッパーは多数ありません。

なぜMobXではありませんか？

コンポーネントのデータ、処理ステータス、エラーの更新も非同期性を漏らしています。インフラストラクチャは、ほとんどの場合、サブジェクトエリアに間接的に関連しています。 MobXでのフェッチのないアプリケーションはシンプルに見えますが、この必要なレイヤーを追加すると、非同期の耳が各サービスまたは多かれ少なかれ複雑なコンポーネントから突き出始めます。 定型コードがあるか、ヘルパーがビジネスロジックを混乱させ、「非同期性がないかのように書く」というアイデアの純度を悪化させるかのいずれかです。 データ自体は複雑で、データ自体も複雑です。通信チャネル実装のコンポーネントは、エラーやデータのダウンロードステータスなどのコンポーネントに漏れます。

MobXの代替として、lom_atomは、ヘルパーを導入することなく、コアでこれらの問題を解決しようとします。 試薬の成分に適応するために、 reactive-diが使用されます （つまり、mobx-reactに似ています）。 私は最初の記事で彼について話しました。反応コンテキストのアイデアを開発し、チューニングのためのより柔軟なコンポーネント、HOCの再利用可能な代替物、フロータイプと将来的には安価なSOLIDとのより良い統合を取得してみてください。

まとめ

基本概念を少し改良することで、Webの一般的なタスクのコードが大幅に簡素化され、コンポーネントがデータの受信の詳細を知る必要がなくなることを、原子の例で示すことができたと思います。 そして、これはPPRができることのほんの一部です。 私の意見では、これはプログラミングの全領域であり、独自のパターン、利点、欠点があります。 また、Kotlinのmol_atom、MobX、 デリゲートプロパティなどが、この領域の概要を見つける最初の試みです。 誰かが他の言語やエコシステムでの同様のアプローチについて何かを知っているなら、コメントに書いてください、これは面白いかもしれません。