フロントエンド

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

Transcript

1. フロントエンド 22卒勉強会
2. 注意書き この発表はフロントエンドという脈々と続く歴史を一新米エンジニアである @Shinyaigeek が解釈しまとめたものになります。 なので思想めいた部分が一部登場します。 また怒られそうなテーマでもあるので, 資料の二次配布は禁止させてください。
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
4. Classic Frontend
5. Classic Frontend 数年前の, ServersideのテンプレートエンジンでHTMLを吐き出して, クライアントサイド でjQueryなどでゴリゴリDOM操作をしていた時代のフロントエンド(造語)
6. 古き良きFrontend • ブラウザ対応は手動で頑張る • モジュールはglobal namespaceに登録される (ex $ jquery) • 型が！！！！！！無い！！！！！！ • DOM APIを介してのDOM操作には人間には限界がある • CSSの名前衝突
7. Node.jsの台頭 JavaScriptをサーバーサイドで書けるようになった. これによりフロントエンドの開発ツールをJavaScriptで書けるようになり, フロントエンド エンジニアがバシバシ開発ツールを開発し始めた. またサーバーサイドのコードとフロ ントエンドのコードを共通させて書きたい需要.
8. Modern Frontend
9. Package Manager JavaScript(not only Frontend)におけるPackage Manager for Frontend, for Serversideなライブラリ両方揃えられている. npm/yarnの二つがよく使われている. どちらもlockfileもworkspaceもサポートしているし 実行速度もあまり差はない. 基本好みレベルの話だと思っている.(稀にこっちじゃないとみたいなのはある) ただlockfileの管理がだるいので, 1projectでどちらかのみを使う.
10. Module Bundler Classic Frontendにおいてモジュールはglobal namespaceに登録される(激ヤバ) 例えばjQueryだと, window.$ を利用することになる為, window.$を利用するようなライ ブラリは使えなくなるといった問題が起こった. 一方Node.jsだと, モジュールを const fs = require(“fs”) という感じで読み込んでいた. これをフロントエンドに持ち込みたいとなり, require.js 等が開発されたが流行らなかっ た...
11. Module Bundler Browserifyの登場: Node.jsのコードをフロントエンドでも用いたい. -> Q. なぜできなかったか A. ブラウザjsにはrequireがないから -> buildの過程で, moduleをbundleすることでrequireのあるjsをブラウザでも動く ようにしてあげる
12. ECMAScript こうした流れを受け, JSにもモジュールシステムを導入すべきだし、もっとイケてる言語 にしようぜ！！ import * as React from “react” ESModules対応しているブラウザだと, 普通にimport出来る. class文とかも, ESで使えるようになってる.
13. Transpiler ESMはもちろん新しいブラウザでしか動かない -> 古いブラウザでも動くようにする
14. Compile どうせESをtranspileするなら, 型付けできてもいいでしょ！！！
15. TypeScript 基本的にliteral type(string, number …), union type( | ), Intersection Type( & ). interface, type assertion, type guardだけ覚えたら割と使える. より高度なことがやりたければtype override, generics, Conditional Typesを覚えよう union type, intersection Typeはただの論理和, 論理積, あまり難しく考えなくとも理解 できる
16. TypeScript Interface と type { } の違い 「Interfaceは extends できる！！」 -> 「type { } も & を使うことで実質 extends できなことはできる(びっくり度は増える)」 実はInterface と type { }の, 出来ることの違いはそこまでない . 認識の違い. type { }はobjectの型定義を行なっているというイメージ . Interfaceはclassの型や, functionの引数など, Interface の型定義を行うイメージ
17. Typescript とりあえずの心得 • any, @ts-ignoreは基本的にNG • Hoge as HogeAlt みたいな Type assertionは用法用量わきまえて ◦ as はTypeScriptの推論より俺の方が賢いぜ！！ってなった時 , TypeScriptを洗脳するイメージ ◦ !はnon-null assertionと行って,値をnullableでないことをTypeScriptに言い聞かせる感じ , これもカ ジュアルに使える割りに危険 . ▪ tscがnullableだよって行ってるなら , 値チェックはしてあげるべき
18. yarn buildの中身 babelでtranspileするときは babel {sourcefile} typescriptをcompileするときは tsc webpackでbundleするときは webpack
19. yarn buildの中身 create-react-appをみてみよう -> react-scriptsでbuildしてる -> react-scriptsはwebpackを呼び出してるだけ Q. babelやtscは？ A.babel-loaderやts-loaderを食わせることでtranspileやcompileもbundle のタイミングでできる
20. yarn buildの中身 ちなみにbabelでも, “@babel/preset-typescript”を食わせることでtypescriptの compileはできるし, tscもbabelのやってるtranspileも出来る. webpackもcompileも transpileも出来る. (ちなみにparcelは0 configで出来る) 構文をES5の構文に落とし込む部分の実装はそれぞれが持ってる為、同じコードでも Babel, tscでビルドすると結果が違う(けど困ることはあまりない。。)
21. Declarative UI DOM APIを介してのDOM操作は人間には限界がある document.querySelector でDOM 要素にアクセスしてSPA作るの無理... こういう宣言的な感じで描きたい const [name, setName] = useState(“”) <div id=”name”>{name}</div>
22. Declarative UI DOM APIを介してDOMを操作することの辛さは, HTMLの世界とJSの世界が独立して いて, DOM操作するためにはJSの世界からDOM APIを介してHTMLの世界に干渉す るという形式を取らざるを得ないところにあった. ReactやVueは HTMLの世界をJSの支配下に置くことで Declarative UIを実現した.
23. JSXは何者？ JSの世界にHTMLを持ち込もうとしてできたものと考えればわかりやすい. 実はショートハンドでもあり, 文法はJavaScript的にはアウト. babelによるtranspileに よって正しいJavaScriptになって、実行される. @babel/preset-reactを入れないといけ ないのはそのせい. 例えば <div id=”hoge”>asdf</div> は React.createElement(“div”, { id: “hoge” }, “asdf) と変換される.
24. Deep Frontend
25. SSR, SSG, CSR, ISR CSR: Client Side Rendering 要するにSPA的な振る舞いのこと, クライアントでcontentをレンダリングする SSR: Server Side Rendering ユーザーが最初に目にするコンテンツだけクライアントでレンダリングしちゃう, hydrateによってSPAになる. SSRはRequestがSSRサーバーに届く毎に実行される. 仕草的にはRails等のテンプ レートエンジンと一緒
26. SSR, SSG, CSR, ISR SSG: Static Site Generate Contentのレンダリングを, SSRサーバー上でRequestが届くたびに行うのではな く、CI/CD環境でコンテンツの更新時に行う. そうして吐き出された静的なコンテンツを 静的サーバーから配信する. hugoと一緒. ISR: Incremental Static Regeneration Requestが届いてSSRするが、その結果を一定期間KVSに保存して、結果が保存 されている間はSSRせずに保存されているcontentを返す
27. SSR, SSG, CSR, ISR 大事なところかつ共通しているところは, データを持つサーバーと, その結果を映し出す Rendererがしっかり分けられていること DataStore Renderer JSON ベースとなる技術, 考え方自体は同じ. WHENとWHEREの違いで しかない
28. SSRはもう古いの？ そんなことは！！！！！ない！！！！！！！！！ SSRでしかできないこともあるし, SSGでしかできないこともある. ISR もある. これらは思想とhowの違いに過ぎないので, 優越はない
29. CSS JSの世界とHTMLの世界が独立していたように, CSSの世界も独立している. CSSはセレクタ(“.{class name}”みたいな)を介してスタイリングを行う. 名前衝突も起きがち... Classic Frontendだと名前衝突が起きないようにルールを決める -> BEM Modern Frontendだと...?
30. CSS JSの世界にCSSも委ねてしまう. • CSS Modules • CSS in JS shadow domで頑張ってるアプローチも見かける
31. CSS Sass, PostCSS等, buildしてCSSを吐き出す潮流があった. tailwind cssは, めちゃくちゃちっちゃい単位でCSSを分解されていて, classを介してそ れを割り当てていくイメージ. 慣れれば要素に直接スタイリングしていく感じでかける. 使われていないCSSはPostCSS等でPurgeする.
32. Graphql Graphqlのgraqhは Oriented Graphのgraph RDBのtableや, MicroServicesにおけるService間の, データの冗長化は人間にはわ かりにくい. User User-Company Company こう描きたい User Company
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
34. 状態管理ツール APIから取ってきたデータをバケツリレーするのはしんどい API JSON
35. 状態管理ツール • Redux • useSWR • React ContextAPI, useReducer • React Query • Apollo これらは思想の違いでしかなく, お互いに優越はない. どの思想がどの状況にマッチするかの違い.
36. 状態管理ツール Redux Dataを一括でRedux Storeで管理する mutateもactionをdispatchしていく useSWR React Query Apollo Dataをcacheでいい感じに管理して, そ の中身をいじいじする
37. 状態管理ツール ←基本こんな感じでいい 自分でこの辺を説明しつつ 選定できるとなおよし
38. i18n Q. i18n A. Internationalization(国際化対応) not only 多言語対応 but also 横読み, 縦読み, カレンダー, 日付の順番, 住所etc... 法律的に引っかかるものを配信しないとかもある . 児童ポルノとかを考えるとわかりやすい . 他にも文化的な忖度も . これは “台湾といった国を” というのを “台湾といった国や地域を ” という表現に書き換えるとかを考 えるとわかりやすい.
39. i18n 多言語対応の流れ 1. この文言を多言語対応させると明示する <Trans>Component/Hello</Trans>, <p>{_i18n(“Component/Hello”)}</p> 2. extractして, この文言を多言語対応させたいというリストをgenする 3. そのリストをよしなに書き換える ComponentHello -> こんにちは 大家好 Hello 4. compileする
40. i18n Q. 多言語対応以外は？ A. 頑張れ... 例えば “編集” ボタンみたいなのが, 言語によってはめちゃくちゃ長い文字数になること でスタイル崩れが起きたりもするので, どこまで対応するかを踏まえた上でデザイナー とコミュニケーションをしていくことが大事.
41. a11y • tabで全ページ操作できるようにする • Modalが出た時のtab focusの扱い • screen readerを用いてる人でもbuttonがbuttonだとわかるようにする ◦ divで書かれた, 見た目だけのbuttonはbuttonだとわからない • タブで操作する時, 今どこにfocusが当たってるかわかるようにする • クライアントのOSの設定に準拠したスタイリング • responsive • etc...
42. a11y ちゃんとしたbuttonや, ModalのFocusなどは基本的にUI libraryを使っていれば回避 できる問題ではある. 自分で作るときは気をつけて作ろう.... クライアントのOSの設定に準拠したスタイリングはprefers-*で出来る. ex) prefers-color-scheme: ダークモードかそうでないかでstyleを分けられる レスポンシブデザイン MediaQueryで行う. Reactならfresnelというライブラリを使うのが, Component base にできて楽なのでおすすめ
43. Performance 大前提: やらかしを無くす Reactをちゃんと使えば開発者がわかるほど遅くなることはそこまでない • ちゃんとproduction buildしてる？ • モジュールの使われてない部分もbundle fileに含まれてない？ • “/” で使うコンテンツを “/post” とかでも読み込んでない？ • 余分なものを読み込んでない？
44. Performance あるあるの失敗 fontawesomeで, Twitterのアイコンを利用しているとき, GitHubやLinkedInなど, 関係 ないアイコンのSVGとかも読まれてる. 実際は400x400くらいのサイズで表示されているのに, 画像を1600x1600で読み込ん でいる source mapがビルドファイルに含まれている
45. Performance ブラウザがレンダリングする仕組み Download Parsing Scripting Caluculate Style Layout Paint Rasterize Composite Layers
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だけ配信する
47. Performance Runtime Costを下げる. • DOMが大きくなりすぎないようにする • JSのファイルサイズを小さくする • JavaScript engineの最適化を受けるようなコード • UI libraryの最適化を受ける ◦ 不要なre-renderingを避ける ▪ React.memo, Redux, map key ◦ 不要な再計算を避ける ▪ useMemo, useCallback • 計算量を減らす
48. Semantic HTML <h1>タグとかってなんの為にあるの？ -> stylingを使えば, ただのdivタグも見た目だけは<h1>と同じに出来る. -> <div> like <h1> と, <h1>は見た目は同じだが意味論的には全く違う -> 機械からすれば, <div> like <h1>はただのdiv 見た目だけ整えるのではなく, HTML の Semanticを守ったHTMLを書くことで, 機械に とっても解釈できるHTMLになる. それは計算機の力をより借りることができることにつ ながる. ex) SEO, Screen Reader
49. V8 friendly JavaScript (一例) Array JavaScriptにおいて, ArrayはObjectのprototype拡張によって作られてる. ArrayがV8にとって, emptyな値を持ちうるとなっていると, emptyな値が本当にempty か確かめるために, Objectのpropertyまで覗きに行ってしまう. なので, holeyま(=emptyな値を持ちうる)arrayを作らないと行った最適化.
50. V8 Friendly JavaScript
51. 計測 lab環境のデータ収集 • LightHouse • LightHouseCI • Chrome Devtools Protocol • etc...
52. 計測 Fieldデータの計測 • Reporting API • sentroy for frontend • Chrome User Experience Report • Next.js Analytics • etc...
53. 誰ガ為ノUsability Usability not only 使いやすさ but also 誰にでも使えること(=universal)
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
55. 誰ガ為ノUsability Accessibility for not only anyone but also anywhere, anytime
56. 誰ガ為ノUsability • たとえマウスが壊れてキーボードで操作している人でも • たとえ育児中で両手がふさがっている人でも • 地下鉄に乗っていて、時々オフラインになるような環境下でも • 全盲の方でも • 最近のデザイン傾向に馴染みのない方でも • 日本語がわからない方にでも • 通信環境が悪い人にでも • 色弱の方ででも 使えるWebを作る, それがUsability
57. Frontendの難しさ What is “Front” -> Client side Client sideはさっきも挙げた通り様々な環境が考えられる
58. Frontendの難しさ Lab 環境で動くFrontendを作ることは正直難しくない. 様々なField環境で動くようにすることが難しい.
59. ただLab環境で動くフロントエン ドを超えた, 伝わるフロントエンド を作ろう！！
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