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

Sviluppatore
1

Vorrei aggiungere alcuni add-on Ember a un plugin.

Ecco un esempio: Power Select di Ember.

(Questo aiuta con i menu a tendina. Discourse utilizza select-kit, che so essere anch’esso potente, ma trovo difficile personalizzarlo perché è fortemente astratto nel codice sorgente. Quindi vorrei provare Power Select).

In un’applicazione Rails/Ember normale, penso che basterebbe aggiungere l’add-on con:

$ ember install ember-power-select

Poi aggiungerei cose come le seguenti:

template hbs:

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

file JavaScript associato:

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

Ma un plugin Discourse non è un’applicazione Rails standard. C’è qualcosa di speciale che devo fare per farlo funzionare?

3 Mi Piace
2

Beh, l’ho guardato chiedendomi se avresti ricevuto qualche indizio, ma eccoci qui, quattro giorni dopo.

Sono piuttosto alle prime armi con Ember, ma sono abbastanza certo che starai molto meglio se riesci a gestire le parti “fortemente astratte” e rispetti quelle regole. Non solo è difficile capire come integrare altri add-on, ma sarà anche difficile da mantenere.

1 Mi Piace
3

Stiamo aggiornando Discourse a EmberCLI e siamo ormai molto vicini:

4

Grazie a tutti.

L’avevo già letto, ma sono felice di avere la conferma che non è possibile aggiungere add-on Ember fino al completamento di tale aggiornamento. Quindi sembra che l’aggiunta di add-on Ember diventerà possibile a breve, una volta completato l’aggiornamento. E questo è un ottimo risultato.

Penso che sia una domanda interessante. Ecco il mio punto di vista:

Per quanto riguarda l’uso della “roba astratta” di Discourse rispetto agli add-on Ember: potrei sbagliarmi, ma penso che utilizzare add-on Ember per compiti specifici nei plugin possa essere più facile da mantenere, nei casi in cui si cerca di fare qualcosa di diverso da ciò che Discourse fa già. Ecco il mio ragionamento:

L’esempio qui è voler aggiungere un nuovo menu a discesa in un plugin. Questa distinzione è probabilmente importante: sto parlando di cercare di fare cose nuove in un plugin che non sono già presenti nel codice di Discourse, e la domanda è se iniziare con i metodi di Discourse o con un add-on separato.

Spesso non si ha davvero scelta. Ad esempio, se volessi aggiungere un campo personalizzato ai topic, mi baserei sempre sui metodi e sul codice preesistenti di Discourse.

Ma se si tratta di una funzionalità mirata, come un menu a discesa per un nuovo scopo, mi troverei già in una situazione in cui, se usassi i metodi di Discourse, li adatterei a scopi per cui non erano stati pensati.

Opzione 1: Potrei provare a prendere il codice select-kit che vedo, ad esempio, in category-chooser, inserirlo in una nuova posizione (non relativa alle categorie) e poi cercare di personalizzarlo per adattarlo a ciò che voglio che il menu a discesa faccia, invece che alle categorie. Questo è il compito che ho descritto prima come complicato.

E potrebbe essere difficile da mantenere: perché se il team di Discourse modifica qualcosa nel funzionamento del codice select-kit di category-chooser, ciò potrebbe alterare il mio nuovo menu a discesa personalizzato, ma in modi imprevedibili (poiché lo avevo personalizzato in modo che funzioni leggermente diversamente dal menu a discesa di category-chooser).

Opzione 2: Potrei inserire qualcosa di Ember che sia robusto ma anche progettato per essere personalizzato, dove posso vedere chiaramente come funziona effettivamente il codice. In tal caso, potrei perdere alcune nuove funzionalità interessanti che Discourse potrebbe aggiungere ai suoi menu a discesa, ma riuscirei a tenere sotto controllo il funzionamento del mio menu a discesa più facilmente. Quindi questa è probabilmente l’opzione migliore, penso, se è possibile.

Opzione 3: Scriverlo interamente da zero. È qui che tendo a finire. Quando la codifica è completata, è piacevole avere un codice che comprendo appieno e posso personalizzare. Ma ovviamente ci vuole più tempo, e (almeno nelle versioni iniziali) è improbabile che sia potente e robusto quanto quello costruito dal team di Discourse o dal team di Ember.

3 Mi Piace
5

Sollevato, e sarebbe ottimo aggiungere il supporto per gli add-on di Ember ai componenti del tema…

6 Mi Piace
6

Aggiornamento.
Se aggiungiamo un addon a Discourse con un comando come
cd app/assets/javascripts/ && yarn add LIB_NAME
come sarà disponibile questo addon nel 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.