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

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

● 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 { }

View Slide

import React from 'react';
const HelloMessage: React.FC =
({name}) => {
return (

Hello {name}

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

View Slide

Vue
● 2014年発表のJavaScriptフレームワーク
● 仮想DOM、宣言的UIといったReactと似た特
徴を持っている
● 気軽に使い始められるように
HTML/CSSを
ベースにした簡易なテンプレート構文で書くこ
とができる
● TypeScriptも一応サポートされてはいるもの
の完全ではなさそう
● 日本でのシェアが高い（東京都コロナ対策サ
イトでも使用）

Hover your mouse over me for a few seconds to
see my dynamically-bound
title!

const AttributeBindingApp = {
data() {
return {
message: 'You loaded this page on ' + new
Date().toLocaleString()
}
}
}
Vue.createApp(AttributeBindingApp).mount('#bind-at
tribute')

View Slide

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

View Slide

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

View Slide

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

View Slide

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を作るごとに環境を用意してくれる）

View Slide

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

View Slide

React/TypeScriptが
必要な理由

View Slide

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

View Slide

サーバーサイドで
TypeScript

View Slide

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/

View Slide

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

View Slide

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

View Slide

参考文献
歴史から学ぶ現代のフロントエンド
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
その他、それぞれの公式ドキュメント参照

View Slide

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

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

mikan3rd

More Decks by mikan3rd

Other Decks in Programming

Featured

Transcript