EmberFest 2018 参加レポート day 2

2018年10月にアムステルダムで行われた EmberFest の二日目の参加レポートです。 f:id:tricknotes:20181011180358j:plain

一日目のレポートはこちら。

tricknotes.hateblo.jp

今回も印象に残ったトークをまとめています。

Honey, I shrunk your Ember app by Simon Ihmig - @simonihmig

話者の開発しているプロダクト(The Local Water)で、いかにアプリケーションのサイズを小さくするかという工夫の話でした。 低速な回線を利用するユーザーを対象とする場合、ファイルサイズは直接ユーザー体験に影響を与えます。 そのため、話者はファイルサイズを小さくして快適に表示できるようにすることで、使い心地のよいアプリケーション開発に注力しているとのことでした。

サイズを小さくするにあたって大事な原則は、Measure -> Analyze -> Optimize のサイクルだそうです。 これらについて、具体的に見てきましょう。

Measure

  • production 用に uglify & gzip したあとのサイズで計測する
  • ember-cli-bundlesize を使うと計測が楽である
  • CI で計測して、サイズを計測し続ける

Analyze

  • broccori-concat-analyzer を使って、どのライブラリのどのコンポーネントが割合を占めているのかを可視化する
  • Ember アプリの場合、ember-cli-bundle-analyzer を使うと可視化しやすい

Optimize

  • 依存の多い Addon は外す前提で考える
    • 例えば ember-lodash, ember-moment, liquid-fire
    • とくに話者の場合はこれらのライブラリが提供する機能に対して、ごく一部しか使っていなかった
  • そもそもサイズの大きなライブラリは外す
    • bootstrap , jQuery*1 (ただし、Addon の中には jQuery に依存している可能性があるので注意)
  • サポート対象外のブラウザのためのトランスパイルが含まれていないか確認する
    • とくに IE11 を対象にするとファイルサイズが大きくなりがち
    • 同様に、babel-polyfill の読み込みを外す
  • gzip 互換なよりよい圧縮が利用できないか検討する(ただし、非対応のCDNは多い)
    • Zopfli
    • Brotli (こちらの方が圧縮性能はよいが、IE11, iOS11 は非対応)
    • ember-cli-deploy-gzip を使うと圧縮ファイルを生成できる

話者はこれらすべてをひとつひとつプロダクトに適用した結果、アプリサイズ500KBから300KBに削減できたそうです。

感想

大変実践的な内容で、ファイルサイズを小さくするにあたってのガイドラインとなりそうな発表内容でした。

Mastering the Art of Forms by Danielle Adams - @danielleadams

Heroku でエンジニアをしている Danielle Adams 氏による、Ember でフォームの作るためのテクニックの話でした。 発表資料はこちらから確認できます。

Composable Elements

コンポーネントを組み合わせ可能な単位で定義することで、ユーザーから見えるひとくくりの部品に名前を与えます。 例えば、ラベルとテキストフィールドの組み合わせに対して FormTextInput というコンポーネントを定義します。

これによってアプリ内で UI が標準化され、実装面・利用面どちらからも統一感のあるものにできます。 結果として、再利用可能になるため UI の変更を行いやすくなります。

Manageable & Performant Data

例えばセレクトボックスの中身のようなマスタデータについては、Route で解決するのではなくコンポーネント自身がデータ取得を行います。 これによって、画面の表示完了を阻害しなくなりますし、コンポーネントがテスト可能になります。*2

また、Ember のモデル層(Ember Data や Ember Model)を永続化層のデータ管理としてだけではなく、一時的なユーザー入力の保存場所として利用することで入力値を管理しやすく入力値チェックを行いやすくなります。*3
例えば、会員登録フォームに対して models/sign-up というモデルを割り当て、入力値に対応する属性を定義します。 入力値に問題があれば ember-cp-validations などのライブラリを利用して、ユーザーにすぐにフィードバックを行えます。

Accessibility

サブミットした瞬間ではなく、入力値に問題があればフォーカスが外れたタイミングでユーザーにフィードバックを返します。 こちらについては、具体的なアプローチは語られていませんでした。

感想

ユーザーのための UI 設計と実装上のテクニックの橋渡しをするようなトーク内容がとても印象的でした。

The Future Of Templating In Ember by Chad Hietala - @chadhietala

Ember のコアチームで Glimmer を担当している Chad Hietala 氏による、Glimmer の将来像についての話でした。 話者の別のカンファレンスでの発表内容はこちらです

まずは Glimmer の設計の原則の話で、以前の Ember は Easy に使えるようなテンプレートのデザインでしたが 現在は Simple を目指しているとのことです。 以下、 Ember のテンプレートにおける Easy と Simple の一例です。

  • Easy
{{name}}
{{#each posts}}
  {{title}} <!-- 暗黙的変数のコンテキストが切り替わり、post の title が参照される -->
  {{name}} <!-- posts の外のスコープで定義された name が参照できなくなる :< -->
{{/each}}
  • Simple
{{name}}
{{#each posts as |post|}}
  {{post.title}} <!-- 明示的に変数を指定して値を参照する -->
  {{name}} <!--コンテキストが切り替わらないので、posts の外のスコープで定義された変数を参照できる -->
{{/each}}

また、すでに実装されたもの・これから取り組んでいくものの RFC が紹介されました。

Required this

コンポーネントから渡ってくるプロパティについては、必ず this 経由でアクセスすることを強制するという機能です。 これによって、プロパティの定義元が自明のものとなります。

Arguments

Easy / Simple の例でも紹介しましたが、as キーワードで引数を受け取れるという機能です。 each ヘルパーのみならず、任意のヘルパー・コンポーネントでも(実装側がサポートしていれば)任意のオブジェクトを引数として受け取ることができます。 こちらは数年前から実装されていますが、Ember 1.0 では提供されていませんでした。

Angle Brackets

Ember 3.4 の目玉機能です。 コンポーネントを template 中に直接記述でき、コンポーネントへの引数と HTML への引数が区別できるようになりました。 github.com

Named Blocks

ひとつの Component に対して、ヘッダとサイドバーなど複数の部品を呼び出し側から差し込むための機能です。 github.com


最終的に、これら RFC がすべて実装されたあとの Ember のテンプレートはこういった世界になるということです。

また、ここで紹介された未来像については、こちらの issue にて議論が進められています。 github.com

感想

将来的なビジョンを定めて、互換性を大事にしつつも着実に進めていく Ember コミュニティの様子には驚かされるばかりです。 これまで「Ember について知っている必要があること」が数多くありました。ただ、これらは初学者にとってのハードルが高くなっていたと言わざると得ません。
今回紹介された Glimmer の改善によって、"ふつうの HTML / JS" の流儀の上で Ember が存在するような世界が実現されるように感じられ今後がとても楽しみです。

全体のまとめ

去年は Glimmer のパフォーマンス改善の話が衝撃的でしたが、今年はユーザー側に向けた地道な改善の話と利用事例・設計の工夫の話が多かったように感じました。 今回のレポートでは取り上げませんでしたが、GraphQLCordova での事例もお話された方がいらっしゃいました。

つい先日最新の LTS である Ember.js 3.4 がリリースされ、ここからしばらくは deprecated になっていた機能の削除と新しい機能追加が行われていくことでしょう。
今回の EmberFest では実際に Ember を本番利用している開発者が多く参加しており、EU 圏での盛り上がりを感じられとても有意義でした。

まだ来年の EmberFest の場所は決まっていません(EU圏のどこかのはずです)が、来年も多くの変化があることを楽しみに参加したいと思います。 もしこの記事を読んで興味持たれた方がいらっしゃれば、来年はぜひ一緒に行きましょう!*4

当日の様子(おまけ)

参考までに、当日の様子を写真でふりかえります。

入り口の立て看板 f:id:tricknotes:20181012022020j:plain

朝ごはんを用意してくれているので、早めに会場に行くと食べながら他の参加者とダラダラしゃべれます。 f:id:tricknotes:20181018000516j:plain

カフェでは好きな飲み物を注文できます。(料金はチケット代に含まれています) f:id:tricknotes:20181018003713j:plain

会場の外はこんな感じアムステルダムの大きな通り沿いにある多目的ホール(?)です。 f:id:tricknotes:20181018000902j:plain

お昼の風景。会場に用意してくれているので、発表を聞き終えたらそのまま好きにとって食べる感じでした。 f:id:tricknotes:20181017195003j:plain

こんな感じ。 f:id:tricknotes:20181017194958j:plain

*1:Ember.js 3.4 ではついに jQuery への依存を外すことができるようになりました

*2:サーバサイドの経験が豊富な開発者だと Route でデータ取得を行いたくなるかもしれませんが、コンポーネントで独立させたほうがテストしやすくなるそうです。

*3:Railsなどのサーバサイドフレームワークでは、フォームオブジェクトとして知られるテクニックとよく似たアイディアです。

*4:いるのかな…