ソリダス・アドミンランド
これはアルファ前の段階であり、将来変更される可能性があります。
これは、solidus_backend 管理パネルのより信頼性の高いバージョンを作成するための、内部目的の楽しいプロジェクトとして始まります。 Solidus には優れたコア コンポーネントとバッテリーを含む管理インターフェイスがありますが、私たちの意見では、カスタマイズのせいで、管理宝石には、solidus_core 構造と通信するための実際のサイド インフラストラクチャとしての設計構造が欠けています。
特徴
- 美しくて使いやすい (UX が重要)
- ホットワイヤーターボ搭載 ⚡️
- importmap による小さな輝きの刺激
- Ransack でフィルタリングが簡単に
- 破棄などのバッチ操作
なぜホイールを書き直すのでしょうか?
前述したように、私たちの意見では、solidus_backend はスプリー フォークに戻って選択されたライブラリに固執するという非常に多くの脱走を中継しており (Deface はあなたを見ている!)、この構造はそれらの選択に対して厳しすぎます。
- Ransack を使用するフィルターの多くはカスタムパラメータダイジェストで混乱しています
- 実際の CRUD ルートではなく、「マクロ」 (:manage、:admin) で使用でき、MVC パターンの規則に固執しません。
- 製品、注文、プロモーションの編集は、従来の CRUD 動作ではなく、バックボーンを備えた ajax に依存します。
- 「実際には」ターボ互換ではありません: ターボリンクはホットワイヤーで進化しており、現在の使用法は JavaScript を正しく実行するための一部にすぎません。
- ターボによるよりクリーンで予測可能な HTML 応答の代わりに、rails-ujs と 'remote: true' の JavaScript リモート実行を多用します。リモートは、実行されることを期待してブラウザのコンソールに JavaScript コードを挿入し、私にとってはクロススクリプティングの潜在的なセキュリティ脅威であるため、リモートは良いアプローチではないと思います。
ご覧のとおり、solidus_admin はかなり古いものであり、solidus_starter_frontend によるsolidus_frontendの刷新に関しては、本格的な実験と刷新の時期が来ています。
新しいsolidus_backend gemを作成しようとしていますか?
ある種ですが、いいえ。私がこれを代替プロジェクトとして始めているのは、まず第一に、これがアルファプロジェクトであり、Rails フレームワークとの結合度が低いバッテリーを含むバックエンドに沿って提供することが目的であるためですが、ヘッドダックを使用せずに拡張性と UI カスタマイズのためのかなり構造化された Adminland フレームワークも提供することです。 。厳密になりすぎずに簡単に統合できるように、ホスト プロジェクトの所有者から選択されたライブラリにもっと依存できるようにしたいと考えています。
さて、あなたの選択は何ですか?あなたも自分の意見を持っていますか?
管理ランドのコード構造がこの基本を尊重するように考えることができると思います。
- オーバーライドが簡単で、オーバーライドの少ないモンキーパッチアプローチで拡張できます。私たちは猿ではなく人間です!
- Deface に対する事前の禁止。私は改ざんのアプローチが好きではなかったので、パッチとインジェクトではなくコピーによってビューをオーバーライドするという代替方法で、最初から UI をモジュール型として考える方が良いと思います。別のサイドカー ツール (管理セクションを備えたすべての Solidus 拡張機能) の拡張性を考慮して、より明確で公開された先頭に追加するポイントを作成することを好みます。
- CRUD ルートに厳密。すべては、構成アプローチよりも規約を優先して、ネストされたルート アプローチと同様に、可能な限り厳密な CRUD ルートに依存する必要があります。
- ジェネレーター スキャフォールド テンプレートを使用して、ホスティング Rails アプリから外部リソースを追加する必要があります。
これを念頭に置いて、「新しい」solidus_adminland プロジェクトに次のようないくつかの選択肢を追加し始めました。
- デフォルトではホットワイヤーを使用し、JS DOM 操作以上のアプローチを奨励します。
- ピッカー、入力マスク、フォーム検証などのシンプルで信頼性の高い追加機能の刺激
- view_component gem を使用して、HTML 結果 (link_to などのより複雑なヘルパー メソッド) をカプセル化します。信頼性のためのパーシャルや UI ロジックのための PORO クラスの代わりに、オーバーライド目的でも簡単です。
- アセットのインポートはすべて、「JavaScript 中心のアプリではないアプローチ」のために、rails-importmap を使用して行われます。
- 表示または送信するデータの表現 (*Dashboard クラスを使用) と CRUD ルートの間で懸念事項を分割するための管理 gem の使用
- すべてのフォームは FormBuilder によってスタイル設定され、すべてのフィールドは分離された Component クラスでレンダリングされます。私たちまたは誰かがドロップダウン JS フィールドなどの奇妙なフィールドを機能に配置したい場合は、新しい Admininstrate::Field、FormBuilder::Component、および JS スパークルの刺激を使用して作成できます。
- 政策手法に関しては、cancan と互換性を持たせつつ、より簡単なピューディット アプローチを使用したハイブリッド アプローチを作成できると思います。この例では、action_policy gem を使用します。これは、アクションごとに実行するためのルールを定義できる PORO オブジェクトに依存しています。これは、「レコード スコープ」、「レコード許可パラメータ」、および「レコード アクセス可能なルート」に対する制御ポリシーのためのコントローラの実質的な中間部分です。
ご覧のとおり、すべてのリソースには次のものがあります。
- 標準の CRUD 操作と同じ名前のコントローラー
- 表示するindex、new_form、edit_form、およびshow paramsに同じ名前のダッシュボード
- 現在のユーザーがアクセスできるスコープ、送信できるパラメータ、およびそのリソースに対して許可されるルートのポリシー。
... そして、「従来の」アプローチとして、これら 3 つを独自に作成 (または拡張) し、好きなように (またはアプリの要求に応じて) ビジネス ロジックを配置することができます。
初期設計は、Tabler を使用したブートストラップ 5 で作成されていますが、管理者/アプリケーションから CRUD 用の標準ビューを簡単にオーバーライドできます。閲覧数は可能な限り低く抑えられます
ロードマップ
ロゴと色のすべての権利は、solidus プレスキットから取得されています。管理者テーマは、solidus ウェブサイトのモックアップからインスピレーションを得ており、Tabler の Bootstrap 5 バージョンに基づいています。