無から有へ
フロントエンドの誕生の当初は、ドキュメントとして、いくつかの基本的なレイアウトを行うことができ、相互作用は、フォームの送信に限定されています。端末の貧しいコンピューティングパワーは、ロジックが主にバックエンドによって処理されるにつながり、長い時間が互換性に費やされている、インターネットの速度が制限となっている、端末で直接結果を取得することを好むのではなく、データを取得し、フロントエンドでレンダリングされ、非常に遅い開発のフロントエンド、および非常に強い依存のバックエンド。ページ間の接続がなく、ルーティングは、バックエンドによって制御されます。
Ajaxの普及後、フロントエンドは柔軟にデータをプルすることができ、一度にすべてをロードする必要はありません、今からデータを管理する必要性を持つようになったが、最初は使用後に直接データを取得することです。しかし、実際の状況ははるかに複雑であり、リクエストを開始するところが多くあり、DOM操作に戻ってくるところも多い。
より多くのajaxリクエストで、独自のデータの各方法は、受け入れられなくなり、一緒にすべてのデータの管理を検討し始め、その後、DOM /コンポーネントを更新するデータに行くと、同時に、データを管理するためのグローバルオブジェクトの使用を検討することができます。今のところフレームワークはなく、アイデアだけです。
フロントエンドMVCプログラム
この種のフレームワークは、私がこの業界で長年働いてきた中でほとんど聞いたことも使ったこともありませんが、それでも開発の歴史の段階として知っておくことは重要です。
Backbone.jsは 、フロントエンドでMVCを完全に実装する初期の有名なフレームワークで、オブジェクトの形でデータを格納するクラスと、モデルの順序付けられた組み合わせを格納するメソッドを提供します。これは、ローカルにデータベースのコピーを作成し、ローカルにCRUDのインターフェイスを提供する様々なメソッドを提供することに相当します。 バックボーンのブレークスルーは、ルーティングをフロントエンドに置くことで、データレイヤー全体をフロントエンドにも置くことができるようにすることです。しかし、この構造は、バックエンドからより多くの作業負荷をシフトさせるだけでなく、実際には核となる問題の多くを解決していないことがすぐに明らかになりました。
フロントエンドのデータに関する核心的な問題は、フロントエンドのデータの多くが状態を記録するために使われているだけだということです。 バックエンドにとって、状態変数のほとんどは一時的なもので、一時的な使用のためにリポジトリから取り出されます。一方、フロントエンドにとっては、ビジネスに関連することが多いビューレイヤーと状態が互いに関連付けられることを決定するため、非常に重要です。jquery時代には、クリックイベントでポップアップの表示/非表示を行うなど、これらの変数は命令的に処理されていましたが、このロジックが大きくなるにつれ、イベントへの対応に追われるようになり、ビジネスロジックと構造ロジックが混在するようになりました。そこで、新しいアイデアが生まれ始めました。
UI=render
バックボーンのMVC構造は、直接問題のバックエンドのデータをコピーして、再利用に資するものではありませんC層にビジネスデータを組み立てることであり、スキーム内のDOM操作はまだjQueryの処理に似ている、コマンドスタイルの操作DOMは、状態を変更します。
しかし、実際には、これらは、データベースの読み書きには適していないことがわかり、テーブル構造、データの同じ種類の状態を持っていない、とよく管理されていない、データがDOMを決定するので、我々は、非コマンド式でDOMを操作する必要はありませんか？データが一元的に管理され、ビューの変更を促すことができるため、この新しいアイデアはデータ駆動型UIと呼ぶこともできます：
- jquery：コマンドスタイルのDOM操作
- Vue/React：DOMを気にせず、データだけを気にする、データが変わればDOMも変わる
例えば、ポップアップウィンドウを表示する場合、jQueryの操作はDOMの追加、DOMの削除であり、データドリブンフレームワークは、DOMと変数の関連付けをフレームワークで完結させるため、true/falseの状態変化だけで、要するに、DOMからデータに注目するようになりました。再利用はまた、コンポーネント化によって解決することができますので、ビューのビジネスニーズは、標準的な作品に、状態/小道具の様々な外部依存、フロントエンドの開発をよりエンジニアリングになります。データレベルの集中は、ビューレベルの集中、つまりコンポーネント化にもつながります。
コンポーネント間コミュニケーション
先ほど言ったように、データはビジネスデータと状態データに分けられます。状態データのほとんどはUIに関連するもので、例えばラジオボックスにチェックが入っているかどうか、ボタンをクリックできるかどうかなどですが、これらはコンポーネント内の状態データであり、ビジネスロジックを理解する必要はありません。またはステートレスで、データはほとんど入力に依存します。
別の種類の状態データは、クロスコンポーネントの状態データであり、データベース内のビジネスデータのマッピングではありませんが、それはフロントエンドの相互作用において非常に重要であり、例えば、3レベルのリンケージのリージョンセレクタなど、クロスコンポーネントの相互作用が必要になったら、親子/兄弟コンポーネント間の通信を解決するための通信メカニズムが必要です。Reactがこれを処理する方法は、親コンポーネントが子コンポーネントにハンドラを渡すことですが、これはエレガントではありません。コンポーネント内のより広い範囲の状態を一元的にデータ管理する必要があります。
この時点で、私たちはデータ管理を次のレベル、つまりSPAアプリケーションのためのグローバルなデータ管理という新しい世界に引き上げました。ここでは、Flux、EventBus、Redux、Mobxなど、一連のフレームワークに出会うことになりますが、後半はこれらについて話しています。
次の質問
ReactはMVCフレームワークですか？MVCを議論する前にMVCを定義しましょう：
- Modelはデータの管理を担当し、ビジネスロジックのほとんどはModelに配置されるべきです；
- Viewはユーザーインターフェースのレンダリングを担当し、ビジネスロジックはViewに置かないようにします；
- Controllerは、ユーザの入力を受け付け、ユーザの入力に従って対応するモデル部分のロジックを呼び出し、結果のデータをView部分に渡し、Viewが必要な出力をレンダリングできるようにします。
MVC（Model-View-Controller）の世界では、ReactはVパートに相当し、ページのレンダリングにのみ関与します。 アプリケーションのデータ管理部分が関与した後は、やはりModelとControllerに委ねられます。しかし、ページが1つしかなく、ページがすべてファイルに書き込まれ、維持するためにすべて状態に依存している場合、かろうじて状態をモデルとして数えることができ、Viewのレンダリング部分が、本当にControllerを見つけることができません。ほとんどの場合、アプリケーションとして1ページだけというわけにはいきませんし、1ページだけにReactを搭載する必要もありませんし、ましてやMVCでアプリケーションと呼ぶのは難しいでしょう。
React - ユーザーインターフェイスを構築するためのJavaScriptライブラリ。
つまり、ReactはViewレイヤーだけを担当すればよく、jQueryを置き換えるために使われ、FluxのようなフレームワークはBackbone.jsのようなMVCフレームワークを置き換えることを目的としているので、React＋Flux/ReduxでかろうじてMVCと呼べる程度だと思います。 MVCフレームワークの場合、データの流れを制御可能にするために、ControllerはMVCフレームワークの場合、データの流れを制御可能にするためには、Controllerが中心になるべきで、ViewがModelにメッセージを渡したいときはControllerのメソッドを呼び、同様にModelがViewを更新したいときもControllerを通して新しいレンダリングをトリガーする必要がありますが、実際にはフロー通りにいかないことが多いので、React + Flux/Reduxは厳密な一方向のデータフローを使うことでMVCを実装しています。
では、VueはMVVMフレームワークなのでしょうか？多くの人がそう考えているため、これについては混乱が多いのですが、まずはMVVMの定義からも始めましょう：
- モデルはデータとロジックです；
- Viewは、ユーザーが画面上で見る構造、レイアウト、外観で、UIとしても知られています；
- ViewModelは、View層とModel層の両方と通信するバインダーです。
MVVM の コアとなる実装は ViewModel 層のデータバインディングによるもので、コアとなる考え方は ViewModel を介して View 層と Model 層を分離することです。 View 層は Model 層と直接通信することはなく、ViewModel 層を介してのみ通信することができます。MVVMの概念をVueに当てはめてみましょう：
<template>View: 1つのファイルにまとめられたタグの内容で、ユーザーに表示されるコンテンツ。ViewModelと双方向にバインドされており、ViewModelが提供するデータを挿入することができます；- ViewModel：Vueインスタンス全体がViewModelであり、Viewと双方向にバインドされています。 ユーザーがViewのデータを変更したり、ajaxなどのコマンドを送信したりすると、ViewModelがタイムリーに対応し、Modelを修正します。このことから、ModelとViewは直接関係ないことがわかります；
- モデル：このレイヤーは曖昧かもしれません。Vuexの場合、Vuexが提供するデータはModelであり、Modelがビジネスロジックを含むバックエンドアーキテクチャと一致しています。しかしVuexがなければ、ModelはJavaScriptのデータオブジェクトそのものであるVueインスタンスのデータプロパティになります。
Vueのドキュメントをよく読んでいる人なら、Vueインスタンスの変数名がvmであることに気づくでしょうし、ドキュメントには、 「MVVMモデルを正確に踏襲しているわけではないが、VueのデザインはMVVMモデルにインスパイアされている」という非常に丁寧な記述が加えられています。VueがMVVMに反しているという主張の中には、次のようなものがあります：
厳密なMVVMでは、ViewがModelと直接通信できないことが要求されますが、Vueはコンポーネントに$refs属性を提供することでこれに違反しており、ModelがViewを直接操作できるようになっています。
それが正しいかどうかは、結局のところわかりません：
10人のソフトウェアアーキテクトを部屋に入れ、Model-View-Controllerパターンとは何かについて議論させたら、12通りの意見が出るでしょう。意見です。
ですから、これは標準的な答えのないオープンな質問なのです。
要約すると
ページ上の最も単純なデータ処理から、複雑なシステムがデータ、状態、スタイルを管理する方法まで、フロントエンドが進化するにつれて、私たちはより複雑なフレームワークを使い始め、状態管理とコンポーネント化は、データを保存し管理するための様々なソリューションやフレームワークとともに急速に進化します。フレームワークの選択だけでなく、フロントエンドのデータを管理する正しい方法をどのように選択するかは、現代のフロントエンドにとって検討すべき課題となっています。
