Administración de Solidus
Esta es una etapa pre-alfa y puede cambiarse en el futuro.
Esto comienza como un proyecto divertido con fines internos para crear una versión más confiable del panel de administración solidus_backend. Solidus tiene un excelente componente central y una interfaz de administración que incluye batería pero, en nuestra opinión y debido a nuestras personalizaciones, la gema de administración carece de estructura de diseño para ser una infraestructura secundaria real para comunicarse con la estructura solidus_core.
Características
- Hermoso y fácil de usar (la UX importa)
- Hotwire Turbo impulsado ⚡️
- Estímulo con mapas de importación para pequeños destellos.
- Filtrado simplificado con Ransack
- Operaciones por lotes como destruir
¿Por qué reescribir la rueda?
Como se dijo, en nuestra opinión, solidus_backend se basa en tantas advertencias de estar atrapado en bibliotecas elegidas de nuevo en la bifurcación (¡Deface, te estoy mirando!) y esta estructura es demasiado estricta con esas opciones:
- Muchos de los filtros con saqueo se confunden con el resumen de parámetros personalizados.
- El uso de Cancan con 'macros' (:manage, :admin) y no con rutas CRUD reales y no se ciñe a las convenciones del patrón MVC.
- La edición de productos, pedidos y promociones se basa en ajax con columna vertebral y no en un comportamiento CRUD más convencional.
- No es "realmente" compatible con turbo: Turbolinks se desarrolló en hotwire y el uso actual es solo un fragmento para la ejecución correcta del script de JavaScript.
- Uso intensivo de la ejecución remota de JavaScript de Rails-ujs y 'remote: true' en lugar de una respuesta HTML más limpia y predecible con turbo. Creo que el control remoto no es un buen enfoque porque inyecta código javascript en la consola del navegador con la esperanza de ser ejecutado y, para mí, es una posible amenaza para la seguridad de secuencias de comandos cruzadas.
Como puede ver, solidus_admin es bastante antiguo y en cuanto a la renovación de solidus_frontend con solidus_starter_frontend, ¡es hora de realizar un gran experimento y renovación!
¿Estás intentando crear una nueva gema solidus_backend?
Algo así, pero no . Estoy comenzando esto como un proyecto alternativo en primer lugar porque es un proyecto alfa y su objetivo es ofrecer, junto con un backend incluido con batería con un marco de acoplamiento bajo con rieles, pero también un marco de Adminland bastante estructurado para extensibilidad y personalización de la interfaz de usuario sin headdacle. . Quiero que dependa más de la biblioteca elegida por el propietario del proyecto anfitrión, como una integración fácil sin ser demasiado estricta.
Bien, ¿cuál es tu elección? ¿Los tuyos también son opinables?
Creo que podríamos pensar en que la estructura del código de administración respete estos fundamentos:
- Ser fácil de anular y extender con menos anulaciones/enfoque de parche de mono. ¡Somos humanos, no monos!
- Prohibición previa para Deface. Nunca me gustó el enfoque de desfiguración y creo que es mejor pensar que la interfaz de usuario es modular desde el principio, en vistas alternativas alternativas mediante copia, pero no mediante parche e inyección. Para la extensibilidad de otra herramienta complementaria (todas las extensiones de solidus con secciones de administración), prefiero hacer un punto de prefijo más claro y expuesto.
- Rutas estrictas para CRUD. Todo debe depender de rutas CRUD lo más estrictas posible, al igual que el enfoque de rutas anidadas, a favor de la convención sobre el enfoque de configuración.
- Agregue recursos externos desde la aplicación hosting Rails con una plantilla de andamio de generador.
Con esto en mente, comencé a poner algunas opciones para el 'nuevo' proyecto solidus_adminland, como por ejemplo:
- hotwire de forma predeterminada y alienta a algo más que un enfoque de manipulación DOM js.
- estímulo para adiciones simples y confiables como selectores, máscara de entrada y validaciones de formularios
- uso de la gema view_component para encapsular métodos auxiliares con resultado HTML (como link_to o otros más complejos). También es más fácil para fines de anulación, como alternativa a los parciales para mayor confiabilidad y la clase PORO para la lógica de la interfaz de usuario.
- Cada importación de activos se realiza con Rails-importmap para un 'enfoque de aplicación sin javascript'
- Uso de administrar gem para dividir la preocupación entre representación (con clase *Dashboard) y rutas CRUD para que los datos se muestren o envíen
- Todos los formularios tienen el estilo de FormBuilder, donde cada campo se representa con una clase de Componente separada. Si en la función nosotros o alguien queremos poner algún campo extraño, como los de Dropdown JS, se puede crear con el nuevo Admininstrate::Field, FormBuilder::Component y estimula para js sparkle.
- En cuanto a la política, creo que podríamos crear un enfoque híbrido que sea compatible con cancan pero con un enfoque de pudit más sencillo. En nuestro caso usamos la gema action_policy. Se basa en un objeto PORO donde podríamos definir para cada acción cuáles son las reglas para realizarla. Es una verdadera pieza intermedia para los controladores en cuanto a la política de control sobre el "alcance de registro", los "parámetros permitidos de registro" y las "rutas accesibles de registro".
Como puede ver, para cada recurso hay:
- un controlador con el mismo nombre para operaciones CRUD estándar
- un panel con el mismo nombre para index, new_form, edit_form y mostrar parámetros para mostrar
- una política para qué alcance con el usuario actual puedo acceder, qué parámetros puedo enviar y qué ruta tengo permitida para ese recurso.
... y como enfoque "convencional", ¡podría simplemente crear el suyo propio (o ampliar) de esos tres y poner su lógica de negocios como desee (o como lo requiera su aplicación)!
El diseño inicial se realizó con bootstrap 5 con Tabler, pero puede anular fácilmente las vistas estándar desde el administrador/aplicación para CRUD. El número de visitas seguirá siendo lo más bajo posible.
Hoja de ruta
Todos los derechos de logotipos y colores se obtienen del kit de prensa de solidus. El tema Admin está inspirado en maquetas de sitios web de solidus y se basa en la versión Bootstrap 5 de Tabler.
