Desenvolvendo Plugins Mais Rápido Separando o Frontend em um Componente de Tema

Eu já perguntei anteriormente sobre como configurar o ambiente local para codificar mais rapidamente ao desenvolver um plugin, e sei que outros também perguntaram.

Tenho usado um novo fluxo de trabalho que tem funcionado muito bem e pensei em compartilhar caso seja útil para outros. Não resolve tudo, mas torna as coisas muito mais agradáveis. Aqui estão os detalhes:

Primeiro, meu problema anterior:

Para desenvolver um plugin, eu tinha que codificar a partir de uma instância local do Discourse, e isso era muito lento porque: 1) qualquer alteração nos arquivos exigia o recarregamento da página, e meu computador fazia isso muito lentamente ao executar o Discourse (cerca de 30 segundos por recarregamento de página), 2) o site local do Discourse para desenvolvimento em que eu testava era muito lento (lento para navegar, etc.), e 3) qualquer alteração no código do plugin de backend exigia parar o servidor e reiniciar - e isso podia levar alguns minutos. Durante todo esse tempo, a ventoinha do meu computador ficava a todo vapor.

Como resultado, provavelmente levaria uma hora de codificação para fazer o que normalmente eu conseguiria codificar em cerca de 10 minutos com um fluxo de trabalho suave.


Minha Solução

Em contraste com o desenvolvimento de um plugin, o fluxo de trabalho para codificar um componente de tema é incrível, graças à Discourse theme CLI. (Meus passos para usá-la estão aqui.) É rápido e suave.

Por que codificar um tema ou componente de tema é tão mais rápido e fácil

Com a ferramenta theme CLI, você pode codificar um tema localmente, mas “observá-lo” (ou seja, executar o tema) em um site ativo (seja seu site real, seu site real apenas em modo de visualização, ou um site de teste ativo que você configurou).

Portanto, você não precisa realmente executar o Discourse em sua máquina - e, consequentemente, minha máquina não fica lenta como ficaria com um plugin. E sempre que você faz uma alteração, basta atualizar o site ativo ao qual está conectado, e a alteração estará lá.

Então, o que eu percebi: a maior parte do tempo quando estou codificando um plugin, é realmente nas coisas de front-end (arquivos hbs, arquivos javascript, etc.). E apenas uma pequena parte é gasta nas coisas de backend (configuração de rotas, criação de campos personalizados, etc.).

Em vez de codificar tudo junto, então, apenas mova toda a codificação de front-end para um componente de tema, para aproveitar o fluxo de trabalho do componente de tema.

Quando eu tiver que atualizar as coisas de backend no plugin, então eu tenho que codificar no plugin novamente - mas isso é apenas cerca de 20% do tempo (no meu desenvolvimento de plugin, de qualquer forma). Permitindo-me agora gastar 80% do meu tempo com o fluxo de trabalho muito mais agradável do componente de tema.

Quando chegar a hora de mover tudo para produção, eu posso:

  • manter o componente de tema e o plugin separados, e apenas usá-los ambos nos sites relevantes do Discourse, ou
  • se for importante ter todo o código em um só lugar, nesse ponto mover o código do componente de tema para o plugin. Admito que isso pode ser um pouco tedioso, mas você só precisaria fazer isso quando estiver pronto para atualizar para produção, enquanto desfruta do fluxo de trabalho mais rápido do componente de tema.

É isso.

Não é revolucionário. Mas tornou as coisas muito melhores em algo que me atrapalhou por um tempo.

7 curtidas

Sim, essa é uma boa abordagem.

Eu usei essa abordagem em Topic List Previews por um tempo, movendo o máximo possível da funcionalidade para o TC e tornando-o independente. Recursos adicionais que exigem modificações de API, em seguida, vão para um plugin e os usuários são incentivados a instalá-lo também para aproveitá-los (se puderem).

O único problema com essa abordagem é se você estiver compartilhando seu código e a modificação da API for uma necessidade, então você terá que garantir que alguém instale ambos os componentes. Dividi-los em dois não é a maneira mais conveniente para as pessoas consumirem seu trabalho, potencialmente, então eu ainda acho que, em última análise, uma única instalação de plugin ainda é a melhor abordagem para trabalho de código aberto dessa natureza.

Se for apenas para o seu próprio site, então, com certeza, isso é ótimo!

3 curtidas

Sim, certamente há situações em que, no final, você deseja um único codebase. O momento de epifania que tive foi que, mesmo que eu quisesse um único codebase no final, eu poderia codificar todas as coisas de front-end no componente de tema e, depois que isso estivesse funcionando, movê-lo para o plugin. Um pouco tedioso, mas no geral muito melhor para mim porque ainda passo a maior parte do meu tempo codificando no fluxo de trabalho do componente de tema.

2 curtidas