mirror of
https://github.com/discourse/discourse.git
synced 2025-01-22 11:58:30 +08:00
af30536690
Our existing PluginOutlet system allows theme/plugin developers to easily insert new content into Discourse.
Another common requirement is to **replace** existing content in Discourse. Previously this could be achieved either using template overrides, or by introducing new content via a PluginOutlet and then hiding the old implementation with CSS. Neither of these patterns are ideal from a maintainability or performance standpoint.
This commit introduces a new mode for PluginOutlets. They can now be used to 'wrap' blocks of content in core. If a plugin/theme registers a connector for the outlet, then it will be rendered **instead of** the core implementation. If needed, outlets can use `{{yield}}` to render the core implementation inside their own implementation (e.g. to add a wrapper element).
In this 'wrapper' mode, only one connector can be registered for each outlet. If more than one is registered, only one will be used, and an error will be printed to the console.
To introduce a new PluginOutlet wrapper, this kind of thing can be added to a core template:
```hbs
<PluginOutlet @name="site-logo" @defaultGlimmer={{true}} @outletArgs={{hash title=title}}>
<h1>This is the default core implementation: {{title}}</h1>
</PluginOutlet>
```
A plugin/theme can then register a connector for the `site-logo` outlet:
```hbs
{{! connectors/site-logo/my-site-logo-override.hbs }}
<h2>This is the plugin implementation: {{@outletArgs.title}}</h2>
```
Care should be taken when introducing new wrapper PluginOutlets. We need to ensure that
1) They are properly sized. In general it's preferable for each outlet to wrap a small amount of core code, so that plugin/themes only need to re-implement what they want to change
2) The `@outletArgs` are carefully chosen. It may be tempting to pass through lots of core implementation into the outletArgs (or worse, use `this` to pass a reference to the wrapping component/controller). Doing this will significantly increase the API surface area, and make it hard to refactor core. Instead, we should aim to keep `@outletArgs` to a minimum, even if that means re-implementing some very simple things in themes/plugins.
|
||
|---|---|---|
| .. | ||
| admin | ||
| bootstrap-json | ||
| confirm-new-email | ||
| deprecation-silencer | ||
| dialog-holder | ||
| discourse | ||
| discourse-common | ||
| discourse-hbr | ||
| discourse-plugins | ||
| discourse-widget-hbs | ||
| docs | ||
| ember-addons | ||
| ember-cli-progress-ci | ||
| ember-production-deprecations | ||
| locales | ||
| patches | ||
| pretty-text | ||
| select-kit | ||
| truth-helpers | ||
| wizard | ||
| .licensee.json | ||
| .npmrc | ||
| handlebars-shim.js | ||
| js-processor.js | ||
| package.json | ||
| polyfills.js | ||
| run-patch-package | ||
| service-worker.js.erb | ||
| yarn.lock | ||