Solidus Adminlândia
Este é um estágio pré-alfa e pode ser alterado no futuro.
Isso começa como um projeto divertido com propósito interno para criar uma versão mais confiável do painel de administração solidus_backend. Solidus possui um ótimo componente central e uma interface administrativa com bateria, mas, em nossa opinião e devido às nossas customizações, a gem administrativa carece de estrutura de design para ser uma verdadeira infraestrutura lateral para comunicação com a estrutura solidus_core.
Características
- Bonito e fácil de usar (UX é importante)
- Hotwire Turbo alimentado ⚡️
- Estímulo com importmaps para pequenos brilhos
- Filtragem facilitada com Ransack
- Operações em lote como destruir
Por que reescrever a roda?
Como dito, em nossa opinião, solidus_backend retransmite tantas advertências de ficar preso a bibliotecas escolhidas de volta ao spree fork (Deface, estou olhando para você!) E essa estrutura é muito rígida para essas escolhas:
- Muitos dos filtros com ransack estão confusos com o resumo de parâmetros personalizados
- Pode ser usado com 'macros' (:manage, :admin) e não com rotas CRUD reais e não seguir convenções do padrão MVC.
- A edição de produtos, pedidos e promoções depende de ajax com backbone e não de um comportamento CRUD mais convencional.
- Não é "realmente" compatível com turbo: Turbolinks evoluiu em hotwire e o uso atual é apenas um trecho para a execução correta do script javascript.
- Uso pesado de execução remota javascript de rails-ujs e 'remote: true' em vez de uma resposta html mais limpa e previsível com turbo. Acho que remoto não é uma boa abordagem porque injeta código javascript no console do navegador na esperança de ser executado e é, para mim, uma potencial ameaça à segurança de script cruzado.
Como você pode ver, o solidus_admin é bem antigo e quanto à reformulação do solidus_frontend com solidus_starter_frontend é hora de um experimento pesado e de renovação!
Você está tentando criar uma nova gem solidus_backend?
Mais ou menos, mas não . Estou começando isso como um projeto alternativo antes de tudo porque é um projeto alfa e seu objetivo é oferecer, junto com um backend incluído com bateria com baixo acoplamento com framework rails, mas também um framework Adminland bastante estruturado para extensibilidade e customização de UI sem headdacle . Quero fazer com que dependa mais da biblioteca escolhida pelo proprietário do projeto host, como uma integração fácil sem ser muito rígido.
Ok, então qual é a sua escolha? Os seus também são opináveis?
Acho que poderíamos pensar que a estrutura do código adminland respeite estes fundamentos:
- Ser fácil de substituir e estender com menos substituições/abordagem de patch de macaco. Somos humanos e não macacos!
- Banimento prévio para Deface. Nunca gostei da abordagem deface e acho melhor pensar a UI como modular desde o início, em alternativas substituindo visualizações por cópia, mas não por patch e injeção. Para a capacidade de extensão de outra ferramenta secundária (todas as extensões solidus com seções administrativas), prefiro fazer um ponto de acréscimo mais claro e exposto.
- Estrito para rotas CRUD. Tudo deve contar com rotas CRUDs tão rigorosas quanto possível, assim como para a abordagem de rotas aninhadas, em favor da abordagem de convenção em vez de configuração.
- Adicione recursos externos do aplicativo Rails de hospedagem com um modelo de andaime gerador.
Com isso em mente, comecei a colocar algumas opções para o 'novo' projeto solidus_adminland, como:
- hotwire por padrão e incentiva mais do que uma abordagem de manipulação de DOM js.
- estímulo para adições simples e confiáveis, como seletores, máscara de entrada e validações de formulário
- uso da gem view_component para encapsular métodos auxiliares com resultados HTML (como link_to ou outros mais complexos). É mais fácil também para fins de substituição, em alternativa às parciais para confiabilidade e à classe PORO para lógica da UI
- Cada importação de ativos é feita com rails-importmap para 'nenhuma abordagem de aplicativo centrada em javascript'
- Uso da gema administrativa para divisão de interesse entre representação (com classe *Dashboard) e rotas CRUD para exibição ou envio de dados
- Todos os formulários são estilizados pelo FormBuilder, onde cada campo é renderizado com a classe Component separada. Se no recurso nós ou alguém quisermos colocar algum campo estranho, como os Dropdown JS, isso pode ser feito com o novo Admininstrate::Field, FormBuilder::Component e estímulo para js sparkle ?
- Em termos de política, penso que poderíamos fazer uma abordagem híbrida que fosse compatível com o cancan, mas com uma abordagem de autoridade mais fácil. No nosso caso, usamos a gem action_policy. Baseia-se em um objeto PORO onde poderíamos definir para cada ação quais são as regras para prosseguir. É uma verdadeira peça intermediária para controladores para política de controle sobre 'escopo de registro', 'parâmetros permitidos de registro' e 'rotas acessíveis de registro'.
Como você pode ver, para cada recurso existe:
- um controlador com o mesmo nome para operações CRUD padrão
- um painel com o mesmo nome para índice, novo_form, edit_form e mostrar parâmetros para exibir
- uma política para qual escopo com o usuário atual posso acessar, quais parâmetros posso enviar e qual rota tenho permissão para esse recurso.
... e como uma abordagem 'convencional', você pode simplesmente criar o seu próprio (ou estender) desses três e colocar sua lógica de negócios como desejar (ou como seu aplicativo exigir)!
O design inicial é feito com bootstrap 5 com Tabler, mas você pode facilmente substituir as visualizações padrão do admin/aplicativo para CRUD. O número de visualizações permanecerá restrito ao menor possível
Roteiro
Todos os direitos dos logotipos e cores são obtidos do solidus presskit O tema Admin é inspirado nos modelos do site solidus e baseado na versão Bootstrap 5 do Tabler
