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. 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
  2. 古き良きFrontend • ブラウザ対応は手動で頑張る • モジュールはglobal namespaceに登録される (ex $ jquery) •

    型が!!!!!!無い!!!!!! • DOM APIを介してのDOM操作には人間には限界がある • CSSの名前衝突
  3. Package Manager JavaScript(not only Frontend)におけるPackage Manager for Frontend, for Serversideなライブラリ両方揃えられている.

    npm/yarnの二つがよく使われている. どちらもlockfileもworkspaceもサポートしているし 実行速度もあまり差はない. 基本好みレベルの話だと思っている.(稀にこっちじゃないとみたいなのはある) ただlockfileの管理がだるいので, 1projectでどちらかのみを使う.
  4. Module Bundler Classic Frontendにおいてモジュールはglobal namespaceに登録される(激ヤバ) 例えばjQueryだと, window.$ を利用することになる為, window.$を利用するようなライ ブラリは使えなくなるといった問題が起こった.

    一方Node.jsだと, モジュールを const fs = require(“fs”) という感じで読み込んでいた. これをフロントエンドに持ち込みたいとなり, require.js 等が開発されたが流行らなかっ た...
  5. Module Bundler Browserifyの登場: Node.jsのコードをフロントエンドでも用いたい. -> Q. なぜできなかったか A. ブラウザjsにはrequireがないから ->

    buildの過程で, moduleをbundleすることでrequireのあるjsをブラウザでも動く ようにしてあげる
  6. ECMAScript こうした流れを受け, JSにもモジュールシステムを導入すべきだし、もっとイケてる言語 にしようぜ!! import * as React from “react”

    ESModules対応しているブラウザだと, 普通にimport出来る. class文とかも, ESで使えるようになってる.
  7. TypeScript 基本的にliteral type(string, number …), union type( | ), Intersection

    Type( & ). interface, type assertion, type guardだけ覚えたら割と使える. より高度なことがやりたければtype override, generics, Conditional Typesを覚えよう union type, intersection Typeはただの論理和, 論理積, あまり難しく考えなくとも理解 できる
  8. TypeScript Interface と type { } の違い 「Interfaceは extends できる!!」

    -> 「type { } も & を使うことで実質 extends できなことはできる(びっくり度は増える)」 実はInterface と type { }の, 出来ることの違いはそこまでない . 認識の違い. type { }はobjectの型定義を行なっているというイメージ . Interfaceはclassの型や, functionの引数など, Interface の型定義を行うイメージ
  9. Typescript とりあえずの心得 • any, @ts-ignoreは基本的にNG • Hoge as HogeAlt みたいな

    Type assertionは用法用量わきまえて ◦ as はTypeScriptの推論より俺の方が賢いぜ!!ってなった時 , TypeScriptを洗脳するイメージ ◦ !はnon-null assertionと行って,値をnullableでないことをTypeScriptに言い聞かせる感じ , これもカ ジュアルに使える割りに危険 . ▪ tscがnullableだよって行ってるなら , 値チェックはしてあげるべき
  10. yarn buildの中身 ちなみにbabelでも, “@babel/preset-typescript”を食わせることでtypescriptの compileはできるし, tscもbabelのやってるtranspileも出来る. webpackもcompileも transpileも出来る. (ちなみにparcelは0 configで出来る)

    構文をES5の構文に落とし込む部分の実装はそれぞれが持ってる為、同じコードでも Babel, tscでビルドすると結果が違う(けど困ることはあまりない。。)
  11. SSR, SSG, CSR, ISR CSR: Client Side Rendering 要するにSPA的な振る舞いのこと, クライアントでcontentをレンダリングする

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

    く、CI/CD環境でコンテンツの更新時に行う. そうして吐き出された静的なコンテンツを 静的サーバーから配信する. hugoと一緒. ISR: Incremental Static Regeneration Requestが届いてSSRするが、その結果を一定期間KVSに保存して、結果が保存 されている間はSSRせずに保存されているcontentを返す
  13. CSS JSの世界にCSSも委ねてしまう. • CSS Modules • CSS in JS shadow

    domで頑張ってるアプローチも見かける
  14. 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
  15. 状態管理ツール • Redux • useSWR • React ContextAPI, useReducer •

    React Query • Apollo これらは思想の違いでしかなく, お互いに優越はない. どの思想がどの状況にマッチするかの違い.
  16. i18n Q. i18n A. Internationalization(国際化対応) not only 多言語対応 but also

    横読み, 縦読み, カレンダー, 日付の順番, 住所etc... 法律的に引っかかるものを配信しないとかもある . 児童ポルノとかを考えるとわかりやすい . 他にも文化的な忖度も . これは “台湾といった国を” というのを “台湾といった国や地域を ” という表現に書き換えるとかを考 えるとわかりやすい.
  17. a11y • tabで全ページ操作できるようにする • Modalが出た時のtab focusの扱い • screen readerを用いてる人でもbuttonがbuttonだとわかるようにする ◦

    divで書かれた, 見た目だけのbuttonはbuttonだとわからない • タブで操作する時, 今どこにfocusが当たってるかわかるようにする • クライアントのOSの設定に準拠したスタイリング • responsive • etc...
  18. 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だけ配信する
  19. Performance Runtime Costを下げる. • DOMが大きくなりすぎないようにする • JSのファイルサイズを小さくする • JavaScript engineの最適化を受けるようなコード

    • UI libraryの最適化を受ける ◦ 不要なre-renderingを避ける ▪ React.memo, Redux, map key ◦ 不要な再計算を避ける ▪ useMemo, useCallback • 計算量を減らす
  20. Semantic HTML <h1>タグとかってなんの為にあるの? -> stylingを使えば, ただのdivタグも見た目だけは<h1>と同じに出来る. -> <div> like <h1>

    と, <h1>は見た目は同じだが意味論的には全く違う -> 機械からすれば, <div> like <h1>はただのdiv 見た目だけ整えるのではなく, HTML の Semanticを守ったHTMLを書くことで, 機械に とっても解釈できるHTMLになる. それは計算機の力をより借りることができることにつ ながる. ex) SEO, Screen Reader
  21. V8 friendly JavaScript (一例) Array JavaScriptにおいて, ArrayはObjectのprototype拡張によって作られてる. ArrayがV8にとって, emptyな値を持ちうるとなっていると, emptyな値が本当にempty

    か確かめるために, Objectのpropertyまで覗きに行ってしまう. なので, holeyま(=emptyな値を持ちうる)arrayを作らないと行った最適化.
  22. 計測 Fieldデータの計測 • Reporting API • sentroy for frontend •

    Chrome User Experience Report • Next.js Analytics • etc...
  23. 誰ガ為ノ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
  24. 誰ガ為ノUsability • たとえマウスが壊れてキーボードで操作している人でも • たとえ育児中で両手がふさがっている人でも • 地下鉄に乗っていて、時々オフラインになるような環境下でも • 全盲の方でも •

    最近のデザイン傾向に馴染みのない方でも • 日本語がわからない方にでも • 通信環境が悪い人にでも • 色弱の方ででも 使えるWebを作る, それがUsability
  25. もっと勉強したい方は • 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