Bubbleのページ遷移におけるData to SendとSend more parameters to the pageの使い分けとは #ページネーション

はじめに

Bubbleでページ遷移の際には遷移先のページにデータを送ります！
そのページ遷移でデータを送る際にはパラメーターが深く関係しています。

そこで、以下のようにページ遷移でデータを送る際にData to SendとSend more parameters to the pageどちらを使うのか迷ったことがありませんか？

ですので、今回はその使い分けについて考えていきます！

「Data to send」機能は、
URLパラメーターを使用してデータを送信するわけではない一方で、
「Send more parameters to the page」という機能は、
URLパラメーターを使用してデータを送信します。

このように使い分けを考えていく中でパラメーターが重要となるので
パラメーターがどういうものであるか整理してみましょう

※パラメーターについて理解がある方は読み飛ばして頂いて大丈夫です

パラメーターとは

WebサイトやWebシステムにおける「パラメーター」とは、URLやフォームデータ、さらにはAPI呼び出しにおいて、特定の情報や要求を伝えるために使用されるデータのことです

例えると
パラメーターとは分岐した扉を開けるためのキーワードのようなもの

パラメーターはいくつかに分類されます

URLパラメーター

これはWebアドレス（URL）の一部として送信される。
通常、? の後にキーと値のペアで表され、
複数のパラメーターは & で区切られます。
例えば、https://example.com/products?category=books&price=low では、
category と price がパラメーターとなります

POSTパラメーター

これらは通常、フォームを介して送信されます。
ユーザーがフォームに入力した情報は、
POSTリクエストの本文に含まれ、サーバーに送信されます。
これはURLには表示されません。

HTTPヘッダーパラメーター

これらはHTTPリクエストのヘッダーに含まれる情報で、
例えばブラウザの種類や言語設定などが含まれます。

Cookieパラメーター

クッキーは、Webサイトがユーザーのブラウザに保存する小さなデータ片です。
これにより、サイトはユーザーの訪問履歴や設定などを記憶できます。

Bubbleの開発においてページ遷移の際に使用されるのはURLパラメーター

Bubbleの開発においてページ遷移の際に使用されるパラメーターは、主にURLパラメーターのことを指します

そして、Bubbleでは、
以下のような方法でURLパラメーターを利用します

ページ間のデータ伝達

ユーザーがあるページから別のページへ移動する際、
特定のデータをURLパラメーターを通じて伝達することができます。

例
ユーザーが選択した商品の詳細ページを表示する

ダイナミックコンテンツの表示

 URLパラメーターを利用して、
 異なるユーザーや条件に基づいてページのコンテンツを動的に変更することができます。
 これにより、よりパーソナライズされたユーザー体験を提供することが可能です。

例
ユーザーが検索バーに「靴」と入力し、検索ボタンをクリックするとウェブページは靴のカテゴリーに属する商品だけを表示する

ブックマークや共有の容易化

URLにパラメーターを含めることで、特定の状態のページをブックマークしたり、
他人と共有しやすくなります。

例
SNS等でユーザーは特定の投稿のURLをブックマークしたり、友人に共有して、直接そのポストを表示させる

Data to SendとSend more parameters to the pageのメリットとデメリット

では、いよいよやっと本題の内容に入ります！
ページ遷移においてData to SendとSend more parameters to the pageにはそれぞれメリット・デメリットどのようなものがあるのでしょうか？

まずはData to Sendのメリット・デメリットです！

「Data to Send」を使用するメリット

セキュリティ

「Data to Send」を使用すると、データはURLに露出せずに渡されるため、
情報が外部に露出するリスクが低減されます。
特にセキュリティが懸念される場合には、この方法が適しています。

例
管理者専用ページや機密性の高いユーザーデータを扱う場合など

クリーンなURL

URLパラメータを使用すると、URLが長く複雑になることがあります。
対照的に、「Data to Send」を使うと、URLが短くクリーンな状態を保てます。
ユーザーはURLを容易に認識できるなどユーザー体験の向上に寄与します。

例
ユーザーがカスタマイズしたダッシュボードやプロフィールページへのアクセス

データの直接的な利用

「Data to Send」を使用すると、遷移先のページでそのデータを
直接参照できることによって迅速にロードすることが可能になります。
これにより、ユーザーは待ち時間を減らし、データの取得や処理を簡素化することができ、
特に大規模なアプリケーションにおいては処理の効率化につながる可能性があります。

例
オンラインストアでの商品詳細ページへの遷移

「Data to Send」を使用するデメリット

ブックマークや共有の制限

「Data to Send」を使うと、送信されるデータはURLに含まれません。
その結果、ユーザーがそのページをブックマークしたり、
他人と共有したりする際、遷移先のページは同じ状態を再現できない可能性があります。
特に、特定の状態やデータを持つページへのダイレクトアクセスが必要な場合、
このアプローチは不便になることがあります。

注意したほうがいい例
SNSの投稿ページなど、ユーザーが頻繁にブックマークや共有を行う可能性が高いページ

サーバーへの依存

データをサーバー経由で送信する必要があるため、
サーバーのパフォーマンスや信頼性によりアプリケーションの効率が左右されます。
これは、特に大量のデータを扱う場合や、高トラフィック状況下での
パフォーマンスに影響を及ぼす可能性があります。

注意したほうがいい例
サーバーの性能が低い場合や不安定な場合
(大量のデータを「Data to Send」で扱うことはサーバーに負荷をかける)

複雑な設定には考慮が多く必要

「Data to Send」を使用する際には、送信するデータの種類と構造、
および遷移先のページでのデータの受け取り方を正しく設定する必要があります。
この設定の複雑さは、特に複雑なデータ構造を扱う場合や
複数のページ間でデータを受け渡す必要がある場合に、開発者にとっての負担となり得ます。

注意したほうがいい例
ユーザーのプロフィール情報に関連付けられた複数のアドレス、連絡先情報、過去の取引履歴などが含まれる場合など

そして、先程の内容とは必然的に逆になりますが
続いてSend more parameters to the pageのメリット・デメリットです！

「Send more parameters to the page」を使用するメリット

直接アクセスと共有が容易

「URLにパラメータを含めることで、特定のページの状態やデータを直接表現できます。
これにより、ユーザーはページを簡単にブックマークや共有でき、
同じ状態のページに直接アクセスできます。

例
SNSの投稿ページなど、ユーザーが頻繁にブックマークや共有を行う可能性が高いページ

状態の再現性

URLパラメータにより、ユーザーが特定のページを再訪した際に
同じ状態やビューを再現することができます。
これは、特定の検索結果や設定を保存しておきたい場合に特に有効です。

例
特定のキーワードで検索を行い、その結果を表示するようなページ

サーバー負荷の軽減

データをURLパラメータとして送信することで、
サーバーへの追加的なデータ送信が必要ないため、
サーバーの負荷が軽減される可能性があります。

例
人気のあるブログ記事やニュース記事など

実装のシンプルさ

URLパラメータを使うことで、データの送受信のロジックがシンプルになることが多く、
特に小規模なアプリケーションや単純なデータ構造の場合には、実装が容易になります。

例
個人のポートフォリオサイト、簡易的なブログシステム、小規模なビジネスウェブサイトなど

「Send more parameters to the page」を使用するデメリット

セキュリティとプライバシーの懸念

機密性の高い情報や個人情報もURLパラメータとして送信するとURLに含まれてしまう。
これは、共有されたリンクを通じて誰でもアクセスできるようになるため、注意が必要です。

注意したほうがいい例
クレジットカード番号や住所、電話番号などの個人情報を扱うとき

URLの長さに制限

URLには長さに制限があります。
非常に多くのデータや複雑なパラメータをURLに含める場合、この制限に達することがあり、
エラーの原因となる可能性があります。

注意したほうがいい例
オンラインショップ等で多数のフィルターやソートオプションを提供する場合、ユーザーが複数のフィルターを適用したときなど

ユーザー体験の影響

長く複雑なURLは、ユーザーにとって直感的ではなく、
見た目にも雑然として見える可能性があります。
これは、特にユーザーがURLを直接操作することが予想される場合に問題となることがあります。

注意したほうがいい例*
アンケートや調査フォームのような、ユーザーが複数の選択肢を選ぶシナリオでは、選択肢の組み合わせがURLに全て反映される

データの整合性の保証が難しい

URLパラメータはユーザーによって編集可能であるため、
無効なデータや意図しない値が渡されるリスクがあります。
これにより、アプリケーションの側で適切なバリデーションや
エラーハンドリングを行う必要があります。

注意したほうがいい例
複数の選択肢や設定を含むダッシュボードの設定など、ユーザーがURLを直接編集することで結果を操作できるとき

Data to SendとSend more parameters to the pageの使い分け

メリットやデメリットを見ると使い分けの観点は様々でありました。

同じWebアプリケーション内でも、
「Data to Send」と「Send more parameters to the page」は異なるページやシナリオに応じて使い分ける必要があります

ざっとまとめるこのような感じになります！

最も分かりやすい判断基準は
「プライバシーとセキュリティの重要性」と言えるでしょう

プライバシーやセキュリティが重要な情報を扱う場合は「Data to Send」を、
共有やブックマークの便宜を重視する場合は「Send more parameters to the page」を
選択するのが一般的です。

その次に重要な判断基準は
「ページの状態やデータの共有と再現性」です

ユーザーがページの特定の状態を簡単に共有、ブックマーク、
または再訪できる必要がある場合は「Send more parameters to the page」が適しています。
逆に、ページ間で複雑なデータや状態を内部的に扱う必要がある場合は
「Data to Send」の方が適切です

以上がData to SendとSend more parameters to the pageの使い分けとなります！

読んでくださり、ありがとうございました
ぜひ、Bubbleでの快適な開発ライフを過ごしていきましょう！
お疲れ様でした！

Bubbleのページ遷移におけるData to SendとSend more parameters to the pageの使い分けとは