Solidus Adminland
Il s’agit d’une étape pré-alfa et peut être modifiée à l’avenir.
Cela commence comme un projet amusant à des fins internes visant à créer une version plus fiable du panneau d'administration solidus_backend. Solidus possède un excellent composant de base et une interface d'administration avec batterie incluse, mais, à notre avis et en raison de nos personnalisations, le joyau d'administration manque de structure de conception pour être une véritable infrastructure secondaire pour communiquer avec la structure solidus_core.
Caractéristiques
- Beau et facile à utiliser (l'UX compte)
- Alimenté par Hotwire Turbo ⚡️
- Stimulation avec importmaps pour les petites étincelles
- Filtrage simplifié avec Ransack
- Opérations par lots comme la destruction
Pourquoi réécrire la roue ?
Comme dit, à notre avis, solidus_backend s'appuie sur tant d'avertissements concernant le fait d'être coincé dans des bibliothèques choisies depuis le fork (Deface, je vous regarde !) et cette structure est trop stricte pour ces choix :
- De nombreux filtres avec ransack sont en désordre avec le résumé des paramètres personnalisés
- Utilisation Cancan avec des « macros » (:manage, :admin) et non avec de vraies routes CRUD et ne respecte pas les conventions du modèle MVC.
- L'édition des produits, des commandes et des promotions repose sur ajax avec backbone et non sur un comportement CRUD plus conventionnel.
- Pas "vraiment" compatible turbo : Turbolinks a évolué en hotwire et l'utilisation actuelle n'est qu'un extrait pour l'exécution correcte du script javascript.
- Utilisation intensive de l'exécution à distance javascript de rails-ujs et de « remote : true » au lieu d'une réponse HTML plus propre et prévisible avec turbo. Je pense que la télécommande n'est pas une bonne approche car elle injecte du code javascript dans la console du navigateur dans l'espoir d'être exécuté et constitue, pour moi, une menace potentielle pour la sécurité des scripts croisés.
Comme vous le voyez, solidus_admin est assez ancien et quant à la refonte de solidus_frontend avec solidus_starter_frontend, il est temps de procéder à une expérimentation lourde et à un renouvellement !
Essayez-vous de créer une nouvelle gemme solidus_backend ?
En quelque sorte mais non . Je commence cela comme un projet alternatif tout d'abord parce que c'est un projet alpha et son objectif est d'offrir, avec un backend inclus avec une batterie avec un faible couplage avec le framework rails, mais aussi un framework Adminland assez structuré pour l'extensibilité et la personnalisation de l'interface utilisateur sans headdacle . Je souhaite qu'il s'appuie davantage sur la bibliothèque choisie auprès du propriétaire du projet hôte, pour une intégration facile sans être trop stricte.
Ok, alors quel est ton choix ? Les vôtres sont-ils également jugés ?
Je pense que nous pourrions penser que la structure du code adminland respecte ces principes fondamentaux :
- Être facile à remplacer et s'étendre avec moins de remplacements/approche de patch de singe. Nous sommes des humains, pas des singes !
- Interdiction préalable pour Deface. Je n'ai jamais aimé l'approche de défiguration et je pense qu'il est préférable de penser l'interface utilisateur comme modulaire dès le début, dans des vues alternatives par copie mais pas par patch et injection. Pour l'extensibilité d'un autre outil side-car (toutes les extensions solidus avec sections d'administration), je préfère faire un point de pré-ajout plus clair et exposé.
- Strict aux itinéraires CRUD. Tout doit s'appuyer sur des routes CRUD aussi strictes que possible, ainsi que sur une approche de routes imbriquées, en faveur d'une approche conventionnelle plutôt que de configuration.
- Ajoutez des ressources externes à partir de l'application d'hébergement Rails avec un modèle d'échafaudage de générateur.
Dans cet esprit, j'ai commencé à faire quelques choix pour le « nouveau » projet solidus_adminland tels que :
- hotwire par défaut et encourage plus qu'une approche de manipulation du DOM js.
- stimulus pour des ajouts simples et fiables tels que des sélecteurs, un masque de saisie et des validations de formulaires
- utilisation de view_component gem pour incapsuler des méthodes d'assistance avec un résultat HTML (comme link_to ou des méthodes plus complexes). Est également plus facile à des fins de remplacement, en alternative aux partiels pour la fiabilité et à la classe PORO pour la logique de l'interface utilisateur
- Chaque importation d'actifs est effectuée avec rails-importmap pour une « approche d'application non centrée sur Javascript »
- Utilisation de la gemme d'administration pour la division des préoccupations entre la représentation (avec la classe *Dashboard) et les routes CRUD pour les données à afficher ou à soumettre
- Tous les formulaires sont stylisés par FormBuilder où chaque champ est rendu avec une classe Component séparée. Si dans la fonctionnalité nous ou quelqu'un voulons mettre un champ étrange tel que ceux de Dropdown JS, cela peut être créé avec new Admininstrate::Field, FormBuilder::Component et stimulus for js sparkle ?
- Pour ce qui est de la politique, je pense que nous pourrions adopter une approche hybride pour être compatible avec le cancan mais avec une approche pudit plus simple. Dans notre cas, nous utilisons action_policy gem. Il s'appuie sur un objet PORO où l'on pourrait définir pour chaque action quelles sont les règles à suivre. Il s'agit d'une véritable pièce intermédiaire pour les contrôleurs pour la politique de contrôle sur la « portée d'enregistrement », les « paramètres autorisés d'enregistrement » et les « routes accessibles d'enregistrement ».
Comme vous pouvez le constater, pour chaque ressource il y a :
- un contrôleur du même nom pour les opérations CRUD standard
- un tableau de bord avec le même nom pour index, new_form, edit_form et show params à afficher
- une politique pour quelle portée avec l'utilisateur actuel je peux accéder, quels paramètres je peux soumettre et quel itinéraire je suis autorisé pour cette ressource.
... et en tant qu'approche « conventionnelle », vous pouvez simplement créer votre propre (ou étendre) ces trois éléments et définir votre logique métier comme vous le souhaitez (ou selon les exigences de votre application) !
La conception initiale est réalisée avec bootstrap 5 avec Tabler mais vous pouvez facilement remplacer les vues standard de l'administrateur/de l'application pour CRUD. Le nombre de vues restera strict au plus bas possible
Feuille de route
Tous les droits des logos et des couleurs proviennent du dossier de presse Solidus. Le thème Admin est inspiré des maquettes de sites Web Solidus et basé sur la version Bootstrap 5 de Tabler.
