【bubble】ステータス管理の実装2パターン

例えばマッチングアプリにおいて、プロジェクトのステータスを「進行中」「完了」など表示する場合があると思います。
メッセージ受信時に「New」と表示することも多いです。

こういった時に使える、bubbleにおけるステータス管理の実装パターンを2種類考えたので、共有します。

①DBに保持したステータスを、ワークフローで変更

DBにステータスを保持し、ワークフローで変更する方法です。

メッセージを送った時。受信した時。リクエストを承認した時。
ステータスが変わる時は必ず、何かしらのアクションを行いますよね。
これをトリガーとし、ワークフローの「make changes to thing..」でステータスを設定します。

おそらく最も単純で、よく使う方法です。

注意点は、ロジックを間違えるとアクションによってステータス表示が意図せず変わってしまう可能性があります。
リクエスト承認後なのに「承認待ち」で上書きしてしまったり。
ロジックは丁寧に考えてあげる必要があります。

また、ステータスの選択肢はWorkFlowに直接書いてもいいですが、スペルミスが増えます。
この場合Option Setsであらかじめ決めておくと、ミスが少なくなりますね。

何度も選ぶ可能性のある文字列は、可能ならあらかじめ定義するべきです。
もし修正したくなったときも、WorkFlowに直接書いていると全て書き直しですが、後者なら定義した1箇所のみで全て変更できます。

この考え方はエンジニアとして鉄則ですので、意識しましょう。

②Conditionalで条件分岐

2つ目は、エレメントのConditionalで条件分岐する方法です。

ステータス表示のtextエレメントを用意。
これのConditionalに条件を指定し、満たしている時はtextを変更。つまりステータスを変更します。

例えばメッセージの未読表示は、
「送信者が自分以外かつ、送信日時が閲覧日時より遅いメッセージのCountが1以上」のような条件で表示させます。

この方法は上手く使うとWorkFlowやDBへアクセスが少なくなるため、動作を軽くすることができます。
また、色なども細かく変更できますね。
（①でも、ステータスが○○の時、というConditionalを設定することで色変更は可能）

Custom Stateと組み合わせることで、更に条件を細かく設定できますね。

デメリットは、ステータスが増えると複雑になりやすいことです。
条件式がandで繋いで長くなったり、Do a search forを多用して結局重くなったり。
シンプルなステータス変更の場合は使いやすいです。

まとめ

2種類として紹介しましたが、WorkFlow、Conditional、Custome Stateなど、組み合わせ次第で様々な条件を実現可能です。

ステータス表示は、同じ未読表示だとしても条件が異なる場合が多いです。
そのため、どのような条件で変更するかを、最初にしっかり考えましょう。

今回はぼんやりとした話でしたが、今度もっと具体的な事例も紹介できればと思います。