Possiamo aggiungere add-on di Ember a un plugin di discourse? (come ember power select)

Sviluppatore
1

I’d like to add some ember add-ons to a plugin.

Here’s an example: Ember’s Power Select.

(This helps with drop-downs. Discourse uses select-kit, which I know is also powerful, but I find it hard to customize because its heavily abstracted in the code base. So I’d like to try power select).

In a normal Rails/Ember app, I think I would just add the add-on with:

$ ember install ember-power-select

Then I’d add stuff like the following:

hbs template:

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

javascript file that goes along with it:

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

But a Discourse plugin is not a standard Rails app. Is there something special I need to do to get it working?

3 Mi Piace
2

Well, I watched this wondering if you’d get any hints, but here we are 4 days later.

I’m pretty novice at Ember, but I’m fairly certain that you’ll be much better off if you manage to deal with the “heavily abstracted” stuff and play by those rules. Not only is pulling in other add-ons hard to figure out, but it’s also going to be hard to maintain.

1 Mi Piace
3

We are upgrading Discourse over to EmberCLI, and we are pretty close to it now:

4

Thanks, all.

I’d seen that before, but am glad to have the confirmation that it is not possible to add Ember add-ons until that upgrade is done. So it sounds like adding ember add-ons will be possible soon–once the upgrade is complete. And that sounds great.

I think that’s an interesting question. Here’s my two cents:

In terms of using the discourse “abstracted stuff” v ember add-ons: I could be wrong, but I think that using ember add-ons for specific tasks in plugins might be easier to maintain, in the cases where you are trying to do something different than what Discourse is doing already. This is my thinking:

Example here is wanting to add a brand new drop-down in a plugin. That distinction is probably important–I’m talking here about trying to do new things in a plugin that are not done in the discourse code-base, and the question is whether to start with discourse methods or a separate add-on.

A lot of times you really don’t have a choice. For example, if I wanted to add a custom field to topics, I’d always customize on top of discourse’s pre-built methods and code.

But If its a targeted piece of functionality–like a drop-down for a new purpose–I’d already be in the case where, if I use the discourse methods, I’d be adapting them to things they weren’t targeted towards.

Option 1: I could try to take the select-kit code I see in, say, category-chooser, and insert it in a new spot (that’s not about categories), and then try to customize it to be about what I want the dropdown to be about, instead of categories. This is the task that I described earlier as being tricky.

And it could be difficult to maintain–because if the discourse team changes something in how the category-chooser select-kit code works, then that could change my new customized drop-down, but in ways that could be surprising (bc I had customized it so it works slightly differently than the actual category-choose dropdown).

Option 2: I could insert something from ember that is robust but that is also made to be customized, where I can see fairly clearly how the code actually works. In that case, I might miss out cool new features that discourse might add to its drop-downs, but I would be able to stay on top of how my drop-down works more easily. So this is probably the best option, I think, if it is possible.

Option 3: Code it entirely from scratch. That’s where I’ve been tending to end up. When the coding is done, it’s nice to have code that I fully understand and can customize. But of course it takes longer, and (the initial versions at least) are unlikely to be as powerful and robust as what the discourse team or the ember team have built.

3 Mi Piace
5

Bump, and to add it would be great to add support for Ember add-ons to Theme Components …

6 Mi Piace
6

Bump.
If we add addon to discourse such
cd app/assets/javascripts/ && yarn add LIB_NAME
How will this addon be available in the plugin?

7

Mi stavo chiedendo se fosse possibile oggigiorno? (E in tal caso, come?)

2 Mi Piace
8

Mi dispiace, ma non è possibile. Gli addon di Ember possono essere aggiunti al core di Discourse, ma non tramite plugin. Potremmo eventualmente aggiungere un modo per i plugin/temi di specificare le dipendenze npm, ma non è nella roadmap immediata.

2 Mi Piace
9

Stavo letteralmente cercando la stessa cosa su Google.

– Domanda secondaria per @david: sebbene non sia disponibile tramite plugin, potremmo teoricamente aggiungere un plugin al core e poi usarlo in un plugin se stiamo auto-ospitando? Se sì, come? (ho provato ad aggiungerlo a package.json in app/assets/javascripts/discourse ma non sono riuscito a caricarlo, immagino perché mi manca qualcosa di semplice.)

1 Mi Piace
10

sì, ma non vuoi davvero fare il fork di Discourse e poi cercare di recuperare tutti i commit. Tutti coloro che l’hanno fatto si sono pentiti amaramente.

Hmm. Ma se è solo quel file, potresti immaginare di far copiare il tuo app.yml il file da qualche parte in /var/www/discourse subito dopo aver clonato Discourse. Penso di averlo già fatto per cambiare i limiti nelle impostazioni del sito.

2 Mi Piace
11

Sì, come ha menzionato @pfaffman, potresti riuscire a farlo funzionare tramite alcune modifiche ad app.yml. Dovresti assicurarti che la modifica venga apportata prima dei passaggi yarn install e assets:precompile.

Ma questo non è assolutamente supportato e potrebbe causare problemi imprevisti. Non lo consiglierei.

Per curiosità, quale componente aggiuntivo speravi di utilizzare?

2 Mi Piace
12

Non ero arrivato molto lontano, tuttavia, ho scoperto che la maggior parte dei componenti aggiuntivi più diffusi ha funzionalità già esistenti in Discourse stesso. Il fascino dei componenti aggiuntivi è che in genere la documentazione è un po’ migliore e le risorse disponibili se rimani bloccato sono piuttosto ben definite. Ad esempio, c’è una ricchezza di documentazione e problemi che sono stati “risolti” con ember-concurrency, quindi se sei un nuovo sviluppatore, avere accesso a quel componente aggiuntivo di solito significa che puoi metterti in funzione un po’ più facilmente.

Ma come ho detto, era più una curiosità che un desiderio.

1 Mi Piace
13

Quindi stai letteralmente cercando guai. Ti consiglio di non considerare alcun componente aggiuntivo finché non scopri che le risorse esistenti non soddisfano le tue esigenze.

Ma non sai che sarà compatibile con il modo in cui Discourse risolve quel problema oggi o in futuro. Se vuoi sviluppare per Discourse, allora guardare esempi di come funzionano le cose in Discourse sarà la strada da percorrere.

Non essere il tipo che cerca le chiavi sotto la lampada invece che sotto l’auto dove le ha fatte cadere perché vedi meglio sotto la lampada.