Reactチュートリアルをやった
時系列の感想についてはスクラップを参照。
チュートリアルやっただけで記事書くのは恐縮なんですが、ノート的に書かせてください。
筆者の前提知識
メインはiOS開発です。
最近SwiftUIをやったので、宣言的UIチョットワカルになりました。
HTML/CSS/JavaScriptは、昔勉強したことがあって、基礎的なことはなんとなくわかっています。
ただ最近のモダンフロントエンドは全然わからない感じです。
Reactチュートリアルとしてやったこと
基本的にはReact公式の情報をもとに学習を進めました。
- Reactチュートリアルをやる（2日間）
https://ja.reactjs.org/tutorial/tutorial.html - ドキュメントのMAIN CONCEPTS 1〜12章を読む（1日間）
https://ja.reactjs.org/docs/hello-world.html
トータルの所要時間としては3日間ほどでした。
チュートリアルはCodePanを使って、Webブラウザでもできるんですが、僕はVSCodeでやりました。
将来的にReactで何かを開発することを考えるなら、なるべくローカルでやった方が良いと思います。
チュートリアルとドキュメントは相互補完と書かれているように、
1から丁寧に説明を受けたい人はドキュメント、ざっくり把握したい人はチュートリアルから入るといいよ！ という風にできていました。
この構成はすばらしいと思いました。
ただ公式は簡潔でわかりやすい記述なんですが、初心者には説明不足でして、適宜Qiitaなり本なりで補う必要がありました。
本はたくさん出てますが、以前下記の本のKindle版を買っていて、読めないままだったので、長いときを経て読みはじめたらわかりやすかったです。
感想
純粋に、よくできたいいチュートリアルでした。
ただプログラミング初学者にはハードルが高いと感じました。
ちょっと前にやったのがRailsチュートリアルで、絶望的に長く感じましたが、アレはアレでプログラミングの知識を前提とせずに、
高度な内容について書いているので、あのボリューム感になったんだろうなと今となってみると思います。
Reactチュートリアルのチュートリアルがあってもいいんだと思います。
あとSwiftUIをやっていたので、理解が早かったです。
何年か前にReactに入門しようとして全然わからなかったんですが、やはり宣言的UIの壁があったと思います。
あとは自分なりの理解を書いていきます
純粋な感想はここまでで、あとはReactチュートリアルのチュートリアルとまではいかないですが、補足的なことを書けていけたらいいかなと思います。
Webフロントエンドとは
Webサイトは、HTML+CSSでできています。
Webブラウザが、ネットワークごしにHTML+CSSドキュメントを読みこんで、ユーザーに表示しています。
古のホームページは本当にそれだけでした。
↑古き良きホームページ
HTMLだけだと静的なコンテンツしかつくれません。
動的なコンテンツを実現するために、JavaScritが発明されました。
90年代は、Perlを使ったCGIを使う手法もありましたが、JSが天下を取りました。
モダンWebフロントエンドの分岐点
モダンWebフロントエンドの分岐点になっているのが、ECMAScript6(ES6/ES2015)の登場です。
JavaScriptの歴史を振り返ってみましょう。
JavaScript は 1995 年、Netscape の技術者ブレンダン・アイク (Brendan Eich) によって創られ、1996 年初頭に Netscape 2 で初めてリリースされました。
当初は LiveScript と呼ばれる予定でしたが、Sun Microsystems の Java 言語の人気にあやかろうという不運なるマーケティング上の決定により改名されました ― 2 つの言語が共通点をほとんど持っていないにもかかわらず。
それ以来、このことは未だに混同の元となっています。Microsoft はその数か月後、IE3 とともに JScript というほとんど互換性のある言語をリリースしました。
さらに数か月後、Netscape はこの言語をヨーロッパの標準化団体 Ecma International に提出し、その結果 1997 年に ECMAScript という標準の第 1 版が生まれました。
この標準は重要なアップデートを受けて 1999 年に ECMAScript 第 3 版となり、その後しばらくほとんど安定してきました。
言語の複雑化に関する政治的な隔たりから、第 4 版は放棄されたものの、その多くのパーツは 2009 年 12 月に発行された新しい ECMAScript 第 5 版の基礎となりました。
そして、標準の第 6 版が 2015 年 6 月に発行されました。
Netscape時代からテキトーにつくられた言語でしたが、それが逆にWebのカオス感にマッチしたのか、覇権をとることになりました。
ES2015以降は、「動けばいいんだよ！」的な言語仕様が見直されて、安全性の高い書き方もできるようになっている……気がします。
Reactの登場
歴史を見るとNode.jsの誕生とかモバイル端末の普及とかSPAの流行/Flashの衰退とか色々あるんでしょうが、
2010年代前半はWebフロントエンドの戦国時代だったような趣があります。
前半？ 後半もそうですかね。
2021年に至って、落ち着いてきたような気がします。
（それもあって僕も重い腰を上げてキャッチアップをはじめたわけですが）
ReactはFacebookのJordan Walkeというエンジニアによって開発されました。
社内では2011年には使われていたそうですが、オープンソース化されたのは2013年。
フレームワークだと僕は思ってますが、サイトを見ると「ライブラリ」と自称しているので、正確にはライブラリと呼ぶのが正しいようです。
日本だと2014年にmizchiさんの下記の記事がバズってた気がします。
この頃はAngularとかVue.jsとかも強かったので、まだReactが覇権を握った感じもなかったですし、なんならjQueryも元気でしたね。
僕は2014年にIT業界で働きはじめましたが、古いシステムを触ってたので、jQueryでも「はえ〜すごい」って感じでした。
DOMって？
仮想DOMの前にそもそもDOMってなによ、という話ですが、
「Document Object Model (DOM) は、ウェブ上の文書のコンテンツと構造からなるオブジェクトのデータ表現です」というのがちゃんとした説明になるかと思います。
HTMLで構成されたドキュメントは、そのままだJavaScriptで操作しづらいので、
操作しやすい表現形式が必要で、そのためにツリー構造でHTML文書を表現する形式が考案されました。
それがDOMです。
仮想DOM（Virtual DOM）
仮想DOMの仕組みがないフレームワークだと、ブラウザのイベントに対して、DOMを直接書き換えていました。
Reactの扱う仮想DOMは、メモリ上でDOMツリーを構築して、差分更新ができるので、複雑な処理をしてもサクサク動きます。
ちょっと僕は「差分更新だから早い！」という理屈まではわかったんですが、中身の動作がよくわかってないので、どうしてこんな上手いこと更新できてるのかわかってません。
コンポーネントが状態を持たないことについての考察
Reactはコンポーネントという単位でUI部品を分離します。
class xxx extends React.Component {
render() {
return (
// do something
);
}
}
このコンポーネントはデフォルトでは状態を持ちません。
（持たせることはできます）
2019年にiOS開発に移るまで、僕はUIを触ったことがありませんでした。
UIを触るようになってみて思ったのですが、UIを中心にソフトウェア設計を考えると、また違う風に見えてきます。
UI部品というのは「ガワ」であって、内部でデータを持ったり、処理したりしない方がいいです。
所謂MVCの設計でも、ViewはあくまでView、とは言われています。
ただ理想論では責務の分離をわかっていても、現実的に実装進めていくと、ViewとControllerの責務分担はごちゃごちゃしていきます。
開発しているフレームワークにも依存するとは思いますが、僕はiOS（SwiftUI以前）のイメージで書きます。
iOS開発だと、UIをStoryboardでつくって、ロジックはViewControllerに書く、という設計が基本となります。
それでアプリの規模が大きくなると、ViewControllerが肥大化するという問題が生じて、1000行、2000行のFatViewControllerが普通に生まれます。
（模範解答としては、アーキテクチャーを入れて責務を適切に分割しようね、なんでしょうが、今の僕の職場だと普通にMVCでやってます）
じゃあStoryboardじゃなくて、コードベースでViewつくって、ViewControllerの責務をViewに移してやるといいのではないかと思ってやってみると、これはこれでしんどさがあります。
プログラマーにとって、コードで扱えるのは嬉しいですが、UIの持っている複雑性というのは、そのままコードで指定するには厳しいと思います。
もしできる人がいるとしたら、高いレベルのデザイナースキルと高いレベルのプログラムスキルをあわせ持った人なんでしょうけど、もしかしたらその人（いるとして）にも厳しいかもですね。
結局iOSでもReactのパクりみたいな宣言的UIとしてSwiftUIが2019年に爆誕したわけですが、
宣言的UIはUIをコードで記述できて、かつUIレイヤーを明確に薄くするように開発者に促す仕組みで、UIの記述方法としては現状最善なのだと思われます。
興味がデータからUIに移っている？
UI中心に考えると、「データはなんか上手いことやってよ」と思うときがあります。
プログラミングの歴史を考えると、バグが出るレイヤーは、UI層とデータ層の2つでした。
UIは最悪最低限でもいいですが、データ層のバグはクリティカルなので、かつてはデータ層でバグを出さないことが至上命題でした。
そのために人類はDBをつくり、排他制御の仕組みをつくり、トランザクション制御の仕組みを発明しました。
かつてのWebシステムはその辺ガバガバで信頼性が低かったですが、90年代を通じてそこら辺の信頼性が上がってきました。
2000年代以降では、Web/モバイルは洗練されたUIが競争力になり、要求される動作も複雑化しました。
UIを中心に考えると、「データはなんか上手いことやっといてよ」という思想になって、UI部品は純粋にUIロジックだけに専念したくなります。
UI部品はスマートフォンにかぶせるカバーみたいなもので、中身のスマートフォンがたとえ変わったとしても、
そのサイズさえ合っていれば、どんな端末にでも使えます。
これをプログラミング的にどうすれば都合がいいかというと、
フレームワークがあるスマートフォンを受け取ったとき、
- サイズがカバーに合っていれば、カバーつきのスマホを返す、
- サイズが合わなければ、そのままのスマホを返す
とすると、カバーは同じスマホを受け取ったとき、同じ結果を返します。
関数型言語でいう純粋関数と同じになります。
まとめ
んーなんかちょっと最後の方が、宣言的UIに至る問題意識みたいなのを自分なりに考えて書いてみようとしたんですが、
なんか上滑りした記述になったような気がします。
まだまだReactもWebフロントエンドも全然わからないですが、チュートリアルのおかげで雰囲気でQiitaの記事読んでた頃の記憶が、
「あっ、これそういうことだったのか」みたいに有機的に結びついてよかったです。
来週はReactを使って、実際に自分でアプリをつくってみようと思います。
二週間前に、「Railsでじゃんけんアプリをつくる」という目標を立てて、結局未完で終わったので、Reactでそれをやってみようかな〜と思います。
Discussion