Houve uma discussão de alguém há um tempo sobre desenvolver em um tema vs um plugin. A parte Rails do https://www.pfaffmanager.com/ está começando a ficar bastante estável, e o que eu gostaria de fazer é mover o desenvolvimento da parte Rails para um componente de tema. Isso está funcionando muito bem, e as alterações em templates e inicializadores no componente de tema estão substituindo o plugin como esperado. Mas, as alterações em javascripts/discourse/components/server-item.js.es6 no tema não estão substituindo os mesmos arquivos no plugin.
Suponho que eu poderia remover completamente as coisas do Ember do plugin e tê-las apenas no tema, mas isso parece um dia de trabalho para mover todas essas peças, testar e enviar para o servidor. Será que estou perdendo algo bobo? Devo aceitar e remover completamente as coisas que eu gostaria no componente de tema do plugin? Devo apenas mantê-las todas no plugin?
Ter o mesmo código tanto no componente do tema quanto no plugin parece um pouco estranho para mim - na minha opinião, seria melhor decidir entre componente do tema/plugin e, em seguida, ir com tudo. Sobrescrever arquivos inteiros não é algo que fazemos, e não é algo que recomendamos. Para sobrescrever o comportamento do core/plugin, seu componente de tema deve usar métodos como api.modifyClass.
Suspeito que a causa raiz aqui é que os módulos ES6 do plugin são prefixados de forma diferente dos módulos do core/tema. Executando isso em seu site, vejo que os módulos são prefixados com plugin. Suspeito que, se você habilitasse o componente do tema, veríamos outra entrada, mas com um prefixo diferente.
Concordo em geral, no entanto, existem alguns casos extremos:
Onde o volume de alterações no JavaScript supera em muito as alterações no back-end, caso em que os Componentes de Tema são uma ótima maneira de implantar e testar código RAPIDAMENTE.
Onde a maior parte da funcionalidade pode ser entregue no Componente de Tema base, mas a adição de um plugin complementar pode adicionar recursos adicionais que não são possíveis apenas em JavaScript. Emprego essa técnica em Visualizações de Lista de Tópicos, onde o Componente faz 90% do que o add-on é capaz, mas se você também adicionar o plugin, obterá alguns recursos adicionais interessantes.
Dito isso, empacotar tudo em um plugin faz sentido, pois há menos confusão na configuração e instalação e tudo está sempre em sincronia.
Mas mesmo no seu cenário de plugin+tema, eu não duplicaria o código Ember tanto no plugin quanto no tema. Portanto, eu precisaria extrair pelo menos a maioria dos templates, inicializadores e componentes do plugin e tê-los apenas no componente do tema.
Como sou o único que vai se confundir com a configuração, isso não é um grande problema. Eu realmente gosto da ideia de poder testar algumas novidades de front-end no site ao vivo, alternando para a versão beta do tema.
O outro problema que vejo é com os testes qunit. (Vou fingir que consigo adicionar algum, o que é outro problema totalmente diferente; acho que meu problema é que não sei como popular os testes com dados para as coisas a serem exibidas…). Acho que se eu tiver testes qunit no meu plugin, eles serão executados quando eu fizer o push para o github (porque tenho certeza de que já vi os meus que falharam falharem).
Posso obter um componente de tema para fazer o mesmo?
Tecnicamente deveria ser possível, mas acho que ainda não temos fluxos de trabalho de ações do GitHub prontos para temas. O teste de temas está passando por uma reformulação no momento (para a transição do ember-cli), mas depois disso, talvez possamos adicionar alguns modelos de fluxo de trabalho de teste de temas em GitHub - discourse/.github.
Cenário: Quero substituir um template implantado em um plugin. Mas quero substituir de uma forma controlada por código.
Então, tentei enviar o novo template em um componente de tema. O mesmo arquivo existe em um plugin (mas é diferente).
Isso parece funcionar na minha instalação de nuvem de desenvolvimento, mas não em uma instalação de produção padrão.
Portanto, é justo dizer que você não pode prever se isso será bem-sucedido ou não com templates? Ou seja, o pipeline de ativos é tal que você não pode prever qual ‘template’ prevalecerá, pois não há precedência predefinida ou previsível?
Eu estava trabalhando com alguma suposição estranha de que havia uma hierarquia, algo como:
core
plugin
componente de tema
alterações locais do site
E se você colocasse um “arquivo” com o mesmo caminho e nome em um nível posterior dessa hierarquia, ele substituiria qualquer definição “anterior”.
Mas minha suposição provavelmente não é segura?
A única solução “empacotada” (desconsiderando alterações locais do site) é, portanto, fazer um fork do plugin e fazer as alterações diretamente nele?
Isso, em alguns sentidos, seria uma pena, pois aumentaria o esforço de manutenção para customizações, já que você teria que mesclar as alterações do repositório principal do plugin periodicamente…
A melhor maneira seria atualizar o plugin existente e dar a ele um ponto de saída de plugin e/ou uma API de personalização que o componente do tema possa usar.
Meu comentário acima foi especificamente sobre substituir arquivos JS inteiros (ou seja, módulos es6). Isso não é possível. O pipeline de ativos prefixa automaticamente os módulos de plugin/tema com o nome/ID do plugin/tema, portanto, é impossível criar um conflito com o núcleo.
Para modelos, sabemos que as pessoas (incluindo nós, em algumas situações) os substituem, então provavelmente manteremos esse sistema funcionando. Mas, por favor, lembre-se de que é um hack. Se o componente/controlador original mudar seu comportamento, seu modelo substituído provavelmente fará com que o site quebre.
Em geral, acho que a hierarquia que você mencionou (núcleo, plugin, tema) deve ser verdadeira - então, se você estiver vendo algo diferente, por favor, compartilhe os detalhes dos caminhos dos arquivos no plugin e no tema.
