最近、開発の状況は変化し、これまで以上に実装が容易になったようだ。 Mendix ウィジェットを通して バイブコーディング魅力は抜群です。ただ座ってリラックスし、AIにコードを生成してもらうだけです。少し試行錯誤すれば、実際に動作するウィジェットときちんとしたUIが完成するかもしれません。とても素敵だと思いませんか？

しかし、この一見シンプルに見えるものは、誤解を招く可能性があります。AIは初期のスキャフォールディングを加速させるのは間違いありませんが、重要な真実が一つあります。それは、システムを理解する必要があるということです。この基礎的な理解がなければ、AIが生成したコードだけに頼ることは、根本原理を真に理解することなく、Stack Overflowから解決策を盲目的にコピーするのと同じような状況に陥りかねません。

ウィジェットの開発 Mendix 独自の課題が伴い、開発プロセスとアプリケーションの長期的な成功の両方に影響を与える、慎重な意思決定が求められます。適切なアーキテクチャの選択からデータの処理、パフォーマンスの最適化に至るまで、それぞれの意思決定にはトレードオフが伴います。

利用可能な様々なアプローチを検討し、その影響を理解することで、より情報に基づいた選択を行い、強力かつ拡張性の高いウィジェットを作成できます。 Mendix ウィジェットの開発。

ウィジェットアーキテクチャ – 正しい選択をする

ウィジェットを構築する場合 Mendix最適なアプローチを決定するには、まずアーキテクチャの決定から始めましょう。選択肢はウィジェットの複雑さに大きく依存するため、以下の点を考慮する必要があります。

• ウィジェットと Mendix コンポーネント
• コンテナウィジェット
• 複数のウィジェット
• ローダーウィジェットアプローチ

最初に思いつくアプローチは、コンポーネント全体に対して1つのウィジェットを作成することです。これは基本的なコンポーネントであれば簡単ですが、コンポーネントが複雑で複数のインタラクティブなアクションが含まれる場合は、より困難になります。

これを やることリスト ウィジェットを例に挙げて、同じウィジェットを実装するための3つの異なるアプローチについて説明します。

アプローチ1: リストコンテナとしての単一ウィジェット

このアプローチでは、データソースをTodoリストウィジェットの設定の一部として含めます。ウィジェットがリスト全体のレンダリングを処理するため、表示を完全に制御できます。例えば、アイテムを縦向き、横向き、または標準では不可能なカスタムレイアウトのカードとしてレンダリングできます。 Mendix コンポーネントをリストします。

ただし、ページネーション、ソート、フィルタリング、遅延読み込みなど、リスト関連のあらゆる課題をウィジェット内で処理する必要があります。つまり、これらの機能を既存の機能を活用するのではなく、ゼロから実装することになります。 Mendixの組み込み最適化。

データ処理の複雑さ

次の大きな課題は、アクションとデータ更新の処理です。データソースは読み取り専用であるため、Todoアイテムを直接変更することはできません。代わりに、マイクロフローを介して変更を渡すためのダミー属性が必要です。これにより、実装上の課題がいくつか生じます。

更新操作

アイテムの削除やToDoのステータスの切り替えといった単純な操作であれば、個別のアクションを実装できます。しかし、より複雑な更新を行う場合は、すべての変更を単一のマイクロフローに渡すか、更新アクション（ステータスの切り替え、タイトルの変更、期日の変更、優先度の変更など）ごとに個別のマイクロフローを作成する必要があります。

パフォーマンスに関する考慮事項

大規模なデータセットを扱う場合は、独自のページネーションロジックを実装する必要があります。これには、ページサイズの管理、無限スクロールのためのスクロールイベントの処理、ユーザーが数千ものアイテム間を移動する際のパフォーマンスの確保などが含まれます。

メモリ管理

ウィジェット内でデータセット全体を扱うため、特にモバイルデバイスや大規模なリストを扱う場合は、メモリ使用量に注意する必要があります。ページネーションを使用すると、この問題を軽減できます。

アクション変数

バージョン10.21.0以降では、アクション変数を使用できるようになり、実装が以前よりも容易になりました。以前のバージョンでは、アクションの背後にあるMFはパラメータを持つことができず、MF自身でダミーオブジェクトの値を取得する必要がありました。

構成の複雑さ

これらの追加設定により、ウィジェットの設定がより難しくなります。 Mendix 開発者は、いくつかの重要な設定をしっかりと理解する必要があります。開発者は、データ受け渡しのためのダミーオブジェクトの設定方法、様々なアクションに適切なマイクロフローを作成する方法、そして失敗した操作を考慮した適切なエラー処理を確実に行う方法を習得する必要があります。さらに、複数のユーザーが同じアイテムを編集しているときにデータの一貫性を維持するには、特別な注意と計画が必要です。

優位性

完全なレンダリング制御
ウィジェットは、リストのレンダリング (カード、垂直、水平レイアウト、カスタム アニメーション、ドラッグ アンド ドロップ インターフェイス) を完全に制御できます。

高度なフィルタリングと並べ替え
ウィジェットは、複雑なソートアルゴリズム、複数列のソート、標準を超える高度なフィルタリングオプションを実装できます。 Mendix 機能を提供します。

一貫したスタイリング
すべてが 1 つのウィジェット内に含まれているため、コンポーネント全体のスタイルの一貫性を維持しやすくなります。

カスタムインタラクション
一括操作、キーボード ショートカット、複雑な選択パターンなどの高度なユーザー インタラクションを実装できます。

デメリット

モノリシックな複雑さ
ウィジェット コード内の複雑さが増すモノリシック構造が作成され、保守とデバッグが困難になります。

パフォーマンス実装の負担
ページ区切り、並べ替え、フィルタリング、遅延読み込みの動作を効率的に実装するには、かなりの労力が必要です。

スタイリング統合の課題
ウィジェットのスタイルをアプリ全体のデザイン システムやテーマの変更に合わせることがより困難になります。

複雑なセットアップ要件
複雑な設定 Mendix 開発者には、ダミー オブジェクト、複数のマイクロフロー、ウィジェットの内部データ フローの理解が必要になります。

テストの複雑さ
すべてが 1 つのコンポーネント内で緊密に結合されているため、個々の機能をテストするのが難しくなります。

アプローチ2: リストアイテムウィジェット

もう一つの選択肢は、 Mendixの組み込みリストコンポーネント、例えば ギャラリー ウィジェット、 リストビューまたは データグリッドこの場合、アイテムウィジェットを作成し、それを提供するリストコンテナ内で使用します。 Mendix.
このアプローチは根本的に異なるコンポーネント間の関心を分離します。 Mendix リストウィジェットは、ページネーション、遅延読み込み、並べ替え、フィルタリングといった複雑なリスト管理タスクをすべて処理します。これらのコントロールとパターンは使い慣れているため、 Mendix 開発者にとって、セットアップは大幅に簡単になり、確立されたパターンに従います。

活用 Mendixの組み込み最適化

使用することにより、 Mendixのネイティブ リスト コンポーネントを使用すると、自動的に次のメリットが得られます。

• 最適化されたデータ取得: Mendix 効率的なデータ検索パターンを自動的に実装します。 取得と集計 完全なデータセットではなくカウントのみが必要な場合にデータベースクエリを削減する最適化。
• 組み込みのページ区切り: 構成可能なページ サイズによるネイティブのページ区切り処理により、サーバーの負荷が軽減され、クライアント側のパフォーマンスが向上します。
• 遅延読み込み: ユーザーがスクロールするときにデータが自動的に遅延読み込みされるため、不要なデータの取得が防止され、最初のページの読み込み時間が短縮されます。
• キャッシュメカニズム: Mendix 冗長なサーバー要求を削減するインテリジェントなキャッシュ戦略を実装します。

シンプルなデータ管理

新しいアイテムを追加する場合は、ポップアップページ、モーダル、または別のフォームへのナビゲーションを表示することで、ウィジェットの外で処理できます。このアプローチにはいくつかの利点があります。

• よく知られたパターン: Mendix 開発者は、すでに知っている標準のページ レイアウト、フォーム検証、およびスタイル設定のアプローチを使用できます。
• アクセス制御: ロールベースのアクセス制御を簡単に実装できます。 Mendixの組み込みセキュリティ機能。
• フォーム検証: 活用できる Mendixの検証フレームワークとエラー処理メカニズム。
• レスポンシブデザイン：自動的に恩恵を受ける Mendixのレスポンシブ デザイン機能。

編集可能なデータの処理

このアプローチでは、 藤堂 アイテムは編集可能になります（ユーザーのオブジェクトアクセス権限によって異なります）。ウィジェット内での更新ロジックの実装は大幅に簡素化されます。

• 直接オブジェクト操作: ダミー オブジェクトを必要とせずにオブジェクト属性を直接変更できます。
• 簡素化されたマイクロフロー: 変更のマイクロフローは単純です。操作に追加のダミー パラメータを必要とせず、オブジェクトをコミットするだけで済みます。
• リアルタイム更新: 複雑な状態管理なしで、変更を UI に即座に反映できます。
• 検証統合: 活用できる Mendixの組み込み検証ルールとエラー処理。

優位性

シンプルなメンテナンス
コードの複雑さが軽減され、潜在的な障害ポイントが減るため、ウィジェットのメンテナンスが大幅に簡素化されます。

標準的なパフォーマンスパターン
ページネーション、ソート、フィルタリング、遅延読み込みには、継続的に改善されている実証済みの最適化された手法を採用しています。 Mendix

設計システム統合
アプリのデザイン システム、自動テーマ サポート、一貫したユーザー エクスペリエンスとウィジェットのスタイル設定の容易な調整

開発者に優しい設定
簡素化されたセットアップ Mendix 開発者は、追加のダミーオブジェクト、複雑なマイクロフロー構成、または内部ウィジェットのデータフローを理解する必要はありません。

実証済みのスケーラビリティ
からの利点 Mendix大規模なデータセットに適応するテスト済みおよび最適化されたリスト処理機能

アクセシビリティのコンプライアンス
自動的に継承 Mendixのアクセシビリティ機能とウェブ標準への準拠

デメリット

レンダリング制御の制限
リストレンダリングオプションの制御が制限される（ Mendixの組み込みレイアウトオプション）

カスタマイズの制約
高度なカスタムインタラクションやレイアウトを実装できない Mendixの標準機能

高度な機能の制限
複雑なドラッグ アンド ドロップ、カスタム ソート アルゴリズム、独自のインタラクション パターンなどの高度な機能をサポートしていない可能性があります。

アプローチ3: 複数のウィジェット

3つ目の選択肢は、相互に接続された複数のウィジェットを構築することです。つまり、アイテムリストをレンダリングするコンテナウィジェットと、個々のTodoアイテムをレンダリングする1つ以上のアイテムウィジェットです。このアプローチは、 Mendix高度なドラッグ アンド ドロップ機能、カスタム レイアウト アルゴリズム、複雑なアイテム間の相互作用など、組み込みのリスト コンポーネント。

このアプローチは、より良い計画と反復的な開発を促進します。どの部分にカスタムウィジェットが必要で、どの部分には既存のウィジェットを利用できるかを判断できます。 Mendixの組み込みコンポーネント。機能の反復作業を進める際に、システム全体を再構築することなく、必要に応じてコンポーネントを置き換えることができます。

スケーラビリティと再利用性の利点

藤堂 例えば、コンテナウィジェットを作成する場合、上記の2番目のアプローチで使用したアイテムウィジェットを再利用できます。そして、コンテナウィジェット内に、次のような高度な機能を追加できます。

• 高度なドラッグ アンド ドロップ: 多方向ドラッグ、視覚的なフィードバック付きのドロップ ゾーン、複雑な並べ替えロジック
• カスタムレイアウトアルゴリズム: 石積みレイアウト、コンテンツに基づく動的なサイズ調整、アルゴリズムによる配置
• 一括操作: 複数選択機能、一括編集、複雑な選択パターン
• リアルタイムコラボレーション: 複数のユーザーが同じリストを編集しているときにライブ更新します
• 高度なフィルタリング: カスタム フィルタ インターフェース、保存されたフィルタ プリセット、複雑なクエリ ビルダー

マルチウィジェットアプローチは、スケーラビリティと関心の分離を向上させます。ただし、コンポーネントを真に再利用性と汎用性を持たせるには、実装の複雑さが増すことを考慮する必要があります。
適切な抽象化と設計がなければ、再利用性が制限され、メンテナンスがより困難になります。

実装の複雑さに関する考慮事項

さらに、同じページ上の複数のウィジェット インスタンスが相互に通信する必要がある場合、大きな課題が生じます。

• 状態同期: データが変更されてもすべてのウィジェットが同期された状態を維持する
• イベント調整: ウィジェット間の複雑なイベントチェーンの管理
• パフォーマンスの最適化: 不要な再レンダリングとデータ取得の防止
• エラー処理: 他のウィジェットに影響を与えずに 1 つのウィジェットの障害を適切に処理します
• ドロップ可能領域の設定: Studio Pro でドロップ可能領域をプレビューするためにウィジェットにプレビュー モードを実装します

国家管理の課題

ウィジェット間のシグナリングと状態管理

複数のウィジェットを扱う上で最も複雑な点の一つは、ウィジェット間の通信と状態管理です。ウィジェット同士が互いの状態を把握する必要がある場合、例えばユーザーがカンバンボード上のアイテムをある列から別の列にドラッグする場合など、堅牢な通信メカニズムが必要です。あるウィジェットがアイテムを非表示にし、別のウィジェットがアイテムを表示するといった状況において、データの一貫性を維持し、スムーズなユーザーフィードバックを提供する必要があります。
これには、ウィジェット間の高度なデータ フローと同期が必要ですが、これは簡単ではなく、特定の実装手法とエッジ ケースの慎重な考慮が必要です。

データフローパターン

複数のウィジェットの場合、データの提供は単一のウィジェットの場合と同様に機能しますが、ウィジェット間でデータを渡すための信頼性の高いパターンを確立する必要があります。子ウィジェットを保持するコンテナウィジェットを使用することもできますが、重要な制限事項を理解しておく必要があります。

React開発者は親コンポーネントから子コンポーネントにプロパティを渡すことができると考えるかもしれないが、これは不可能である。 Mendix プラグ可能なウィジェット。親ウィジェット内に別のウィジェットをレンダリングすると、 Mendix ランタイムは、渡されたプロパティをStudio Proで設定されたウィジェット設定のデータで上書きします。つまり、一般的なReactアプリケーションのようにコンポーネントツリーを介して動的にデータを渡すことはできません。

代替コミュニケーション方法

代わりに、ウィジェット間でデータを共有するには、別の方法が必要です。

共有属性:

• あるウィジェットの属性に書き込み、別のウィジェットで読み取ることができる
• 属性が変更されると、2番目のウィジェットはプロパティが変更されたため自動的に再レン​​ダリングされます。
• 自動的な反応を提供しますが、頻繁な更新によりパフォーマンスの問題が発生する可能性があります。
• 選択されたアイテムやフィルター値などの単純な状態の共有に最適

Reactコンテキスト:

• React 18では状態管理のためのコンテキストが導入されました（以前はReduxのようなサードパーティのライブラリが必要でした）
• すべてから Mendix ページ上のウィジェットは同じReact DOMによってレンダリングされ、ウィジェット間でコンテキストを共有できます。
• 1つのウィジェットでコンテキストプロバイダーを作成し、他のウィジェットでそれを使用することができます。
• 複雑な状態管理とプロペラ掘削の回避に最適
• メモリリークを防ぎ、適切なクリーンアップを確実に行うために、慎重な設定が必要です。

投稿メッセージ API:

• この確立されたメカニズムは、 window.postMessage API ページ全体にイベントを送信する
• ウィジェットは、位置に関係なく、iframe を越えてもこれらのイベントをサブスクライブできます。
• ウィジェット間の疎結合を提供しますが、イベントの命名とペイロード構造を慎重に行う必要があります。
• 一方向通信やイベント放送に最適
• 異なるページや異なるアプリケーション間でも動作可能

スタイリングの課題

ウィジェットが複数ある場合、スタイル設定は非常に複雑になります。あるウィジェットにCSSスタイルシートがあり、他のウィジェットからそのスタイルシートにアクセスしたい場合は、スタイル設定アーキテクチャを慎重に計画する必要があります。

共有リポジトリ構造:

• 両方のウィジェットがアクセスできる、より大きなリポジトリ構造を使用する
• 共通のスタイルを共有できるビルドプロセスを実装する
• ウィジェット開発チーム間の調整が必要
• バージョン同期の課題につながる可能性がある

設計システム統合:

• スタイル設定をウィジェットから完全に移動して、デザインシステムに任せる
• ウィジェットでデザインシステムのクラスを使用し、デザインシステムのスタイルを間接的な依存関係として文書化します。
• 一貫性は向上するが、成熟したデザインシステムが必要
• 個々のウィジェットのカスタマイズオプションが制限される可能性があります

モジュールベースの公開:

• ウィジェットをスタンドアロンウィジェットではなくモジュールとして公開する
• これにより、ウィジェット間で共有できるCSSファイルをエクスポートできます。
• 柔軟性は向上するが、公開と配布のプロセスは複雑になる
• 以下の理解が必要 Mendix モジュール開発パターン

セットアップの複雑さと開発者のエクスペリエンス

Mendix 開発者にとって、複数のウィジェットを設定することは、単一のウィジェットを設定するよりもはるかに困難です。その複雑さはいくつかの形で現れます。

構成の依存関係:

• 1つのウィジェットで、開発者はデータソースを簡単に構成できます。
• 複数のウィジェットを使用する場合、開発で使用される特定のパターンを理解して従う必要があります。
• 設定を誤ると、機能が壊れたり、パフォーマンスが低下したりする可能性があります。

データ構造の要件:

• 複数のウィジェットでは、特定のデータ構造と関係が必要になることが多い
• 開発者はウィジェットがどのように通信し、各ウィジェットがどのようなデータを期待しているかを理解する必要がある。
• 実装を成功させるにはドキュメント化が重要になる

展開調整:

• 互換性を確保するために、関連するすべてのウィジェットを一緒に展開する必要があります。
• ウィジェット間のバージョンの不一致によりランタイムエラーが発生する可能性がある
• 慎重なリリース管理とテスト手順が必要

デバッグの複雑さ:

• 問題は複数のウィジェットにまたがる可能性があり、デバッグがより困難になる
• 開発者は、問題のトラブルシューティングを行うためにウィジェットのエコシステム全体を理解する必要がある
• すべてのウィジェットにわたって包括的なログ記録とエラー処理が必要です

パフォーマンスに関する考慮事項

複数のウィジェットでは、単一のウィジェットでは発生しないパフォーマンス上の考慮事項も発生します。

• レンダリング調整: 複数のウィジェットを同時に再レンダリングすると、パフォーマンスのボトルネックが発生する可能性があります。
• メモリ管理: 各ウィジェットは独自の状態を維持するため、メモリ使用量が増加する可能性があります。
• ネットワーク最適化: 複数のウィジェットが同時に API 呼び出しを行うと、サーバーに過負荷がかかる可能性があります。
• イベント処理: ウィジェット間の複雑なイベントチェーンは、適切に最適化されていない場合、パフォーマンスの問題を引き起こす可能性があります。

これらの課題にもかかわらず、複数ウィジェットのアプローチは、正しく実装すれば非常に強力になります。コードのモジュール性と再利用性を維持しながら、洗練されたユーザーインターフェースを柔軟に作成できます。重要なのは、事前にアーキテクチャを慎重に計画し、通信、スタイル、データ管理のための明確なパターンを確立することです。

3つのアプローチの例

比較のために、上記のすべてのアプローチを用いてTodoリストのショーケースウィジェットを3つ実装しました。コードは主にCopilotを使用したVibeコーディングで生成されています。要件と期待される機能を指定し、それらを反復処理することで期待される結果が得られました。なお、これらのリポジトリはあくまでショーケース用の例であり、本番環境での使用に必要な品質管理は完了していません。

• 1 つのコード例にアプローチします。 https://github.com/MeisamMahdian/showcase-todolist-single-widget
• アプローチ 2 のコード例: https://github.com/MeisamMahdian/showcase-todolist-single-item
• アプローチ 3 のコード例: https://github.com/MeisamMahdian/showcase-todolist-container-widget

この記事が、あなたにとってより明確な理解をもたらすことを願っています。 Mendix ウィジェット アーキテクチャは、単なるコード生成を超えたプラットフォームの包括的な理解が、優れたカスタム ソリューションを作成するために不可欠である理由を示しています。