ノードを使用したクライアントサイドビジネスロジック

このガイドで学べること

このガイドでは、Noodlの異なるロジックノードを使用してシンプルなビジネスロジックを構築する例をいくつか紹介します。ガイドでは、条件付きフォーム（つまり、他のフィールドの入力内容に基づいて異なるフィールドを入力する必要があるフォーム）を使用しますが、概念は一般的です。このガイドでは、Javascriptを使用せず、Noodlに存在するノードのみに依存します。

ロジックの実装には、Expression、Condition、Switch、Statesノード、およびブールノードのAndとOrを使用します。

概要

このガイドでは、以下のロジック実装方法を紹介します。

• Mounted属性を持つSwitchとStatesノードを使用して、画面上に表示されるものを制御する
• ExpressionとConditionを使用してテキスト入力の内容を検証する
• ブール演算子を使用してロジックを構築する

ロジックを構築する別の方法として、JavascriptノードのFunctionとScriptを使用する方法があります。これについてはこのガイドでカバーされています。

条件付きフォームの構築

フォームに入力する内容に応じて徐々に変化する、あの複雑なフォームを構築してみましょう。この場合、例えばオンラインで注文した服の返品登録用のフォームになります。

フォームのロジック

言葉で説明すると、以下のようなフォームを構築したいと考えています：

• 注文番号またはメールアドレスを入力してフォームを開始します。
• 注文番号を入力した場合、それは正確に8桁でなければなりません。そうでない場合は、フォームがユーザーに警告を出す必要があります。
• 返品の理由も指定する必要があります。オプションは商品が合わなかった、期待に応えなかった、またはその他です。
• 商品が合わなかったを選択した場合、商品が大きすぎたか小さすぎたかを選択する必要があります。
• 期待に応えなかったを選択した場合、詳細を記入するための任意のテキストフィールドが与えられます。
• その他を選択した場合も、詳細を記入するための任意のテキストフィールドが与えられます。

フォームの最後には「送信」ボタンがあります。必要な情報がすべて与えられている場合のみ利用可能になり、そうでない場合は無効になります。

すべてのデータは、以下のプロパティを持つObjectに保存されるべきです：

 {
 	"email":<the user email>,
 	"order_nbr":<the order_nbr>,
 	"reason":<either "bad_fit","did_not_meet_exp" or "other">,
 	"bad_fit_reason":<"too_small" or "too_large">,
 	"did_not_meet_exp_reason":<any text>,
 	"other_reason":<any text>
 }

自然に、メールアドレスか注文番号のどちらか一方を持つ必要があります。また、bad_fitを理由に選択した場合、bad_fit_reasonも提出する必要があります。

では、始めましょう！

フォームの静的コンテンツ

まずは、無条件のフォームのコンテンツから始めます。これには以下が含まれます：

• order_nbrまたはemailのオプションを持つRadio Button Group。
• 返品理由というラベルと、商品が合わなかった、期待に応えなかった、その他のオプションを持つ別のRadio Button Group。
• [Button](/nodes

/ui-controls/button)としての送信ボタン。

• 異なるセクションを分けるためのいくつかのタイトル。

ラベルを埋めて、パディングとマージンを設定すると、以下のようなフォームになります。自分でノードを作成したくない場合は、以下のコピーボタンを使用して新しいプロジェクトに貼り付けることができます。

最初のRadio Buttonグループのvalueも埋められています（email/order_nbrおよびbad_fit/did_not_meet_exp/other）。後でこの値を使用してロジックを決定します。また、最初の選択肢としてorder_nbrをデフォルトオプションとして設定しました。

Switchを使用した条件付きUI

フォームの最初の条件付き部分は、ユーザーが注文番号を入力するかメールアドレスを入力するかです。それを作成しましょう。このタイプの条件付きUIを扱う良い方法の1つは、両方のケースをノードツリーに追加し、各ケースのルートグループのMountedプロパティを使用して、表示されるものを選択することです。

状態をエンコードするために、例えばSwitchがtrueの場合は注文番号がアクティブで、それ以外の場合はfalseとするSwitchが必要

です。実際のチェックは、Expressionノードを使用して行います。これは、論理ステートメントを書くシンプルな方法です。Javascript形式を使用します。Radio Button GroupのValueが文字列order_nbrと等しい場合にtrueを返し、そうでない場合はfalseを返すように、式ノードに以下のように書きます：

order_or_email_selection === "order_nbr"

これにより、Expressionノードにorder_or_email_selectionという名前の新しい入力が作成されます。最初のRadio Button Groupの出力Valueをその入力に接続します。Expressionノードの出力Resultは、現在trueまたはfalseになります。この値はSwitchの状態を制御します。したがって、Order Nbr selectedと呼ばれるSwitchを作成し、そのState入力に接続します。

これで、Switchは、ユーザーが最初のRadio Button Groupで選択したものに基づいてOnまたはOffになります。これを使用して、条件付きUIを制御したいと思います。最初のRadio Button Groupの下に2つのText Inputノードを追加します。1つは注文番号用で、これはNumberタイプにし、もう1つはEmailタイプのメールアドレス用です。それらに適切なラベルを付けます。また、幅を300 pxに設定します。注文番号については、プレースホルダーテキストに8桁であることを示す追加のヒントも追加します。

これらのテキストフィールドは相互排他的である必要があり、つまり、一度に1つだけが表示されるようにしたいと考えています。注文番号については非常に簡単です。SwitchのCurrent StateをText InputのMounted入力に接続します。メールアドレス用のText Inputの状態を反転させる必要があるため、Inverterノードを追加し、Switchとメールアドレス用のText Inputの間に接続します。

ご覧のとおり、最初のRadio Button Groupの設定に応じて、異なるText Inputsが表示されるようになりました。

Statesノードを使用した条件付きUI

次に、"商品を返品する理由"Radio Button Groupのロジックを構築しましょう。ここでは、追跡する必要がある4つの異なる状態があるため、Switchでは不十分です。4つの状態は以下の通りです：

• 選択なし
• 商品が合わなかった
• 商品が期待に応えなかった
• その他

これらの状態をStatesノードで簡単にエンコードできます。アプリにStatesノードを追加します。次に、4つの状態を作成します。状態の名前は、上記のデータObjectのreasonプロパティの値と一致するように使用するため、状態はno_selection、bad_fit、did_not_meet_exp、otherと呼ばれます。

このStatesノードに値を追加する必要はありません。Statesノードを以前に使用したことがある場合、たとえば異なる値をアニメーションするために、値が変わるときに状態が変わる必要があるのに、なぜ値が必要ないのか不思議に思うかもしれません。実際には、Statesノードの状態プロパティにのみ関心があり、具体的にはAt bad_fit、At did_not_meet_exp、At otherに関心があります。再び、UIの状態をすべてツリーに追加し、Mountedシグナルを使用して表示されるものを制御するトリックを使用します。

したがって、異なるUIコンポーネントをツリーに追加します。商品が小さすぎたか大きすぎたかを選択するための別のRadio Button Groupと、Text Areasとして設定された2つのText Inputノードです。タイトルやマージンの小さな調整を追加したツリーの下部は、次のようになります。正確なレイアウトを取得した

い場合は、以下のノードをコピーして貼り付けることができます。

返品の理由を制御するRadio Button Groupが、Statesノードの状態を制御するようにしましょう。状態をreasonプロパティの値と同じ名前にしたため、Radio Button GroupのValueを直接Stateに接続できます。

StatesノードのAt <state>出力を使用して、それぞれのコントロールがマウントされるタイミングを制御します。At <state>出力のいずれかがいつでもtrueになるため、ここではInverterを使用する必要はありません。

今、ラジオボタンをクリックしてみると、設定に応じて異なるコントロールがマウントされるのがわかります。

Conditionsとブールロジックノードを使用したフォーム内容の検証

次は、フォームの入力が一貫しているかどうかを簡単に検証するステップです。例えば、商品が合わなかったと言った場合、商品が小さすぎたのか大きすぎたのかを記入しなければなりません。フォームが適切に記入されていない場合、「送信」ボタンはグレーアウトされるべきです。もちろん、異なるシナリオではルールが異なります。メールアドレスを使用する場合は、8桁の注文番号を記入する必要はありませんなど。

まず、注文参照に関する最初の2つのルールから始めましょう。注文番号が選択されたかどうかを既に知っているSwitchがあります。また、注文番号が8桁であるかどうかを確認する必要があります。これを行うには、内容をStringノードに渡します。Stringの長さを抽出し、それが正確に8であるかどうかを確認できます。

同様に、メールアドレス文字列の長さも同じ方法でチェックします。もちろん、メールアドレスが有効であるかどうかもチェックできますが、今回はこれを省略します。このような文字列検証を多く行う場合は、Form Validation Moduleなどの専用モジュールの使用が良いアイデアかもしれません。この例では、文字列検証ではなく、ボタンの状態を制御するロジックに焦点を当てます。

さて、ロジックを構築する準備が整いました。つまり、注文参照が有効である場合は、(メールが選択されていてメールが0文字以上の場合)または(注文番号が選択されていて注文番号が正確に8桁の場合) です。括弧を使用して、異なる式が評価される順序を明確にしています（これは違いを生むことがあります）。これをAndおよびOrノードを使用してエンコードします。

「注文番号が選択された」ということをエンコードするためにInvertedが使用されていることに注意してください。実際には、「メールが選択されていない」と言っています。入力してみてください。注文番号とメールアドレスを入力し、切り替えてみてください。うまくいきます！ ご覧の通り、これら

のブール構造には、ノードツリーがかなり大きくて散らかることがあります。それをコンポーネントに入れることできれいにしましょう。

新しいロジックコンポーネントを作成します。

「有効な参照」と呼びます。既にComponent InputとComponent Outputノードが定義されていることがわかります。入力を定義する必要があります。検証に必要な入力は、Order Number Selected、Order Number、およびEmailです。既存のDo入力を削除し、それらを追加します。

コンポーネントの出力は、1つのブール値、Reference Validと呼ぶことにします。したがって、Component Outputから既存のポートを削除し、それを追加します。次に、既存のロジックをルートコンポーネントから切り取り、このコンポーネントに追加します。

入力と出力が適切に接続されると、コンポーネントは以下のようになります。以下のノードをコピーしてコンポーネントに貼り付けることもできます。

旧ロジックを新しいコンポーネントに置き換えると、以下のようになります：

次に、返品の理由の部分について同様のことを行う必要があります。今回は別のコンポーネントから始めます。したがって、別のロジックコンポーネントを作成し、「有効な理由」と呼びます。必要な入力はReturn ReasonとBad Fit Reasonです。ロジックは、_理由が有効である場合は、(理由がdid_not_meet_expまたはotherの場合)または(理由がbad_fitであり、悪いフィットの理由がtoo_smallまたはtoo_largeのいずれかである場合)_です。他にもロジックを表現する方法はありますが、これは一つの方法です。このロジックを新しいコンポーネントで構築しましょう。

Component Inputsを追加し、Component OutputポートReturn Reason Validを追加します。このロジックを構築します。

Expressionノードを使用して、より複雑なテストを構築できることがわかります。この場合、||（または）演算子を使用しています。実際、全体のテストを1つの大きなExpressionで構築できます。

(return_reason === "did_not_meet_exp" || return_reason === "other") || (return_reason === "bad_fit" && (bad_fit_reason === "too_large" || bad_fit_reason === "too_small"))

しかし、分割することで、各サブ式がどのように評価されるかを見ることができ、必要に応じてデバッグしやすくなります。

メインアプリにロジックコンポーネントを追加すると、以下のようになります：

さて、ほぼ完成です。参照が有効であり、理由が有効である必要がありますので、両方をAndノードにフィードします。結果がtrueの場合、「送信」ボタンを有効にし、そうでない場合は無効にします。簡単です！

Objectにフォームの内容を保存

フォームが完成しました。これで、値をObjectに保存してアプリの他の場所で使用できるようにする必要があります。このロジックのほとんどは簡単です。値をObjectに接続し、Set Object Propertiesを使用してそこに保存しますが、1つの複雑な問題があります。再び形式を見てみましょう。

 {
    "email":<the user email>,
    "order_nbr":<the order_nbr>,
    "reason":<either "bad_fit","did_not_meet_exp" or "other">,
    "bad_fit_reason":<"too_small" or "too_large">,
    "did_not_meet_exp_reason":<any text>,
    "other_reason":<any text>
 }

emailとorder_nbrを保存する際に注意が必要です。両方を保存すると、どちらを使用するかわかりません。したがって、一方だけが保存され、もう一方は空になるようにする必要があります。他の値はシンプルです。reasonがbad_fitに設定されている場合、bad_fit_reasonが有効であることを知っています。そうでない場合は単に無視します。did_not_meet_expとotherもそれぞれのプロパティに対して同じです。

しかし、基本から始めましょう。フォームがマウントされたときに新しいObjectを作成したいので、ルートGroupのDid MountシグナルをCreate New ObjectのDoシグナルに接続します。

この新しいObjectのIdは、これから使用するものです。次に、emailとorder_nbrのいずれかを保存する問題に取り組みましょう。1つはemail、reason、bad_fit_reason、did_not_meet_exp_reason、other_reasonを持つSet Object Propertiesノードを作成し、もう1つはorder_nbr、reason、bad_fit_reason、did_not_meet_exp_reason、other_reasonを持ちます。Create New Objectノードの

IdをSet Object PropertiesのIdsに接続します。

フォームコンポーネントからすべての値をSet Object Propertiesに接続しましょう。

また、保存されない値（注文番号を使用する場合のemail、メールアドレスを使用する場合のorder_nbr）が空の文字列に設定されるように、それらのプロパティを作成し、空のStringノードをそれぞれの値に接続します。Stringノードに値を割り当てないと、空の文字列になります。

Conditionノードを使用して異なるノードをトリガー

行うべきことは、2つのSet Object Propertiesのうちの1つをトリガーするために、参照の2つのケースを決定するために使用するSwitchに基づいてConditionノードを使用することです。Conditionノードは、特定の瞬間に何かを評価したいときに非常に便利です。この場合、"送信"ボタンがクリックされたときです。trueまたはfalseの値に応じて、2つのシグナルのいずれか、On TrueまたはOn Falseが得られます。構築してみましょう！

Conditionノードを作成します。Order Nbr SelectedSwitchのCurrent State出力をConditionノードのCondition入力に接続します。これが_何を_評価したいかです。次に、"送信"ボタンのClickシグナルをConditionノードのEvaluateアクションに接続します。これが_いつ_評価したいかです。最後に、ConditionノードのOn TrueおよびOn FalseシグナルをそれぞれのSet Object Propertiesノードに接続します。On Trueは「注文番号が選択された」がtrueであることを意味するため、そのシグナルはemailが空に設定されたSet Object Propertiesに接続されるべきです。逆もまた然りです。

ObjectをIdに接続して、何が起こっているかを確認しましょう。

完成しました。カスタムロジックを持つ条件付きフォームを実装しました。以下からプロジェクト全体をダウンロードできます。