メインコンテンツまでスキップ
バージョン: 0.4.2

📦 注文ハンドラーブロック

注文ハンドラーブロックは、Nodeblocksアプリケーションにおける注文管理操作のためのコアビジネスロジック関数を提供します。これらのハンドラーは、注文データベース操作、データ変換、レスポンスフォーマッティングの共通パターンをカプセル化します。

🎯 概要​

注文ハンドラーブロックは以下を目的として設計されています：

  • 再利用可能な関数での注文ビジネスロジックのカプセル化
  • 適切なエラー管理による注文データベース操作の処理
  • 異なるフォーマット間での注文データの変換
  • TypeScript統合による型安全性の確保
  • 他の注文ブロックとのコンポジションのサポート

📋 注文ハンドラー種類​

注文非同期ハンドラー​

非同期注文操作（データベース呼び出し、APIリクエストなど）を実行する関数。

注文同期ハンドラー​

同期注文操作（データ変換、検証など）を実行する関数。

注文ターミネーターハンドラー​

最終的な注文レスポンスをフォーマットして返す関数。

🔧 利用可能な注文ハンドラー​

createOrder​

検証とエンティティ管理により、データベースに新しい注文を作成します。

目的: 検証とエンティティ管理による注文作成を処理

パラメータ:

  • payload: リクエストコンテキストとデータを含むRouteHandlerPayload

戻り値: Result<RouteHandlerPayload, Error> - orderIdを含む成功またはエラー

使用例:

// コンポジションでの使用:
compose(createOrder, terminator);

主要機能:

  • リクエストボディが存在し空でないことを検証
  • タイムスタンプとIDを含むベースエンティティを作成
  • データベースに注文を挿入
  • 成功時にorderIdを返す
  • データベースエラーを適切に処理

updateOrder​

IDにより既存の注文を更新し、検証と競合検出を行います。

目的: 検証と競合検出による注文更新を処理

パラメータ:

  • payload: リクエストコンテキストとデータを含むRouteHandlerPayload

戻り値: Result<RouteHandlerPayload, Error> - orderIdを含む成功またはエラー

使用例:

// コンポジションでの使用:
compose(updateOrder, terminator);

主要機能:

  • orderIdが提供されていることを検証
  • リクエストボディが存在し空でないことを検証
  • タイムスタンプを含むベースエンティティを更新
  • 更新前に注文が存在することを確認
  • 成功時にorderIdを返す
  • 見つからない場合と更新失敗を処理

getOrderById​

存在検証により、IDで単一の注文を取得します。

目的: 存在検証による注文データの取得

パラメータ:

  • payload: リクエストコンテキストとデータを含むRouteHandlerPayload

戻り値: Result<RouteHandlerPayload, Error> - orderGroupを含む成功またはエラー

使用例:

// コンポジションでの使用:
compose(getOrderById, normalizeTerminator);

主要機能:

  • orderIdが提供されていることを検証
  • データベースでIDによる注文を検索
  • 注文が見つからない場合は404を返す
  • 成功時にorderGroupデータを返す
  • データベースエラーを適切に処理

findOrders​

オプションのフィルタリングサポートで複数の注文を検索します。

目的: フィルターサポートによる注文のクエリを処理

パラメータ:

  • payload: リクエストコンテキストとデータを含むRouteHandlerPayload

戻り値: Result<RouteHandlerPayload, Error> - orderGroups配列を含む成功またはエラー

使用例:

// コンポジションでの使用:
compose(findOrders, listTerminator);

主要機能:

  • リクエストクエリからのオプションフィルターを受け入れ
  • フィルターが提供されない場合は全注文を返す
  • orderGroupsの配列を返す
  • データベースエラーを適切に処理

deleteOrder​

安全な削除と存在検証により、IDで注文を削除します。

目的: 存在検証による注文の安全な削除を処理

パラメータ:

  • payload: リクエストコンテキストとデータを含むRouteHandlerPayload

戻り値: Result<RouteHandlerPayload, Error> - 削除フラグを含む成功またはエラー

使用例:

// コンポジションでの使用:
compose(deleteOrder, deleteTerminator);

主要機能:

  • orderIdが提供されていることを検証
  • データベースからIDによる注文を削除
  • 注文が見つからない場合は404を返す
  • 削除確認フラグを返す
  • データベースエラーを適切に処理

ターミネーターハンドラー​

createOrderTerminator​

適切なレスポンスフォーマッティングで注文作成を終了します。

目的: 201ステータスで成功した注文作成レスポンスをフォーマット

パラメータ:

  • result: Result<RouteHandlerPayload, Error>

戻り値: データとstatusCodeを含むフォーマット済みレスポンスオブジェクト

使用例:

// コンポジションでの使用:
compose(createOrder, createOrderTerminator);

主要機能:

  • 結果がエラーの場合はエラーをスロー
  • コンテキストにorderGroupが存在することを検証
  • データベース_idフィールドを削除
  • 作成に対して201ステータスコードを返す

normalizeOrderTerminator​

データベース固有フィールドを削除して注文データを正規化します。

目的: APIレスポンス用の注文データをクリーンアップ

パラメータ:

  • result: Result<RouteHandlerPayload, Error>

戻り値: 正規化された注文オブジェクト

使用例:

// コンポジションでの使用:
compose(getOrderById, normalizeOrderTerminator);

主要機能:

  • 結果がエラーの場合はエラーをスロー
  • コンテキストにorderGroupが存在することを検証
  • データベース_idフィールドを削除
  • クリーンな注文オブジェクトを返す

normalizeOrdersListTerminator​

各項目からデータベース固有フィールドを削除して注文リストを正規化します。

目的: APIレスポンス用の注文配列データをクリーンアップ

パラメータ:

  • result: Result<RouteHandlerPayload, Error>

戻り値: 正規化された注文オブジェクトの配列

使用例:

// コンポジションでの使用:
compose(findOrders, normalizeOrdersListTerminator);

主要機能:

  • 結果がエラーの場合はエラーをスロー
  • orderGroups配列をマップ
  • 各注文からデータベース_idフィールドを削除
  • クリーンな注文オブジェクトの配列を返す

deleteOrderTerminator​

適切なステータスコードで注文削除を終了します。

目的: 204ステータスで成功した削除レスポンスをフォーマット

パラメータ:

  • result: Result<RouteHandlerPayload, Error>

戻り値: 204 statusCodeを含むレスポンスオブジェクト

使用例:

// コンポジションでの使用:
compose(deleteOrder, deleteOrderTerminator);

主要機能:

  • 結果がエラーの場合はエラーをスロー
  • 削除フラグが存在することを検証
  • 成功した削除に対して204ステータスコードを返す

🔗 関連ドキュメント​