---
title: "JSSを扱う際のベストプラクティス"
slug: "best-practices-when-working-with-jss"
abstract: "JSSアプリの開発・展開やサーバー側レンダリング対応アプリケーション開発時のベストプラクティス"
---
# JSSを扱う際のベストプラクティス

JSSアプリケーションは通常のJavaScriptアプリケーションには対応できないユースケースをサポートしなければなりません。したがって、JSSアプリケーションを開発する際には、JSSアプリケーションが期待される機能を安全に提供するために、いくつかのベストプラクティスに従う必要があります。

## 一般的な開発のベストプラクティス

JSSアプリケーションを開発する際は、レイアウト、コンテンツ、ルートに対するコンテンツ作成者のコントロール権を保持しなければなりません。

### ハードコーディングレイアウトは避けましょう

コンテンツオーサー管理に対応したアプリを作るには、コンポーネント階層やテキストや画像などの非コードコンテンツのハードコーディングを避ける必要があります。代わりに、コンポーネント内のJSSパッケージのコンポーネントを使用してください。これにより、コンテンツ作成者が生成した動的なデータがコンポーネントに提供されます。

コンポーネントのネストを明示的にハードコーディングしないでください。代わりに、JSSライブラリの <Placeholder> コンポーネントを使って、コンテンツ作成者が他のコンポーネントをネストできるバスケットを作成しましょう。

> !ヒントこの推薦の申請を検証するには、Experience Editorが期待通りに動作しているか確認してください。コンテンツ作成者は、レンダリングを挿入できる必要があります。レンダリングを削除し、移動できます。

### ハードコーディングフィールドは避けてください

もしコンポーネントにコンテンツ作成者が制御しなければならない値がある場合は、JSSライブラリから関連するフィールドコンポーネント( TextやImageなど)をインポートし、それらの値の代わりにこれらのコンポーネントを使用してください。フィールド値をハードコードしたり、他の方法で注入したりしてはいけません。

> !ヒントこの推奨の申請を検証するには、Experience Editorが期待通りに動作しているか確認してください。コンテンツ作成者はすべてのデータソースフィールドをインラインで編集できなければなりません。

### 作成要件について問い合わせてください

Sitecoreは、強力なマーケティング機能を備えた複雑なアプリケーションを構築するためのツールのコレクションです。

Sitecoreサイトが構築された後、Sitecoreはユーザー向けに様々なツールや統合を提供し、エンドユーザーのウェブサイト *体験* を分析、育成、パーソナライズします。Sitecoreサイト、ひいてはJSSアプリの主要なクライアントは、マーケター、Sitecore管理者、コンテンツ作成者です。開発者として、これらのクライアントのビジネス要件を満たすJSSアプリを構築しなければなりません。つまり、JSSアプリはSitecoreのオーサリングインターフェースとの互換性を維持し、サイトやコンテンツ管理能力を制限する技術的な制限を導入しないようにしなければなりません。

### 作者が管理するカスタムルートのサポートを保持する

Sitecoreでは、コンテンツ作成者は希望するURL構造に基づいてコンテンツツリーを整理することで各ページのURLを制御できます。JSSアプリはこの機能を完全にサポートすることが期待されています。JSSアプリはコンテンツ作成者が制御するURL構造をサポートする [カスタムルーティング](https://doc.sitecore.com/xp/ja/developers/hd/21/sitecore-headless-development/route-handling-and-data-fetching-in-jss-apps.html "Route handling and data fetching in JSS apps") を実装しています。

## サーバー側レンダリングと互換性のあるアプリケーション開発

サーバーサイド環境にはクライアントサイドアプリケーションにはない制限があります。コンテンツ作成者がグラフィカルユーザーインターフェースでコンポーネントを編集できるように、オーサリング環境との互換性を維持するために、本番ビルドがクライアント側レンダリングを使っていても、SSR互換のJSSコンポーネントを構築することを推奨します。

ご希望のフレームワークのSSRガイドやベストプラクティス、さらにJSSアプリで使用するサードパーティライブラリのSSR互換性に関する推奨事項に従うことを強くお勧めします。

### ブラウザ固有のオブジェクトは避けてください

SSR互換性を維持するために、以下のようなブラウザ固有のオブジェクトの使用を排除します。

-   window.
-   document.
-   localStorage.
-   sessionStorage.

これらのブラウザ固有のオブジェクトを使用する必要がある場合は、コードを条件文でラップして現在の実行コンテキストを確認するか、SSR中に起動しないライフサイクルメソッドに配置してください。

JSSには、アプリが現在レンダリングされているかどうかをNode.jsコンテキストで確認するためのユーティリティ機能isServer() があります。コントロールフローと組み合わせてSSRコンテキストを扱うこともできます。例えば:

import { isServer } from ‘@sitecore-jss/sitecore-jss’;

fetch('https://some-url', { options }).catch((error) => {
 if (isServer()) {
 // use Node's global console object to log the error
 console.error('Error:', error);
 } else {
 // Notify the user about the error. Note: this is for code demonstration only;
 // this is not an attractive way to show errors to end-users
 window.alert('An error has occurred.');
 }
});

### 第三者依存関係の検証

プロジェクトでサードパーティ依存関係を使う場合、SSRをサポートするための追加設定やミドルウェアが必要になるかもしれません。

SSRの互換性についてはドキュメントを確認してください。初期化オプション、レンダリング時間パラメータ、SSR特有のビルド構成など、特別な点がないか確認してください。

注意すべき一般的な依存関係は以下の通りです:

-   AxiosやSWRのようなデータ取得ライブラリ。
-   状態管理ライブラリ。例えば、ReduxやVuexなどです。
-   GraphQLのデータグラフ実装、例えばApolloなど。
-   ルーティングライブラリ(react-router、 vue-router)。
-   CSS in-JSライブラリ、例えば styled-components や emotion。
-   ドキュメントヘッドマネージャーライブラリ( react-helmet.
-   動的に負荷がかかるコンポーネント。例えば、 react-loadable。

## 配備とセキュリティ

JSSアプリケーションのデプロイ手順は [、開発ワークフロー](https://doc.sitecore.com/xp/ja/developers/hd/21/sitecore-headless-development/development-workflows.html "Development workflows")によって異なります。

本番環境では、ほとんどのアプリが[Sitecoreファースト](https://doc.sitecore.com/xp/ja/developers/hd/21/sitecore-headless-development/sitecore-first-development-workflow.html "Sitecore-first development workflow")ワークフローを使用しています。

Sitecoreファーストのワークフローでは、以下のSitecore DevOpsのベストプラクティスが適用されます。

-   繰り返し可能で完全自動化された展開プロセスを持つこと。
-   UnicornやTDSのようなアイテムシリアライゼーションツールを使って、開発者所有のSitecoreアイテム(テンプレート、レンダリングなど)をソース管理し、JSSサイトのものも含めてデプロイしてください。

特にJSSに関しては、以下の点も推奨しています:

-   SitecoreのバックエンドコードとJSSサイトコードを同じソース管理リポジトリに保存することで、フロントエンドとバックエンド間の変更同期の問題を避け、開発者が簡単にコミット、テスト、変更を差し戻せるようにしましょう。これにより、CIビルド時にJSSサイトの成果物をSitecoreにビルド・デプロイしやすくなります。
-   SitecoreのアップデートとJSSのサイトアップデートをヘッドレスモードで単一のビルドプロセスに自動化し、フロントエンドとバックエンドの異なるバージョンをデプロイした際に生じる欠陥を回避します。
-   JSS接続情報や展開情報をデプロイ変数に格納できるようにするには、[jss setupコマンドでいくつかのオプション](https://doc.sitecore.com/xp/ja/developers/hd/21/sitecore-headless-development/sitecore-javascript-rendering-sdk-cli-tools-api-reference.html "Sitecore JavaScript Rendering SDK CLI Tools API reference")を使用できます。

> !ヒントグローバルnpmパッケージをインストールできない環境でjss CLIコマンドを実行する場合、代わりにnpm run jss commandを使うと、CLIコマンドがnpmにアリアス化されます。
> 
> 実行するコマンドの引数の前に \-- を使npm。例えば、npm run jss deploy items -- --skipPackage

### 輸入サービス

[インポートサービス](https://doc.sitecore.com/xp/ja/developers/hd/21/sitecore-headless-development/import-service.html "Import Service")は、コード優先のSitecoreアイテムアーティファクトをSitecoreにデプロイし、またSitecore優先の開発者スキャフォールディングにも使われます。このサービスは[Sitecoreヘッドレスサービス](https://doc.sitecore.com/xp/ja/developers/hd/21/sitecore-headless-development/sitecore-headless-services.html "Sitecore Headless Services")をインストールすると自動的にインストールされます。

-   展開サービスは認証に共有秘密を使用します。これらは環境ごとに一意で、 *ランダム生成* (パスフレーズなし)、かつ少なくとも32文字でなければなりません。共有秘密はHMACを使用し、パッケージが展開される要素として利用されるため、パッケージが改ざんされていないことを示す署名検証があり、共有秘密が有線経由で送信されることは決してありません。
-   シグネチャ検証があっても、インポートサービスを含むすべてのSitecore HTTPサービスはTLSで保護されたチャネル上で実行することを強く推奨します。
-   インポートサービスは、Sitecoreサーバーの役割がローカル開発や本番環境でContentManagementされないStandalone、自動的に無効化されます。公開サーバーではJSSアプリのインポートは自動的に許可されていません。
-   インポートサービスにIPホワイトリストを展開したい場合は、ネットワークレベルで行うことができます。