Acho que precisamos de uma maneira geral de fazer isso, que seja específica e agnóstica em relação ao Theme Component - como temos agora.
Tenho outro Theme Component que usa essa técnica:
Então, são pelo menos dois do meu lado, e pode haver mais.
3 curtidas
Concordo. Criei uma coleção de componentes de blocos, cada um autônomo, em vez de empacotados em um único pacote: Blocks · GitLab.
No momento, posso colocar esses blocos em uma página inicial dedicada com meu componente Homepage Blocks, assim como posso usá-los com Right Sidebar Blocks ou em Bars.
Recentemente, fiz uma experiência com o tema Central, onde precisei de um layout de barra lateral personalizado. Eu poderia facilmente criar um framework de blocos para uma barra lateral personalizada e colocar componentes de blocos nela: https://central.kostka.studio (assim como colocar o componente Powered-by-discourse na barra lateral, apenas referenciando-o pelo nome).
Componentes de blocos autônomos são realmente a ferramenta mais útil que tenho no momento para construir personalizações de clientes de forma flexível e sustentável. Seria ótimo ter um caminho geral para apoiar isso.
3 curtidas
Gostaria de reabrir este tópico, pois estou tentando descobrir a melhor maneira de lidar com meus componentes. Atualmente, vejo duas opções que têm desvantagens significativas: eu poderia criar um registro por componente de tema que renderiza blocos, mas isso meio que anula todo o propósito modular. Ou adicionar um globalmente através de um plugin, mas então meus componentes se tornam dependentes da instalação desse plugin.
Portanto, parece que ter uma API de registro de blocos global no core realmente ajudaria. Algo que os componentes de tema poderiam usar para invocar a renderização de blocos e também para registrar novos blocos.
Eu adoro trabalhar com a abordagem de blocos porque me permite dividir as preocupações entre o layout do aplicativo e o conteúdo do componente. O componente de bloco apenas lida com a renderização de seu conteúdo, e então é renderizado por outro componente no aplicativo. Posso remover toda a lógica de rota e outlet do componente de bloco, e posso facilmente reutilizar o mesmo bloco várias vezes em um layout e até mesmo em todo o aplicativo.
Eu acho que isso torna tudo mais enxuto e reutilizável, e é uma abordagem elegante no geral. Ter um suporte sólido para esse padrão no Discourse seria ótimo.
4 curtidas
David, seria viável ter uma API discricionária para registrar componentes de “temas/plugins cruzados” para uso em outro plugin/componente?
Isso evitaria registrar tudo, mas ainda forneceria a flexibilidade para tornar isso explicitamente possível.
2 curtidas
Não tenho certeza sobre uma API genérica para isso. Existem muitas maneiras de usar componentes, e todos eles têm expectativas diferentes em relação a argumentos e tempo de carregamento.
Para o seu caso de uso, um registro específico de tema/plugin funcionaria? Como o mockup acima para blocos da barra lateral direita?
Se não, fornecer alguns exemplos concretos pode nos ajudar a descobrir exatamente que tipo de API é necessária. Todos os temas e plugins mantidos pela CDCK foram migrados para gjs, e este não é um problema que encontramos (exceto pelos casos específicos como os blocos da barra lateral direita).
1 curtida
Sim, na verdade, relendo mais atentamente o que você escreveu no Draft PR me leva a crer que esta é uma solução boa o suficiente, especificamente:
“Este commit introduz uma lista dedicada de componentes do Right Sidebar Blocks e permite que outros temas/plugins registrem componentes adicionais.”
Eu acho que isso é fundamental - ser capaz de registrar remotamente como compatível com outro tema e, em seguida, permitir que o tema “mestre” incorpore os elementos registrados remotamente é exatamente o que eu quero, então acho que você já demonstrou que isso é possível.
1 curtida
Ótimo!
Em casos muito simples, você pode até conseguir usar um PluginOutlet no tema “mestre”, e então outros temas podem usar renderInOutlet (ou colocar um arquivo em connectors/...).
2 curtidas
Também é verdade. Eu realmente gosto do seu padrão de registro, muito bom. Seria bom manter a compatibilidade com o RSB, na verdade (o Bars já usa o mesmo sistema de parâmetros), para que todo o sistema se torne interoperável (embora ter dois inicializadores possa ser um desafio - ou potencialmente não precisará de um adicional se eu puder desativar a camada de layout do RSB, então eu poderia simplesmente carregar o RSB em sua totalidade e reutilizar 
)