Modern lightweight portals for Ember
A modern take on using so-called "portals" to render things in a
different place of the DOM tree than they are logically defined in the app.
Implemented using lightweight Glimmer components and Ember's new {{in-element}},
but without its caveats.
- Ember.js v4.12 or above
- Embroider or ember-auto-import v2
``
ember install ember-stargate
There are a number of existing solutions in the Ember ecosystem for the same
problem, so why this addon you may ask?
Let's see how it compares to some of those...
#### ember-wormhole
The first addon to make portals popular in Ember uses proprietary implementation
tricks, that make it potentially less stable. Also defining portal targets in your
app is less flexible.
#### ember-elsewhere
While using only public Ember APIs, due to its requirement to use Ember's
component helper it comes with some caveats:
- you cannot send arbitrary content though the portal, it must be a single component
- you cannot use a component in block form
- the component helper does not support passing HTML attributes (as in regular angle bracket invocation)
#### in-element
While Ember starting with 3.20 (or earlier using ember-in-element-polyfill
has a built-in primitive with {{in-element}}, due to its (intentional) low-level nature it is suitable
more for usage in addons (for things like modals, tooltips, dropdowns), but using it in apps is not very ergonomic:
- it requires you to pass a reference to the target DOM element, which is less ergonomic than a CSS selector or some other
higher-level way to define the target (e.g. a target component)
- that DOM element has to _exist_ already before using {{in-element}}, so it's sensitive to rendering timings
Other than that, {{in-element}} is a very useful primitive, and in fact this addon uses it under the hood,
with just some simple higher-level abstractions on top of it!
You need two things to make a portal work: define the content that should be sent through the portal using, and the target - identified by its name - where it should be rendered to
using .
Let's take an example where we want to render a sticky footer inside application.hbs, as it will be used
across routes, but the actual content (left and right sections for action buttons etc. and a title) needs
to be defined within the actual routes;
step1.hbs:
`hbs
`
application.hbs:
`hbs
{{outlet}}
`
Note that although the footer will be rendered _after_ the portals, as it comes after the {{outlet}} at the
bottom of the DOM, this poses no problem for this addon as it explicitly supports this case: a portal's content
will not be rendered until its target is available, but then the target will immediately show the portal's content.
- @target: required argument to specify the name of the target@fallback
- : by default the portal's content will not render until the target is available.@fallback="inplace"
With the content will be rendered in place as long as the target is not available.@renderInPlace
- : if true the portal is effectively disabled, and the content is rendered in place.
- @name: required argument that identifies the target@multiple
- : by default if multiple portals refer to the same target, they will replace each other@multiple={{true}}
(in the order of rendering). With the portal's content will be appended (again in the order of rendering).@onChange
- : whenever a portal is rendered to or removed from the target, this action will be called. It will receive
the current portal count of this target as an argument.
All components have proper Glint types, which allow you when using TypeScript to get strict type checking in your templates.
Unless you are using strict mode templates (via first class component templates),
you need to import the addon's Glint template registry entries as described in the Using Addons documentation:
`ts
// e.g. types/glint.d.ts
import '@glint/environment-ember-loose';
import type StargateRegistry from 'ember-stargate/template-registry';
declare module '@glint/environment-ember-loose/registry' {
export default interface Registry
extends StargateRegistry / other addon registries / {
// local entries
}
}
``
> Note that Glint itself is still under active development, and as such breaking changes might occur. Therefore, Glint support by this addon is also considered experimental, and not covered by our SemVer contract!
See the Contributing guide for details.
This project is licensed under the MIT License.