Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
フロントエンド
Search
Shinobu Hayashi
November 08, 2020
Programming
0
160
フロントエンド
身内で行った勉強会での発表資料
Shinobu Hayashi
November 08, 2020
Tweet
Share
More Decks by Shinobu Hayashi
See All by Shinobu Hayashi
ESLint Rule により事業, 技術ドメインに沿った制約と誓約を敷衍させるアプローチのすゝめ
shinyaigeek
1
4.1k
Big “heart” of mud, 10000 lines VCL generated from .vcl.handlebars
shinyaigeek
0
170
Managing "side effect" in Frontend Development
shinyaigeek
3
3.4k
爆速の日経電子版開発の今
shinyaigeek
2
2.2k
加速するEdge Computing
shinyaigeek
6
6.7k
ブラウザ作りのすゝめ
shinyaigeek
1
440
ASTをいじいじして僕のかんがえた最強のDXを得る
shinyaigeek
0
360
Web Frontend Performance Tuning
shinyaigeek
1
380
Other Decks in Programming
See All in Programming
距離関数を極める! / SESSIONS 2024
gam0022
0
290
3rd party scriptでもReactを使いたい! Preact + Reactのハイブリッド開発
righttouch
PRO
1
610
TypeScriptでライブラリとの依存を限定的にする方法
tutinoko
3
690
シェーダーで魅せるMapLibreの動的ラスタータイル
satoshi7190
1
480
Kaigi on Rails 2024 〜運営の裏側〜
krpk1900
1
230
Remix on Hono on Cloudflare Workers
yusukebe
1
300
Hotwire or React? ~アフタートーク・本編に含めなかった話~ / Hotwire or React? after talk
harunatsujita
1
120
TypeScript Graph でコードレビューの心理的障壁を乗り越える
ysk8hori
2
1.1k
よくできたテンプレート言語として TypeScript + JSX を利用する試み / Using TypeScript + JSX outside of Web Frontend #TSKaigiKansai
izumin5210
6
1.7k
GitHub Actionsのキャッシュと手を挙げることの大切さとそれに必要なこと
satoshi256kbyte
5
430
OnlineTestConf: Test Automation Friend or Foe
maaretp
0
110
見せてあげますよ、「本物のLaravel批判」ってやつを。
77web
7
7.8k
Featured
See All Featured
Typedesign – Prime Four
hannesfritz
40
2.4k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Making the Leap to Tech Lead
cromwellryan
133
8.9k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.5k
Imperfection Machines: The Place of Print at Facebook
scottboms
265
13k
A Modern Web Designer's Workflow
chriscoyier
693
190k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
109
49k
A Tale of Four Properties
chriscoyier
156
23k
Building Adaptive Systems
keathley
38
2.3k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
8.2k
A Philosophy of Restraint
colly
203
16k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
65k
Transcript
フロントエンド 22卒勉強会
注意書き この発表はフロントエンドという脈々と続く歴史を一新米エンジニアである @Shinyaigeek が解釈しまとめたものになります。 なので思想めいた部分が一部登場します。 また怒られそうなテーマでもあるので, 資料の二次配布は禁止させてください。
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
Classic Frontend
Classic Frontend 数年前の, ServersideのテンプレートエンジンでHTMLを吐き出して, クライアントサイド でjQueryなどでゴリゴリDOM操作をしていた時代のフロントエンド(造語)
古き良きFrontend • ブラウザ対応は手動で頑張る • モジュールはglobal namespaceに登録される (ex $ jquery) •
型が!!!!!!無い!!!!!! • DOM APIを介してのDOM操作には人間には限界がある • CSSの名前衝突
Node.jsの台頭 JavaScriptをサーバーサイドで書けるようになった. これによりフロントエンドの開発ツールをJavaScriptで書けるようになり, フロントエンド エンジニアがバシバシ開発ツールを開発し始めた. またサーバーサイドのコードとフロ ントエンドのコードを共通させて書きたい需要.
Modern Frontend
Package Manager JavaScript(not only Frontend)におけるPackage Manager for Frontend, for Serversideなライブラリ両方揃えられている.
npm/yarnの二つがよく使われている. どちらもlockfileもworkspaceもサポートしているし 実行速度もあまり差はない. 基本好みレベルの話だと思っている.(稀にこっちじゃないとみたいなのはある) ただlockfileの管理がだるいので, 1projectでどちらかのみを使う.
Module Bundler Classic Frontendにおいてモジュールはglobal namespaceに登録される(激ヤバ) 例えばjQueryだと, window.$ を利用することになる為, window.$を利用するようなライ ブラリは使えなくなるといった問題が起こった.
一方Node.jsだと, モジュールを const fs = require(“fs”) という感じで読み込んでいた. これをフロントエンドに持ち込みたいとなり, require.js 等が開発されたが流行らなかっ た...
Module Bundler Browserifyの登場: Node.jsのコードをフロントエンドでも用いたい. -> Q. なぜできなかったか A. ブラウザjsにはrequireがないから ->
buildの過程で, moduleをbundleすることでrequireのあるjsをブラウザでも動く ようにしてあげる
ECMAScript こうした流れを受け, JSにもモジュールシステムを導入すべきだし、もっとイケてる言語 にしようぜ!! import * as React from “react”
ESModules対応しているブラウザだと, 普通にimport出来る. class文とかも, ESで使えるようになってる.
Transpiler ESMはもちろん新しいブラウザでしか動かない -> 古いブラウザでも動くようにする
Compile どうせESをtranspileするなら, 型付けできてもいいでしょ!!!
TypeScript 基本的にliteral type(string, number …), union type( | ), Intersection
Type( & ). interface, type assertion, type guardだけ覚えたら割と使える. より高度なことがやりたければtype override, generics, Conditional Typesを覚えよう union type, intersection Typeはただの論理和, 論理積, あまり難しく考えなくとも理解 できる
TypeScript Interface と type { } の違い 「Interfaceは extends できる!!」
-> 「type { } も & を使うことで実質 extends できなことはできる(びっくり度は増える)」 実はInterface と type { }の, 出来ることの違いはそこまでない . 認識の違い. type { }はobjectの型定義を行なっているというイメージ . Interfaceはclassの型や, functionの引数など, Interface の型定義を行うイメージ
Typescript とりあえずの心得 • any, @ts-ignoreは基本的にNG • Hoge as HogeAlt みたいな
Type assertionは用法用量わきまえて ◦ as はTypeScriptの推論より俺の方が賢いぜ!!ってなった時 , TypeScriptを洗脳するイメージ ◦ !はnon-null assertionと行って,値をnullableでないことをTypeScriptに言い聞かせる感じ , これもカ ジュアルに使える割りに危険 . ▪ tscがnullableだよって行ってるなら , 値チェックはしてあげるべき
yarn buildの中身 babelでtranspileするときは babel {sourcefile} typescriptをcompileするときは tsc webpackでbundleするときは webpack
yarn buildの中身 create-react-appをみてみよう -> react-scriptsでbuildしてる -> react-scriptsはwebpackを呼び出してるだけ Q. babelやtscは? A.babel-loaderやts-loaderを食わせることでtranspileやcompileもbundle
のタイミングでできる
yarn buildの中身 ちなみにbabelでも, “@babel/preset-typescript”を食わせることでtypescriptの compileはできるし, tscもbabelのやってるtranspileも出来る. webpackもcompileも transpileも出来る. (ちなみにparcelは0 configで出来る)
構文をES5の構文に落とし込む部分の実装はそれぞれが持ってる為、同じコードでも Babel, tscでビルドすると結果が違う(けど困ることはあまりない。。)
Declarative UI DOM APIを介してのDOM操作は人間には限界がある document.querySelector でDOM 要素にアクセスしてSPA作るの無理... こういう宣言的な感じで描きたい const [name,
setName] = useState(“”) <div id=”name”>{name}</div>
Declarative UI DOM APIを介してDOMを操作することの辛さは, HTMLの世界とJSの世界が独立して いて, DOM操作するためにはJSの世界からDOM APIを介してHTMLの世界に干渉す るという形式を取らざるを得ないところにあった. ReactやVueは
HTMLの世界をJSの支配下に置くことで Declarative UIを実現した.
JSXは何者? JSの世界にHTMLを持ち込もうとしてできたものと考えればわかりやすい. 実はショートハンドでもあり, 文法はJavaScript的にはアウト. babelによるtranspileに よって正しいJavaScriptになって、実行される. @babel/preset-reactを入れないといけ ないのはそのせい. 例えば <div
id=”hoge”>asdf</div> は React.createElement(“div”, { id: “hoge” }, “asdf) と変換される.
Deep Frontend
SSR, SSG, CSR, ISR CSR: Client Side Rendering 要するにSPA的な振る舞いのこと, クライアントでcontentをレンダリングする
SSR: Server Side Rendering ユーザーが最初に目にするコンテンツだけクライアントでレンダリングしちゃう, hydrateによってSPAになる. SSRはRequestがSSRサーバーに届く毎に実行される. 仕草的にはRails等のテンプ レートエンジンと一緒
SSR, SSG, CSR, ISR SSG: Static Site Generate Contentのレンダリングを, SSRサーバー上でRequestが届くたびに行うのではな
く、CI/CD環境でコンテンツの更新時に行う. そうして吐き出された静的なコンテンツを 静的サーバーから配信する. hugoと一緒. ISR: Incremental Static Regeneration Requestが届いてSSRするが、その結果を一定期間KVSに保存して、結果が保存 されている間はSSRせずに保存されているcontentを返す
SSR, SSG, CSR, ISR 大事なところかつ共通しているところは, データを持つサーバーと, その結果を映し出す Rendererがしっかり分けられていること DataStore Renderer
JSON ベースとなる技術, 考え方自体は同じ. WHENとWHEREの違いで しかない
SSRはもう古いの? そんなことは!!!!!ない!!!!!!!!! SSRでしかできないこともあるし, SSGでしかできないこともある. ISR もある. これらは思想とhowの違いに過ぎないので, 優越はない
CSS JSの世界とHTMLの世界が独立していたように, CSSの世界も独立している. CSSはセレクタ(“.{class name}”みたいな)を介してスタイリングを行う. 名前衝突も起きがち... Classic Frontendだと名前衝突が起きないようにルールを決める -> BEM
Modern Frontendだと...?
CSS JSの世界にCSSも委ねてしまう. • CSS Modules • CSS in JS shadow
domで頑張ってるアプローチも見かける
CSS Sass, PostCSS等, buildしてCSSを吐き出す潮流があった. tailwind cssは, めちゃくちゃちっちゃい単位でCSSを分解されていて, classを介してそ れを割り当てていくイメージ. 慣れれば要素に直接スタイリングしていく感じでかける.
使われていないCSSはPostCSS等でPurgeする.
Graphql Graphqlのgraqhは Oriented Graphのgraph RDBのtableや, MicroServicesにおけるService間の, データの冗長化は人間にはわ かりにくい. User User-Company
Company こう描きたい User Company
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
状態管理ツール APIから取ってきたデータをバケツリレーするのはしんどい API JSON
状態管理ツール • Redux • useSWR • React ContextAPI, useReducer •
React Query • Apollo これらは思想の違いでしかなく, お互いに優越はない. どの思想がどの状況にマッチするかの違い.
状態管理ツール Redux Dataを一括でRedux Storeで管理する mutateもactionをdispatchしていく useSWR React Query Apollo Dataをcacheでいい感じに管理して,
そ の中身をいじいじする
状態管理ツール ←基本こんな感じでいい 自分でこの辺を説明しつつ 選定できるとなおよし
i18n Q. i18n A. Internationalization(国際化対応) not only 多言語対応 but also
横読み, 縦読み, カレンダー, 日付の順番, 住所etc... 法律的に引っかかるものを配信しないとかもある . 児童ポルノとかを考えるとわかりやすい . 他にも文化的な忖度も . これは “台湾といった国を” というのを “台湾といった国や地域を ” という表現に書き換えるとかを考 えるとわかりやすい.
i18n 多言語対応の流れ 1. この文言を多言語対応させると明示する <Trans>Component/Hello</Trans>, <p>{_i18n(“Component/Hello”)}</p> 2. extractして, この文言を多言語対応させたいというリストをgenする 3.
そのリストをよしなに書き換える ComponentHello -> こんにちは 大家好 Hello 4. compileする
i18n Q. 多言語対応以外は? A. 頑張れ... 例えば “編集” ボタンみたいなのが, 言語によってはめちゃくちゃ長い文字数になること でスタイル崩れが起きたりもするので,
どこまで対応するかを踏まえた上でデザイナー とコミュニケーションをしていくことが大事.
a11y • tabで全ページ操作できるようにする • Modalが出た時のtab focusの扱い • screen readerを用いてる人でもbuttonがbuttonだとわかるようにする ◦
divで書かれた, 見た目だけのbuttonはbuttonだとわからない • タブで操作する時, 今どこにfocusが当たってるかわかるようにする • クライアントのOSの設定に準拠したスタイリング • responsive • etc...
a11y ちゃんとしたbuttonや, ModalのFocusなどは基本的にUI libraryを使っていれば回避 できる問題ではある. 自分で作るときは気をつけて作ろう.... クライアントのOSの設定に準拠したスタイリングはprefers-*で出来る. ex) prefers-color-scheme: ダークモードかそうでないかでstyleを分けられる
レスポンシブデザイン MediaQueryで行う. Reactならfresnelというライブラリを使うのが, Component base にできて楽なのでおすすめ
Performance 大前提: やらかしを無くす Reactをちゃんと使えば開発者がわかるほど遅くなることはそこまでない • ちゃんとproduction buildしてる? • モジュールの使われてない部分もbundle fileに含まれてない?
• “/” で使うコンテンツを “/post” とかでも読み込んでない? • 余分なものを読み込んでない?
Performance あるあるの失敗 fontawesomeで, Twitterのアイコンを利用しているとき, GitHubやLinkedInなど, 関係 ないアイコンのSVGとかも読まれてる. 実際は400x400くらいのサイズで表示されているのに, 画像を1600x1600で読み込ん でいる
source mapがビルドファイルに含まれている
Performance ブラウザがレンダリングする仕組み Download Parsing Scripting Caluculate Style Layout Paint Rasterize
Composite Layers
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だけ配信する
Performance Runtime Costを下げる. • DOMが大きくなりすぎないようにする • JSのファイルサイズを小さくする • JavaScript engineの最適化を受けるようなコード
• UI libraryの最適化を受ける ◦ 不要なre-renderingを避ける ▪ React.memo, Redux, map key ◦ 不要な再計算を避ける ▪ useMemo, useCallback • 計算量を減らす
Semantic HTML <h1>タグとかってなんの為にあるの? -> stylingを使えば, ただのdivタグも見た目だけは<h1>と同じに出来る. -> <div> like <h1>
と, <h1>は見た目は同じだが意味論的には全く違う -> 機械からすれば, <div> like <h1>はただのdiv 見た目だけ整えるのではなく, HTML の Semanticを守ったHTMLを書くことで, 機械に とっても解釈できるHTMLになる. それは計算機の力をより借りることができることにつ ながる. ex) SEO, Screen Reader
V8 friendly JavaScript (一例) Array JavaScriptにおいて, ArrayはObjectのprototype拡張によって作られてる. ArrayがV8にとって, emptyな値を持ちうるとなっていると, emptyな値が本当にempty
か確かめるために, Objectのpropertyまで覗きに行ってしまう. なので, holeyま(=emptyな値を持ちうる)arrayを作らないと行った最適化.
V8 Friendly JavaScript
計測 lab環境のデータ収集 • LightHouse • LightHouseCI • Chrome Devtools Protocol
• etc...
計測 Fieldデータの計測 • Reporting API • sentroy for frontend •
Chrome User Experience Report • Next.js Analytics • etc...
誰ガ為ノUsability Usability not only 使いやすさ but also 誰にでも使えること(=universal)
誰ガ為ノ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
誰ガ為ノUsability Accessibility for not only anyone but also anywhere, anytime
誰ガ為ノUsability • たとえマウスが壊れてキーボードで操作している人でも • たとえ育児中で両手がふさがっている人でも • 地下鉄に乗っていて、時々オフラインになるような環境下でも • 全盲の方でも •
最近のデザイン傾向に馴染みのない方でも • 日本語がわからない方にでも • 通信環境が悪い人にでも • 色弱の方ででも 使えるWebを作る, それがUsability
Frontendの難しさ What is “Front” -> Client side Client sideはさっきも挙げた通り様々な環境が考えられる
Frontendの難しさ Lab 環境で動くFrontendを作ることは正直難しくない. 様々なField環境で動くようにすることが難しい.
ただLab環境で動くフロントエン ドを超えた, 伝わるフロントエンド を作ろう!!
もっと勉強したい方は • 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