Podemos adicionar add-ons do Ember a um plugin do Discourse? (como o ember power select)

Dev
1

Gostaria de adicionar alguns add-ons do Ember a um plugin.

Aqui está um exemplo: o Power Select do Ember.

(Isso ajuda com menus suspensos. O Discourse usa select-kit, que sei ser poderoso, mas acho difícil de personalizar porque ele é altamente abstraído na base de código. Então, gostaria de tentar o power select).

Em um aplicativo Rails/Ember normal, acho que eu apenas adicionaria o add-on com:

$ ember install ember-power-select

Depois, adicionaria coisas como a seguinte:

template hbs:

<PowerSelect @options={{this.names}} @onChange={{this.foo}} as |name|>
  {{name}}
</PowerSelect>

arquivo JavaScript que acompanha:

    import Controller from '@ember/controller';
    export default class extends Controller {
      names = ['Stefan', 'Miguel', 'Tomster', 'Pluto']
      foo() { }
    }

Mas um plugin do Discourse não é um aplicativo Rails padrão. Há algo especial que preciso fazer para fazê-lo funcionar?

2

Bem, assisti a isso imaginando se você pegaria algumas dicas, mas aqui estamos, 4 dias depois.

Sou bastante iniciante em Ember, mas tenho certeza de que você estará muito melhor se conseguir lidar com as coisas “altamente abstraídas” e seguir essas regras. Não só é difícil entender como integrar outros add-ons, como também será difícil de manter.

3

Estamos migrando o Discourse para o EmberCLI e estamos bem próximos disso agora:

4

Obrigado, pessoal.

Eu já tinha visto isso antes, mas fico feliz em ter a confirmação de que não é possível adicionar add-ons do Ember até que essa atualização seja concluída. Então, parece que será possível adicionar add-ons do Ember em breve — assim que a atualização for finalizada. Isso soa ótimo.

Acho que essa é uma questão interessante. Aqui está minha opinião:

No que diz respeito ao uso das “coisas abstraídas” do Discourse versus add-ons do Ember: posso estar errado, mas acho que usar add-ons do Ember para tarefas específicas em plugins pode ser mais fácil de manter, nos casos em que você está tentando fazer algo diferente do que o Discourse já faz. Essa é a minha lógica:

Um exemplo aqui seria querer adicionar um novo menu suspenso em um plugin. Essa distinção é provavelmente importante — estou falando de tentar fazer coisas novas em um plugin que não são feitas no código-base do Discourse, e a questão é se começar com os métodos do Discourse ou com um add-on separado.

Muitas vezes, você realmente não tem escolha. Por exemplo, se eu quisesse adicionar um campo personalizado aos tópicos, eu sempre personalizaria sobre os métodos e o código pré-construídos do Discourse.

Mas, se for uma funcionalidade específica — como um menu suspenso para um novo propósito — eu já estaria no cenário em que, se usasse os métodos do Discourse, estaria adaptando-os a coisas para as quais não foram originalmente destinados.

Opção 1: Poderia tentar pegar o código do select-kit que vejo, digamos, no category-chooser, e inseri-lo em um novo local (que não seja sobre categorias) e, em seguida, tentar personalizá-lo para ser sobre o que eu quero que o menu suspenso seja, em vez de categorias. Essa é a tarefa que descrevi anteriormente como complicada.

E pode ser difícil de manter — porque, se a equipe do Discourse mudar algo na forma como o código do select-kit do category-chooser funciona, isso poderia alterar meu novo menu suspenso personalizado, mas de maneiras surpreendentes (já que eu o personalizei para funcionar de forma ligeiramente diferente do menu suspenso real do category-chooser).

Opção 2: Poderia inserir algo do Ember que seja robusto, mas também feito para ser personalizado, onde eu possa ver com bastante clareza como o código realmente funciona. Nesse caso, eu poderia perder recursos legais novos que o Discourse possa adicionar aos seus menus suspensos, mas eu conseguiria acompanhar como meu menu suspenso funciona de forma mais fácil. Então, essa é provavelmente a melhor opção, na minha opinião, se for possível.

Opção 3: Codificar tudo do zero. É para onde eu tenho tendido a acabar. Quando a codificação está pronta, é bom ter um código que eu compreenda totalmente e possa personalizar. Mas, claro, leva mais tempo, e (as versões iniciais, pelo menos) provavelmente não serão tão poderosas e robustas quanto o que a equipe do Discourse ou a equipe do Ember construíram.

5

Bump, e seria ótimo adicionar suporte para add-ons do Ember nos Componentes de Tema…

6

Bump.
Se adicionarmos um addon ao Discourse assim:
cd app/assets/javascripts/ && yarn add LIB_NAME
Como esse addon ficará disponível no plugin?

7

Só queria saber se isso é possível hoje em dia? (E se for, como?)

8

Receio que não. Addons do Ember podem ser adicionados ao core do Discourse, mas não através de plugins. Podemos eventualmente adicionar alguma forma para plugins/temas especificarem dependências npm, mas não está no roadmap imediato.

9

Estava literalmente pesquisando a mesma coisa.

– Pergunta paralela para @david: embora não esteja disponível via plugins, poderíamos teoricamente adicionar um plugin ao core e depois usá-lo em um plugin se estivermos auto-hospedando? Se sim, como? (Tentei adicionar ao package.json em app/assets/javascripts/discourse, mas não tive sorte em carregá-lo, imagino que porque estou perdendo algo simples.)

10

sim, mas você realmente não vai querer fazer um fork do Discourse e então tentar puxar todos os commits. Todos que fizeram isso se arrependem muito de ter feito.

Hmm. Mas se for apenas um arquivo, você poderia concebivelmente ter seu app.yml copiando o arquivo de algum lugar para /var/www/discourse logo após clonar o Discourse. Acho que já fiz isso antes para alterar os limites nas configurações do site.

11

Sim, como o @pfaffman mencionou, você talvez consiga fazer funcionar por meio de algumas modificações no app.yml. Você teria que garantir que a modificação fosse feita antes das etapas de yarn install e assets:precompile.

Mas isso não é totalmente suportado e pode quebrar coisas inesperadas. Eu não recomendaria.

Por curiosidade, qual addon você esperava usar?

12

Ainda não tinha chegado tão longe, no entanto, descobri que a maioria dos add-ons populares tem funcionalidades que já existem no próprio Discourse. O apelo dos add-ons é que, geralmente, a documentação é um pouco melhor e os recursos disponíveis quando você fica preso são bem desenvolvidos. Por exemplo, há uma riqueza de documentação e problemas que são “resolvidos” com ember-concurrency, então, se você é um novo desenvolvedor, ter acesso a esse add-on geralmente significa que você pode começar a trabalhar um pouco mais facilmente.

Mas, como eu disse, era mais uma curiosidade do que uma necessidade.

13

Então você está literalmente procurando por problemas. Eu recomendo não considerar nenhum add-on até que você descubra que os recursos existentes não atendem às suas necessidades.

Mas você não sabe se ele será compatível com a forma como o Discourse resolve esse problema hoje ou no futuro. Se você quer desenvolver para o Discourse, então olhar para exemplos de como as coisas funcionam no Discourse será o caminho a seguir.

Não seja o cara que procura as chaves debaixo da lâmpada em vez de debaixo do carro onde as deixou, porque você enxerga melhor debaixo da lâmpada.