いまさらきけない SPAのきほん ２０１8/７/２８

    

SPAとは  Single Page Applicationの略  単一のページで構成されるWebアプリケーションのこと。  初回のアクセス時に必要なリソースを全て取得。  その後の処理は画面遷移も含めJavaScriptで実行。  データの送信や最新データの取得などが必要な場合はajaxで通信。  つまりフロントエンドの技術でMVCでいうところのVのみの話。

普通のWebアプリとの違い 普通のWebアプリ ブラウザ サーバー SPA ブラウザ サーバー URL入力 次ページ要求 URL入力 … 次ページ要求 Javascriptで ファイルを切替 通信(Ajax)

SPAのメリデメ メリット •ネイティブアプリ並みの操 作性 •高速な画面遷移 •一つのソースでWebとネイ ティブとのハイブリッド化 も可能 デメリット •初回アクセスが遅い •実装コードが増える •学習コスト高め

SPAを実現する代表的なFramework  Angular Googleとコミュニティによって開発されている。 AngularJSの後継であるものの記述方法はだいぶ異なる。 TypeScript推奨。  React Facebook製。 個人的にはAngularに比べて覚えることが多いように感じる…  Backbone.js 大規模な開発向けのMVC（MVP）framework。  Vue.js 軽量framework。  Aurelia 元Angularメンバが開発する新興のframework。

SPA Frameworkのトレンド

これからはReactか？

本日はAngularをベースに解説！

Angularとは  Full stack な framework  component指向  開発支援ツールもあるよ（CLI）  TypeScriptで書ける（ってか推奨）

TypeScript のおさらい  静的型付言語  変数のチェックができる。  JavaScriptは 動的型付け言語であり、変数にどのような値でも設定で きてしまう。  名前空間が存在  クラスベース指向のobject指向言語（C#、Javaライク）  ブラウザはTypeScriptのコードを実行できるわけではない  TypeScriptコードからJavaScriptコードへの変換が必要（コンパイル）

Angularの主な機能 • HTMLベースのtemplate engine • component／template間のdata binding機能 • component／service間の依存関係を解決するDIコンテナ機能 • DOMツリーを操作するためのdirective機能 • 表示する値を加工／変換するためのpipe機能 • business logicを実装するためのservice機能 • URLに応じて画面表示を切り替えるルーティング機能 • ユニットテスト／E2EテストをサポートするTesting framework

Angular CLI が便利  開発に必要なツール一式がバンドルされる  Webサーバ、テスト等  各種雛形の生成  アプリケーション、component  ある一定の規約  命名規則やdirectory構成などがあらかじめ定められている  各種コマンドの実行  コンパイル、ビルド、テスト、サーバー起動

Angularのきほん  View（template）、ロジックをひとつにま とめ、責務分割されたcomponentとして実 装する。  それらcomponentを組み合わせひとつの ページを組み立てるのが基本。  componentは画面に依存しない為（半分ウ ソw）、複数の画面で利用することが可能 となり、再利用性が高まる。 HomeComponent SignInComponent AboutComponent

Angularの仕組み index.html まだ描画しない main.ts 起動時のメインクラス app.module.ts moduleの読み app.component.ts route componentの読込 index.ts app.module app.componentsをexport index.html 初期表示 ※実態はapp.component.html 触らないで 必要に応じて修正 ブラウザからURL入力

moduleで機能を分割 Application route module component UI部品 service ビジネスロジック custom module A component service Angular modules Common Module Http Module ・・・ custom module B component service

強力なData Binding  xamlなどでおなじみ テンプレート 送信 コンポーネント export class SampleComponent { message: string; constructor(){ this.message = "Hello, world!"; } onClicked(){ } }

基本的な流れ  node 6.9.X 以上をインストール  npm 3.x.x 以上をインストール ※Node Package Managerの略でNode.jsパッケージの管理ツール。  Angular CLI のインストール $ npm install -g @angular/cli ※powershellは"@angular/cli"  プロジェクトを作成する $ ng new  Build $ ng build ※資源は開発者のソースコードとnode module 完了するとdistフォルダが作成される  ローカルサーバー起動 $ ng serve --open オプションを指定すること、ブラウザも立ち上げ

基本的な流れ  node 6.9.X 以上をインストール  npm 3.x.x 以上をインストール ※Node Package Managerの略でNode.jsパッケージの管理ツール。  Angular CLI のインストール $ npm install -g @angular/cli ※powershellは"@angular/cli"  プロジェクトを作成する $ ng new  Build $ ng build ※資源は開発者のソースコードとnode module 完了するとdistフォルダが作成される  ローカルサーバー起動 $ ng serve --open オプションを指定すること、ブラウザも立ち上げ

コンポーネントを追加する  $ ng generate Componet generate は g で省略可能  src/app 配下に以下ように生成される CREATE src/app/home/home.component.html (23 bytes) CREATE src/app/home/home.component.spec.ts (614 bytes) CREATE src/app/home/home.component.ts (261 bytes) CREATE src/app/home/home.component.css (0 bytes) UPDATE src/app/app.module.ts (388 bytes)

Flux architecture

MVVMより扱いやすいパターン  ViewModelが肥大化しがち  コンポーネントをちゃんと設計出来ていない  肥大化しないようにViewModelを分割したもののViewと蜜結合しが ち  再利用できないことが多い  個々の責務に対する理解が低いが故に責務の範疇を超えた処理が散乱 しがち  ViewModelではプレゼンテーションロジックを行うはずなのにビジネ スロジックが混じっていたり

Flux architecture とは  プレゼンテーションレイヤーにおけるデータの流れを一方向に限定する設計パ ターン（Webブラウザの中の話）  処理の流れも一方通行なのでわかりやすく見通しが良い  componentが複雑にネストしていたりデータフローが複雑化な場合は相性が良い  基本的にはMVCの拡張でありObserver Patternでもある  個人的な解釈としてはMVCにおけるcontrollerやMVVMにおけるViewModelの処 理をわかりやすくドメイン分割したもの。

各ドメインの解説  action creator  actionTypeとpayload を元にactionを作成する。 例）actionTypeのaction.MESSAGE_CREATE action.MESSAGE_DELETE  状態の変更または画面遷移等が必要な際にactionをdispatcherに通知する。  dispatcher  storeへ伝える必要があるactionのリストを保持し、actionがaction creatorから飛んでくると、actionTypeに該当するstoreへ通 知する。  dispatcherが仲介することでaction creatorとstoreの依存関係が無くしている。  上記のような性質上、シングルトンインスタンスになる。  store  アプリケーション内のすべての状態を保持し、すべての状態を変更するロジックは store 内部に隠ぺいする。  データと状態の管理を担いあくまで管理だけ行い変更はActionに任せる。  状態が変更されるとcontrollerに通知する。  View (Controller-View)  ユーザーからの入力とデータの出力（表示）を取り扱う  Storeから発生するメッセージを購読する  Storeからの入力に応じて（一意な）データの出力を行う

まとめ  FrameworkはReactが元気  AngularはTypeScriptで書くとJavaScriptに自信が無くてもとっつき やすい  Fluxはシンプルでわかりやすいが銀の弾丸ではないのでケースバイ ケースで使う