フロントエンド

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

Transcript

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

   View Slide

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

   View 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 Slide

4. Classic Frontend
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

8. Modern Frontend
   

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View 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 Slide

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

    View Slide

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

    View Slide

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

    View 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

24. Deep Frontend
    

    View Slide

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

    View 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

50. V8 Friendly JavaScript
    

    View Slide

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

    View Slide

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

    View Slide

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

    View 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View 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 Slide