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. どうしてフロントエンドに
    React/TypeScriptが
    必要なのか?
    2020/12/15
    mikan3rd
    〜そしてサーバーサイドへ〜

    View full-size slide

  2. 伝えたいこと
    ● なんでわざわざReact/TypeScriptはを使ってるの?
    ● TypeScript(Node.js)でサーバーサイドも作れるよ!

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  6. 2010年代後半
    ● Redux / Vuex / ngrx といった大規模アプリケーションの状態管理用のフレームワークも誕

    ● サーバーサイドからフロントエンドを完全に分離して、バックエンドの
    API + SPA(Single
    Page Application)という構成が使われ始める
    ● それに応じてSSR(Server Side Rendering)が必要になるケースが発生(
    Next.js / Nuxt.js)
    ● TypeScriptによる(漸進的)静的型付けでフロントエンドでも型安全なコードが書けるように
    なる
    ?

    View full-size slide

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

    View full-size slide

  8. ● 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 full-size slide

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

    Hello {name}

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

    View full-size slide

  10. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  14. 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 full-size slide

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

    View full-size slide

  16. React/TypeScriptが
    必要な理由

    View full-size slide

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

    View full-size slide

  18. サーバーサイドで
    TypeScript

    View full-size slide

  19. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide