どうしてフロントエンドに React/TypeScriptが 必要なのか？ 2020/12/15 mikan3rd 〜そしてサーバーサイドへ〜

伝えたいこと ● なんでわざわざReact/TypeScriptはを使ってるの？ ● TypeScript（Node.js）でサーバーサイドも作れるよ！

すごいざっくりした フロントエンドの今昔

2000年代 ● HTML + CSS + JavaScript（jQuery） ● 静的webページ（阿部寛のホームページみたいな） ● フロントエンドエンジニアというよりマークアップエンジニア？ ● もしくはサーバーサイドエンジニアが片手間に作る Adobe Flash お疲れ様でした

2010年代前半〜中盤 ● 通信速度が向上し複雑な webページの作成が可 能になる ● UIが複雑化するにつれてjQueryでselector指定で DOMを変更するのに限界が訪れる ● DOMをいろいろ書き換えた結果、今どんな状態な のか把握するのが困難（データとビューの不整合 が発生しやすい） ● コンポーネントに分けて状態管理ができる Angular / React / Vue といったフロントエンド用のフレーム ワークが使われ始める

2010年代後半 ● Redux / Vuex / ngrx といった大規模アプリケーションの状態管理用のフレームワークも誕 生 ● サーバーサイドからフロントエンドを完全に分離して、バックエンドの API + SPA（Single Page Application）という構成が使われ始める ● それに応じてSSR（Server Side Rendering）が必要になるケースが発生（ Next.js / Nuxt.js） ● TypeScriptによる（漸進的）静的型付けでフロントエンドでも型安全なコードが書けるように なる ?

近年のフロントエンドで 知っておくと良い知識

● Google製のTypeScriptベースのwebアプリ用フ レームワーク ● 2009年に発表されたAngularJSというものがあっ たが、いろいろ問題があったため 2016年に Angularとして「作り直された」 ● 名前はほぼ同じだが全くの別物のフレームワーク らしい ● DI（依存性の注入）、様々な機能を付加する decorator、RxJS（非同期とイベントのための Observerパターンを使ったライブラリ）などが特徴 Angular import { BrowserModule } from '@angular/platform-browser' ; import { NgModule } from '@angular/core' ; import { AppComponent } from './app.component' ; @NgModule({ declarations: [ AppComponent ], imports: [ BrowserModule ], providers: [], bootstrap: [AppComponent] }) export class AppModule { }

import React from 'react'; const HelloMessage: React.FC<{name: string}> = ({name}) => { return ( ); }; React ● 2013年に発表されたFacebook製のJavaScript フレームワーク ● Viewの責務に特価し、仮想DOMにより宣言的に UIが記述できる ● コンポーネントはテンプレート構文ではなく JSXで 書くことでDOMと状態を表現する ● JSXなので全てTypeScriptで型安全に書くことが できる ● 最近ではReact Hooksによりコンポーネントから ロジックを分離しやすくなった ● React NativeでAndroid/iOS両対応のネイティブ アプリを作ることも可能 ● 海外でのシェアが高いらしい

Vue ● 2014年発表のJavaScriptフレームワーク ● 仮想DOM、宣言的UIといったReactと似た特 徴を持っている ● 気軽に使い始められるように HTML/CSSを ベースにした簡易なテンプレート構文で書くこ とができる ● TypeScriptも一応サポートされてはいるもの の完全ではなさそう ● 日本でのシェアが高い（東京都コロナ対策サ イトでも使用） const AttributeBindingApp = { data() { return { message: 'You loaded this page on ' + new Date().toLocaleString() } } } Vue.createApp(AttributeBindingApp).mount('#bind-at tribute')

Redux（Vuex / ngrx） ● 状態管理のためのライブラリ ● Reactとセットで使われることが多いが Reactでな くても使える（VuexはVueに依存してるらしい） ● Reactだけだとページをまたぐグローバルな状態 （例えばログイン中ユーザーの情報）を管理する ことが難しいため必要とされた ● redux-saga/redux-formなどReduxを拡張する ライブラリもいろいろある ● コードの記述量が増える&コードを追いづらくなり やすい ● 最近ではReact Contextで同等の機能が実装で きるので不要かも

SPA / MPA ● 従来（Multi Page Application）はルーティングごとに静的なテンプレートが読み込まれる ● SPAでは用意されているテンプレートは 1つだけでJSで書き換えている ● 初回アクセス時に全ページの JSを読み込んで、以降はルーティングに対応してクライアント側で表示 するコンポーネントを切り替えているだけ ● なめらかなページ遷移やリッチな UIが実現しやすい 画像 https://shimablogs.com/what-is-spa

CSR / SSR ● CSR（Client Side Rendering）はSPAの動作そのもの（テンプレートをクライアントサイドで書き 換えてレンダリングする） ● CSRの場合、クライアント側で動的に書き換えられる部分は JSを実行しないクローラーでは読み 取れないのでSEOで不利だった（動的にOGPを変えられない問題は健在） ● SPAにおけるSSR（Server Side Rendering）とは、初回アクセス時のページのみレンダリングさ れた状態にすること（その後のページ遷移は引き続きクライアント側で切り替える） ● SEOやOGP以外の理由でSSR対応する必要はそんなにないので webアプリでは不要（ユザー 認証とかあると意味がない） ● 逆にメディアサイトをSPAで作る場合は要件的に必須だが面倒

Next.js（Nuxt.js） ● Vercel製のReact用フレームワーク（Vue用がNuxt.js） ● もともとはReactでSSR対応するために使われていたが、他にも Dynamic Routing / 画像の最 適化 / ページ単位でのbundleファイル自動分割などReactで足りない要素をカバーするように アップデートされる続けていておすすめ ● 最近ではbuild時にデータを取得して静的ファイルを生成しておく SSG（Static Site Generation） や、一定時間ごとにバックグラウンドでデータの再取得 &ページの再レンダリングを行う ISR （Incremental Static Regeneration）といった機能も注目されています ● またSSRするためにはSSR用サーバーが必要になりますが、 Vercelというフロント向けのPaaSを 使うと準備不要（しかもGitHubのPRを作るごとに環境を用意してくれる）

● 2012年発表のMicrosoft製の（漸進的）静的型付けプログラミング言語 ● 要するに型定義できるJavaScript ● JavaやC#をベースにした型機能も豊富（型推論 / ジェネリック） ● 同じくMicrosoft製のエディターVSCodeと相性が良い（特にESLint） ● 最終的にはJavaScriptにコンパイルして動かす（ts-nodeでtsファイルを直接実行することは可 能） ● （今時そんなにないですが） TypeScriptの型定義がないライブラリを使う場合は面倒 ● 主なメリット ○ 型の整合性チェックによる堅牢性の高いコードの維持（特に既存のコードの修正時など）とテストの量 を減らせる ○ 型定義によりコードの可読性が上がる &コードの補完が効きやすいので開発効率が UP ● https://www.typescriptlang.org/play で試し書きできます TypeScript

React/TypeScriptが 必要な理由

● 今のフロントエンドは複雑な UIの状態変化の管理との戦い ● これまでのHTMLテンプレートエンジンの場合は初回のレンダリングしか表現することができ ず、以降はJavaScriptで書き換えるという技術的な境界があった ● n回目のレンダリングでも整合性の取れた状態管理をするためには全て JavaScriptで表現する しかない（仮想DOM） ● Reactはテンプレート構文ではなく JavaScriptのJSXでDOMと状態を全て表現することができる ● Vueも似ているがDSL （Domain Specific Language）でテンプレートにデータや関数を渡さなけ ればいけない ● さらにJSXであればTypeScriptで全て書くことができ、TypeScriptの恩恵を全て受けることがで きる なぜReact/TypeScriptがベストプラクティスなのか 個人の感想です

サーバーサイドで TypeScript

TypeScriptだけで バックエンドもフロントエンドも作ってみる NestJS / Next.js / GraphQL / TypeORM ● フロントエンドではJavaScriptを使わざるを得ない ● バックエンドもJavaScriptにすることはできる ● Node.jsだけは辛いけどTypeScriptがあれば全然いけるのでは？ ● 唯一型定義が不完全なAPIのIF部分を担保するためにGraphQLを使ってみた ● https://zenn.dev/mikan3rd/articles/5b7840cdbcd2d9 ● ちょうど似たことをYahooでやってた ○ Next.js + NestJS + GraphQLで変化に追従するフロントエンドへ〜 ショッピングクーポンの 事例紹介（2020/12/15） ○ https://techblog.yahoo.co.jp/entry/2020121530052952/

Firebase（Cloud Function）でTypeScript ● firebase のCLIで `firebase init` でするだけでTypeScriptで動くNode.jsサーバーレス環境が作 れます（バックエンドでTypeScriptを簡単に試せる） ● Puppeteerで簡単なクローラーを作って定期処理で動かすのも容易 ○ 個人利用では料金が高額になることはないと思いますが従量課金なので使い方には注意 ● ちなみにこれでSlackアプリを制作中 ○ https://github.com/mikanx3rd/lively

まとめ ● 近年の複雑なUIであってもReactならJSXでDOMと状態管理 を全て表現することができる ● 全てTypeScriptで書けるので型安全かつ生産性の高い開発 を実現できる ● TypeScript（Node.js）でサーバーサイドを作るのも選択肢の 1つとして考えてみては

参考文献 歴史から学ぶ現代のフロントエンド https://speakerdeck.com/10shi10ma/li-shi-karaxue-buxian-dai-falsehurontoendo フロントエンドはどこから来て、どこへ向かうのか？ https://logmi.jp/tech/articles/282382 本当に倒すべきだったのは jQuery ではなくテンプレートエンジンだった https://scrapbox.io/fsubal/本当に倒すべきだったのは _jQuery_ではなくテンプレートエンジンだった 「ちょっとLTやってよ」と突然言われた時に押さえたい５つのポイント https://qiita.com/shogotgm/items/c769cfc7d6fc2ef8f003 その他、それぞれの公式ドキュメント参照