リレーションデザイン研究所

榊原昌彦

2018/05/07

Ionic 2 から 4 への、この2年間の進化を振り返る

記事のアイキャッチ画像

「Angular 2から6までの主要な進化をまとめた記事を読みたい」とツイートしたら、Angularの強い人にIonic情報とのトレードを提案いただいたので、Ionic 2から4までのIonicとその周辺ライブラリの進化を時系列にまとめていきます。

Angular v2からv6までの変化をまとめてみた とあわせてご覧ください。

なお、Ionicって何よ？という方は少し古い記事となるのですが「Angular 2を使うならUIはコレで！Ionic 2ことはじめ」をご参考ください。

Ionic v2

2016年2月11日

私のIonicをプロダクト採用したレポジトリをみると、この日の angular2@2.0.0-beta.2 / ionic-framework@2.0.0-alpha.57 が最古のコミットになっておりました。技術調査はもうちょっと前からしていましたが、本記事のスタートラインはここからとさせてください。

Ionic 2.0.0リリース – 2017年1月

ionic-2-final-header

v2正式リリースまでに細かい変更はいろいろあったのですが、記憶に残っているのはIonicの独自路線からAngularのメソッドにあわせていったことです。

  • 推奨する書き方がES2015から、AngularにあわせてTypeScriptに変更。
  • @Page() という独自デコレーターからAngular標準の @Component() に変更
  • Directive名がケバブベースからキャメルケースに変更（nav-pop => navPopなど）
  • AngularのLifecycleと明確に分けるために、IonicのLifecycleには ion と接頭語がつくように変更（ onPageLoaded() => ionViewDidLoad など）

Ionicチームが、ブログ「Announcing Ionic 2.0.0 Final」で「最初はAngularチームに疑問を呈してたが、Angularチームの様々な決定は最高なものだった（ the best that Angular could have made.）」と書いてて、なるほどなと思いました。

SplitPane/Grid の追加 – 2017年2-3月

split-pane.gif

リリース以降もUIコンポーネント追加は行われていたのですが、デスクトップ対応に舵を切り出したのはこの頃でした。それまでは、「Webでも表示できる、iOS/Android/WindowsPhoneアプリをつくるためのフレームワーク」という立て付けが強かったですが、Web（特にデスクトップ表示）のサポートがはじめました。SplitePaneというレスポンシブでハンバーガーメニューとサイドメニューが切り替わるコンポーネントとGrid機能が提供されました。

Ionic v3

Ionic 3.0.0リリース – 2017年4月

Angular v4に対応する形でのアップデートです。Angularのメジャーバージョンアップにあわせて、Ionic本体もメジャーバージョンアップをしています（Ionic CLI内部的にはapp-scriptsでIonic 2系とIonic 3系のビルドを共通して処理する形）

AngularのLazy Loadingに対応する形で、Ionicも @IonicPage() によるLazy Loadingが実装されました。ionic g pageコマンド標準採用になったことから、Ionic 3ではすべてのpageをLazy Loadingでつくるのが一般的になりました。

PWA（Progressive Web Apps）サポート – 2017年8-11月

スターターテンプレートレベルで、Web App Manifest と Service Workers のサポートがはじまりました。あと、ちょうどこの時期から新しい動きに舵を切り出しました。

  • AngularでつくられていたIonicを、Web Components（HTML5仕様）で作り直すことを決定
  • IonicをWeb Componentsで再構築するためのライブラリ「Stencil」の開発を公表（開発自体はもうちょっと前からスタートしてた模様）
  • Cordovaに代わるクロスプラッフォームフレームワーク「Capacitor」の開発を開始

Stencilの説明

Web ComponentsをTypeScript（.tsx）で開発するためのライブラリ。Ionic以外のオリジナルのWeb Components作成にも使えます。Components毎のLazy Loadingができたり、SSR（Server Side Rendering）ができたりすることが特徴。なぜかRoutingもついてます。

Ionicチームはこれを利用してIonic v4のWeb Componentsをつくっています。2018年5月7日時点でv0.8です。

スクリーンショット 2018-05-07 21.48.39.png

Stencil Webサイト（英語）

Capacitorの説明

Ionicを、iOS/Androidだけではなく、Electron、PWAでも動作するようにするクロスプラットフォームフレームワーク。Cordovaの代替ではなく、全く新しいアプローチになります。なお、引き続きCordovaのサポートも行われます。

Web/NativeのAPI変換レイヤーを用意することでAPIひとつですべてのクロスプラットフォームに対応したり、iOSまわりはSwiftデフォルトであったり、Native UIとWeb Viewを両立させたりと「次のクロスプラットフォーム」のための多くの構想があります。

Announcing Capacitor 1.0.0 Alpha (英語)

Ionic v4 alpha

様々な切り口からv4はどう変わるのか、をみていこうと思います。

Stencil/Web Componentsからみる

Web Componentsとなったといっても、Angularとのラッパーとして @ionic/angularが提供されます。もちろんこれを使わず実装することも可能ですが辛い道になりそうで、Web ComponentsベースとなってもIonicがAngularと密結合に近いかたちでありつづけるのは変わらないかなと思っております。

また、呼び出すComponentsのみが（Lazy Loadingで）ロードされるので、これまでのように「使わないコンポーネント多いのでIonicを導入したら全体的に重くなる」ということはなくなります。

PWAからみる

262fb77d6b7c01cd05f8b009bfb512c4

Ionic v3で、限定的なPWA対応（Web App ManifestとService Workerによるオフライン対応）の実装が行われましたが、Ionicチームでは「Ionic Pwa Toolkit」というレポジトリを現在、用意しております。Beta版で、以下の機能があります。

  • 新しいバージョンのPWAが利用可能な時の通知
  • Push通知設定
  • Web App ManifestとService Worker
  • 設定なしでのLazy Loading
  • Pre-rendering
  • 画像のLazy Loading

v4リリース後は、現在の限定的なPWA対応から、PWAにフル対応したWebアプリの作成サポートがこれから行われるかもしれません。

CLIからみる

Ionic CLIは、v1からv3まで独自でビルドまわりを実装してきましたが、それが大きく変わります。v4では、Angular CLIをラップします。ですので、 ionic serve は内部的には ng serve となります。

Ionicではv2時代にAngular CLIを利用しようという構想があったものの、遷移時のアニメーションでのスタック関係がうまく整理できずに独自路線にいった記憶があります（ちょっとあやふやですが）。それ以降の進化として

  • Stencilで内部的にルーティングできるようになった
  • @angular-devkit が生まれ、Angular CLIを独自カスタマイズできるようになった
  • Ionic v2からURLルーティングに悩まされ続けており独自路線つらい

などありまして、この度、CLIまわりも刷新されるようになりました。このため、CLIは内部的処理でバージョンが分かれており

  • Ionic 1 : GulpをベースにしたCLI
  • Ionic Angular 2/3： @ionic/app-script の実行ツール
  • Ionic Angular 4:  Angular CLIをラップしたツール

の3つの機能を持つことになりました。なので、Ionic v3は、v4リリース後も使い続けることができるようになります。

Capacitorからみる

intro-capacitor-header

Capacitorは、Ionic CLIで ionic cap コマンドで使えるようになります。現在は、Web向けコンパイルは npm run build 、スマホアプリは ionic cordova コマンドによってビルドしますが、今後は「使い分けられるユーザ」だけが使うようになり、リリース用ビルドは ionic capコマンドが主流となる可能性があります。

Routerからみる

Angular CLIによってビルドされることにより、Angular Routerを利用することができるようになります。このことにより、今までネックであったTabsのURLルーティングの不具合がなくなる見込みであり、また特定のComponents群をひとまとめにLazy Loadingにするといったことも可能となります。

それとは別に、URLルーティングを行わずに、Ionic内部で複数Componentを呼び出し、スタックさせてルーティングしているようにみせることも可能です。ただ、 @IonicPage() は廃止されますので、現在のようにスタックさせる形でURLを自動的に切り替えることはできなくなるので、Angular Routerを使うのが推奨となります。

既存アプリをv3からv4に移行させる場合、ここが一番のハードルになりそうです。

マイグレーションサポート

いくつかの破壊的変更が起きることはIonicチームも課題に感じておりまして、マイグレーションサポートを予定しております。

の開発が現在進んでいます。

まとめ

IonicはTwitterの公式アカウントで「Always Bet on the Web」（いつでもWebに賭ける）と明言しており、Web/HTMLの進化、そしてそれをキャッチアップするAngularに追随していっているので、これからもどのように変わっていくかをみていこうと思います。

スクリーンショット 2018-05-07 21.40.06.png

また、Ionic Japanで、Ionicの知見を共有するためのslackのオープンチャンネルを運営しており、v4についてのチャンネルもございますのでぜひご利用ください。
https://t.co/K9slM8tvi8

ちなみに本Webサイトは、 Ionic v4 alpha.3 / Angular 6 で作成されております。

それでは、また。

Cookieを利用します

このWebサイトでは、Google Analyticsをアクセス解析のために導入しており、個人データであるCookieにアクセスします。引き続き利用する場合はCookieの利用への同意が必要です。

同意する