UX week5
- Don't hide the place where you don't have an elegant solution with glitz or glam decoration
CSS/SVG/Canvasのビジュアル表現でできること・できないこと
- 直線的なものはCSS、ベジェ曲線を動かしたかったらSVG、画像自体をぐにゃぐにゃ動かしたい時はWebGL(Canvas)。ぐにゃぐにゃはSVGでもできることもあるが、要素全体を書き直すとなると計算量が大きくなるので非効率なことも。
- アニメーションも、上下左右、円のみの動きならCSSでOK。限られているように感じるが上下と左右を組み合わせると違和感なく動きが出せる。pathにそって動かす形でいいならSVG、残像をつけるなど「直前の描画結果を使って何かしたい」場合はCanvas。
- CSSFilterのマウスオーバーパターン
- エフェクト表現に関しては基本的にCSS Filter->SVG Filter->Canvasの順に自由度が増していく。SVGにFilterがあるの知らなかったし、この記事みたいなゆらゆらしてる表現がSVGでできるのは知らなかったな…。
Webフロントエンド パフォーマンス改善ハンドブック
- ページロードのパフォーマンス改善として、ファイルサイズは環境に左右されないので手を出しやすい。ああこんなこともやってたな…と思い出した。bundle-analyzerのことを完全に忘れていたので明日試そう。
- 例えば社内ライブラリを使う時、bundle済のものだけを配布すると使う側は何も考えなくて良い一方、依存ライブラリが重複しているときに重複して最終bundleに入ってしまうという問題もある。筆者は両方を配布するようにすることで、treeshakingなどの恩恵を受けられるようにした一方、scriptなどで読み込む時はbundle済を使えるようにしたとのこと。lodashあると大きいよなぁ…。使わないに越したことないけどすでに使われてしまっている状態だと辛いものがある。
- exportは動的なモジュール読み込みを許容してしまうため、ほとんどの場合静的な解析により行われるTreeShakingの対象にならないことがほとんど。一方でES2015導入のimport/export構文はトップレベルでの読み込みをしなければならない制約により確実に読み込みが保証されるのでこうした解析ができるようになっている。
- 通常npmで配布しているライブラリでは
package.jsonのmainのパスを読み込む。ここはrequireで読めるCommonJSのパスになる。moduleフィールドに書くパスはEXMAScriptモジュールのパスでimport/exportで読めるものになる。webpackはmoduleがあればそちらを優先してロードする。 tsconfig.module.json > compilerOptions > module: "esnext"= "module"によってimport/exportのまま出力できる
