👃🏽 🎿 👩🏼‍🔬 Mrr：Reactの合計FRP 👩🏻‍💻 💺 💐

Mrrは、Reactの機能的に反応するライブラリです（架空のトートロジーについては謝罪します）。

「反応性」という言葉は通常、参照FRPとしてRx.jsを指します。ただし、このテーマに関するHabréの一連の最近の記事（ [1] 、 [2] 、 [3] ）は、Rxのソリューションの扱いにくいことを示しました。 Rxは大きく強力であり、フローの抽象化自体が示唆する問題の解決に最適です（実際には、これは主に非同期タスクの調整です）。しかし、たとえば、Rxで単純な同期フォーム検証を作成しますか？彼は通常の命令型アプローチと比較してあなたの時間を節約しますか？

mrrは、FRFが特定の「ストリーミング」問題だけでなく、最も一般的な日常のフロントエンドタスクでも便利で効果的なソリューションになり得ることを証明する試みです。

リアクティブプログラミングは非常に強力な抽象化であり、現時点ではフロントエンドに2つの方法で存在します。

反応変数（計算変数）：シンプルで信頼性が高く、直感的ですが、RPの可能性は完全には明らかにされていません
Rx、Baconなどのストリームを操作するためのライブラリ：強力ですが、かなり複雑なため、実際の使用範囲は特定のタスクに限定されます。

Mrrはこれらのアプローチの利点を組み合わせています。 Rx.jsとは異なり、mrrにはユーザーが追加して拡張できる短いAPIがあります。多数のメソッドと演算子の代わりに-Observable（ホットとコールド）、Subjectなどの代わりに4つの基本演算子 -1つの抽象化：ストリーム。また、mrrには、コードの読みやすさを大幅に複雑にする可能性のある複雑な概念（メタストリームなど）がありません。

ただし、mrrは「新しい方法で簡素化されたRx」ではありません。 Rxと同じ基本原則に基づいて、mrrはアプリケーションのグローバルおよびローカル（コンポーネントレベル）状態を管理する、より大きなニッチであると主張しています。リアクティブプログラミングの元の概念は非同期タスクで動作することを目的としていましたが、mrrは通常の同期タスクにリアクティブアプローチをうまく使用しています。これが「総FRP」の原則です。

多くの場合、Reactでアプリケーションを作成する際に、複数の異種テクノロジーが使用されます：コンポーネント状態の再構成（またはすぐに-フック）、グローバル状態のRedux / mobx、副作用を管理し非同期を調整するためのredux-observable（またはthunk / saga）を持つRxエディターのタスク。同じアプリケーション内のさまざまなアプローチやテクノロジーの「サラダ」の代わりに、mrrを使用すると、単一のテクノロジーとパラダイムを使用できます。

mrrインターフェースは、Rxや同様のライブラリーとも大きく異なります-より宣言的です。反応性の抽象化と宣言的アプローチのおかげで、mrrは表現力豊かで簡潔なコードを書くことができます。たとえば、 mrr上の標準のTodoMVCは、50行未満のコード（JSXテンプレートをカウントしません）で済みます。

しかし、十分な広告。「軽い」RPと「重い」RPの利点を1つのボトルにまとめることができましたか。判断する必要がありますが、最初にコード例を読んでください。

TodoMVCはすでにかなり痛いので、Githubユーザーに関するデータをダウンロードする例はあまりにも原始的で、ライブラリの機能を感じることができません。鉄道チケットを購入するための条件付きアプリケーションの例として、mrrを検討します。 UIには、開始ステーションと終了ステーション、日付を選択するためのフィールドがあります。次に、データを送信した後、利用可能な列車とその中の場所のリストが返されます。特定の列車と車の種類を選択すると、ユーザーは乗客データを入力して、チケットをバスケットに追加します。行こう

ステーションと日付を選択できるフォームが必要です。

ステーションを入力するためのオートコンプリートフィールドを作成します。

import { withMrr } from 'mrr'; const stations = [ '', '', '', ' ', ... ] const Tickets = withMrr({ //    $init: { stationFromOptions: [], stationFromInput: '', }, //   - "" stationFromOptions: [str => stations.filter(s => s.indexOf(str)===0), 'stationFromInput'], }, (state, props, $) => { return (<div> <h3>    </h3> <div>  : <input onChange={ $('stationFromInput') } /> </div> <ul className="stationFromOptions"> { state.stationFromOptions.map(s => <li>{ s }</li>) } </ul> </div>); }); export default Tickets;

mrrコンポーネントはwithMrr関数を使用して作成されます。この関数は、リアクティブリンク図（フローの説明）とレンダリング関数を受け入れます。レンダリング関数は、状態だけでなくコンポーネントの小道具にも渡されますが、現在はmrrによって完全に制御されています。これには、初期値（ブロック$ init）が含まれ、反応セルの数式値によって計算されます。

これで、2つのセル（または同じものである2つのストリーム）があります： stationFromInput 、 $ヘルパーを使用したユーザー入力からの値（データ入力要素に対してevent.target.valueをデフォルトで渡す）、およびそれから派生したセル名前で一致するステーションの配列を含むstationFromOptions 。

stationFromOptionsの値は、関数を使用して親セルが変更されるたびに自動的に計算されます（Excelの数式に似た「数式」と呼ばれるmrr用語で）。 mrr式の構文は単純です。最初は、セルの値を計算する関数（または演算子）です。次に、このセルが依存するセルのリストがあります。値は関数に転送されます。このような奇妙な一見した構文には多くの利点がありますが、これについては後で検討します。これまでのところ、ここでのmrrロジックは、Vue、Svelte、およびその他のライブラリで使用される計算可能な変数を使用した通常のアプローチに似ていますが、唯一の違いは純粋な関数を使用できることです。

入力フィールドのリストから選択したステーションの置換を実装します。ユーザーがいずれかのステーションをクリックした後に、ステーションのリストを非表示にすることも必要です。

 const Tickets = withMrr({ $init: { stationFromOptions: [], stationFromInput: '', }, stationFromOptions: [str => stations.filter(s => str.indexOf(a) === 0), 'stationFromInput'], stationFrom: ['merge', 'stationFromInput', 'selectStationFrom'], optionsShown: ['toggle', 'stationFromInput', 'selectStationFrom'], }, (state, props, $) => { return (<div> <div>  : <input onChange={ $('stationFromInput') } value={ state.stationFrom }/> </div> { state.optionsShown && <ul className="stationFromOptions"> { state.stationFromOptions.map(s => <li onClick={ $('selectStationFrom', s) }>{ s }</li>) } </ul> } </div>); });

ステーションのリストで$ヘルパーを使用して作成されたイベントハンドラーは、各オプションの固定値を出力します。

mrrは、その宣言的アプローチに一貫性があり、あらゆる突然変異とは無関係です。ステーションを選択した後、セル値を「強制」変更することはできません。代わりに、新しいstationFromセルを作成します。このセルは、マージストリーム演算子（Rxの近似値はcomposeLatest）を使用して、ユーザー入力（ stationFromInput ）とステーション選択（ selectStationFrom ）の2つのストリームの値を収集します。

ユーザーが何かを入力した後にオプションのリストを表示し、オプションの1つを選択した後に非表示にします。 optionsShownセルは、他のセルの変更に応じてブール値を取るオプションのリストの可視性を担当します。これは、構文糖が存在する非常に一般的なパターン、 トグル演算子です。最初の引数（ストリーム）が変更されるとセルの値がtrueに設定され、2番目の引数がfalseに設定されます。

入力したテキストをクリアするボタンを追加します。

 const Tickets = withMrr({ $init: { stationFromOptions: [], stationFromInput: '', }, stationFromOptions: [str => stations.filter(s => str.indexOf(a) === 0), 'stationFromInput'], clearVal: [a => '', 'clear'], stationFrom: ['merge', 'stationFromInput', 'selectStationFrom', 'clearVal'], optionsShown: ['toggle', 'stationFromInput', 'selectStationFrom'], }, (state, props, $) => { return (<div> <div>  : <input onChange={ $('stationFromInput') } value={ state.stationFrom }/> { state.stationFrom && <button onClick={ $('clear') }></button> } </div> { state.optionsShown && <ul className="stationFromOptions"> { state.stationFromOptions.map(s => <li onClick={ $('selectStationFrom', s) }>{ s }</li>) } </ul> } </div>); });

入力フィールドのテキストの内容を担当するstationFromセルは、2つのストリームからではなく、3つのストリームから値を収集します。このコードは単純化できます。 [* formula *、* ... cell arguments *]という形式のmrrコンストラクトは、LispのS式に似ており、Lispのように、このような構造を任意に相互にネストできます。

無駄なclearValセルを取り除き、コードを短くしましょう。

  stationFrom: ['merge', 'stationFromInput', 'selectStationFrom', [a => '', 'clear']],

命令型スタイルで書かれたプログラムは、組織化されていないチームと比較することができます。チームは常にお互いに何かを注文します（メソッド呼び出しと変更の変更をお勧めします）。さらに、両方のマネージャーは部下であり、その逆も同様です。宣言的なプログラムは、反対のユートピア的な図に似ています。つまり、誰もがどのような状況でもどのように行動すべきかを明確に知っている集団です。そのようなチームでは注文の必要はありません;誰もがちょうど彼らの場所にいて、起こっていることに反応して働いています。

イベントの考えられるすべての結果を説明する代わりに（特定の突然変異を起こすために読む）、このイベントが発生する可能性のあるすべてのケースを説明します。セルが他のセルの変更にどのような値を取るか。これまでの小さな例では、stationFromセルとその値に影響する3つの状況について説明しました。命令型コードに慣れているプログラマーにとって、このアプローチは珍しいように思えるかもしれません（または「松葉杖」、「倒錯」さえ）。実際、実際に見られるように、コードの簡潔さ（および安定性）のために労力を節約できます。

非同期性はどうですか？ ajaxで提案されたステーションのリストをプルアップすることは可能ですか？問題ありません！本質的に、関数が値を返すかプロミスを返すかは、mrrにとって重要ではありません。 mrr promiseが返されると、その解決を待って、受信したデータをストリームに「プッシュ」します。

 stationFromOptions: [str => fetch('/get_stations?str=' + str).then(res => res.toJSON()), 'stationFromInput'],

また、非同期関数を数式として使用できることも意味します。より複雑なケース（エラー処理、約束のステータス）は後で検討されます。

出発駅を選択する機能が用意されました。到着ステーションに同じものを複製することは意味がありません。再利用できる別のコンポーネントに入れる価値があります。これは自動補完機能を備えた一般化された入力コンポーネントになるため、フィールドの名前を変更し、propsで適切なオプションセットを取得するための関数を作成します。

 const OptionsInput = withMrr(props => ({ $init: { options: [], }, val: ['merge', 'valInput', 'selectOption', [a => '', 'clear']], options: [props.getOptions, 'val'], optionsShown: ['toggle', 'valInput', 'selectOption'], }), (state, props, $) => <div> <div> <input onChange={ $('valInput') } value={ state.val } /> </div> { state.optionsShown && <ul className="options"> { state.options.map(s => <li onClick={ $('selectOption', s) }>{ s }</li>) } </ul> } { state.val && <div className="clear" onClick={ $('clear') }> X </div> } </div>)

ご覧のとおり、mrrセルの構造をpropsコンポーネントの関数として指定できます（ただし、初期化時に1回だけ実行され、propsの変更には応答しません）。

コンポーネント間の通信

次に、このコンポーネントを親コンポーネントに接続し、mrrが関連コンポーネントがデータを交換できるようにする方法を確認します。

 const getMatchedStations = str => fetch('/get_stations?str=' + str).then(res => res.toJSON()); const Tickets = withMrr({ stationTo: 'selectStationFrom/val', stationFrom: 'selectStationTo/val', }, (state, props, $, connectAs) => { return (<div> <OptionsInput { ...connectAs('selectStationFrom') } getOptions={ getMatchedStations } /> - <OptionsInput { ...connectAs('selectStationTo') } getOptions={ getMatchedStations } /> <input type="date" onChange={ $('date') } /> <button onClick={ $('searchTrains') }></button> </div>); });

親コンポーネントを子コンポーネントに関連付けるには、 connectAs関数（render関数の4番目の引数）を使用してパラメーターを渡す必要があります。この場合、子コンポーネントに付けたい名前を示します。この方法でコンポーネントをアタッチすることにより、この名前でそのセルにアクセスできます。この場合、val cellsを聞いています。逆も可能です-親セルの子コンポーネントからリッスンします。

ご覧のとおり、ここでmrrは宣言的なアプローチに従います。onChangeコールバックは不要です。connectAs関数で子コンポーネントの名前を指定するだけで、その後セルにアクセスできます。この場合も、宣言性のために、別のコンポーネントの作業に干渉の脅威はありません。その中の何かを「変更」する能力はありません。変異して、データを「聞く」ことしかできません。

信号と値

次の段階では、選択したパラメーターに適した列車を検索します。命令型のアプローチでは、おそらく特定のプロセッサを作成してonSubmitフォームを送信します。これにより、さらにアクション（ajaxリクエストと結果の表示）が開始されます。しかし、あなたが覚えているように、私たちは何も「注文」することはできません！フォームのセルから派生した別のセルのセットのみを作成できます。もう1つのリクエストを書きましょう。

 const getTrains = (from, to, date) => fetch('/get_trains?from=' + from + '&to=' + to + '&date=' + date).then(res => res.toJSON()); const Tickets = withMrr({ stationFrom: 'selectStationFrom/val', stationTo: 'selectStationTo/val', results: [getTrains, 'stationFrom', 'stationTo', 'date', 'searchTrains'], }, (state, props, $, connectAs) => { return (<div> <OptionsInput { ...connectAs('selectStationFrom') } getOptions={ getMatchedStations } /> - <OptionsInput { ...connectAs('selectStationTo') } getOptions={ getMatchedStations } /> <input type="date" onChange={ $('date') } /> <button onClick={ $('searchTrains') }></button> </div>); });

ただし、このようなコードは期待どおりに機能しません。引数のいずれかが変更されると、計算（セル値の再計算）がトリガーされるため、たとえば「検索」をクリックするだけでなく、最初のステーションを選択した直後にリクエストが送信されます。一方では、ステーションと日付が式の引数に渡される必要がありますが、他方では、それらの変更に応答しません。 mrrには、パッシブリスニングと呼ばれるこのためのエレガントなメカニズムがあります。

  results: [getTrains, '-stationFrom', '-stationTo', '-date', 'searchTrains'],

セル名の前にマイナス記号を追加するだけです。現在、結果はsearchTrainsセルへの変更にのみ応答します。

この場合、 searchTrainsセルは「セル信号」として機能し、 stationFromなどのセルは「セル値」として機能します。シグナルセルの場合、値が「流れる」瞬間だけが重要であり、どのようなデータになるのか-とにかく、それは単にtrue、1またはその他（この場合、これらはDOMイベントオブジェクトになります））値セルの場合、その値は重要ですが、同時にその変化の瞬間は重要ではありません。これらの2種類のセルは相互に排他的ではありません。多くのセルはシグナルと値の両方です。 mrrの構文レベルでは、これらの2種類のセルはまったく異なりませんが、リアクティブコードを記述する際には、このような違いを概念的に理解することが非常に重要です。

ストリームを分割する

列車の座席を検索するリクエストには時間がかかる場合があるため、ローダーを表示し、エラーが発生した場合に対応する必要があります。自動解決によるこのデフォルトのアプローチには、すでにいくつかの約束があります。

 const Tickets = withMrr({ $init: { results: {}, } stationFrom: 'selectStationFrom/val', stationTo: 'selectStationTo/val', searchQuery: [(from, to, date) => ({ from, to, date }), '-stationFrom', '-stationTo', '-date', 'searchTrains'], results: ['nested', (cb, query) => { cb({ loading: true, error: null, data: null }); getTrains(query.from, query.to, query.date) .then(res => cb('data', res)) .catch(err => cb('error', err)) .finally(() => cb('loading', false)) }, 'searchQuery'], availableTrains: 'results.data', }, (state, props, $, connectAs) => { return (<div> <div> <OptionsInput { ...connectAs('selectStationFrom') } getOptions={ getMatchedStations } /> - <OptionsInput { ...connectAs('selectStationTo') } getOptions={ getMatchedStations } /> <input type="date" onChange={ $('date') } /> <button onClick={ $('searchTrains') }></button> </div> <div> { state.results.loading && <div className="loading">...</div> } { state.results.error && <div className="error"> . ,  .   .</div> } { state.availableTrains && <div className="results"> { state.availableTrains.map((train) => <div />) } </div> } </div> </div>); });

ネストされた演算子を使用すると、データをサブセルに「分解」できます。このため、式の最初の引数はコールバックであり、サブセル（1つ以上）にデータを「プッシュ」できます。これで、エラー、Promiseのステータス、および受信したデータを担当する個別のストリームができました。ネストされた演算子は非常に強力なツールであり、mrrには数少ない命令の1つです（データを配置するセルを指定します）。マージ演算子は複数のスレッドを1つに結合しますが、ネストするとスレッドは複数のサブスレッドに分割されるため、その逆になります。

上記の例は、promiseを操作する標準的な方法です。mrrでは、promise演算子として一般化されており、コードを短縮できます。

  results: ['promise', (query) => getTrains(query.from, query.to, query.date), 'searchQuery'], //     availableTrains: 'results.data',

また、promise演算子は、最新のpromiseの結果のみが使用されるようにします。

利用可能な座席を表示するためのコンポーネント（簡単にするために、さまざまな種類の車を拒否します）

 const TrainSeats = withMrr({ selectSeats: [(seatsNumber, { id }) => new Array(Number(seatsNumber)).fill(true).map(() => ({ trainId: id })), '-seatsNumber', '-$props', 'select'], seatsNumber: [() => 0, 'selectSeats'], }, (state, props, $) => <div className="train">  №{ props.num } { props.from } - { props.to }.   : { props.seats || 0 } { props.seats && <div>     : <input type="number" onChange={ $('seatsNumber') } value={ state.seatsNumber || 0 } max={ props.seats } /> <button onClick={ $('select') }></button> </div> } </div>);

数式で小道具にアクセスするには、特別な$小道具ボックスに登録できます。

 const Tickets = withMrr({ ... selectedSeats: '*/selectSeats', }, (state, props, $, connectAs) => { ... <div className="results"> { state.availableTrains.map((train, i) => <TrainSeats key={i} {...train} {...connectAs('train' + i)}/>) } </div> }

「選択」ボタンをクリックすると、パッシブリスニングを使用して、選択した場所の数を取得します。 connectAs関数を使用して、各子コンポーネントを親に関連付けます。ユーザーは提案された列車のいずれかで座席を選択できるため、マスク「*」を使用してすべての子コンポーネントの変更を聞きます。

ただし、問題は次のとおりです。ユーザーは最初に1つの列車で座席を追加し、次に別の列車で座席を追加できるため、新しいデータは以前の列車を粉砕します。ストリームデータを「蓄積」する方法これを行うために、ネストされたファネルと一緒にmrrの基礎を形成するクロージャー演算子があります（他のすべては、これら3つに基づく構文シュガーにすぎません）。

  selectedSeats: ['closure', () => { let seats = []; //     return selectedSeats => { seats = [...seats, selectedSeats]; return seats; } }, '*/selectSeats'],

最初にクロージャーを （componentDidMountで）使用すると、式を返すクロージャーが作成されます。したがって、彼女はクロージャー変数にアクセスできます。これにより、グローバル変数と共有された可変状態の深byに陥ることなく、安全な方法で呼び出し間でデータを保存できます。したがって、クロージャを使用すると、スキャンなどのRx演算子の機能を実装できます。ただし、この方法は難しい場合に適しています。 1つの変数の値のみを保存する必要がある場合、特別な名前「^」を使用して、セルの前の値へのリンクを使用するだけです。

  selectedSeats: [(seats, prev) => [...seats, ...prev], '*/selectSeats', '^']

ここで、ユーザーは選択した各チケットの姓と名を入力する必要があります。

 const SeatDetails = withMrr({}, (state, props, $) => { return (<div> { props.trainId } <input name="name" value={ props.name } onChange={ $('setDetails', e => ['name', e.target.value, props.i]) } /> <input name="surname" value={ props.surname } onChange={ $('setDetails', e => ['surname', e.target.value, props.i]) }/> <a href="#" onClick={ $('removeSeat', props.i) }>X</a> </div>); }) const Tickets = withMrr({ $init: { results: {}, selectedSeats: [], } stationFrom: 'selectStationFrom/val', stationTo: 'selectStationTo/val', searchQuery: [(from, to, date) => ({ from, to, date }), '-stationFrom', '-stationTo', '-date', 'searchTrains'], results: ['promise', (query) => getTrains(query.from, query.to, query.date), 'searchQuery'], availableTrains: 'results.data', selectedSeats: [(seats, prev) => [...seats, ...prev], '*/selectSeats', '^'] }, (state, props, $, connectAs) => { return (<div> <div> <OptionsInput { ...connectAs('selectStationFrom') } getOptions={ getMatchedStations } /> - <OptionsInput { ...connectAs('selectStationTo') } getOptions={ getMatchedStations } /> <input type="date" onChange={ $('date') } /> <button onClick={ $('searchTrains') }></button> </div> <div> { state.results.loading && <div className="loading">...</div> } { state.results.error && <div className="error"> . ,  .   .</div> } { state.availableTrains && <div className="results"> { state.availableTrains.map((train, i) => <TrainSeats key={i} {...train} {...connectAs('train' + i)}/>) } </div> } { state.selectedSeats.map((seat, i) => <SeatDetails key={i} i={i} { ...seat } {...connectAs('seat' + i)}/>) } </div> </div>); });

selectedSeatsセルには、選択した場所の配列が含まれます。ユーザーが各チケットの名前と姓を入力すると、配列の対応する要素のデータを変更する必要があります。

  selectedSeats: [(seats, details, prev) => { // ??? }, '*/selectSeats', '*/setDetails', '^']

標準的なアプローチは私たちには適していません。式では、どのセルが変更されたかを知り、それに応じて応答する必要があります。マージ演算子の形式の1つが役立ちます。

  selectedSeats: ['merge', { '*/selectSeats': (seats, prev) => { return [...prev, ...seats]; }, '*/setDetails': ([field, value, i], prev) => { prev[i][field] = value; return prev; }, '*/removeSeat': (i, prev) => { prev.splice(i, 1); return prev; }, }, '^'/*,       */],

これはReduxレデューサーに少し似ていますが、より柔軟で強力な構文を備えています。また、配列を変更することを恐れることはできません。1つのセルの数式のみが制御できるため、並列変更はそれぞれ除外されます（ただし、引数として渡される配列の変更は確かに価値がありません）。

リアクティブコレクション

セルがそれ自体に格納され、配列が変更されるときのパターンは非常に一般的です。配列に対するすべての操作には、挿入、変更、削除の3つのタイプがあります。これを記述するために、エレガントなcoll演算子があります。 selectedSeatsの計算を簡素化するために使用します。

それは：

  selectedSeats: ['merge', { '*/selectSeats': (seats, prev) => { return [...prev, ...seats]; }, '*/setDetails': ([field, value, i], prev) => { prev[i][field] = value; return prev; }, '*/removeSeat': (i, prev) => { prev.splice(i, 1); return prev; }, 'addToCart': () => [], }, '^']

になりました：

  selectedSeats: ['coll', { create: '*/selectSeats', update: '*/setDetails', delete: ['merge', '*/removeSeat', [() => ({}), 'addToCart']] }]

ただし、setDetailsストリームのデータ形式を少し変更する必要があります。

  <input name="name" onChange={ $('setDetails', e => [{ name: e.target.value }, props.i]) } /> <input name="surname" onChange={ $('setDetails', e => [{ surname: e.target.value }, props.i]) }/>

coll演算子を使用して、配列に影響を与える3つのスレッドを記述します。この場合、作成ストリームには要素自体が含まれている必要があり、要素は配列（通常はオブジェクト）に追加する必要があります。削除ストリームは、 削除する要素のインデックス（「* / removeSeat」の両方）とマスクを受け入れます。マスク{}はすべての要素を削除します。たとえば、マスク{name： 'Carl'}はCarlという名前のすべての要素を削除します。更新ストリームは、値のペア（要素（マスクまたは関数）で行う必要のある変更）と、変更する必要のある要素のインデックスまたはマスクを受け入れます。たとえば、[{surname： 'Johnson'}、{}]は、ジョンソンの姓を配列のすべての要素に設定します。

coll演算子は、内部クエリ言語のようなものを使用して、コレクションの操作と宣言の作成を容易にします。

JsFiddle でのアプリケーションの完全なコード。

私たちは、mrrの必要な基本機能のほとんどすべてに精通しました。船外に残っているかなり重要なトピックはグローバルな資産管理であり、おそらく以下の記事で検討されるでしょう。ただし、mrrを使用して、コンポーネントまたは関連するコンポーネントのグループ内の状態を管理できるようになりました。

結論

mrrの力とは何ですか？

mrrを使用すると、Reactで機能的に反応するスタイルでアプリケーションを作成できます（mrrは、Make Reactを反応的に復号化できます）。 mrrは非常に表現力豊かです-コードの行を書くのに費やす時間が少なくなります。

mrrは、基本的な抽象概念の小さなセットを提供します。これは、すべての場合に十分です-この記事では、mrrのほぼすべての主要な機能とテクニックについて説明します。この基本セット（カスタムオペレーターを作成する機能）を拡張するツールもあります。マニュアルの数百ページを読むことなく、関数型プログラミングの理論的な深さを勉強することなく、美しい宣言型コードを書くことができます。 mrr自体は、純粋な計算と状態の変化を分離する巨大なモナドです。

他のライブラリでは異種アプローチ（メソッドを使用する命令型とリアクティブバインダーを使用する宣言型）が共存することがよくありますが、プログラマーは「レタス」をランダムに混合しますが、mrrには単一の基本エンティティ（コードの均一性と均一性に寄与するストリーム）があります。快適さ、便利さ、シンプルさ、プログラマの時間の節約がmrrの主な利点です（ここから、mrrを「mrrrr」としてデコードする、つまり猫の生活に満足している猫を鳴らす）。

欠点は何ですか？

「ライン」を使用したプログラミングには、長所と短所の両方があります。セル名のオートコンプリートは機能しません。また、セル名が定義されている場所を検索することもできません。一方、mrrには常にセルの動作が決定される場所が1つだけあり、ストアのReduxフィールドの値が決定される場所、またはネイティブのsetStateを使用する場合は状態フィールドがさらに少ない場所を検索しながら、単純なテキスト検索で簡単に見つけることができます長くなる可能性があります。

誰がこれに興味がありますか？

まず第一に、関数型プログラミングの支持者-宣言的アプローチの利点が明らかな人々。もちろん、ClojureScriptコーシャーソリューションは既に存在しますが、それでもニッチ製品であり続けますが、Reactはボールを支配します。プロジェクトですでにReduxを使用している場合は、mrrを使用してローカル状態を管理し、将来的にグローバルに切り替えることができます。現時点で新しいテクノロジを使用する予定がない場合でも、mrrは一般的な状態管理ライブラリとは大きく異なるため、おなじみのタスクを新しい観点から見て、mrrを処理して「脳を伸ばす」ことができます。

これはすでに使用できますか？

原則として、はい:)ライブラリは若いため、これまでいくつかのプロジェクトで積極的に使用されてきましたが、基本的な機能のAPIは既に確立されており、現在、主にさまざまなローション（構文糖）で作業が行われ、開発をさらに加速および促進するように設計されています。ちなみに、mrr自体の原理にはReactに固有のものはなく、どのコンポーネントライブラリでも使用できるように適合させることができます（組み込みの反応性の欠如またはこのために一般に受け入れられているライブラリのためにReactが選択されました）。

ご清聴ありがとうございました。フィードバックと建設的な批判に感謝します。

Mrr：Reactの合計FRP