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

フロントエンド

 フロントエンド

身内で行った勉強会での発表資料

Shinobu Hayashi

November 08, 2020
Tweet

More Decks by Shinobu Hayashi

Other Decks in Programming

Transcript

  1. フロントエンド
    22卒勉強会

    View full-size slide

  2. 注意書き
    この発表はフロントエンドという脈々と続く歴史を一新米エンジニアである
    @Shinyaigeek が解釈しまとめたものになります。
    なので思想めいた部分が一部登場します。
    また怒られそうなテーマでもあるので, 資料の二次配布は禁止させてください。

    View full-size slide

  3. Agenda
    ● Classic Frontend
    ○ jQuery, Rails, BEM, Sass, gulp
    ● Modern Frontend
    ○ React, MicroService, gql, CSS in JS, babel, webpack, typescript, Redux
    ● Deep Frontend
    ○ perf, i18n, Next.js, service worker, Linter, E2E, storybook
    ● 誰ガ為ノUsability

    View full-size slide

  4. Classic Frontend

    View full-size slide

  5. Classic Frontend
    数年前の, ServersideのテンプレートエンジンでHTMLを吐き出して, クライアントサイド
    でjQueryなどでゴリゴリDOM操作をしていた時代のフロントエンド(造語)

    View full-size slide

  6. 古き良きFrontend
    ● ブラウザ対応は手動で頑張る
    ● モジュールはglobal namespaceに登録される (ex $ jquery)
    ● 型が!!!!!!無い!!!!!!
    ● DOM APIを介してのDOM操作には人間には限界がある
    ● CSSの名前衝突

    View full-size slide

  7. Node.jsの台頭
    JavaScriptをサーバーサイドで書けるようになった.
    これによりフロントエンドの開発ツールをJavaScriptで書けるようになり, フロントエンド
    エンジニアがバシバシ開発ツールを開発し始めた. またサーバーサイドのコードとフロ
    ントエンドのコードを共通させて書きたい需要.

    View full-size slide

  8. Modern Frontend

    View full-size slide

  9. Package Manager
    JavaScript(not only Frontend)におけるPackage Manager
    for Frontend, for Serversideなライブラリ両方揃えられている.
    npm/yarnの二つがよく使われている.
    どちらもlockfileもworkspaceもサポートしているし
    実行速度もあまり差はない.
    基本好みレベルの話だと思っている.(稀にこっちじゃないとみたいなのはある)
    ただlockfileの管理がだるいので, 1projectでどちらかのみを使う.

    View full-size slide

  10. Module Bundler
    Classic Frontendにおいてモジュールはglobal namespaceに登録される(激ヤバ)
    例えばjQueryだと, window.$ を利用することになる為, window.$を利用するようなライ
    ブラリは使えなくなるといった問題が起こった.
    一方Node.jsだと, モジュールを
    const fs = require(“fs”)
    という感じで読み込んでいた.
    これをフロントエンドに持ち込みたいとなり, require.js 等が開発されたが流行らなかっ
    た...

    View full-size slide

  11. Module Bundler
    Browserifyの登場: Node.jsのコードをフロントエンドでも用いたい.
    -> Q. なぜできなかったか A. ブラウザjsにはrequireがないから
    -> buildの過程で, moduleをbundleすることでrequireのあるjsをブラウザでも動く
    ようにしてあげる

    View full-size slide

  12. ECMAScript
    こうした流れを受け, JSにもモジュールシステムを導入すべきだし、もっとイケてる言語
    にしようぜ!!
    import * as React from “react”
    ESModules対応しているブラウザだと, 普通にimport出来る.
    class文とかも, ESで使えるようになってる.

    View full-size slide

  13. Transpiler
    ESMはもちろん新しいブラウザでしか動かない
    -> 古いブラウザでも動くようにする

    View full-size slide

  14. Compile
    どうせESをtranspileするなら, 型付けできてもいいでしょ!!!

    View full-size slide

  15. TypeScript
    基本的にliteral type(string, number …), union type( | ), Intersection Type( & ).
    interface, type assertion, type guardだけ覚えたら割と使える.
    より高度なことがやりたければtype override, generics, Conditional Typesを覚えよう
    union type, intersection Typeはただの論理和, 論理積, あまり難しく考えなくとも理解
    できる

    View full-size slide

  16. TypeScript
    Interface と type { } の違い
    「Interfaceは extends できる!!」
    -> 「type { } も & を使うことで実質 extends できなことはできる(びっくり度は増える)」
    実はInterface と type { }の, 出来ることの違いはそこまでない
    . 認識の違い.
    type { }はobjectの型定義を行なっているというイメージ
    .
    Interfaceはclassの型や, functionの引数など, Interface の型定義を行うイメージ

    View full-size slide

  17. Typescript
    とりあえずの心得
    ● any, @ts-ignoreは基本的にNG
    ● Hoge as HogeAlt みたいな Type assertionは用法用量わきまえて
    ○ as はTypeScriptの推論より俺の方が賢いぜ!!ってなった時 , TypeScriptを洗脳するイメージ
    ○ !はnon-null assertionと行って,値をnullableでないことをTypeScriptに言い聞かせる感じ , これもカ
    ジュアルに使える割りに危険 .
    ■ tscがnullableだよって行ってるなら , 値チェックはしてあげるべき

    View full-size slide

  18. yarn buildの中身
    babelでtranspileするときは
    babel {sourcefile}
    typescriptをcompileするときは
    tsc
    webpackでbundleするときは
    webpack

    View full-size slide

  19. yarn buildの中身
    create-react-appをみてみよう
    -> react-scriptsでbuildしてる
    -> react-scriptsはwebpackを呼び出してるだけ
    Q. babelやtscは?
    A.babel-loaderやts-loaderを食わせることでtranspileやcompileもbundle
    のタイミングでできる

    View full-size slide

  20. yarn buildの中身
    ちなみにbabelでも, “@babel/preset-typescript”を食わせることでtypescriptの
    compileはできるし, tscもbabelのやってるtranspileも出来る. webpackもcompileも
    transpileも出来る. (ちなみにparcelは0 configで出来る)
    構文をES5の構文に落とし込む部分の実装はそれぞれが持ってる為、同じコードでも
    Babel, tscでビルドすると結果が違う(けど困ることはあまりない。。)

    View full-size slide

  21. Declarative UI
    DOM APIを介してのDOM操作は人間には限界がある
    document.querySelector でDOM 要素にアクセスしてSPA作るの無理...
    こういう宣言的な感じで描きたい
    const [name, setName] = useState(“”)
    {name}

    View full-size slide

  22. Declarative UI
    DOM APIを介してDOMを操作することの辛さは, HTMLの世界とJSの世界が独立して
    いて, DOM操作するためにはJSの世界からDOM APIを介してHTMLの世界に干渉す
    るという形式を取らざるを得ないところにあった.
    ReactやVueは HTMLの世界をJSの支配下に置くことで Declarative UIを実現した.

    View full-size slide

  23. JSXは何者?
    JSの世界にHTMLを持ち込もうとしてできたものと考えればわかりやすい.
    実はショートハンドでもあり, 文法はJavaScript的にはアウト. babelによるtranspileに
    よって正しいJavaScriptになって、実行される. @babel/preset-reactを入れないといけ
    ないのはそのせい.
    例えば
    asdf は
    React.createElement(“div”, { id: “hoge” }, “asdf) と変換される.

    View full-size slide

  24. Deep Frontend

    View full-size slide

  25. SSR, SSG, CSR, ISR
    CSR: Client Side Rendering
    要するにSPA的な振る舞いのこと, クライアントでcontentをレンダリングする
    SSR: Server Side Rendering
    ユーザーが最初に目にするコンテンツだけクライアントでレンダリングしちゃう,
    hydrateによってSPAになる.
    SSRはRequestがSSRサーバーに届く毎に実行される. 仕草的にはRails等のテンプ
    レートエンジンと一緒

    View full-size slide

  26. SSR, SSG, CSR, ISR
    SSG: Static Site Generate
    Contentのレンダリングを, SSRサーバー上でRequestが届くたびに行うのではな
    く、CI/CD環境でコンテンツの更新時に行う. そうして吐き出された静的なコンテンツを
    静的サーバーから配信する. hugoと一緒.
    ISR: Incremental Static Regeneration
    Requestが届いてSSRするが、その結果を一定期間KVSに保存して、結果が保存
    されている間はSSRせずに保存されているcontentを返す

    View full-size slide

  27. SSR, SSG, CSR, ISR
    大事なところかつ共通しているところは, データを持つサーバーと, その結果を映し出す
    Rendererがしっかり分けられていること
    DataStore Renderer
    JSON
    ベースとなる技術, 考え方自体は同じ. WHENとWHEREの違いで
    しかない

    View full-size slide

  28. SSRはもう古いの?
    そんなことは!!!!!ない!!!!!!!!!
    SSRでしかできないこともあるし, SSGでしかできないこともある. ISR
    もある.
    これらは思想とhowの違いに過ぎないので, 優越はない

    View full-size slide

  29. CSS
    JSの世界とHTMLの世界が独立していたように, CSSの世界も独立している.
    CSSはセレクタ(“.{class name}”みたいな)を介してスタイリングを行う.
    名前衝突も起きがち...
    Classic Frontendだと名前衝突が起きないようにルールを決める -> BEM
    Modern Frontendだと...?

    View full-size slide

  30. CSS
    JSの世界にCSSも委ねてしまう.
    ● CSS Modules
    ● CSS in JS
    shadow domで頑張ってるアプローチも見かける

    View full-size slide

  31. CSS
    Sass, PostCSS等, buildしてCSSを吐き出す潮流があった.
    tailwind cssは, めちゃくちゃちっちゃい単位でCSSを分解されていて, classを介してそ
    れを割り当てていくイメージ. 慣れれば要素に直接スタイリングしていく感じでかける.
    使われていないCSSはPostCSS等でPurgeする.

    View full-size slide

  32. Graphql
    Graphqlのgraqhは Oriented Graphのgraph
    RDBのtableや, MicroServicesにおけるService間の, データの冗長化は人間にはわ
    かりにくい.
    User User-Company Company
    こう描きたい
    User Company

    View full-size slide

  33. Graphql
    type Company {
    name: String
    location: String
    }
    type User {
    name: String
    company: Company
    }
    ● Frontendの欲しいデータBaseに記述できる!
    ● Scheme から型をcodegenできる!
    Service
    1
    Service
    2
    Service
    3
    GraphQL BFF Server
    Client

    View full-size slide

  34. 状態管理ツール
    APIから取ってきたデータをバケツリレーするのはしんどい
    API
    JSON

    View full-size slide

  35. 状態管理ツール
    ● Redux
    ● useSWR
    ● React ContextAPI, useReducer
    ● React Query
    ● Apollo
    これらは思想の違いでしかなく, お互いに優越はない.
    どの思想がどの状況にマッチするかの違い.

    View full-size slide

  36. 状態管理ツール
    Redux
    Dataを一括でRedux Storeで管理する
    mutateもactionをdispatchしていく
    useSWR
    React Query
    Apollo
    Dataをcacheでいい感じに管理して, そ
    の中身をいじいじする

    View full-size slide

  37. 状態管理ツール
    ←基本こんな感じでいい
    自分でこの辺を説明しつつ
    選定できるとなおよし

    View full-size slide

  38. i18n
    Q. i18n A. Internationalization(国際化対応)
    not only 多言語対応
    but also 横読み, 縦読み, カレンダー, 日付の順番, 住所etc...
    法律的に引っかかるものを配信しないとかもある .
    児童ポルノとかを考えるとわかりやすい .
    他にも文化的な忖度も .
    これは “台湾といった国を” というのを “台湾といった国や地域を ” という表現に書き換えるとかを考
    えるとわかりやすい.

    View full-size slide

  39. i18n
    多言語対応の流れ
    1. この文言を多言語対応させると明示する
    Component/Hello, {_i18n(“Component/Hello”)}
    2. extractして, この文言を多言語対応させたいというリストをgenする
    3. そのリストをよしなに書き換える ComponentHello -> こんにちは 大家好 Hello
    4. compileする

    View full-size slide

  40. i18n
    Q. 多言語対応以外は?
    A. 頑張れ...
    例えば “編集” ボタンみたいなのが, 言語によってはめちゃくちゃ長い文字数になること
    でスタイル崩れが起きたりもするので, どこまで対応するかを踏まえた上でデザイナー
    とコミュニケーションをしていくことが大事.

    View full-size slide

  41. a11y
    ● tabで全ページ操作できるようにする
    ● Modalが出た時のtab focusの扱い
    ● screen readerを用いてる人でもbuttonがbuttonだとわかるようにする
    ○ divで書かれた, 見た目だけのbuttonはbuttonだとわからない
    ● タブで操作する時, 今どこにfocusが当たってるかわかるようにする
    ● クライアントのOSの設定に準拠したスタイリング
    ● responsive
    ● etc...

    View full-size slide

  42. a11y
    ちゃんとしたbuttonや, ModalのFocusなどは基本的にUI libraryを使っていれば回避
    できる問題ではある. 自分で作るときは気をつけて作ろう....
    クライアントのOSの設定に準拠したスタイリングはprefers-*で出来る.
    ex) prefers-color-scheme: ダークモードかそうでないかでstyleを分けられる
    レスポンシブデザイン
    MediaQueryで行う. Reactならfresnelというライブラリを使うのが, Component base
    にできて楽なのでおすすめ

    View full-size slide

  43. Performance
    大前提: やらかしを無くす
    Reactをちゃんと使えば開発者がわかるほど遅くなることはそこまでない
    ● ちゃんとproduction buildしてる?
    ● モジュールの使われてない部分もbundle fileに含まれてない?
    ● “/” で使うコンテンツを “/post” とかでも読み込んでない?
    ● 余分なものを読み込んでない?

    View full-size slide

  44. Performance
    あるあるの失敗
    fontawesomeで, Twitterのアイコンを利用しているとき, GitHubやLinkedInなど, 関係
    ないアイコンのSVGとかも読まれてる.
    実際は400x400くらいのサイズで表示されているのに, 画像を1600x1600で読み込ん
    でいる
    source mapがビルドファイルに含まれている

    View full-size slide

  45. Performance
    ブラウザがレンダリングする仕組み
    Download Parsing Scripting
    Caluculate
    Style
    Layout
    Paint Rasterize
    Composite
    Layers

    View full-size slide

  46. Performance
    I/O Costを下げる.
    ● ファイルサイズを下げる
    ○ 今すぐいらないファイルはあとで読み込む
    ■ “loading” attr, rel=”preload” code splitting
    ○ いらないコードはバンドルに含まない
    ■ Treeshaking
    ■ dead code eliminating
    ● レイテンシーを下げる
    ○ CDN
    ● I/Oを減らす
    ○ differential serving : 必要なJSだけ配信する
    ○ Critical CSS Optimazation : first viewに必要なcssだけ配信する

    View full-size slide

  47. Performance
    Runtime Costを下げる.
    ● DOMが大きくなりすぎないようにする
    ● JSのファイルサイズを小さくする
    ● JavaScript engineの最適化を受けるようなコード
    ● UI libraryの最適化を受ける
    ○ 不要なre-renderingを避ける
    ■ React.memo, Redux, map key
    ○ 不要な再計算を避ける
    ■ useMemo, useCallback
    ● 計算量を減らす

    View full-size slide

  48. Semantic HTML
    タグとかってなんの為にあるの?
    -> stylingを使えば, ただのdivタグも見た目だけはと同じに出来る.
    -> like と, は見た目は同じだが意味論的には全く違う
    -> 機械からすれば, like はただのdiv
    見た目だけ整えるのではなく, HTML の Semanticを守ったHTMLを書くことで, 機械に
    とっても解釈できるHTMLになる. それは計算機の力をより借りることができることにつ
    ながる. ex) SEO, Screen Reader

    View full-size slide

  49. V8 friendly JavaScript
    (一例) Array
    JavaScriptにおいて, ArrayはObjectのprototype拡張によって作られてる.
    ArrayがV8にとって, emptyな値を持ちうるとなっていると, emptyな値が本当にempty
    か確かめるために, Objectのpropertyまで覗きに行ってしまう.
    なので, holeyま(=emptyな値を持ちうる)arrayを作らないと行った最適化.

    View full-size slide

  50. V8 Friendly JavaScript

    View full-size slide

  51. 計測
    lab環境のデータ収集
    ● LightHouse
    ● LightHouseCI
    ● Chrome Devtools Protocol
    ● etc...

    View full-size slide

  52. 計測
    Fieldデータの計測
    ● Reporting API
    ● sentroy for frontend
    ● Chrome User Experience Report
    ● Next.js Analytics
    ● etc...

    View full-size slide

  53. 誰ガ為ノUsability
    Usability
    not only 使いやすさ
    but also 誰にでも使えること(=universal)

    View full-size slide

  54. 誰ガ為ノUsability
    A Universal Web. The power of the Web is in its
    universality. Access by everyone regardless of
    disability is an essential aspect
    Tim berners-lee

    View full-size slide

  55. 誰ガ為ノUsability
    Accessibility for
    not only anyone
    but also anywhere, anytime

    View full-size slide

  56. 誰ガ為ノUsability
    ● たとえマウスが壊れてキーボードで操作している人でも
    ● たとえ育児中で両手がふさがっている人でも
    ● 地下鉄に乗っていて、時々オフラインになるような環境下でも
    ● 全盲の方でも
    ● 最近のデザイン傾向に馴染みのない方でも
    ● 日本語がわからない方にでも
    ● 通信環境が悪い人にでも
    ● 色弱の方ででも
    使えるWebを作る, それがUsability

    View full-size slide

  57. Frontendの難しさ
    What is “Front”
    -> Client side
    Client sideはさっきも挙げた通り様々な環境が考えられる

    View full-size slide

  58. Frontendの難しさ
    Lab 環境で動くFrontendを作ることは正直難しくない.
    様々なField環境で動くようにすることが難しい.

    View full-size slide

  59. ただLab環境で動くフロントエン
    ドを超えた, 伝わるフロントエンド
    を作ろう!!

    View full-size slide

  60. もっと勉強したい方は
    ● JavaScript: https://jsprimer.net/
    ● TypeScript: https://qiita.com/uhyo/items/e2fdef2d3236b9bfe74a
    ● React: https://ja.reactjs.org/docs/getting-started.html
    ● React: https://qiita.com/mizchi/items/4d25bc26def1719d52e6
    ● v8: https://v8.dev/
    ● v8: https://jsconf.jp/2019/talk/sho-miyamoto
    ● a11y: https://www.webaxe.org/
    ● CDN: https://speakerdeck.com/sisidovski/nikkei-itpro-cdn
    ● Semantic HTML:
    https://www.amazon.co.jp/%E3%82%BB%E3%83%9E%E3%83%B3%E3%83%
    86%E3%82%A3%E3%83%83%E3%82%AF-HTML-XHTML-%E7%A5%9E%E5%B

    View full-size slide