Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

mikan3rd
December 16, 2020

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

【NestJS/Next.js/GraphQL/TypeORM】TypeScriptだけでバックエンドもフロントエンドも作ってみる
https://zenn.dev/mikan3rd/articles/5b7840cdbcd2d9

Next.js + NestJS + GraphQLで変化に追従するフロントエンドへ〜 ショッピングクーポンの事例紹介
https://techblog.yahoo.co.jp/entry/2020121530052952/

参考文献

歴史から学ぶ現代のフロントエンド
https://speakerdeck.com/10shi10ma/li-shi-karaxue-buxian-dai-falsehurontoendo

フロントエンドはどこから来て、どこへ向かうのか?
https://logmi.jp/tech/articles/282382

本当に倒すべきだったのは jQuery ではなくテンプレートエンジンだった
https://scrapbox.io/fsubal/本当に倒すべきだったのは_jQuery_ではなくテンプレートエンジンだった

「ちょっとLTやってよ」と突然言われた時に押さえたい5つのポイント
https://qiita.com/shogotgm/items/c769cfc7d6fc2ef8f003

その他、それぞれの公式ドキュメント参照

mikan3rd

December 16, 2020
Tweet

More Decks by mikan3rd

Other Decks in Programming

Transcript

  1. 2000年代 • HTML + CSS + JavaScript(jQuery) • 静的webページ(阿部寛のホームページみたいな) •

    フロントエンドエンジニアというよりマークアップエンジニア? • もしくはサーバーサイドエンジニアが片手間に作る Adobe Flash お疲れ様でした
  2. 2010年代前半〜中盤 • 通信速度が向上し複雑な webページの作成が可 能になる • UIが複雑化するにつれてjQueryでselector指定で DOMを変更するのに限界が訪れる • DOMをいろいろ書き換えた結果、今どんな状態な

    のか把握するのが困難(データとビューの不整合 が発生しやすい) • コンポーネントに分けて状態管理ができる Angular / React / Vue といったフロントエンド用のフレーム ワークが使われ始める
  3. 2010年代後半 • Redux / Vuex / ngrx といった大規模アプリケーションの状態管理用のフレームワークも誕 生 •

    サーバーサイドからフロントエンドを完全に分離して、バックエンドの API + SPA(Single Page Application)という構成が使われ始める • それに応じてSSR(Server Side Rendering)が必要になるケースが発生( Next.js / Nuxt.js) • TypeScriptによる(漸進的)静的型付けでフロントエンドでも型安全なコードが書けるように なる ?
  4. • 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 { }
  5. import React from 'react'; const HelloMessage: React.FC<{name: string}> = ({name})

    => { return ( <div> Hello {name} </div> ); }; React • 2013年に発表されたFacebook製のJavaScript フレームワーク • Viewの責務に特価し、仮想DOMにより宣言的に UIが記述できる • コンポーネントはテンプレート構文ではなく JSXで 書くことでDOMと状態を表現する • JSXなので全てTypeScriptで型安全に書くことが できる • 最近ではReact Hooksによりコンポーネントから ロジックを分離しやすくなった • React NativeでAndroid/iOS両対応のネイティブ アプリを作ることも可能 • 海外でのシェアが高いらしい
  6. Vue • 2014年発表のJavaScriptフレームワーク • 仮想DOM、宣言的UIといったReactと似た特 徴を持っている • 気軽に使い始められるように HTML/CSSを ベースにした簡易なテンプレート構文で書くこ

    とができる • TypeScriptも一応サポートされてはいるもの の完全ではなさそう • 日本でのシェアが高い(東京都コロナ対策サ イトでも使用) <div id="bind-attribute" class="demo"> <span v-bind:title="message"> Hover your mouse over me for a few seconds to see my dynamically-bound title! </span> </div> const AttributeBindingApp = { data() { return { message: 'You loaded this page on ' + new Date().toLocaleString() } } } Vue.createApp(AttributeBindingApp).mount('#bind-at tribute')
  7. Redux(Vuex / ngrx) • 状態管理のためのライブラリ • Reactとセットで使われることが多いが Reactでな くても使える(VuexはVueに依存してるらしい) •

    Reactだけだとページをまたぐグローバルな状態 (例えばログイン中ユーザーの情報)を管理する ことが難しいため必要とされた • redux-saga/redux-formなどReduxを拡張する ライブラリもいろいろある • コードの記述量が増える&コードを追いづらくなり やすい • 最近ではReact Contextで同等の機能が実装で きるので不要かも
  8. SPA / MPA • 従来(Multi Page Application)はルーティングごとに静的なテンプレートが読み込まれる • SPAでは用意されているテンプレートは 1つだけでJSで書き換えている

    • 初回アクセス時に全ページの JSを読み込んで、以降はルーティングに対応してクライアント側で表示 するコンポーネントを切り替えているだけ • なめらかなページ遷移やリッチな UIが実現しやすい 画像 https://shimablogs.com/what-is-spa
  9. CSR / SSR • CSR(Client Side Rendering)はSPAの動作そのもの(テンプレートをクライアントサイドで書き 換えてレンダリングする) • CSRの場合、クライアント側で動的に書き換えられる部分は

    JSを実行しないクローラーでは読み 取れないのでSEOで不利だった(動的にOGPを変えられない問題は健在) • SPAにおけるSSR(Server Side Rendering)とは、初回アクセス時のページのみレンダリングさ れた状態にすること(その後のページ遷移は引き続きクライアント側で切り替える) • SEOやOGP以外の理由でSSR対応する必要はそんなにないので webアプリでは不要(ユザー 認証とかあると意味がない) • 逆にメディアサイトをSPAで作る場合は要件的に必須だが面倒
  10. 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を作るごとに環境を用意してくれる)
  11. • 2012年発表のMicrosoft製の(漸進的)静的型付けプログラミング言語 • 要するに型定義できるJavaScript • JavaやC#をベースにした型機能も豊富(型推論 / ジェネリック) • 同じくMicrosoft製のエディターVSCodeと相性が良い(特にESLint)

    • 最終的にはJavaScriptにコンパイルして動かす(ts-nodeでtsファイルを直接実行することは可 能) • (今時そんなにないですが) TypeScriptの型定義がないライブラリを使う場合は面倒 • 主なメリット ◦ 型の整合性チェックによる堅牢性の高いコードの維持(特に既存のコードの修正時など)とテストの量 を減らせる ◦ 型定義によりコードの可読性が上がる &コードの補完が効きやすいので開発効率が UP • https://www.typescriptlang.org/play で試し書きできます TypeScript
  12. • 今のフロントエンドは複雑な UIの状態変化の管理との戦い • これまでのHTMLテンプレートエンジンの場合は初回のレンダリングしか表現することができ ず、以降はJavaScriptで書き換えるという技術的な境界があった • n回目のレンダリングでも整合性の取れた状態管理をするためには全て JavaScriptで表現する しかない(仮想DOM)

    • Reactはテンプレート構文ではなく JavaScriptのJSXでDOMと状態を全て表現することができる • Vueも似ているがDSL (Domain Specific Language)でテンプレートにデータや関数を渡さなけ ればいけない • さらにJSXであればTypeScriptで全て書くことができ、TypeScriptの恩恵を全て受けることがで きる なぜReact/TypeScriptがベストプラクティスなのか 個人の感想です
  13. 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/
  14. Firebase(Cloud Function)でTypeScript • firebase のCLIで `firebase init` でするだけでTypeScriptで動くNode.jsサーバーレス環境が作 れます(バックエンドでTypeScriptを簡単に試せる) •

    Puppeteerで簡単なクローラーを作って定期処理で動かすのも容易 ◦ 個人利用では料金が高額になることはないと思いますが従量課金なので使い方には注意 • ちなみにこれでSlackアプリを制作中 ◦ https://github.com/mikanx3rd/lively