IE と polyfill 関連の記事まとめ
- カテゴリ:
- JavaScript
- Index
- コメント数:
- Comments: 0
最近の記事がいつも以上に前の記事の続きだったり 記事間の関係があってごちゃごちゃしてきたのでまとめ
IE で WebComponents 使ったり babel の polyfill (core-js) を使ったりの話です
IE で WebComponents 使ったり babel の polyfill (core-js) を使ったりの話です
WebComponents 機能をふんだんに使ってる lit-element が IE でも動くと言うのを見かけたのが始まり
IE でも WebComponents が動く polyfill が実用レベルになってるんだなぁ と使ってみたのがこの記事
▶ IE で WebComponent (lit-element) 使うのつらい
あまり情報がないのであれこれ苦労して一応動くようになってます
公式のドキュメントにあった polymer-cli を使ってますが 古いものですし 汎用的なものでもないので自由度がなく不満も多いです
汎用的なバンドラーの parcel や webpack でやってみた記事がこれ
▶ IE11 で WebComponents はやめたほうがよさそう
parcel は依存モジュールを babel でトランスパイルできないことや webpack 使うとなぜか IE で実行時にスタックオーバーフローするなどの問題があって結局 polymer-cli 以外ではまともに動きませんでした
polymer-cli だとやはり不便な点が多いですし そういうことやそもそもこういう環境づくりでいろいろ躓くという本質じゃないところで苦労するので polyfill 詰め込んでビルドやらバンドルいるようなことはやめたほうが良いと思った結果が記事タイトルです
その後 スタックオーバーフローの原因が polyfill のロード順が原因とわかって lit-element を webpack で動くようにしたのがこの記事
▶ lit-html/lit-element を IE で動かす
先に babel の polyfill をロードすれば大丈夫でした
polyfill には @babel/polyfill を使っていたのですが deprecated になっていて core-js と regenerator-runtime を使うことが推奨になっていたのでそのあたりを試したのがこの記事
▶ @babel/polyfill と core-js
少しファイルは大きくなりましたが 必要な機能をモジュール単位でロードできるようなしくみが入ったので IE が消えれば将来的には小さいサイズになりそうです
IE は使えない機能が多いのでそこまで小さくなりません
polyfill をアプリケーション中で import してバンドルに含めてしまうのも一つの方法ですが 読み込み順でエラーが発生することもありますし なにより 変わらない polyfill 部分は別に分けていたほうがいろいろ良さそうです
なので polyfill のみでバンドルしたファイルを別にロードさせるようにしたのがこの記事
▶ core-js-builder 使ってみる
これまでの @babel/polyfill のように minify 済みのを使うなら core-js-bundle のコードをロードするだけです
自分で必要機能を指定してバンドルするのには core-js-builder が使えます
まぁ そこまで設定できることもないので用意されてるので良いかも知れないですけどね
core-js に置き換えてもロード順によっては IE でスタックオーバーフローする問題は変わらずでした
このエラーは自分のコードでなにかしなくても polyfill のロードだけで発生します
▶ IE で polyfill 入れると stack overflow する問題
ちなみに WebComponents と core-js の組み合せ以外にもエラーが起きるケースはあります
Google Maps API の場合もこれを先にロードするとエラーになりました
ライブラリが独自にもっている部分的な polyfill との競合が起きそうなので core-js を使った polyfill は常に最初にロードするようにしておくと安心だと思います
▶ Babel と GoogleMaps API の相性が悪い?
lit-html に近い hyperhtml の場合は lit-html とは違い polyfill を別途ロードしていることを要求しません
内部で pol(n)yfill を持っていて 機能がない場合に使用されます
そのため 使うには hyperhtml をロードするだけで良く 外部に polyfill は不要なので簡単に使えます
lit-html は WebComponents を使う気がなくても template タグの polyfill が必要で WebComponents の polyfill が必要になるのでさっと使いたいときは こっちのほうが良いかもですね
▶ IE11 だと lit-html より hyperHTML のほうがよさそう
また polymer-cli で不便だった部分も polymer-build を直接 JavaScript から使えばマシになるかなと試してみたのがこの記事
▶ polymer-build 使ってみた
やってみた結果 簡単に変更できる部分は polymer.json でいじれるところで babel の設定とかになるとけっこう大変なので イマイチでした
さらに 情報が少ない上に gulp 系ツールに依存とか結構古い感じで これは使わなくていいかなというのが結論
webpack で動くことがわかったので WebComponents を使うときでも polymer-cli と polymer-build はもう使わないでしょう
ところで polymer-cli では es5 adapter という JavaScript が必要に応じて自動でロードされるようにコードが追加されます
これは Chrome などのモダンブラウザで ES5 にビルドされた JavaScript から WebComponents を使うときに必要なものらしいです
それについての記事がこれ
▶ polymer の ES5 adapter の中身
しかし 結局 webpack のときに追加しなくても Chrome で動いたので必要なのかよくわかりません
最後に webpack の使い方を簡単にまとめた記事
▶ webpack の基本的な使い方まとめ
使い始めの状態で書いたものなので比較的初心者向けかなと思います
IE でも WebComponents が動く polyfill が実用レベルになってるんだなぁ と使ってみたのがこの記事
▶ IE で WebComponent (lit-element) 使うのつらい
あまり情報がないのであれこれ苦労して一応動くようになってます
公式のドキュメントにあった polymer-cli を使ってますが 古いものですし 汎用的なものでもないので自由度がなく不満も多いです
汎用的なバンドラーの parcel や webpack でやってみた記事がこれ
▶ IE11 で WebComponents はやめたほうがよさそう
parcel は依存モジュールを babel でトランスパイルできないことや webpack 使うとなぜか IE で実行時にスタックオーバーフローするなどの問題があって結局 polymer-cli 以外ではまともに動きませんでした
polymer-cli だとやはり不便な点が多いですし そういうことやそもそもこういう環境づくりでいろいろ躓くという本質じゃないところで苦労するので polyfill 詰め込んでビルドやらバンドルいるようなことはやめたほうが良いと思った結果が記事タイトルです
その後 スタックオーバーフローの原因が polyfill のロード順が原因とわかって lit-element を webpack で動くようにしたのがこの記事
▶ lit-html/lit-element を IE で動かす
先に babel の polyfill をロードすれば大丈夫でした
polyfill には @babel/polyfill を使っていたのですが deprecated になっていて core-js と regenerator-runtime を使うことが推奨になっていたのでそのあたりを試したのがこの記事
▶ @babel/polyfill と core-js
少しファイルは大きくなりましたが 必要な機能をモジュール単位でロードできるようなしくみが入ったので IE が消えれば将来的には小さいサイズになりそうです
IE は使えない機能が多いのでそこまで小さくなりません
polyfill をアプリケーション中で import してバンドルに含めてしまうのも一つの方法ですが 読み込み順でエラーが発生することもありますし なにより 変わらない polyfill 部分は別に分けていたほうがいろいろ良さそうです
なので polyfill のみでバンドルしたファイルを別にロードさせるようにしたのがこの記事
▶ core-js-builder 使ってみる
これまでの @babel/polyfill のように minify 済みのを使うなら core-js-bundle のコードをロードするだけです
自分で必要機能を指定してバンドルするのには core-js-builder が使えます
まぁ そこまで設定できることもないので用意されてるので良いかも知れないですけどね
core-js に置き換えてもロード順によっては IE でスタックオーバーフローする問題は変わらずでした
このエラーは自分のコードでなにかしなくても polyfill のロードだけで発生します
▶ IE で polyfill 入れると stack overflow する問題
ちなみに WebComponents と core-js の組み合せ以外にもエラーが起きるケースはあります
Google Maps API の場合もこれを先にロードするとエラーになりました
ライブラリが独自にもっている部分的な polyfill との競合が起きそうなので core-js を使った polyfill は常に最初にロードするようにしておくと安心だと思います
▶ Babel と GoogleMaps API の相性が悪い?
lit-html に近い hyperhtml の場合は lit-html とは違い polyfill を別途ロードしていることを要求しません
内部で pol(n)yfill を持っていて 機能がない場合に使用されます
そのため 使うには hyperhtml をロードするだけで良く 外部に polyfill は不要なので簡単に使えます
lit-html は WebComponents を使う気がなくても template タグの polyfill が必要で WebComponents の polyfill が必要になるのでさっと使いたいときは こっちのほうが良いかもですね
▶ IE11 だと lit-html より hyperHTML のほうがよさそう
また polymer-cli で不便だった部分も polymer-build を直接 JavaScript から使えばマシになるかなと試してみたのがこの記事
▶ polymer-build 使ってみた
やってみた結果 簡単に変更できる部分は polymer.json でいじれるところで babel の設定とかになるとけっこう大変なので イマイチでした
さらに 情報が少ない上に gulp 系ツールに依存とか結構古い感じで これは使わなくていいかなというのが結論
webpack で動くことがわかったので WebComponents を使うときでも polymer-cli と polymer-build はもう使わないでしょう
ところで polymer-cli では es5 adapter という JavaScript が必要に応じて自動でロードされるようにコードが追加されます
これは Chrome などのモダンブラウザで ES5 にビルドされた JavaScript から WebComponents を使うときに必要なものらしいです
それについての記事がこれ
▶ polymer の ES5 adapter の中身
しかし 結局 webpack のときに追加しなくても Chrome で動いたので必要なのかよくわかりません
最後に webpack の使い方を簡単にまとめた記事
▶ webpack の基本的な使い方まとめ
使い始めの状態で書いたものなので比較的初心者向けかなと思います