はじめに

株式会社GROWTH VERSEでフロントエンドの開発をしているシムです。この記事では、AIMSTARにおける汎用性の高い抽出条件設定機能の開発について紹介します。

抽出条件設定機能とは

弊社では、AIMSTARにおけるデータ分析の際に詳細な抽出条件設定機能を提供しています。抽出条件設定機能は、様々な環境と要求に対応するために頻繁な追加・削除・修正が可能な仕様となっています。

この拡張性と柔軟性は通常の開発方法では実現できないため、汎用性の高い構造としてFormLayoutParametersを採用することで、解決しました。

通常の開発方法との違い

FormLayoutParametersを用いることで、動的なコンテンツ生成が可能となります。ここでは、まず静的なコンテンツ生成と動的なコンテンツ生成を比較します。

静的なコンテンツ生成 VS 動的なコンテンツ生成

動的な文書生成は「テンプレートエンジン」と関連します。テンプレートエンジンとは、Webアプリケーション開発において静的なコンテンツを動的に生成するためのツールです。テンプレートとデータを組み合わせることで、最終的なコンテンツを生成します。

<!-- 静的なコンテンツ生成の場合 -->

<html>
<head>
    <title>Example</title>
</head>
<body>
    <div>1番目のdivです。</div>
    <div>2番目のdivです。</div>
    <div>3番目のdivです。</div>
    <div>4番目のdivです。</div>
    <div>5番目のdivです。</div>
</body>
</html>

<!-- 動的なコンテンツ生成の場合 -->

<html>
<head>
    <title>Example</title>
</head>
<body>
    <% for(var i=0; i<5; i++) { %>
        <div><%= i+1 %>番目のdivです。</div>
    <% } %>
</body>
</html>

上記は簡単な例ですが、テンプレートエンジンにより動的なコンテンツ生成を実現することで、コードの再利用性や保守性の向上に寄与します。これにより、開発速度が大幅に向上します。なお、ReactやVueのようなモダンなフロントエンドフレームワークもテンプレートエンジンの延長線上にあるといえます。

通常の開発方法 VS FormLayoutParameters

次に、FormLayoutParametersを通常の開発方法と比較します。

分析の抽出条件詳細設定機能は、変更頻度の高い複数の画面を持ちます。この機能の開発は、画面ごとで抽出処理を行うためのデータ構造を定義してコンポーネントを作成するような通常の開発方法でも進められます。しかし、頻繁な画面の変更に柔軟に対応することは困難です。

FormLayoutParametersを使うと、画面内の複数の入力コンポーネントを共通化して使用でき、柔軟に変更に対応できます。また、この特徴を実現するための流れは以下の通りです。

入力コンポーネントのデータ構造を定義する。（後述）
1. 共通項目を定義する。
2. インプットタイプとインプット値を定義する。
サーバーとのやり取りを定義する。（後述）
1. サーバー側で画面ごとに必要な入力コンポーネントのデータを保持する。
2. 画面の閲覧時にサーバーから必要な入力コンポーネントのデータを取得する。

※ 入力コンポーネントの変更時には、共通の入力コンポーネントとサーバー側のメタデータを編集する必要がある。

通常の開発方法 vs FormLayoutParametersのまとめ

	通常の開発方法	FormLayoutParameters
開発アプローチ	画面ごとに個別の実装	共通化されたコンポーネントによる実装
データ管理	画面ごとに別のデータの管理	コンポーネントのデータの共通管理画面ごとでパラメーターのみの管理
変更容易性	変更対応が困難	変更対応が柔軟に可能
一貫性	画面間での一貫性の維持が困難	画面間での一貫性の維持が容易

FormLayoutParametersの仕組み

FormLayoutParametersの仕組みについて説明します。重要な部分は入力コンポーネントのデータ構造の定義と、サーバーとのやり取りにあります。

入力コンポーネントのデータ構造

まず、入力コンポーネントの要素を定義します。これにより、サーバーとのデータ形式が決まります。

共通項目

すべての入力コンポーネントが共通で使用する情報を定義します。

タイトル（必須）
説明（任意）
インプットのラベル（任意）
対象アイテムの識別ID（必須）

インプットタイプとインプット値

入力コンポーネントで利用するインプットタイプとインプット値の型を定義します。

Radio：ラジオグループ（複数選択不可）
- 値：String
- 選択肢の値：Array<{Label: String; Value: String}>
Input：単一行の入力欄
- 値：String
Select：セレクトボックス
- 値：String
- 選択肢の値：Array<{Label: String; Value: String}>
Input + Select
- 値：Input + Select
Checkbox：チェックボックス（複数選択可能）
- 値：Array
- 選択肢の値：Array<{Label: String; Value: String}>
SQL：複数行のプレーンテキスト入力欄
- 値：String
- ※ 開発環境によって改行文字の扱いが異なる
Double Input：2つの単一行の入力欄
- 左のInputの値：String
- 右のInputの値：String
Double Input List：複数行のDouble Input
- 値：Array
Double Input Date：日付形式のテキスト入力欄
- 値：YYYYMMDD形式のString
- ※ 開発環境によって日付形式・書式が異なる

サーバーとのやり取り

定義した入力コンポーネントの情報を元にサーバーとのデータのやり取りを行います。

抽出条件の選択

まず、ユーザーが利用する抽出条件を選択します。

抽出条件の情報の取得

次に、選択された抽出条件に関しての以下の情報を取得します。

抽出条件のタイトル（必須）
抽出条件の説明（任意）
該当インプット情報リスト（必須）

FormLayoutParametersのメリット・デメリット

メリット

拡張性と柔軟性
- 動的なコンポーネント定義
  - FormLayoutParametersは入力コンポーネントを動的に定義できます。これにより、新しい変更に迅速に対応できます。
- テンプレートベースの設計
  - 画面に必要な入力コンポーネントをテンプレートのように定義して再利用でき、多様な入力形式を簡単に追加できます。
一貫性
- 共通コンポーネントの使用
  - すべての画面で共通の入力コンポーネントを使用することで、一貫したユーザー体験を提供します。これにより、メンテナンスと拡張が容易になります。
- 一元管理
  - サーバー側で入力コンポーネントを一元管理することで、画面間の一貫性を維持しやすくなります。
メンテナンス性
- コードの重複削減
  - 同じ入力形式を複数の画面で再利用することで、コードの重複を減らし、メンテナンス性を向上させます。
- 簡単な修正と追加
  - 入力コンポーネントの修正や追加が簡単になり、開発の生産性を向上させます。

デメリット

目的を見失う可能性
- 共通コンポーネントがない場合
  - 共通コンポーネントの利用が少なく、利用する画面の数が少ないか変更の可能性が低い場合、FormLayoutParametersの導入が不必要な複雑さを招く可能性があります。
初期設定の複雑さ
- 初期設定と定義作業が必要なため、簡単なプロジェクトや小規模なアプリケーションではオーバーヘッドになる可能性があります。
パフォーマンスのリスク:
- 追加のサーバーリクエスト
  - 画面のロード時にサーバーからコンポーネントデータを取得する必要があるため、追加のネットワークリクエストが発生する可能性があります。これはパフォーマンスの低下を招く可能性があります。
- 動的レンダリングの複雑さ
  - 動的にコンポーネントをレンダリングする過程で、クライアント側のレンダリングパフォーマンスが低下する可能性があります。特に、多数の動的コンポーネントを処理する場合、この問題が顕著になることがあります。