俺得フロントエンド (1) LT会
オレオレ cli スクリプトでフロントエンド全社 JS 基盤の治安を直して得した
発端
yarnじゃない理由
歴史的経由
git+ssh なのでyarnが使えないnpmがよくわからん
やること
全依存関係取得
cloneする
再起依存を解除する
GHQをつかうと楽
非同期並列数制御にbluebirdの
Promise.map() が便利readdirRecursivelySyncFlatten が便利
reduceはしばらくすると自分も読むのがつらい
とはいえI/Fの型が書いてるので便利
package.jsonの対応表をつくると楽
再帰コードもTSだとよい
reduceと組あわせるのはつらい
統合可能性の調査
殲滅対象がわかったのでそれらを
/src/node_modules にぶちこんだCTOから許可もらった
依存順を確認
依存が固定の場合はどうする？
社内libはキャレットを許容する
peerDepじゃないと不安、ロックしたい
残ったパッケージの依存関係整理
浅い順からnpm enterprise化
アプリケーションに反映
100パッケージのgit HEAD参照を解消しって7階層の依存を解消した
結果
HEADのは快適変更でのバグ回避
承認のCDフローの確立
Node6 EOL対応が楽になった
アプリドメイン完全に理解した
俺得なwebpack pluginsの紹介
株式会社Kaizen Platform フロントエンドアドバイザー
公式にのってない便利なプラグイン
error-overlay-webpack-plugin
creat-react-appを使ってる人はわかる
注意：単一エントリーの場合はエラーになるかも
progress-bar-webpack-plugin
ローディング状況の可視化
Speed measure plugin
ビルド速度を測定する
webpack-config-plugins
loaderに関する設定のベストプラクティス集
zero-configで完結可能
webpack-notifier
ビルドが失敗した時の通知
fork-ts-checker-notifier-webpack-plugin
型エラーの通知版
ForkTsCheckerWebpackPluginを先に読む
v1系である必要
preload-webpack-plugin
preload や prefetch できるプラグイン4.6.0以降は不要
copy-webpack-plugin
指定ファイルやディレクトリをコピーしてくれる
画像のディレクトリをバンドルされるdistにコピー
pathが指定できる
imagemin plugins
画像圧縮
dev ではOFFにするwebpack-libs-optimizations
タイガー＆ドラゴン
SPA歴＝エンジニア歴
SPAにつかれたので愚痴を聞いてくれ
なぜやるのか？
サーバーサイドからクライアント事情を切り離す
画面真っ白うざい
リッチUI
サーバーサイドの負荷を減らす
リクエスト数が減る？
キャッシュするとバグになりかねない
SPAで作ったほうが早い
壊れる状態
意図しないリモートのデータの組み合わせで起きる
起きないように気をつける
データフェッチし忘れ
削除されてるデータを持ってる場合は？
更新したらどこまで追従する？
間違っちゃったで壊れる
コンパイラは助けてくれない
テストをちゃんとかいてないとfetch系を呼び出してくるのはしんどい
整合性保つのは大変
なぜ難しいのか？それがSPAだから
トップレベルに並べられるリモートソースの状態
徐々に辛くなる状態構成
リソースにページングがきたらつらい
種類／関連がパッと見でわからない
view と分離されてるとはいえ色んな文脈で操作されるどうすればいいのか？
トップレベルにリソースならべるのはやめる
共通ロジックと状態の居場所は関係ない
むしろ蜜にならないモジュール化
ページごとにリソースも状態をわける
伝えたかったこと
SPAのベストプラクティスは自分たちのアプリに当てはまるとはいえない
状態構造／ライブラリに依存しないモジュール化
要件や構造によってかわる状態構造はあうようにしよう
Elmはいいぞ
外部ライブラリもインストール・型解釈できるTypeScript Playgroudを作った
TypeScript Playground
ブラウザだけで完結するTypeScriptのPlayground
ちょっとコード書いて型を試すのに便利
transpile結果も簡単に確認できる
シェア機能で型パズルの出題やTipsの共有も便利
型周りもうひと押しほしい 🤔
npmモジュール（@types etc）も絡めて型を確かめたいことがある
tsconfig.json を直接いじりたい、それもシェアされてほしい非公式TypeScript playgroundを作った
型のチェックだけ、実行はできない
@types やTS製npmモジュールをインストールし型解釈できるtsconfig.jsonをフル※カスタマイズ可能
内部技術ピックアップ
monaco-editor 内部の TypeScript の LanguageService
monaco-editor に npm パッケージの型定義を読み込ませる
npm パッケージの検索
npm パッケージ（型定義ファイル）のインストール
monaco-editorにはブラウザ用にインターフェースを実装したts LanguageServiceが入っている
monaco.Uri で仮想的なfileプロトコルをしゃべれるnpm moduleのインストール
参考実装：Babel repl
高速でフルマネージドな全文検索エンジン（のWebサービス）
npm registryのレプリカをAlgoliaに構築
AlgoliaのAPIクライアント + UI
多くのOSSのドキュメントのサイト内検索もこれ
とても高速。大量のレコード管理はちょっとお高い
npm Public Registry API
npm/registry
（Archiveされてるけど）npm registryのAPIドキュメント
おおまかな実装方針
1. 何かしらのAPIでnpmパッケージを検索
2. 選択されたパッケージのtarballをnpm registryからfetchし解凍
tarballとCORSの壁
3. package.jsonを読み依存ツリーを全探索
4. monacoに読み込ませる
monaco に npm moduleの型を読ませる
編集中のコードの仮想的なパスを指定（ex.
/index.tsx ） .d.ts のコード（string）を手に入れる型解釈されるように配置（ex.
/node_modules/xxx/index.d.ts ）任意のnpmモジュールのimportが型解釈が可能に！
{package}@{version}/{path} → npm publish されたファイルの中身かゆいところに手が届く機能いろいろ
CDNが手前にあるのでとても高速
CORSいける
パッケージの中身の取得
unpkg.comではパッケージ内の全ファイル一覧を取れる
不要なファイルも取得するので遅いがパス解決不要
Service Worker runtime cachingである程度効率化できる
１つ１つとってくるのは非効率
依存pkgの依存pkg のバージョン解決UNPKGがsemverを解決してリダイレクトしてくれる
@types/react/ index.d.ts node_modules/csstype/index.d.ts 他に使ってる技術
ブラウザでgzipかけてURLを圧縮・解凍
今後
Hooks 版 react-redux 使ってみよう
フィードバックもらって完成度あげたい
import のパスやパッケージ名の補完が効くように
本家monaco-typescriptのCompletionProviderを改善したい
公式 playground に還元したい
得してほしい情報
monacoとTypeScriptの成熟によりブラウザエディタが（私の中で）アツい
UNPKGは開発用途で可能性感じる
ちょっと複雑な型遊びがしたかったら、
Figma APIで便利ツールを作ろう
TOKENとファイルのキーを突っ込むとコンポーネントのURL一覧を書き出してくれる
技術
Hooksを使ってみた
Figma API
figma-js
Little wrapper(+types)for the Figma API
型定義がバッチリ
中身はaxios
TODO
Authentication対応
URL一覧のダウンロード
エラーメッセージがない
おまけ
FigmaにPlugin Betaが来た
利用申し込みする必要あり
Live Embedが便利
iframeでデザインデータのプレビューを埋め込める
TrelloのPower Upに対応
実践ReasonReact
Telecomunication
Facebook製のAltJS
JSXが使える
多相バリアント
JSのメソッド呼び出しができる
まとめ
Firebaseはすごい
型は定義しないといけない
おすすめ
型安全に書きたいけど既存の資産は使いたい
使って欲しい人
ML系言語の経験がない人むけ
関数型言語に興味あるけど何から始めるべきか迷ってる人
Lighthouse performance 100点のサイトから0点を目指す
やったこと
1. Service Worker をオフにする
2. Cache-Control をオフにする
ngnixを使用してる
3. gzip 圧縮を off にする
4. Component の
Lazy load での Code splitting を off にする5. コード圧縮を off にする
ファイルサイズ
142KB → 7782KB（54 倍） へ
スピード
First Contentful Paint が 0.3 → 41.5s （138 倍）へ
まとめ： Performance 0 を目指すために
ファイルサイズを増やす = 読み込むデータ量を増やすと効果に直結
gzip、コード分割、minify をやめるとファイルサイズ増大
高画質画像を元画像のまま活用することも効果が期待できる
大は小を兼ねる！
100 点のときと 0 点の時とでは表示までに体感できるほどの差がある
会社設備の高速な回線だと見過ごしがち
ユーザーはスマホが大半だったりキャリア回線も多い
モバイルユーザーはページ表示に 3 秒待てないと言われている
現代人には余裕が必要
3G ならゆっくりお茶を飲むことも可能！
SSRで生成したコンテンツをCSRで使い回すこと
メリット
SSRとの組み合わせで画面遷移してからのコンテンツ描画時間を減らす
段階的にHydrationに行う
ページ操作が可能になる時間を短縮する
快適なUXを行う