Skip to main content
OutSystems

コンポーネントの作成に関する完全ガイド

このトピックでは、OutSystemsでコンポーネントを作成するときに必要なすべての手順のガイドを提供します。推奨事項、ベストプラクティス、よくある状況に関する情報などを説明します。

はじめに

コンポーネントはローコードプラットフォームの最も重要な要素のひとつです。これにより、コードの再利用コンポーネントライブラリのリポジトリが可能になります。その結果、開発者が高品質なアプリコンポーネントを作成して他の開発者と共有することができ、アプリケーションの開発時間が短縮され、コードのフラグメント化を促進できます。

この記事にはコンパニオンチェックリストが含まれています。これを印刷していつでも参照できます。

コンポーネントとは

コンポーネントとは再利用可能なオブジェクトのことです。これを使用すると、アプリケーションの作成とデリバリーを高速化できます。コンポーネントは追加機能を提供するアプリケーションまたはモジュールです。コンポーネントは使いやすくて理解しやすく、主なユースケースや一般的なユースケースを対象にする必要があります。

コンポーネントを作成すると3つの成果が得られます。

  • コードをモジュール化し、アプリケーション内で再利用できます(Don't Repeat Yourself - DRY)。
  • 開発インフラのピースとなり、複数のアプリケーションで再利用できます。
  • Forgeにパブリッシュし、複数のアプリや開発者に提供できます。

優れたコンポーネントを作成するには、以下を行う必要があります。

  • 目的を決定する。
  • メインシナリオをサポートするAPIロジックを設計する。
  • 適切な名前とアイコンを設定するなど、表示を定義する。
  • 再利用とメンテナンスエクスペリエンスを向上させるためのベストプラクティスに従う。
  • パフォーマンス、セキュリティ、スケーラビリティなど、非機能要件を含めるようにする。
  • リリースを計画し、コンポーネントを公開する。

コンポーネントは、OutSystemsアプリケーションを構築するときに使用される4 Layer Canvasのアーキテクチャの方法論に適合することに留意します。

コンポーネントのタイプ

コンポーネントには5つのタイプがあります。

  • テーマ: テーマは、一連のスタイルシートルールや画面上の要素の位置とサイズの決定に使用されるグリッド定義によって、アプリケーションのルックアンドフィールを定義します。よい例として、DublinテーマなどのSilk UIテーマがあります。
  • ウィジェット/ブロック: ウィジェットやブロックは、通常はUIやイベントに関連する追加機能や再利用機能を提供する独立したコンポーネントです。Cropperウィジェットなどがあります。ブロックがコンポーネントになるには、パラメータなどの一連の定義と変数が必要です。ブロックのプロパティの詳細については、ブロックのプロパティをご覧ください。
  • ライブラリ: JavaScriptライブラリとは、開発を容易にするために事前に記述されたJavaScriptのライブラリのことです。例として、Google Mapsライブラリがあります。これらのライブラリには、操作しやすいインターフェイスを提供するブロックやアクションが含まれています。JavaScriptのプロパティの詳細についてはJavaScriptのプロパティをご覧ください。
  • コネクタ: コネクタを使用すると、カスタムコードを記述することなく、連携できるようになるため、時間と労力を大幅に削減しながらエラーを排除できます。基本的に、コネクタはFacebookPaypalなどの他のアプリケーションとの統合を可能にするものです。
  • プラグイン: プラグインは、Apache Cordovaプラグインのラッパーとして機能するアプリケーションモジュールです。プラグインで使用されているApache Cordovaに応じて、iOSとAndroidの両方またはそのいずれかに対応するネイティブモバイル機能の使用をサポートできます。OutSystemsが提供するサポート対象プラグインの一覧をご覧ください。

コンポーネントの作成: 検討

コンポーネントの作成を開始する前に、コンポーネントについて検討する必要があります。コンポーネントに求めることは何か。コンポーネントにどのようなオプションを含めるか。そのまますぐに使用できるデフォルトの動作をどのようにするか。最も重要なユースケースは何か。コンポーネントはこれらをどのように提供するか。

通常、コンポーネントはブロックおよびアクションのセットであり、モジュールやアプリケーションとして分散している必要があります。たとえば、独自コードをモジュール化する場合、コンポーネントは新しいブロックとなる可能性が高いです。しかし、共通ライブラリ化を計画している場合やコンポーネントを一般公開する場合、コンポーネントはアプリケーション内にモジュールとして含めます。

ロジックのみを含むコンポーネントを作成する場合、空のモジュールを作成してUIの依存関係が含まれないようにすることを検討してください。このようにするとコンポーネントに追加の依存関係が含まれず、軽量で再利用しやすくなります。

一方、コンポーネントにUI要素を含める場合は、テンプレートを使用してモジュールの作成を開始してください。こうすることで、その目的に対して最適化されたストラクチャが提供されます。

最初からうまく構築できるシナリオを検討してください。

コンポーネントの作成: 構築

コンポーネントの目的を定義した後、関連するUI要素、アクション、ロジックを定義し、コンポーネントの構築を開始できます。

最適なオプションを提供するためのAPI設計

優れた車を所有していても、乗り方を知らなければ無駄になります。これはコンポーネントについても同様です。実装する際には、開発者の経験とスキルセットを考慮します。たとえば、以下のような点に注意します。

  • APIは小さくシンプルでわかりやすくします。たとえば、位置指定は360度によって入力せずに、単純に上下左右によって入力にするようにします。
  • APIは主なユースケースを対象とし、最適なデフォルト設定にします。他のオプションは、拡張メカニズムを通じて提供されます。
  • コンポーネントのデフォルト動作として本当に必要なもののみに入力の数を限定することを検討します。

入力をほとんど追加せずにコンポーネントの構成オプションを拡張する方法のひとつとして、すべての拡張オプションをJSONとして受け取る入力を1つだけ追加する方法があります。利用可能なJSONオプションを入力とコンポーネントの両方の説明に記載するようにします。

高度なシナリオが多数ある場合は、それらの拡張オプションに特化した説明ページの作成を検討します。コンポーネントをForgeにパブリッシュする場合、これによって[Try Now]オプションを提供できます。

CSSおよびJavaScript

スタイルクラスを使用してカスタマイズを簡素化する

Style Classesプロパティの式を活用するようにします。これにより、style属性を使用する代わりにclass属性を変更するコードが生成され、DOMの不要なデータを避けることができ、カスタマイズが簡素化されます。静的であっても条件付きのものはすべてCSSクラスにすることができるため、動的なスタイルがある場合にのみインラインスタイル属性を使用するように留意します。また、その点についてコメントを残して説明することも検討します。

CSSセレクタを使用して再利用性を高める

CSSセレクタでクラスのみを使用すると、参照できるコンポーネントのインスタンスが1つだけになり、同一画面での複数利用が制限されるため、コンポーネントの再利用性が限定されます。クラスのみを使用する代わりに、コンポーネントの特定のインスタンスに関連するCSSセレクタを作成するには、以下の手順を実行します。

  1. ラッパーdivを追加し、Nameプロパティを追加します。
  2. セレクタを使用するJavaScriptノードを含めるアクションで、入力パラメータを追加し、それをMyBlockWrapperの要素IDとして設定します。
  3. 入力として渡したIDに関連するCSSクラスでセレクタを作成します。この例では、CSSクラスが存在する要素はラッパー要素の子ですが、同じ要素である場合もあります。

制限とカスタマイズのバランスをとる

コード、特にCSSとJavaScriptを記述する場合は、開発者を制限しないように注意します。コンポーネントのUI要素がUX要素を変更される可能性を考慮します。

  • !important CSSタグは避けます。これが適切な選択である場合もありますが、開発者のカスタムCSSを上書きしてカスタマイズを制限することになるため、コンポーネントで使用することは望ましくない場合があります。
  • 簡単に上書きできないため、色やボタンを設定することも避けます。アクションをトリガーするボタンなどのUI要素がある場合、これらをプレースホルダに置き換えて、開発者が独自のUI要素を追加し、実行するアクションやロジックを決定できるようにすることを検討します。

拡張性を考慮して作成する

コンポーネントのAPIを設計する際は、開発者が機能を拡張するためのメカニズムが十分に備わっているかを検討します。たとえば、JavaScriptオブジェクトを作成したコンポーネントには、それらのオブジェクトへのアクセスを提供する機能が必要になります。そうすることで、開発者は、別の機能をラップするコンポーネントを作成する機能を追加できます

ライフサイクルイベントを適切に使用する(モバイルのみ)

画面やブロックのデータや動作を制御するうえで、コンポーネントの開発中に画面やブロックのライフサイクルを理解することは非常に重要です。変数のデフォルト値を定義するか、無関係になるデータを削除します。ライフサイクル動作をよく知ることで、問題の予測パフォーマンスの最適化が可能になります。

詳細については、「画面とブロックのライフサイクルイベント」のドキュメントをご覧ください。以下では、コンポーネントとの関連性が高いイベントについて説明します。

OnInitializeを使用して変数のデフォルト値を定義する

デフォルト値がFalseのブーリアン型のローカル変数を含む画面があるとします。画面ロジックが実行されると、値がTrueに変化して別の画面に移動します。実行時、変数の値(モデルとして定義)が保存されるため、戻るナビゲーション(前画面ナビゲーション)がある場合は値を復元できます。

このナビゲーションの後、変数はTrueになりますが、画面の状態をリセットする必要がある場合があります。そのため、デフォルト値がある変数を使用する場合は常にこれらのナビゲーションシナリオを考慮し、必要に応じてOnInitializeイベントハンドラでデフォルト値を割り当てます。

OnDestroyを使用してメモリリークを避ける

一部のコンポーネントは、使用中にグローバル変数、イベントリスナー、その他のデータを作成します。OnDestroyイベントでそのデータを削除することを検討します。

OnRenderによる描画とデータ変更

コンポーネントにUIが含まれる場合、OnRenderイベントも重要です。このイベントは画面やブロックの描画のたびに実行されます。たとえば、画面のデータが変更されるたびに実行されます。

コンポーネントの作成: 表示

コンポーネントの作成において重要なのは、再利用できることとシンプルであることです。コンポーネントはわかりやすく、主なユースケースを対象にする必要があります。名前説明アイコンなどの視覚的な手掛かりは、コンポーネントの目的や使い方をわかりやすくするための基本要素です。

名前および説明

名前と説明は、ユーザーがコンポーネントの目的や使用方法を理解するのに役立ちます。名前は、コンポーネントの目的を明確に示すものである必要があります。コンポーネントは、ユーザー向けに前もって包括的かつ簡潔な説明を提供する必要があります。

コンポーネントの概要を包括的なものにするには、ライブラリURL、APIバージョン、外部リソースへの参照などの項目を説明に含める必要があります。

特に、以下の命名規則に留意します。

  • 意味のある名前を使用する(例: 「Cppr」ではなく「Cropper」)。
  • パスカルケースを使用する(例: 「Firebasereceiver」ではなく「FirebaseReceiver」)。
  • 「On」で始まるイベント名を使用する(例: 「Ready」ではなく「OnReady」)。

OutSystemsの命名規則の一覧をご覧ください。

Good example of icon, name and description.

Bad example of icon, name and description.

説明によって開発中に視覚的な手掛かりを提供し、開発エクスペリエンスを高めることができます。以下に例を示します。

  • アプリケーションの依存関係の上にマウスポインタを重ねると、その説明を表示します。
  • Manage Dependencies]ポップアップウィンドウ内にマウスポインタを重ねると、モジュールの説明を確認できます。
  • 検索ボックスでは、名前と説明を検索できます。なお、左側のツールボックスにはアイコン付きのコンポーネントのみが表示されます。

視覚的参照のためのアイコン

ビジュアルプログラミング環境にはグラフィック要素やアイコン要素が含まれ、これらをインタラクティブに使用します。アイコンは、開発者が開発環境で実際に見るものであるため重要です。

最初の留意点は、コンポーネントを識別できる画像を使用するということです。たとえば、FirebaseコネクタはFirebase社のロゴがアイコンになっています。

2つ目に重要な点は、アプリケーションレベルからアクションレベルまで一貫して同じ画像を使用するべきであるということです。これによって一貫性が保たれ、開発者がすべてのコンポーネントを容易に識別できるようになります。

アプリケーションアイコン

アプリケーションアイコンを設定すると、コンポーネントのメインアイコンが定義されます。ユーザーは、このアイコンを持つものすべてをそのコンポーネントに関連付けます。アプリケーションアイコンは、コンポーネントとその参照のすべてにわたって表示されます。たとえば、コンポーネントのドキュメント内でも使用されます。

アプリケーションアイコンは.png形式で透明化し、サイズは1,024 x 1,024pxにする必要があります。ファイルが大きいと画面の読み込みが低速になるため、ファイルサイズに留意します。

モジュールアイコン

モジュールにアイコンを設定すると、開発者が[Manage Dependencies]ウィンドウでモジュールをアプリケーションに関連付けることができます。 
モジュールアイコンのサイズは、1,024 x 1,024pxにする必要があります。

ブロックアイコン

ブロックのアイコンを設定すると、UI要素が属するコンポーネントが識別しやすくなります。そのため、要素を検索するときに、コンポーネントに関連するブロックをすぐに確認できます。
ブロックアイコン(.ico形式)のサイズは、32 x 32pxにする必要があります。

アクションアイコン

アクションにアイコンを設定すると、フロー内のアクションが属するコンポーネントが識別しやすくなります。

クライアントアクションおよびサーバーアクションアイコン

Service Studioではクライアントアクションとサーバーアクションが視覚的に区別されています。この視覚的な手掛かりによって、ユーザーはアクションのコンテキストだけではなく関連スコープも把握できます。

たとえば、オフラインアプリケーションのクライアント側フォームで作業を行っているときに、クライアント側の検証を使用し、サーバーアクションを避ける必要がある場合があります。該当する場合はできる限り、コンポーネントはこの区別に従う必要があります。

クライアントアクションとサーバーアクションを両方実装する場合は、同じアイコンでスタイルを変更して使用することを検討します。OutSystemsでは、クライアントアクション用とサーバーアクション用のデフォルトアイコンがすでに用意されています。これらを変更する場合、サイズは32 x 32pxにする必要があります。

開発者エクスペリエンスを向上する

適切なプレビューを構成する

開発者エクスペリエンスを向上するには、Service Studio内で適切なプレビューを行うことが重要です。UI要素には、アプリケーション開発時に避けるべき特定のスタイルが含まれているケースがよくあります。このため、実行できる改善項目をプレビューできるようになっています。

False条件を使用してプレビューを向上する

条件としてIfウィジェットでFalseを使用すると、サイドパネルやバーなどのUIの領域の大部分を占めるプレースホルダを非表示にできる使いやすいUIが表示されます。
また、これを使用して実行時UIを置き換える画像を表示したり、JavaScriptによって生成されるチャートやイベントを反映するプラグインブロックなどのUIを含まないコンポーネントにUIを追加したりすることができます。

以下に示すSilk UI Mobile FloatingActionsパターンの例をご覧ください。この目的は、展開時に追加オプションが表示されるクリック可能な円を提供することです。

If False condition

servicestudio CSSタグを使用して開発環境を向上する

-servicestudio-というプレフィックス付きのCSSプロパティを使用してプレビューを改善することで、開発エクスペリエンスを向上させることができます。これにより、開発時にレイアウト調整が可能になります。たとえば、位置を「absolute」にして固定したいプレースホルダがある場合、開発者はコメントを追加できます。エディタはすべてのCSS命令を実行するため、エディタから要素にアクセスできなくなることがあります。

-servicestudio-タグを使用することにより、開発者は他の機能を犠牲にすることなく値を設定できます。

プレースホルダ内のサンプルコンテンツ

プレースホルダが動作やストラクチャに直結している場合、サンプルコンテンツを含める必要があります。これにより開発者は、そのプレースホルダ内で想定されるコンポーネントがわかるようになります。たとえば、Silk UI SearchブロックとAnimatedLabelブロックは、いずれも入力がないと適切に動作しないため、入力サンプルを用意します。

テキストや画像などの簡単な要素のサンプルコンテンツは使用しないようにします。開発者にとってこれらを削除する手間が増えるだけです。必須である場合や開発者に役立つ場合にのみ、サンプルコンテンツを追加します。

 

コンポーネントのメンテナンス

コードは整理しておく必要があります。これは、数か月後に見直したり、他の開発者が再利用したりしやすくするために重要です。Forgeにパブリッシュする場合、他のユーザーが理解して同じコードで作業できるようにすることは必須です。

バージョン間のコード変更にコメントを付けると、変更内容や変更理由がわかりやすくなります。

注記およびコメント

コンポーネントのロジック関連のコードが明確ではない場合、その目的を説明するコメントや注記を追加する必要があります。これは、他の開発者がコードを追跡したり改善したりできるようにするために不可欠です。しかし、それほど複雑ではない場合であっても、わかりやすいコードにするため、常に簡単なラベルを追加するようにします。

以下に示すJavaScriptノードや複雑な割り当ての例をご覧ください。

多様な考え方を持つユーザーを想定して、式エディタのコメントを使用するべきです。複雑なコードの説明だけではなく、概要のコメントも残します。これは、JavaScriptの知識が乏しい開発者がJavaScriptノードの裏側にある機能を理解したいときに役立ちます。

非機能要件

スケーラビリティ

将来を見据えた構築を心がけます。そのためには、コンポーネントが同一画面で複数ブロックをサポートできるようにします。

また、同時実行シナリオを検討します。OutSystemsではすでに、バックグラウンドで各ブロックが分離されたままにすることでこれをサポートしていますが、ユーザーがトリガーするアクションに注意する必要があります。たとえば、ボタンを高速で何度もクリックすると、複数のサーバー呼び出しがトリガーされます。

コンポーネントでデータを取得する場合、開発者がコンポーネントでデータを取得するのではなく、(画面などの)コンポーネント外でデータを取得し、そのデータを(コンポーネントへの)入力パラメータとして提供できるようにすることを検討します。

外部リソース(外部ライブラリやJSONファイルなど)を使用する場合、これらを再取得する代わりに再利用することを検討します。たとえば、システムのRequireScriptアクションでは、リクエスト済みの場合はキャッシュファイルを使用します。

特定の要件に応じてスケーラビリティを調整する方法については、OutSystemsにおけるスケーラビリティの処理に関する詳しい説明をご覧ください。

セキュリティ

セキュリティに関しては、あらゆるデバイスにセキュリティ侵害が発生しうるということを考慮する必要があります。そのため、常にデータの安全性の保持に努めるようにします。

クライアント側にあるものはすべてアクセス可能で脆弱性が高いため、機密データが保護されていることを確認する必要があります。データを暗号化するには、このプラグインを使用します。

サーバー側の通信については、サーバー側の検証(特に権限ロール)を実装して、通信の安全性を確保する必要があります。

可能な限り、画面、ページ、統合でHTTPSセキュリティを適用します。

モバイルアプリとWebアプリのライフサイクル全体を通じたデータの安全性の確保については、ビルド済み機能を使用したOutSystemsにおけるセキュリティの処理に関する詳しい説明をご覧ください。

パフォーマンス

OutSystemsでは、設計時の検証によってパフォーマンスのボトルネックがないようにします。アプリケーションにソースコードを生成する際、OutSystemsはすべてのアプリケーションレイヤーでコードのパフォーマンスを最適化します。

さらに、より多くのサンプルレコードでコンポーネントを十分にテストします。できるだけ現実に近いシナリオを設定し、起こりそうな条件でコンポーネントをテストします。

さらに、レコード数や条件のピークを検討し、数千人規模の同時ユーザーによるシナリオをテストしします。コンポーネントがサーバーに接続する場合、パフォーマンスに影響を及ぼすことがあります。

コンポーネントをパブリッシュする

他の開発者にも役立つと考えられるコンポーネントは、パブリッシュすることを検討します。

Forgeはコンポーネント、ライブラリ、コネクタのリポジトリです。アプリケーションで再利用可能な既存のモジュールを提供し、デリバリーを高速化します。

ライセンスに関しては、ForgeのコンポーネントはBSDライセンスの下で配布されています。ただし、一部のコンポーネントやプラグインには異なるライセンスモデルがあり、アプリの帰属などの要件が異なる場合があります。詳細については、サードパーティライセンス要件への準拠をご覧ください。

詳細については、コミュニティが作成したコンポーネントを使用する方法をご覧ください。

デモモジュール

コンポーネントのパブリッシュに向けて、新しいモジュールを1つアプリケーションに追加し、よく使用されるユースケースのデモを含めます。ユーザーはコンポーネントの名前で検索するため、コンポーネントの名前には「Demo」または「Example」と付けるようにします。

このデモはガイド付きわかりやすいものにし、できるだけ単一画面または中央画面を使用し、ログインなしで使用できるようにします。

Forgeでのパブリッシュ

コンポーネントが準備できたら、以下の手順を実行してForgeパブリッシュします。

  1. 依存関係を管理して未使用の要素をすべて削除し、eSpaceモジュール(.oml)が最終的に大きくなりすぎないようにします。大きすぎる場合は、使用している画像ファイルやリソースの圧縮を検討します。
  2. Service Centerに移動し、コンポーネントをダウンロードします。
    コンポーネントは、アプリケーション(.osp)またはモジュール/eSpace(.oml)としてダウンロードできます。可能な限り、アプリケーションとしてダウンロードするようにします。ただし、ForgeではeSpace形式もサポートしています。
  3. Forgeにログインし、[Publish New Project]をクリックします。
  4. 手順1でダウンロードしたコンポーネントのファイルを選択します。依存関係に関する警告が表示される場合があります。
  5. 引き続き、コンポーネントの詳細を編集します。デフォルトでは、名前アイコン説明はコンポーネントの開発中に定義したものになります。これらの説明は、パブリッシュ後も変更できます。
  6. コンポーネントの機能、主なユースケース、動作を最も適切に説明する画像を追加します。アプリケーションのスクリーンショット(サイズは500/600 x 280px)を選択します。
  7. Preview URL]に、[Try Now]オプションを提供するURLを入力します。このURLはサンプル、デモ、チュートリアル画面のいずれかにリンクし、ダウンロード可能なモジュール内で提供することもできます。このリンクは、個人向け環境などのパブリックサーバーでホストする必要があります。
  8. コンポーネントの内容に最も合致するカテゴリを1つ以上選択します。このカテゴリによりユーザーがコンポーネントを探しやすくなります。
  9. プロジェクトバージョンを入力します。番号が一意になるように留意します。番号はForgeから提示されますが、変更できます。この番号はコンポーネントのバージョンに表示されるため、新しいバージョンを更新するごとに割り当てる番号を増やしていき、どれが最新バージョンであるかが簡単にわかるようにします。
  10. Stable]チェックボックスは、未完成または未テストのプロジェクトを許可する際に使用します。ただし、コンポーネントが完成し、すべての機能の実装とテストが完了し、最適なパフォーマンスで動作するようになったら、他のユーザーに通知して[Stable]チェックボックスを選択する必要があります。
  11. Requirementsの下に、Forgeが提案するプラットフォームバージョンが示されます。さらに、サポートされるデータベースサポートされるスタックを選択します。ユーザーはこれを使用して、コンポーネントをダウンロードして使用するための条件をすべて満たしているかどうかを確認できます。
  12. 関連するタグを追加します。ユーザーは、タグを使用してコンポーネントを検索したり、パブリッシュされているコンポーネントをフィルタリングしたりすることができます。
  13. コンポーネントの詳細な説明を入力します。コンポーネントの機能とオプションを十分に説明するようにします。前述のベストプラクティスに従うことを検討します。説明が明確になるようにし、ユースケースや動作について説明します。
  14. Publish]をクリックして完了します。

最新の状態を保つ

これらのガイドラインに従うことで、多くのユーザーがコンポーネントを使い始めるでしょう。開発者にはコンポーネントの所有者としての責任があり、コンポーネントの機能や実装に関する問い合わせが寄せられることがあります。その場合は、サポートに全力を尽くしてください。対応する時間やコンポーネントの反復開発を行う時間がない場合は、ユーザーを招待してチームに加えることを検討します。

OutSystemsの新しいバージョンがリリースされることもあります。多くの場合、これらのリリースによって新しい機能が導入されます。新しいプラットフォームリリースにアップグレードして新しい機能を利用し、コンポーネントを最新の状態に保つようにしてください。

 

  • Was this article helpful?