tkiryu’s blog

本ブログの内容は個人の意見です。所属組織の公式見解ではありませんのであしからず。

.NET Conf 2017 Tokyo で登壇してきました

– この記事は 2017/10/13(Fri) 現在の情報に基づいています –

先日開催された .NET Conf 2017 Tokyo で登壇してきましたので、その振り返りをしたいと思います。

発表内容

発表スライドはこちらです。

発表内容としては大きく2つ

  1. ASP.NET Core 2.0 で追加された Angular SPA テンプレートの紹介
  2. ASP.NET Core のプロジェクトと、Angular CLI で作成したプロジェクトを統合する方法

でした。

発表内容補足

Angular 用 の SPA テンプレートは

  • Client Side Routing
  • Server Side Prerendering
  • webpack dev middleware
  • Hot module replacement

の機能を備えたテンプレートです。これはこれで良いのですが、Angular やるなら Angular CLI 使わなきゃ損、というのが今回の主張だったのですが、発表のあとで「結局、テンプレートの方が高機能ってことですよね」と言われてしまったので、この場を借りて補足しておきたいと思います。

  • Client Side Routing

に関しては、Angular CLI では ng new 時に --routing オプションをつけてあげると、ルーティングモジュールを含んだ形でプロジェクトを生成してくれます。

ng new my-app --routing

ルーティングモジュールの中身は 公式ページのガイド に沿って実装すればよいだけなので、Angular SPA テンプレートじゃないとダメというわけではありません。

  • webpack dev middleware

に関しては、Angular CLI でもデフォルトで同等の機能(編集保存するたびに自動コンパイル)があります。

  • Hot module replacement

に関しては、Angular CLI でも HMR の手順 どおりに設定することで有効にすることができます。

唯一 Angular CLIASP.NET Core の組み合わせで Server Side Prerendering を実現することはできない(と今のところ思っていますが、やりようがないか調べ中)ですが、それ以外は、Angular CLI でも簡単に構成することができますし、Angular CLI を使うことでそれ以上の恩恵を受けることができると思います。

特に大きいのが Angular パッケージのアップデートです。ASP.NET Core に内包された状態だと、パッケージのアップデートは手動で行わなければなりません。また、独自のビルドロジックになっているので、Angular のアップデートに伴ってビルド方法も変更しなくてはならなくなることも想定されます。Angular CLI の場合は、パッケージ管理も、ビルド方法も、Angular CLI さえアップデートすれば完了します。このメンテナンス性の高さは非常にアドバンテージがあると思います。

以上の理由から Angular CLI の使用を推すわけです。

なお、ASP.NET Core で Angular CLI を使いたいという要望は多く、Github 上に Issue:Add new Angular CLI-based template も登録されているので、今後の進展が楽しみです。

所感

  • 時間配分を間違え、しかも、時間オーバー
  • 時間が無くなるにしたがって次第に早口に、噛みまくり
  • 一番話したかった部分を十分に伝えられなかった

などいろいろ反省点が多く、力量不足を感じました。セッションに足を運んでいただいた方々には、理解しにくい点、聞き取りづらい点など多々あったかと思うと、申し訳ない気持ちです。

もしまた機会を頂けたら、今回の反省点を活かして再チャレンジできたらなと思います。

最後に

運営の皆さま、このような大きなコミュニティイベントで貴重な登壇機会をいただきまして本当にありがとうございました。非常によい経験をさせていただきました。またぜひ参加できればと思います。