banseivlog

大器晩成型 - 仕事中の覚え書きや反省文を書く程度のブログです

TypeScriptでIsomorphicなCode Splittingをする

frontend TypeScript webpack

以前webpack2でDynamic importsが実装される前にWebpackのCode Splittingについて書きましたが、せっかくTypeScript 2.4でもDynamic Importsが実装されたので（結構経ちますが）TypeScript環境下でいかにしてCode Splittingを実現させるかを書き残しておきます。

webpack.ensureとbabelでハマりがちなこと - banseivlog

前提となる環境

  • webpack v3.4.1
  • TypeScript v2.4.2
  • Isomorphic

環境的にはwebpackでクライアントコードをビルドしてサーバーはtsc or webpackでビルドしてます。

TypeScriptにDynamic Imports入った→入れてみた→Code Splittingしない

結構な人が躓くと思うのですが、大抵の場合requre.ensureあたりをそのままDynamic ImportsにしてもCode Splittingしてくれません。

単純にTS側のトランスパイルの仕組みなのですが、tsc --initとかでtsconfig.jsonを作ると以下のようになります。

{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "strict": true,
    // ...
  }
}

普通に使ってる分には問題はないのですがこれだとDynamic ImportsをTypeScriptは以下のように変換してしまいます

import('./hoge');

Promise.resolve().then(function () { return require('./hoge'); });

というのも"module": "commonjs"と指定されているので、すべてCommonJS方式で出力されます。

三茶の蟹と海老屋さん美味

続きを読む

Next Billion Users と Accessibility - Google I/O

Accessibility frontend Chrome

先日Google I/Oへ参加してきました。 参加レポートは会社のブログの方で書いたのでそちらを御覧ください。

developers.cyberagent.co.jp

個人的にアクセシビリティ周りで思うことがあったのでこっちのブログにまとめていきます。

Accessibility

アクセシビリティは、「利用しやすさ・アクセスのしやすさの程度」を表現する言葉です。

ただ最近見ている資料がWeb Accessibility(特にWAI-ARIAの仕様を偏った視点)で見ているせいでしょうか、アクセシビリティといったら認知や視覚にハンディキャップのある人に向けた対応が僕の認識の中で大きくなっていました。 つまりアクセシブルなWebを実現するためにはとりあえずWCAG(Web Content Accessibility Guidelines)に沿うようにマークアップ等の実装をしていくだけなのかなと思ってしまっていました。

Next Billion Users

そんな中で先日Google I/Oの “Designing for the Next Billion Users: Accessibility UX Insights from the Developing World” を見てきました。

www.youtube.com

ここでは、Googleが次の10億人を狙っていく際に浮上するアクセシビリティ的な課題への解決のためどういった考え方でアプローチしているのかについて話されています。 もちろんここでは従来?のアクセシビリティについての重要性について挙げられています。次の10億人 = 新興市場（ex: インド）の市場感について話すとともに、多くの人が多様なDisablityを抱えていると述べてます。次に列挙するのが具体的なDisablitiyの例です。

  • ロースペックなモバイル端末
  • 通信料は非常に高価なもの
  • 多様な言語とリテラシー
  • 文化
  • 性別

これからわかるように、起こりうる障害についてより広くアクセシビリティという観点を持っていることがわかります。ここには挙げられていませんが、視覚・聴覚・認知・移動性など我々が認識している側面からももちろん考えられていました。

「利用しやすさ・アクセスのしやすさの程度」と私は最初に表現しましたが、アクセシブルなウェブサイトとは？と考えた時、すべての人が利用しやすい・アクセスしやすいウェブサイトと言うように言い換えることができます。

「すべての人」ってすごくざっくりとしていて、僕はわかりやすいところで「視覚や聴覚などの障害を持つ人々も」と考えていましたが、実際に言葉の意味することはいついかなる環境下でも(たとえオフラインでも)アクセスできることがアクセシビリティの本質なのかなと、このGoogle I/Oのセッションで認識を変えさせられました。

改めてAccessibilityを考える

「そもそもこのセッションはGoogleが次狙うターゲットに向けたアクセシビリティの強化で日本ではそこまで関係ないじゃん」と思われる方いるかもしれないですが、すべてとは言いませんが日本でもNext Billion Usersに向けたアクセシビリティは考えていくべきです。

Googleが次に狙う市場と言ったように、アクセシビリティを広範囲にサポートしていくということは言い換えればその分市場を拡大していることにも繋がります。多様な通信環境・言語・障害は思っている以上にどこにでも発生しうるユーザーの状態です。わかりきった話ですが、その中でアクセスしやすいものとアクセスしにくいものがあったときに戦えるのは前者だけなのではと。グローバルな市場に攻めていきたいなら尚更です。

と言った感じで、アクセシビリティに対して自分が狭い考え方をもっていたことに対する反省でした。

アクセシビリティ＝パフォーマンスにつながる側面もあるのでI/OでAMPやらPWAやら耳にタコができるくらい聞かされたのかな。あとアクセシブルな文章をかけるようにもっと国語を学ばなきゃ

npmパッケージ公開デビューした

javascript nodejs webpack npm frontend

npmパッケージデビューしました。
公開するまでに感じたあれこれを残しておこうと思います。

経緯としてはbrowserifyからwebpackに移行して、webpackと親しくなっていると痒いところに手が届くようなプラグインが欲しくなったというのがありました。

例えば browserifyで綺麗にライセンス表示を出してくれたlicensifyのようなもの。
webpack上でライセンス表示といえば、UglifyJsPluginとuglify-save-licenseを掛け合わせた方法が一般的ですが、イケてる感じにしたいとなるとなかなかに難しい。ネットサーフィンしながら他のプラグインでできないかなーと探しても僕のググり力ではいい感じのが見つからない…というわけで作ることにしました。

そうこうして license-banner-webpack-plugin を作りました。
※パッケージの中身についてはご容赦くださいm(_ _)m

npm publish の際の心構え

いかんせん初めてなものでドキドキしながら npm publish したわけですが、最低限以下のことに気をつけながらやりました。

  • テストが通ったものを出す
  • バージョン上げる
  • 遠慮しない

拙いテストになってしまっているのですが人が使うかもしれない可能性もあるのでテストコードをリリース前に書いて出すようにするのが最低限のマナーになるのかなと思います。

バージョン上げる作業なれないと忘れがちになりそうなので気をつけるようにしています。（一応自動化を目標にはしたい）

遠慮しないこともまた最初の一歩としては大事かなと思います。
いままでずっと遠慮していたんですが、そもそも僕ごときのエンジニアが出したパッケージなんて誰も見ないんで諸々の不安は杞憂だなと思います。

そんな心構えの中での最初の npm publish は思った以上に簡単に公開できて怖かったです。

f:id:ryo_suga:20170203101351j:plain 写真は新宿某所にある会員制のお肉のお店"29on"のお肉

続きを読む