Kredis を使用して一時的な UI 状態を Rails に簡単に保存

Kredis (Keyed Redis) は、Rails 開発者ツールキットに最近追加されたものです。 Redis 上の構造化データの保存とアクセスを簡素化することを目指しています。

2 部構成シリーズの最初の部分では、まず Kredis がどのように機能するかについて説明します。次に、特注の Redis キーを使用して一時的な UI 状態を保存するユースケースの例を実行します。

始めましょう!

Rails 用 Kredis の概要

Kredis は、次の 3 つの方法で使用を効率化する便利なラッパーを提供する Railtie です。

• Ruby 風の API :たとえば、Kredis.list のようなコレクション型 または Kredis.set ネイティブの Ruby タイプ (およびそれぞれの API) を可能な限りエミュレートする
• 入力 :コレクションに特に便利な Kredis は、標準データ型 (例:datetime) からの要素の型キャスト、または標準データ型への要素の型キャストを処理できます。 、json ).
• アクティブレコード DSL :おそらくライブラリの最大の資産であり、Redis データ構造を特定のモデル インスタンスに簡単に接続できるようになります。 .

以下は README の例です。

Kredis の主な利点は、特定のレコードに関連付けられた一時的な情報を、 セッションとは独立して簡単に保存できることです。 。通常、Rails でデータを永続化する必要がある場合、いくつかのオプションがあります。そのうちの 2 つの最も一般的なオプションは次のとおりです。

• アクティブレコード :ほとんどの場合、これには列を追加するか、データ モデルにパッチを適用する必要があります。移行が必要であり、さらにオプションで古いレコードのバックフィルも必要です。
• セッション :すべての Rails アプリのデフォルトのキー/値ストアであり、セットアップがまったくまたはほとんど必要ありません。欠点は、そこに保存されたデータがログイン/ログアウト サイクル後に存続しないことです。

Kredis は 3 番目のオプションをテーブルにもたらします。モデル内で DSL を呼び出すこと以外に、ほとんどセットアップは必要ありません。ただし、Redis インスタンスがダウンしない限り、データはセッション間、さらにはデバイス間で保存されます。したがって、Kredis の良い使用例は、ウェブ アプリとコンパニオン モバイル アプリなど、デバイスの境界を越えて共有したい重要ではない情報です。

ケーススタディ:Kredis を使用して、折りたたまれた/展開された UI 状態を保持および復元する

Kredis の優れた使用例の典型的な例は、次のような UI 状態を永続化する場合です。

• サイドバーの開閉状態
• ツリービューの開閉状態
• アコーディオンの折りたたみ/展開状態
• カスタム ダッシュボード レイアウト
• 表示するデータテーブルの行数

例として、<details> の折りたたみ/展開状態を管理する方法を見てみましょう。 要素。

新しい Rails アプリから始めましょう。kredis を追加します。 バンドルに追加し、そのインストーラーを実行します。

注: これにより、config/redis/shared.yml に Redis 構成ファイルが作成されます .

この記事の残りの部分では、ローカルで Redis インスタンスが実行されていると仮定します。 Homebrew を備えた macOS では、これは次のコマンドを実行するのと同じくらい簡単です。

オペレーティング システムに Redis をインストールする方法については、公式の「はじめに」ガイドを参照してください。

ユーザー認証

User を使用します。 UI 状態情報を格納するエンティティとしてモデルを使用します。ここで自転車置き場を避けるために、Devise がすぐに提供するものをそのまま使用しましょう。

次に、Rails コンソールでサンプル ユーザーを作成します。

サンプル アプリ:オンライン ストア

Kredis が複雑なツリー構造の状態を維持するのにどのように役立つかを説明するために、オンライン デパートを運営していると仮定してみましょう。この目的のために、Department をスキャフォールディングします。 と Product モデル。 2 レベルの入れ子構造を作成するために、部門から部門への自己結合を組み込みます。

もちろん、ツリー構造のルートを許可するには、null の親を許可する必要があります。

私たちの Department と Product モデルは次のように定義されます。

最後に、faker を使用してシード データを生成します。

店頭の足場

非常に単純な HomeController を作成します。 それが私たちの店の店頭として機能します。

部門の子に対して自己結合を実行して、実際にサブ部門を持つ (つまり、ツリーのルートである) ものだけを取得します。

インデックス ビューでは、<details> の 2 つのレベルを使用してネストされたツリー ビューを設定します。 私たちの部門の要素:

現在、意図的にふざけた製品名が付けられた部門のツリー ビューがあり、開いたり閉じたりすることで探索できます。

個々のカテゴリの開示状態を保持したいと考えており、次にこれを処理します。

Kredis でのカテゴリの UI 状態の永続化

これから行うことを段階的に説明します。

<オル>

kredis_set を追加します open_department_ids と呼ばれる User へ モデル。ここでセットを使用する理由は、重複が許可されていないため、部門を安全に追加および削除できるためです。

UIStateController を作成します 次のパラメータを受け取ります:

• department_id
• open その部門の状態

次に、この部門を kredis_set に追加または削除します。 現在ログインしているユーザーの場合。

刺激コントローラーを作成します。 これは、詳細要素のトグル イベントをリッスンし、それぞれのペイロードを介して送信します。

さあ、始めましょう!

上記の Kredis データ構造を User に追加します。 モデルは kredis_set を呼び出すのと同じくらい簡単です そして識別子を渡します:

次に、UIStateController を生成します。 UI 状態の更新を受信します。生成されたルートを patch になるように構成する必要があることに注意してください。 エンドポイント:

Kredis の API と最初に遭遇したのはコントローラーです。 Ruby 開発者の期待にできる限り一致しようとしていることがわかります。そのため、<< を使用してセットに追加できます。 、remove を使用して削除します .

ここで何が起こっているのかというと、特定の department_id の存在を切り替えているということです。 open に基づくセット内 param はクライアントから渡されます。全体像を完成させるには、これらの UI 状態の変更を送信するためのクライアント側のコードを記述する必要があります。

@rails/request.js を使用します。 アクションを実行するには、それを固定する必要があります:

特定の <details> に接続する新しい Stimulus コントローラー内 要素に、部門 ID とその open を追加します。 状態を FormData に設定します オブジェクトを作成し、送信します。

提案どおりにビュー コードを編集し、toggle をリッスンします。 各 <details> のイベント UI 状態の更新をトリガーする要素:

DOM を手動で再水和する

一周するために欠けている唯一の要素は水分補給です。 ユーザーがページを更新すると、DOM が目的の状態になります。これを手動で行うには、open を追加します。 <details> の属性 ノード (部門 ID が Kredis セットに存在する場合):

最後に、結果がこちらです。個々のツリー ノードの開閉状態は 2 つのレベルにわたって保持されることに注意してください。

次へ:UI 状態の一般化されたユーザーローカル コンテナ

この 2 部構成のシリーズの最初の部分では、Kredis を紹介し、Kredis を使用して折りたたみ/展開された UI 状態を永続化および復元する方法を検討しました。

オンライン デパートの例を使用して、最終的に DOM を手動でリハイドレートする前に、Kredis が複雑なツリー構造の状態をどのように保持できるかを強調しました。

ただし、これは、多くの Kredis キーを発明する必要があることを意味します。次回は、UI 状態用の一般化されたユーザーローカル コンテナを使用してこれに対処する方法について詳しく説明します。

それまで、コーディングを楽しんでください!

追記Ruby Magic の投稿を報道後すぐに読みたい場合は、Ruby Magic ニュースレターを購読して、投稿を 1 つも見逃さないようにしてください。