FRPを使用してReactフックをポンピングします

フックをマスターして、多くのReact開発者は幸福感を経験し、最終的に、より少ないコードでタスクを実装できるシンプルで便利なツールキットを手に入れました。 しかし、これは、状態を管理するために必要な標準のuseStateフックとuseReducerフックだけが必要なことを意味しますか？

私の意見では、それらの生の形では、それらの使用はあまり便利ではなく、むしろ本当に便利な状態管理フックを構築するための基礎とみなすことができます。 React開発者自身がカスタムフックの開発を強く推奨しています。 カットの下で、非常にシンプルで理解しやすい例、通常のフックの何が悪いのか、どのように改善できるのかを見て、純粋な形での使用を完全に拒否します。

入力用の特定のフィールド、条件付きで名前があります。 そして、クリックすることで、入力された名前でサーバーにリクエストを行うボタンがあります（特定の検索）。 それは簡単だと思われるでしょうか？ ただし、解決策は明らかではありません。 最初の単純な実装：

const App = () => { const [name, setName] = useState(''); const [request, setRequest] = useState(); const [result, setResult] = useState(); useEffect(() => { fetch('//example.api/' + name).then((data) => { setResult(data.result); }); }, [request]); return <div> <input onChange={e => setName(e.target.value)}/> <input type="submit" value="Check" onClick={() => setRequest(name)}/> { result && <div>Result: { result }</div> } </div>; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで何が間違っていますか？ ユーザーがフィールドに何かを入力してフォームを2回送信すると、最初のリクエストのみが機能します。 2回目のクリック要求では変更されず、useEffectは機能しません。 アプリケーションがチケット検索サービスであり、ユーザーが変更を加えずに何度も何度もフォームを送信する場合、そのような実装は機能しません！ useEffectの依存関係として名前を使用することも受け入れられません。そうしないと、テキストが変更されるとすぐにフォームが送信されます。 さて、あなたは工夫を示さなければなりません。

 const App = () => { const [name, setName] = useState(''); const [request, setRequest] = useState(); const [result, setResult] = useState(); useEffect(() => { fetch('//example.api/' + name).then((data) => { setResult(data.result); }); }, [request]); return <div> <input onChange={e => setName(e.target.value)}/> <input type="submit" value="Check" onClick={() => setRequest(!request)}/> { result && <div>Result: { result }</div> } </div>; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、クリックするたびに、意味のあるリクエストを反対に変更し、目的の動作を実現します。 これは非常に小さくて無邪気な松葉杖ですが、コードを理解するのが多少混乱します。 おそらく今、私は私の指から問題を吸い出し、その規模を膨らませているように思われます。 それが本当かどうか答えるために、このコードをより表現力のあるアプローチを提供する他の実装と比較する必要があります。

スレッド抽象化を使用して、この例を理論レベルで見てみましょう。 ユーザーインターフェイスの状態を記述するのに非常に便利です。 したがって、2つのストリームがあります。テキストフィールドに入力されたデータ（名前$）、およびフォームの送信ボタンをクリックしたストリーム（$をクリック）です。 それらから、サーバーへのリクエストの3番目の結合ストリームを作成する必要があります。

 name$ __(C)____(Ca)_____(Car)____________________(Carl)___________ click$ ___________________________()______()________________()_____ request$ ___________________________(Car)___(Car)_____________(Carl)_
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

達成する必要がある動作を次に示します。 各ストリームには、2つの側面があります。それは、値と、値が流れる時点です。 さまざまな状況で、いずれかまたは両方の側面が必要になる場合があります。 これを音楽のリズムと調和と比較できます。 応答時間のみが重要なストリームは、信号とも呼ばれます。

私たちの場合、クリック$は純粋なシグナルです。どの値が流れるかは関係ありません（未定義/ true /イベント/何でも）。これは重要なことです。 ケース名$

逆に、システムの変更を伴う変更は一切ありませんが、ある時点でその意味が必要になる場合があります。 そして、これらの2つのストリームから、最初の値、2番目の値から3番目の値を作成する必要があります。

Rxjsの場合、これにはほとんどすぐに使える演算子があります。

 const names$ = fromEvent(...); const click$ = fromEvent(...); const request$ = click$.pipe(withLatestFrom(name$), map(([name]) => fromPromise(fetch(...))));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、ReactでのRxの実際的な使用は非常に不便です。 より適切なオプションは、Rxと同じ機能的反応原理に基づいて構築されたmrrライブラリですが、「完全な反応性」の原理に基づいてReactでの使用に特に適合し、フックとして接続されます。

 import useMrr from 'mrr/hooks'; const App = props => { const [state, set] = useMrr(props, { result: [name => fetch('//example.api/' + name).then(data => data.result), '-name', 'submit'], }); return <div> <input value={state.name} onChange={set('name')}/> <input type="submit" value="Check" onClick={set('submit')}/> { state.result && <div>Result: { state.result }</div> } </div>; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

useMrrインターフェイスはuseStateまたはuseReducerに似ています。値をスレッドに入れるために、状態オブジェクト（すべてのスレッドの値）とセッターを返します。 しかし、すべての内部は少し異なります：DOMイベントから直接値を入力するものを除く各状態フィールド（=ストリーム）は、関数と親ストリームのリストによって記述され、その変更により子が再計算されます。 この場合、親スレッドの値が関数に代入されます。 ストリームの値を取得するだけで、その変更に応答しない場合は、名前の場合と同様に、名前の前に「マイナス」を書き込みます。

基本的に、希望する動作を1行で取得しました。 しかし、これは単なる簡潔さではありません。 得られた結果をより詳細に比較してみましょう。まず第一に、結果のコードの読みやすさと明確さなどのパラメーターに関してです。

mrrでは、「テンプレート」から「ロジック」をほぼ完全に分離することができます。JSXで複雑な命令型ハンドラーを記述する必要はありません。 すべてが非常に宣言的です：実質的に変換せずにDOMイベントを対応するストリームにマップします（入力フィールドの場合、値を指定しない限り、値e.target.valueは自動的に抽出されます）。既にuseMrr構造にベースフローの形成方法を記述します子会社。 したがって、同期および非同期の両方のデータ変換の場合、値がどのように形成されるかを常に簡単に追跡できます。

Pxとの比較：追加の演算子を使用する必要さえありませんでした。その結果、mrr関数がプロミスを受け取った場合、受け取ったデータを解決してストリームに入れるまで自動的に待機します。 また、withLatestFromの代わりに、

パッシブリスニング（マイナス記号）、これはより便利です。 名前に加えて、他のフィールドを送信する必要があると想像してください。 次に、mrrで、受動的にリッスンする別のストリームを追加します。

 result: [(name, surname) => fetch(...), '-name', '-surname', 'submit'],
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Rxでは、LatestFromをマップでもう1つスカルプトするか、最初に名前と姓を1つのストリームに結合する必要があります。

しかし、フックとMRRに戻ります。 データがどのように形成されるかを常に示す、より読みやすい依存関係レコードは、おそらく主な利点の1つです。 現在のuseEffectインターフェースは、基本的に信号ストリームに応答することを許可していません。そのため、

さまざまな工夫が必要です。

もう1つのポイントは、通常のフックのオプションが追加のレンダリングを実行することです。 ユーザーがボタンをクリックしただけの場合、これはまだ反応が描画する必要があるUIの変更を伴いません。 ただし、レンダーが呼び出されます。 mrrのあるバリアントでは、サーバーからの応答が既に到着した場合にのみ、返される状態が更新されます。 マッチを保存しますか？ まあ、おそらく。 しかし個人的には、基本的なフックの基礎である「理解できない状況で再レンダリングする」という原則は拒否を引き起こします。

余分なレンダリングは、イベントハンドラーの新しい構成を意味します。 ところで、ここでは普通のフックはすべて悪いです。 ハンドラーは必須であるだけでなく、レンダリングするたびに再生成する必要があります。 そして、ここでキャッシュを完全に使用することはできません。 多くのハンドラーは、コンポーネントの内部変数にロックする必要があります。 mrrハンドラーはより宣言的であり、キャッシュは既にmrrに統合されています。set（ 'name'）は一度だけ生成され、後続のレンダリングのためにキャッシュから置き換えられます。

コードベースが増加すると、命令型ハンドラーはさらに面倒になります。 ユーザーが行ったフォーム送信の数も表示する必要があるとしましょう。

 const App = () => { const [request, makeRequest] = useState(); const [name, setName] = useState(''); const [result, setResult] = useState(false); const [clicks, setClicks] = useState(0); useEffect(() => { fetch('//example.api/' + name).then((data) => { setResult(data.result); }); }, [request]); return <div> <input onChange={e => setName(e.target.value)}/> <input type="submit" value="Check" onClick={() => { makeRequest(!request); setClicks(clicks + 1); }}/><br /> Clicked: { clicks } </div>; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

見た目はあまり良くありません。 もちろん、ハンドラーをコンポーネント内の別の関数としてレンダリングできます。 読みやすさは向上しますが、各レンダリングで関数を再生成する問題と、命令性の問題は残ります。 React APIは機能的なアプローチに向けて徐々に変化していると広く信じられていますが、本質的にこれは一般的な手続きコードです。

問題の規模が誇張されているように見える人には、たとえば、Reactの開発者自身がハンドラーの過剰な生成の問題を認識しており、useCallbackの形で松葉杖をすぐに役立つと答えることができます。

MRRの場合：

 const App = props => { const [state, set] = useMrr(props, { $init: { clicks: 0, }, isValid: [name => fetch('//example.api/' + name).then(data => data.isValid), '-name', 'makeRequest'], clicks: [a => a + 1, '-clicks', 'makeRequest'], }); return <div> <input onChange={set('name')}/> <input type="submit" value="Check" onClick={set('makeRequest')}/> </div>; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

より便利な代替手段はuseReducerです。これにより、ハンドラーの命令を放棄できます。 ただし、他の重要な問題が残っています：信号の処理の欠如（同じuseEffectが副作用の原因となるため）、および非同期変換中の最悪の可読性（言い換えると、同じuseEffectにより、ストアのフィールド間の関係を追跡することはより困難です） ） mrrで状態フィールド（スレッド）間の依存関係グラフがすぐにはっきり見える場合、フックでは目を少し上下に動かさなければなりません。

また、同じコンポーネントでuseStateとuseReducerを共有するのはあまり便利ではありません（useStateで何かを変更する複雑な命令型ハンドラーが再び存在します）

そのため、おそらくコンポーネントを開発する前に、いずれかのオプションを受け入れる必要があります。

もちろん、すべての側面の検討を継続することができます。 記事の範囲を超えないようにするために、重要性の低いいくつかの点について詳しく説明します。

集中ログ、デバッグ。 mrrではすべてのストリームが1つのハブに含まれているため、デバッグするには1つのフラグを追加するだけで十分です。

 const App = props => { const [state, set] = useMrr(props, { $log: true, $init: { clicks: 0, }, isValid: [name => fetch('//example.api/' + name).then(data => data.isValid), '-name', 'makeRequest'], clicks: [a => a + 1, '-clicks', 'makeRequest'], }); ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、ストリームに対するすべての変更がコンソールに表示されます。 状態全体（つまり、すべてのスレッドの現在の値）にアクセスするには、疑似ストリーム$状態があります。

 a: [({ name, click, result }) => { ... }, '$state', 'click'],
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、必要な場合、または編集スタイルに非常に慣れている場合は、mrrでエディタースタイルを記述し、イベントと以前の状態全体に基づいて新しいフィールド値を返すことができます。 しかし、これらの反応性がないため、逆（useReducerまたはmrrスタイルのエディターでの書き込み）は機能しません。

時間を操作します。 フローの2つの側面、つまり意味と応答時間、調和とリズムを覚えていますか？ したがって、通常のフックで最初のフックを操作するのは非常に簡単で便利ですが、2番目のフックでは-いいえ。 時間をかけて作業するということは、「リズム」が親とは異なる子ストリームの形成を意味します。 これは主にあらゆる種類のフィルター、debowns、trotlなどです。 これはすべて、おそらく自分で実装する必要があります。 mrrでは、既成のステートメントをそのまま使用できます。 紳士セットmrrは、さまざまな演算子Rxに劣りますが、より直感的な命名方法があります。

コンポーネント間相互作用。 エディターでは、ストーリーを1つだけ作成することをお勧めしました。 多くのコンポーネントでuseReducerを使用する場合、

当事者間の相互作用の組織に問題がある可能性があります。 mrrでは、フローは1つのコンポーネントから別のコンポーネントに階層の上下に自由に「流れる」ことができますが、これは宣言的なアプローチのため問題を引き起こしません。 詳細

このトピックおよびmrr APIのその他の機能については、 Reactのアクター+ FRPの記事で説明されています。

結論

新しいリアクションフックは素晴らしく、私たちの生活を簡素化しますが、高レベルの汎用フック（状態管理）で修正できるいくつかの欠陥があります。 機能反応ライブラリmrrのUseMrrが提案され、そのように見なされました。

問題とその解決策：

• 各レンダリングでの不必要なデータの再カウント（プッシュベースの反応性のため、mrrは存在しません）
• 状態の変化がUIの変化を伴わない場合の追加のレンダリング
• 非同期変換を使用したコードの読みやすさの低下（同期と比較）。 mrrでは、非同期コードは、読みやすさと表現力において同期に劣りません。 mrrのuseEffectに関する最近の記事で説明されている問題のほとんどは、基本的に不可能です。
• 常にキャッシュ可能とは限らない命令型ハンドラー（mrrでは自動的にキャッシュされます。ほとんどの場合、宣言的にキャッシュできます）
• useStateとuseReducerを同時に使用すると、厄介なコードが作成される可能性があります
• 経時的にフローを変換するツールの不足（デバウンス、スロットル、競合状態）

多くの点で、カスタムフックによって解決できると主張することができます。 しかし、これはまさに提案されているものですが、異なる実装の代わりに、個別のタスクごとに、全体的で一貫したソリューションが提案されています。

多くの問題はあまりに馴染みすぎて、私たちにははっきりと認識されません。 たとえば、非同期変換は常に同期変換よりも複雑で複雑に見え、この意味でのフックは以前のアプローチ（edsなど）より悪くありません。 これを問題として認識するためには、より良い解決策を提供する他のアプローチを最初に見る必要があります。

この記事は、特定の見解を課すのではなく、問題に注意を引くことを目的としています。 他のソリューションが存在するか、価値のある代替手段になり得るが、まだ広く知られていない他のソリューションが作成されていると確信しています。 今後のReact Cache APIも大きな違いを生むことができます。 コメントでの批判と議論を歓迎します。

興味のある方は、3月28日にkyivjsでこのトピックに関するプレゼンテーションを見ることができます。