Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Classic Frontend

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Modern Frontend

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Deep Frontend

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

i18n 多言語対応の流れ 1. この文言を多言語対応させると明示する Component/Hello,

{_i18n(“Component/Hello”)}

2. extractして, この文言を多言語対応させたいというリストをgenする 3. そのリストをよしなに書き換える ComponentHello -> こんにちは 大家好 Hello 4. compileする

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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だけ配信する

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

Semantic HTML

タグとかってなんの為にあるの？ -> stylingを使えば, ただのdivタグも見た目だけは

と同じに出来る. ->
like

と,

は見た目は同じだが意味論的には全く違う -> 機械からすれば,
like

はただのdiv 見た目だけ整えるのではなく, HTML の Semanticを守ったHTMLを書くことで, 機械に とっても解釈できるHTMLになる. それは計算機の力をより借りることができることにつ ながる. ex) SEO, Screen Reader

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

V8 Friendly JavaScript

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

誰ガ為ノ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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

もっと勉強したい方は ● 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