Posticipare il caricamento di JavaScript in Themes e Components

Sviluppatore
1

Grazie a @david, abbiamo un pattern molto pulito per il caricamento “eager” di JavaScript nei temi.

Ciò significa che basta inserire i file *.js.es6 nella directory javascripts e funzionano esattamente come i plugin: è glorioso.

Ad esempio, ecco come si crea un inizializzatore ora, con il 100% di parità rispetto ai plugin:

  • Crea un file chiamato /javascripts/discourse/initializers/my-init.js.es6
import { withPluginApi } from "discourse/lib/plugin-api";

function initialize(api) {
  // init via api qui
}

export default {
  name: "discourse-otp",

  initialize() {
    withPluginApi("0.8.28", initialize);
  }
};

Questa è una funzionalità enormemente importante perché ora possiamo suddividere temi grandi e complessi in molte parti, ottenendo linting, evidenziazione della sintassi e tutte le altre cose positive.

Tuttavia, in alcuni casi potremmo voler opzionalmente distribuire un payload JS.

Ad esempio, diciamo che stiamo decorando i post, ma solo quelli con un markdown molto specifico. Non ha senso scaricare una libreria complessa da 100KB finché non sappiamo che la useremo.

Ho risolto questo problema nel mio componente seguendo questo elegante cambiamento:

https://github.com/discourse/discourse/commit/719a93c312b9caa6c71de22d67f1ce1a78c1c8b2

Con:

import loadScript from "discourse/lib/load-script";

function generateOtp($elem) {
  loadScript(settings.theme_uploads.jsotp).then(() => {
     // il codice va qui
  });
}

Questo ha significato:

  1. Dovevo aggiungere .js alle “estensioni autorizzate per il tema”
  2. Dovevo aggiungere una bypass alla CSP per la risorsa specifica in “content security policy script src”
  3. Dovevo nominare la risorsa nel mio about.json

Come autore di componenti per i temi, è semplicemente troppo attrito, perché non hai alcuna possibilità nel gioco della distribuzione richiedendo questo livello di abilità ninja.

Penso che per renderlo utilizzabile ci siano 2 alternative tra cui possiamo scegliere:

  1. Possiamo insegnare al sistema di applicare automaticamente la CSP alle risorse .js nei temi attivi e, per impostazione predefinita, permettere ai temi di caricare .js

  2. Possiamo spostarci verso qualcosa come javascript_cache che usa il JS del tema non differito.

Sono un po’ propenso alla soluzione 1, perché aggiungere .js alle estensioni autorizzate per il tema sembra banale e l’applicazione automatica della CSP non dovrebbe essere impossibile.

@pmusaraj / @Johani / @Osama, avete qualche pensiero a riguardo?

10 Mi Piace
2

The ability to reference theme uploads in JS is a great addition! :100:

This makes a lot of sense to me because anything you can do in a .js file can already be done in files in the javascripts folder of the theme. So, I don’t see any harm in allowing themes to have .js uploads by default.

7 Mi Piace
3

Riattivazione perché l’unica cosa rimasta qui è insegnare a CSP di consentire i caricamenti js del tema. I file js sono consentiti per impostazione predefinita come caricamenti del tema da un po’ di tempo.

Se i caricamenti js del tema non sono bloccati da CSP, allora componenti come Image Annotator - Allows you to annotate images in the previewer non avranno bisogno di caricare le loro dipendenze sulla homepage (~170kb gzip). Quel componente, ad esempio, avrà solo bisogno di caricare quelle dipendenze se il composer viene aperto. Inoltre, non avrà mai bisogno di caricarle per gli spettatori anonimi.

Inoltre, questa modifica “permetterebbe” ai temi di avere file web worker che possono fare un po’ di lavoro pesante fuori dal thread principale.

Consentire tra virgolette sopra perché puoi averli come blob, ma è molto più bello averli in file separati invece di pasticciare con javascript in una stringa.

4 Mi Piace
4

Ho delle buone notizie qui, è un po’ complicato da implementare ma alla fine supporteremo gli asset JS locali per i casi in cui vogliamo utilizzare web worker nei componenti del tema.

Non c’è nessun altro modo pulito per far passare questo attraverso la CSP, servire i file worker dallo stesso dominio risolve il gigantesco buco qui.

3 Mi Piace
5

Nota… questo è stato spedito :confetti_ball:

5 Mi Piace