次の方法で共有

一般的なクライアント側の Web テクノロジ

ヒント

このコンテンツは、ASP.NET Core と Azure を使用した最新の Web アプリケーションの設計に関する電子ブックからの抜粋です。 .NET Docs またはオフラインで読み取ることができる無料のダウンロード可能な PDF として入手できます。

PDF をダウンロードする

ASP.NET Core と Azure eBook の表紙サムネイルを使用して最新の Web アプリケーションを設計します。

"Web サイトは内側と外側から見た目が良いはずです。" - ポール・クックソン

ASP.NET Core アプリケーションは Web アプリケーションであり、通常は HTML、CSS、JavaScript などのクライアント側の Web テクノロジに依存します。 ページ (HTML) のコンテンツをレイアウトとスタイル (CSS) とその動作 (JavaScript 経由) から分離することで、複雑な Web アプリは懸念事項の分離の原則を活用できます。 これらの懸念が絡み合っていない場合、アプリケーションの構造、設計、または動作に対する将来の変更は、より簡単に行うことができます。

HTML と CSS は比較的安定していますが、JavaScript は、アプリケーション フレームワークとユーティリティを使用して、開発者が Web ベースのアプリケーションの構築に取り組み、ブレークネック速度で進化しています。 この章では、Web 開発者が JavaScript を使用するいくつかの方法について説明し、Angular および React クライアント側ライブラリの概要を説明します。

注

Blazor は、豊富な対話型クライアント ユーザー インターフェイスを構築するための JavaScript フレームワークの代替手段を提供します。

HTML

HTML は、Web ページと Web アプリケーションの作成に使用される標準的なマークアップ言語です。 その要素は、書式設定されたテキスト、画像、フォーム入力、およびその他の構造を表すページの構成要素を形成します。 ページまたはアプリケーションをフェッチするかどうかにかかわらず、ブラウザーが URL に対して要求を行うとき、最初に返されるのが HTML ドキュメントです。 この HTML ドキュメントでは、CSS 形式の外観とレイアウト、または JavaScript の形式での動作に関する追加情報を参照または含めることができます。

CSS

CSS (カスケード スタイル シート) は、HTML 要素の外観とレイアウトを制御するために使用されます。 CSS スタイルは、HTML 要素に直接適用することも、同じページで個別に定義することも、別のファイルで定義してページによって参照することもできます。 スタイルは、特定の HTML 要素の選択に使用される方法に基づいてカスケードされます。 たとえば、スタイルはドキュメント全体に適用される場合がありますが、特定の要素に適用されるスタイルによってオーバーライドされます。 同様に、要素固有のスタイルは、要素に適用された CSS クラスに適用されたスタイルによってオーバーライドされます。そのスタイルは、その要素の特定のインスタンスをターゲットとするスタイル (その ID を介して) によってオーバーライドされます。 図 6-1

CSS の特定の規則

図 6-1 CSS の特定の規則を順番に示します。

スタイルを独自の個別のスタイルシート ファイルに保持し、選択ベースのカスケードを使用して、一貫性のある再利用可能なスタイルをアプリケーション内に実装することをお勧めします。 HTML 内にスタイル ルールを配置することは避ける必要があり、(要素のクラス全体、または特定の CSS クラスが適用されている要素ではなく) 特定の個々の要素にスタイルを適用することは、ルールではなく例外である必要があります。

CSS プリプロセッサ

CSS スタイルシートでは、条件付きロジック、変数、およびその他のプログラミング言語機能がサポートされていません。 したがって、多くの場合、大きなスタイルシートには、同じ色、フォント、またはその他の設定が HTML 要素や CSS クラスのさまざまなバリエーションに適用されるため、かなりの繰り返しが含まれます。 CSS プリプロセッサは、変数とロジックのサポートを追加することで、スタイルシートが DRY 原則 に従うのに役立ちます。

最も一般的な CSS プリプロセッサは Sas と LESS です。 どちらも CSS を拡張し、下位互換性があります。つまり、プレーンな CSS ファイルは有効な Sass または LESS ファイルです。 Sass は Ruby ベースで、LESS は JavaScript ベースであり、どちらも通常、ローカル開発プロセスの一部として実行されます。 どちらもコマンド ライン ツールと、Gulp または Grunt タスクを使用して実行するための Visual Studio の組み込みサポートを備えています。

JavaScript

JavaScript は、ECMAScript 言語仕様で標準化された、動的で解釈されたプログラミング言語です。 Web のプログラミング言語です。 CSS と同様に、JavaScript は HTML 要素内の属性として、ページ内のスクリプトブロックとして、または別のファイルで定義できます。 CSS と同様に、JavaScript を個別のファイルに整理し、個々の Web ページまたはアプリケーション ビューで見つかった HTML から可能な限り分離しておくことをお勧めします。

Web アプリケーションで JavaScript を使用する場合、一般的に実行する必要があるタスクがいくつかあります。

  • HTML 要素を選択し、その値を取得または更新する。

  • Web API でデータのクエリを実行する。

  • Web API にコマンドを送信する (その結果を使用してコールバックに応答する)。

  • 検証の実行。

これらのタスクはすべて JavaScript だけで実行できますが、これらのタスクを簡単にするために多くのライブラリが存在します。 これらのライブラリの最初で最も成功したライブラリの 1 つは jQuery です。これは、Web ページ上でこれらのタスクを簡略化するための一般的な選択肢であり続けます。 シングル ページ アプリケーション (SPA) の場合、jQuery では Angular と React が提供する目的の機能の多くは提供されません。

jQuery を使用した従来の Web アプリ

JavaScript フレームワークの基準では古いとされる jQuery は、HTML/CSS を操作するためによく使用されるライブラリであり、また、AJAX を用いて Web API に呼び出しを行うアプリケーションの構築にも一般的に用いられています。 ただし、jQuery はブラウザー ドキュメント オブジェクト モデル (DOM) のレベルで動作し、既定では宣言型ではなく命令型モデルのみを提供します。

たとえば、テキスト ボックスの値が 10 を超える場合、ページ上の要素を表示する必要があるとします。 jQuery では、この機能は通常、テキスト ボックスの値を検査し、その値に基づいてターゲット要素の可視性を設定するコードを含むイベント ハンドラーを記述することによって実装されます。 このプロセスは、命令型のコードベースのアプローチです。 別のフレームワークでは、代わりにデータ バインドを使用して、要素の可視性を宣言によってテキスト ボックスの値にバインドする場合があります。 この方法では、コードを記述する必要はなく、代わりにデータ バインディング属性に関連する要素を修飾するだけで済みます。 クライアント側の動作が複雑になるにつれて、データ バインディングアプローチが頻繁に行われるので、コードと条件付きの複雑さが少ないソリューションが簡単になります。

jQuery と SPA フレームワーク

要素 jQuery 角度
DOM を抽象化します はい はい
AJAX サポート はい はい
宣言型データ バインディング いいえ はい
MVC スタイルのルーティング いいえ はい
テンプレート いいえ はい
ディープリンク ルーティング いいえ はい

jQueryに本質的に欠けている機能のほとんどは、他のライブラリを追加することで追加することができます。 ただし、Angular のような SPA フレームワークは、これらの機能を最初からすべて念頭に置いて設計されているため、より統合された方法で提供されます。 また、jQuery は命令型ライブラリです。つまり、jQuery を使用して何かを行うには jQuery 関数を呼び出す必要があります。 SPA フレームワークが提供する作業と機能の多くは宣言によって実行でき、実際のコードを記述する必要はありません。

データ バインディングは、この機能の優れた例です。 jQuery では、通常、DOM 要素の値を取得したり、要素の値を設定したりするコード行は 1 行だけです。 ただし、要素の値を変更する必要がある場合は、いつでもこのコードを記述する必要があります。また、これはページ上の複数の関数で発生することがあります。 もう 1 つの一般的な例は、要素の可視性です。 jQuery では、特定の要素が表示されたかどうかを制御するコードを記述するさまざまな場所がある場合があります。 いずれの場合も、データ バインディングを使用する場合は、コードを記述する必要はありません。 対象の要素の値または可視性をページ上の ビューモデル にバインドするだけで、そのビューモデルへの変更はバインドされた要素に自動的に反映されます。

Angular SPA

Angular は、世界で最も人気のある JavaScript フレームワークの 1 つです。 Angular 2 以降、チームは ( TypeScript を使用して) フレームワークを一から再構築し、元の AngularJS 名から Angular にブランド変更しました。 数年経った今でも、再設計された Angular は、シングル ページ アプリケーションを構築するための堅牢なフレームワークです。

Angular アプリケーションはコンポーネントから構築されます。 コンポーネントは、HTML テンプレートを特殊なオブジェクトと結合し、ページの一部を制御します。 Angular のドキュメントの単純なコンポーネントを次に示します。

import { Component } from '@angular/core';

@Component({
    selector: 'my-app',
    template: `<h1>Hello {{name}}</h1>`
})

export class AppComponent { name = 'Angular'; }

コンポーネントは、コンポーネントに関するメタデータを取り込む @Component デコレーター関数を使用して定義されます。 selector プロパティは、このコンポーネントが表示されるページ上の要素の ID を識別します。 テンプレート プロパティは、最後の行で定義されたコンポーネントの name プロパティに対応するプレースホルダーを含む単純な HTML テンプレートです。

コンポーネントとテンプレートを使用して操作することで、Angular アプリは、DOM 要素の代わりに利用し、通常の JavaScript ("vanilla JS" とも呼ばれます) や jQuery を用いて作られたアプリよりも、抽象化のレベルを高くし、少ないコードで機能を実現できます。 Angular では、クライアント側のスクリプト ファイルを整理する方法にも何らかの順序が課されます。 慣例により、Angular アプリは共通のフォルダー構造を使用し、モジュールとコンポーネントのスクリプト ファイルはアプリ フォルダーに配置されます。 アプリのビルド、デプロイ、テストに関連する Angular スクリプトは、通常、上位レベルのフォルダーに配置されます。

CLI を使用して Angular アプリを開発できます。 Angular の開発をローカルで開始する (git と npm が既にインストールされている場合) は、GitHub からリポジトリを複製し、 npm install と npm startを実行するだけで構成されます。 さらに、Angular には独自の CLI が付属しています。これにより、プロジェクトの作成、ファイルの追加、テスト、バンドル、デプロイのタスクを支援できます。 この CLI の使いやすさにより、Angular は特に ASP.NET Core と互換性があり、優れた CLI サポートも備えています。

Microsoft は、Angular SPA 実装を含む参照アプリケーション eShopOnContainers を開発しました。 このアプリには、オンライン ストアのショッピング バスケットの管理、カタログからのアイテムの読み込みと表示、注文作成の処理を行うための Angular モジュールが含まれています。 GitHub からサンプル アプリケーションを表示およびダウンロードできます。

反応する

完全なモデルView-Controller パターン実装を提供する Angular とは異なり、React はビューにのみ関係します。 フレームワークではなく、単なるライブラリであるため、SPA を構築するには、追加のライブラリを利用する必要があります。 React を使用してリッチ シングル ページ アプリケーションを生成するように設計されたライブラリは多数あります。

React の最も重要な機能の 1 つは、仮想 DOM の使用です。 仮想 DOM には、パフォーマンス (仮想 DOM は、更新する必要がある実際の DOM のどの部分を最適化できるか) やテスト容易性 (React とその仮想 DOM との対話をテストするためにブラウザーを用意する必要がない) など、いくつかの利点があります。

React は、HTML での動作も珍しい方法です。 コードとマークアップを厳密に分離するのではなく (JAVAScript への参照が HTML 属性に表示される可能性があります)、React は JAVAScript コード内に JSX として HTML を直接追加します。 JSX は、純粋な JavaScript にコンパイルできる HTML に似た構文です。 例えば次が挙げられます。

<ul>
{ authors.map(author =>
    <li key={author.id}>{author.name}</li>
)}
</ul>

JavaScript を既に知っている場合は、React を簡単に学習できます。 Angular やその他の一般的なライブラリほど多くの学習曲線や特別な構文はありません。

React は完全なフレームワークではないので、通常、他のライブラリでルーティング、Web API 呼び出し、依存関係管理などを処理する必要があります。 素晴らしい点は、これらのそれぞれに最適なライブラリを選択できることですが、欠点は、これらの決定をすべて行い、選択したすべてのライブラリが完了したらうまく連携することを確認する必要があることです。 適切な開始点が必要な場合は、React Slingshot などのスターター キットを使用できます。このキットでは、一連の互換性のあるライブラリを React と共に事前にパッケージ化します。

Vue

ファースト ステップ ガイドでは、「Vue は、ユーザー インターフェイスを構築するためのプログレッシブ フレームワークです。 他のモノリシック フレームワークとは異なり、Vue は段階的に導入できるようにゼロから設計されています。 コア ライブラリはビュー レイヤーのみに重点を置き、他のライブラリや既存のプロジェクトを簡単に選択して統合できます。 一方、Vueは、最新のツールやサポートライブラリと組み合わせて使用する場合、洗練された Single-Page アプリケーションに完全に電力を供給することができます。

Vue の使用を開始するには、HTML ファイル内にそのスクリプトを含める必要があります。

<!-- development version, includes helpful console warnings -->
<script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>

フレームワークを追加すると、Vue の単純なテンプレート構文を使用して、DOM にデータを宣言的にレンダリングできるようになります。

<div id="app">
  {{ message }}
</div>

次のスクリプトを追加します。

var app = new Vue({
  el: '#app',
  data: {
    message: 'Hello Vue!'
  }
})

これは、ページに "Hello Vue!" をレンダリングするのに十分です。 ただし、Vue は単にメッセージを div に 1 回レンダリングするだけではありません。 データ バインドと動的更新をサポートしているため、 message の値が変更されると、 <div> 内の値が直ちに更新されて反映されます。

もちろん、これはVueが可能なものの表面を傷つけるだけです。 ここ数年で大きな人気を集め、大規模なコミュニティを持っています。 Vue と連携してそれを拡張する サポート コンポーネントとライブラリの一覧は、膨大で増え続けています 。 Web アプリケーションにクライアント側の動作を追加する場合、または完全な SPA の構築を検討している場合は、Vue を調査する価値があります。

Blazor WebAssembly

他の JavaScript フレームワークとは異なり、 Blazor WebAssembly は、.NET を使用して対話型のクライアント側 Web アプリを構築するためのシングルページ アプリ (SPA) フレームワークです。 Blazor WebAssembly では、プラグインやコードを他の言語に再コンパイルすることなく、オープン Web 標準を使用します。 Blazor WebAssembly は、モバイル ブラウザーを含むすべての最新の Web ブラウザーで動作します。

Web ブラウザー内での .NET コードの実行は、WebAssembly (省略 wasm) によって可能になります。 WebAssembly は、ダウンロードを高速化し実行速度を最大限に高めるために最適化されたコンパクトなバイトコード形式です。 WebAssembly はオープンな Web 標準であり、プラグインのない Web ブラウザーでサポートされています。

WebAssembly コードは、JavaScript 相互運用性と呼ばれる JavaScript を介してブラウザーの全機能にアクセスできます。多くの場合、JavaScript 相互運用または JS 相互運用に短縮されます。 ブラウザーの WebAssembly 経由で実行される .NET コードは、ブラウザーの JavaScript サンドボックス内で実行されます。その際、クライアント コンピューター上での悪意のある操作に対して、サンドボックスに備わった保護が適用されます。

詳細については、「ASP.NET Core Blazorの概要」を参照してください。

SPA フレームワークの選択

SPA をサポートするのに最適なオプションを検討するときは、次の考慮事項に注意してください。

  • チームはフレームワークとその依存関係 (場合によっては TypeScript を含む) に精通していますか?

  • フレームワークはどのくらい意見が出ていて、その既定のやり方に同意しますか?

  • アプリに必要なすべての機能が含まれていますか (またはコンパニオン ライブラリ)。

  • それは十分に文書化されていますか?

  • そのコミュニティはどのくらい活発ですか? それを使って新しいプロジェクトが構築されているか。

  • コア チームのアクティブな状態はどのくらいですか? 問題は解決され、新しいバージョンは定期的に出荷されていますか?

フレームワークは、ブレークネック速度と共に進化し続けています。 上記の考慮事項を使用して、後で依存しているフレームワークを選択するリスクを軽減します。 特にリスクを嫌う場合は、商用サポートを提供するフレームワークや、大企業によって開発されているフレームワークを検討してください。

参照 – クライアント Web テクノロジ

前へ次へ