React を始めて学んだこと ~第1回~

こんにちは、広野です。

私はいわゆる IT サービスマネージャでして、運用一筋で約 20 年従事してきました。
IT 企業に長年いますがプログラミングを本業にしたことは一度もなく、ほぼ趣味、独学でプログラミングを学んできました。

過去、COBOL、VBScript、ASP、PHP、JavaScript を主に勉強してきましたが、React の習得難易度は他に比べて別格の難しさであったと感じています。

しかし、理解してしまえば React ほど書きやすい言語はない、と今となっては思っています。

今日から、私なりに学んだ React の解釈を何回かに分けて語ります。初回は自己紹介と SPA の概念になります。

React との出会い

私が初めて勉強した開発言語は COBOL でした。IT 企業入社直後の基本情報技術者試験受験のためだけでしたが、お蔭でプログラミングの基礎を理解できました。その後他の言語を学習する上で基礎が身に付いていたことは大きかったと思います。配属されたデータセンター運用業務のかたわら、自分の業務効率化のために VBScript でちょっとしたバッチスクリプトを作り始め、その延長で ASP の WEB アプリ、さらにその延長で PHP の WEB アプリを書くようになりました。誰に命令されたわけでもなく、完全に自分のために書いていました。

歳を取るにつれてマネージャ的な仕事をする時間が長くなり、久しくプログラミングからは離れていました。あるとき部署異動により AWS を学ぶ機会があり、そこで従来とは全く違うサーバーレスアーキテクチャが存在することを知りました。サーバーレスでアプリをどのように作るのか全く想像ができず、趣味で勉強を始めました。試行錯誤の結果、API Gateway、Lambda、DynamoDB でバックエンドをつくり、フロントエンドは S3 に静的 HTML を配置し、HTML から呼び出す JavaScript と jQuery で初めてサーバーレス WEB アプリを書きました。ちょっとしたアプリであれば、コードの非効率さは感じつつも、やりたいことは実現できた感はありました。

ここまでは比較的順調に習得できたのですが、SPA (Single Page Application) 開発にチャレンジせざるを得なくなった出来事がありました。勉強がてら開発した JavaScript、jQuery によるサーバーレス WEB アプリを、社内に展開したいという話が舞い込んできたのです。ですが実現するにあたり、無視できなかったことがセキュリティ対策、特に MFA の導入でした。アプリに MFA を導入するには Cognito と Amplify (正確には Amplify UI ライブラリ) を連携させることが近道であることがわかりましたが、そのためには JavaScript + jQuery で書いていたアプリを SPA に書き換える必要があったのです。

SPA の開発フレームワークにはいくつかのメジャーなものがありました。それらを見比べて、なんとなく直感的に React で即決しました。が、これまでとは習得の難易度が全然違いました。コードの書き方は JavaScript ベースなのに書いたものが全く動かないのです。あまりにも思い通りに行かないために一度は習得を断念しました。その後数か月間、React に関わりませんでしたが、年末年始休みにもう1回だけ頑張ってみようと一念発起し、1週間真剣に React と向き合い、理解することができました。そのときは食事と風呂以外全ての時間を React 学習に費やし、睡魔に耐えられなかったときだけ寝落ちするという生活でした。当時新型コロナ蔓延により年末年始に外出自粛となったことで、このような生活をしていても家族が何も不満を言わなかったのだと思います。(いずれにしろどこにも行けなかったので)

React を理解するために、何をしたか

  • まず Kindle Unlimited を契約し、React 学習本を 1日で 5冊読みました。
  • でも全く理解できませんでした。
  • なぜなら、開発者特有の専門用語が多すぎて、何を言っているのか全く理解できないからです。DOM、メソッド、クラス、レンダー、、、って何?って話です。私は独学でプログラミングしてきた中で、そういう開発専門用語を勉強して来ず。今でもよくわかっていません。
  • 一番役に立ったのは、React 公式ドキュメントでした。
  • そこに書いてあるサンプルコードをひたすら書き写し、自分が理解できる範囲で少しずつ変更しながら動きを理解していきました。
  • インターネットで有志が公開してくれているブログは役に立ちませんでした。
  • なぜなら、コードミスが多かったのと(自力ではミスであることに気付くこともできず、時間を浪費するだけ)、React や React モジュールのバージョン、コンポーネントの違いによってコードの書き方が異なるなど、そのまま書いても動かないことが多すぎたためです。(それを自力で的確にコード修正するまでの実力は当然ない)
  • また、私がつまずいたのは、state という変数の概念でした。これについては、今後語ることにします。

React とは何か

ここまでは自己紹介のようなものでした。前置きが長くなってしまいすみません。

ここからは、私が苦労して理解した React について語ります。

そもそも React って何?

  • JavaScript をベースとした、WEB アプリ開発フレームワーク
  • Facebook 社(現 Meta 社)が開発
  • 今流行りの SPA (Single Page Application)、いわゆるサーバーレスの WEB アプリを開発できる
    モダン WEB アプリケーションとも呼ばれる
  • HTML と JavaScript を禁断の融合をさせたような JSX という言語を使う
    HTML から外部 JavaScript を呼び出すのではなく、ネイティブにプログラマブルになった HTML とイメージすると良い。
HTML と JavaScript の禁断の融合と表現している理由は、私はそのせいで文法の理解に長い間混乱させられたからです。1つのコードファイル内が、JavaScript ベースの文法と HTML ベースの文法で書く部分に分かれます。それぞれは全然違う文法であることはわかっているのですが、初学者にとってはごっちゃになり、細かいところでどう書けばよいのかわからなくなるのです。

React を使うと何かいいことあるの?

画面遷移の際、変更箇所だけを再描画するため、レスポンスが速い。自由度が高い。今風なかっこいい動的画面をつくれる
画面の変更箇所を再描画する命令をいちいち書く必要がない=効率的に書ける。
並列処理、非同期処理が得意、表示できるところから表示させる。だから速い。
画面をコンポーネント(部品)単位に分けてコード化するため、コードの再利用をしやすい=効率的に書ける。
JavaScript と HTML をわかっている人は習得しやすい・・・と思われがちでが、私のようにそうでもない人はいるのでは?

逆に React の悪いところって?

大量データを処理するのは苦手。
表示順序を気にする直列処理をコーディングしづらい。(基本は並列処理なので)
コードがコンポーネント単位で分散するため、コンポーネント間の連携がわかりにくい。

ん-なんだかまだよくわからないんだけど?

そうですよね。ここまでに登場している SPA (Single Page Application) の概念から順を追って説明した方がいいと思いました。
React と言うよりは、SPA の良さを理解して頂こうと思います。

SPA とは

SPA って何?

  • Single Page Application の略
  • その名の通り、WEB アプリケーションを構成する HTML ファイルが index.html しか存在しない
  • index.html から呼び出す JavaScript により、画面を描画する
  • 代表的な SPA 開発フレームワークに、React、Vue、Angular がある

従来の WEB アプリと何が違うの?

画面描画処理の設計思想が全然違います。
大きく分けて画面描画をする役割がサーバか、クライアントかの 2 種類があります。クライアントが画面描画をするアーキテクチャを、サーバーレスと呼びます。

従来の WEB アプリ(サーバサイド)

  • WEB サーバ(サーバサイド)で画面描画処理をする。
    ブラウザは画面描画の都度、WEB サーバにアクセスする。
  • 画面描画は、データ取得後に直列に処理される。(同期処理と呼ばれる)
  • 画面遷移は、リンクのクリックなどをトリガーに画面全体を再描画するイメージ。ブラウザで画面遷移を制御する。
    例:https://example.com/aaa.php の画面から https://example.com/bbb.php へのリンクをクリックする(URL パスが変わる)ことで画面が再描画される。
  • Java、PHP、Python、Go、Ruby などが代表的な言語
サーバサイド WEB アプリケーションは、サーバの処理能力が必要となる大規模処理に強みがあります。

サーバーレス(クライアントサイド)

  • ブラウザに読み込んだ JavaScript が画面描画処理をする。
    データベースやその他リソースとのやり取りは、ブラウザから WEB サーバを介さず直接行われる。
    WEB サーバはホスティング以外のことは何もしないため、サーバーレスやクライアントサイドと呼ばれる。
  • 画面描画とデータ取得は並行に処理される。(非同期処理と呼ばれる)
  • 画面遷移は、ボタンクリックなどをトリガーに JavaScript により画面内で更新が必要な部分だけを再描画するのが基本。
  • React、Vue、Angular、jQuery などが代表的な開発フレームワーク。言語は JavaScript。
画面を部分的に更新できるため、かつクライアント側だけで画面更新をさせるために、画面更新の自由度が高いこととレスポンスが劇的に速いことが特徴です。
画面描画処理がクライアント側デバイスの処理能力に依存するので、大規模処理には向きません。

ここで、サーバーレス(クライアントサイド)WEB アプリの種類が 2 つに分かれます。
従来型(jQuery)と、SPAReact、Vue、Angular 等)です。

同じサーバーレスでも、画面描画の仕組みが全く異なります。

従来型(jQuery)

jQuery のアーキテクチャは、静的 WEB サイトの中で動的に変更したい箇所を HTML タグ個別に JavaScript で更新をかけるイメージです。

  • ソースコードは HTML がベースです。動的に変更をかけたい HTML タグの属性に対して、JavaScript で個別に変更をかけます。jQuery は、あくまでも変更するコードを効率的に書けるようにするためのライブラリ集です。
  • 大部分が静的 HTML で、ほんのちょっとだけ動的に変更させたい部分があるという要件には合います。
  • 逆に、動的に変更させたい部分が多くなればなるほど、コード量も JavaScript ファイルも多くなり、開発者が対応しきれなくなります。
  • HTML に毛が生えたような程度の仕組みなので、コンパイルが不要です。jQuery ライブラリも配置するだけです。導入の容易さはあります。
  • 画面遷移は技術的には JavaScript のみで制御することはできると思いますが、おそらくコードを書くのが大変すぎるため、サーバサイドと同様にリンクで制御するのが主流であると考えられます。
  • 各 HTML ファイル間で重複するコードが多くなります。コード修正が非常に非効率です。
jQuery は、動的な変更が少ない WEB アプリでないと適用は難しいです。
例:静的 WEB サイトに管理者への問い合わせフォームを追加する、入力フォームの値に応じて特定の処理をした結果を表示するだけ、など。
SPA

SPA のアーキテクチャは、全ての画面描画・画面遷移を完全に JavaScript に依存します。

  • ソースコードは JavaScript ベースですが、SPA 開発用フレームワーク(React、Vue、Angular 等)が必ず必要になります。コードの文法は開発フレームワークによって異なります。
  • 開発用フレームワークのモジュールをインストールした開発環境で開発用コードを書き、公開するためにビルド(コンパイル)をします。ビルドしたコードを公開するためのアプリ稼働環境が必要です。アプリ稼働環境にビルド済みコードを配置することをデプロイと言います。ビルド・デプロイするための環境も当然必要になります。
  • HTML ファイルは index.html しかありません。ブラウザが初めて WEB アプリにアクセスするときにどうしても必要なためです。それだけの理由のため、index.html の中身はすっからかんで、画面描画用の JavaScript を呼び出すコードしかありません。(必要に応じて追加することもありますが量は少ないです)
  • 画面遷移は完全に JavaScript の管理下になるため、ユーザがアクセス可能な URL パスは index.html のみになります。ただし、仮想的にパスをつくることは可能です。
    例: https://example.com/ から https://example.com/admin にリンクさせる、など。(実体はないので仮想的です)
  • 動的な画面変更をするために最適化されたコード設計になっているため、画面遷移、画面の部分的な変更の自由度が高いです。いわゆるモダン WEB アプリケーションと呼ばれる、今風のかっこいい画面開発ができます。ただし、コード習得の難しさがあります。何がそんなに難しいのかは今後説明します。
  • 開発用コードはコンポーネントと呼ばれる画面を構成する部品単位で書きます。各コンポーネントには親子関係が生まれます。そのためコードの再利用がしやすく、うまく書けば重複するコードはゼロになります。全体的に効率的なコードになり、コード量も必然的に少なくなります。
    コンポーネント毎にファイルを分けたり、ファイル内でコンポーネントを複数に分けたりなどは自由です。ある程度セオリーはありますが。
動的な変更が多い WEB アプリには断然 SPA 推し。
習得難易度が高いため、未経験からの導入は容易ではないのが難点。しかし習得さえしてしまえば、かっこいい画面を簡単に作れます!

次回予告&まとめ

いかがでしたでしょうか?

書いていて、SPA のアーキテクチャの話ばかりになってしまい、具体的な画面例がなかったため難しくなってしまいました。今後、加筆・修正するかもしれません。

SPA は開発環境、ビルド・デプロイ環境、アプリの稼働環境づくりをしていかなければ動かすことすらできないので、そのあたりの負担を激減させてくれる AWS サービスを次回紹介します。

次々回には、React を象徴する衝撃的な機能を紹介します。それが理解できると、「従来型の開発ではできなかった、あんなことやこんなことができる!」とインスピレーションが湧いてくるはずです。

本記事が皆様のお役に立てれば幸いです。最後までお読み下さいまして、ありがとうございました。

著者について
広野 祐司

AWSサーバーレスアーキテクチャを駆使して社内クラウド人材育成アプリや教育コンテンツをつくっています。ReactでSPAを書き始めたら、快適すぎて他の開発言語には戻れなくなりました。AWSサーバーレスやReactの仲間を増やしたいです。
取得資格:AWS認定は7つ、ITサービスマネージャ、ITIL v3 Expert、等
2020, 2021 APN AWS Top Engineers 受賞
2022 AWS Partner Ambassador 受賞
好きなAWSサービス:AWS Amplify / Amazon Cognito / AWS Step Functions / AWS CloudFormation

広野 祐司をフォローする
クラウドに強いによるエンジニアブログです。
SCSKは専門性と豊富な実績を活かしたクラウドサービス USiZE(ユーサイズ)を提供しています。
USiZEサービスサイトでは、お客様のDX推進をワンストップで支援するサービスの詳細や導入事例を紹介しています。
サーバレスアーキテクチャその他技術ナレッジ
TechHarmony
タイトルとURLをコピーしました