Dividir el Javascript del tema en múltiples archivos

Complex theme javascript can be split into multiple files, to keep things nicely organised.

To use this functionality, simply add files to the /javascripts folder in your theme directory. These files can not be edited from the Discourse UI, so you must use the Theme CLI or source the theme from git.

Javascript files are treated exactly the same as they are in core/plugins, so you should follow the same file/folder structure. Theme files are loaded after core/plugins, so if the filenames match, the theme version will take precedence.


As an example, you can now accomplish Using Plugin Outlet Connectors from a Theme or Plugin by adding a single file to your theme:

/javascripts/my-theme/connectors/discovery-list-container-top/add-header-message.gjs

import Component from "@glimmer/component"; import { service } from
"@ember/service"; export default class HeaderMessage extends Component {
@service currentUser;

<template>
  Welcome
  {{this.currentUser.username}}
</template>
}

To use the JS API, create an initializer:

/javascripts/discourse/api-initializers/init-theme.gjs

import { apiInitializer } from "discourse/lib/api";

export default apiInitializer((api) => {
  // Your code here
});

If you need a totally different .js asset (e.g. for a web worker), check out this topic.


This document is version controlled - suggest changes on github.

27 Me gusta

Supongamos que no sé nada sobre las jerarquías de archivos de core/plugins, porque acabo de venir aquí para crear un nuevo componente temático. ¿Dónde debo buscar para averiguarlo? ¿Cuáles son las convenciones de nomenclatura para los directorios y los archivos dentro de ellos?

Solo mirando diferentes componentes temáticos que circulan, hay todo tipo de esquemas de anidación y subdirectorios diferentes. No he podido descifrar un patrón ni encontrar ninguna documentación. (Por ejemplo, ¿cuál es la diferencia entre /initializers, /api-initializers y /pre-initializers? :crying_cat_face:)

1 me gusta

Los archivos aquí usan la API. Honestamente, yo también me pregunté esto por un tiempo, ¿por qué no puedo poner los archivos api-initializers en initializers?

Sí. Es difícil de entender. Prefiero no pensar en la cantidad de veces que pasé 3 horas en algo solo para descubrir que nombré algo mal o lo puse en el lugar equivocado, o a veces, olvidé incluirlo de una de las muchas maneras que parecen existir para hacerlo (en plugin.rb, en un include en un archivo js, ¿qué ruta? ¿Necesito una extensión?).

Lo mejor es usar Instala la aplicación de consola Discourse Theme CLI para ayudarte a crear temas y que cree un esqueleto de tema para ti. Y hace que sea muy fácil depurar, ya que lo carga automáticamente en tu servidor (un servidor de producción normal) y (generalmente) recarga tu navegador automáticamente.

No tengo idea de si hay alguna diferencia (¿no creo que la haya? Pero tengo poca idea). Usaría el que está en el esqueleto del tema.

Hay un repositorio llamado all-the-themes. Puedes descargarlo y buscar ejemplos en él. Y usa siempre el que se ha modificado más recientemente.

3 Me gusta

Gran parte de EmberJS (y Rails) se basa en Convenciones. Esto es genial la mayor parte del tiempo, pero puede ser increíblemente frustrante cuando te equivocas incluso un poco, por ejemplo, al nombrar algo.

3 Me gusta

Por cierto, encontré una explicación de api-initializers/ aquí:

(Y eso lo conecta con la documentación de Ember, y entonces empieza a tener sentido).

Aún así, sería bueno tener una enumeración/explicación básica de las posibilidades de la estructura de directorios en un solo documento. (Por ejemplo, sé que connectors/ es una cosa… ¿hay más?)

Además, por cierto: la aplicación Theme CLI extrae el esqueleto de:

Solo menciona api-initializers/.

(De hecho, estoy usando la aplicación Theme CLI, pero empecé a usarla después de que ya tenía los inicios de un componente de tema, así que me salté el paso del esqueleto).

2 Me gusta