ember.js
ember.js copied to clipboard
Remove unneeded restriction around creating sub-applications
A path to unblocking:
- https://github.com/NullVoxPopuli/limber/pull/1925
- This Limber PR has a patch of the change in this EmberJS PR
While working new repl infra for https://limber.glimdown.com, I want to take a more "islands" approach, like https://astro.build -- it enables a ton of power -- however, there is an assertion that prevents using nested applications -- which kinda feels silly since we allow it via "engines".
Like with how we use modifiers and 3rd party libraries that manage DOM, whenever we use an element that has some external control of its descendents, we must make the same assumptions and allowances --- generally this is safe, as once we let 3rd party scripts manage their subtree, ember doesn't mess around in there (because when someone would instruct ember to mess around in someone else's subtree, that's when you run in to problems -- but this is easy enough to avoid).
In my use case, I have:
- host ember app (could be any other app though, even react)
- run through repl stuff
- be given an element to put somewhere
- render that element
- in my case for https://limber.glimdown.com, the element is rendered via a component.
so this component is mounting a whole new app, and nothing is is going to mess with the subtree.
This works via using the newtemplate()API for the runtime compiler:const element = await compiler.compile('gjs', code); component = template(`{{element}}`, { scope: () => ({ element }) });
- in my case for https://limber.glimdown.com, the element is rendered via a component.
so this component is mounting a whole new app, and nothing is is going to mess with the subtree.
- render that element
- be given an element to put somewhere
- run through repl stuff
Estimated Asset Sizes
Diff
Details
| This PR | main |
|---|---|
|
|
From two Chrises:
- global event dispatcher may get in the way here
Related: https://github.com/emberjs/rfcs/pull/1102
If we block this PR on the removal of the global event dispatcher, then this can't land until v7 at the latest.
I'm not sure we need to do that though, because it's a "protection", if anything
I think it is fine to merge this so long as you can confirm nested apps work as expected. Is the EventDispatcher still used for events on Input and TextArea etc?
Also that RFC should be a deprecation RFC
Also that RFC should be a deprecation RFC
I copied the deprecation template :see_no_evil:
Also that RFC should be a deprecation RFC
I copied the deprecation template 🙈
Sorry about that -- it looked different to me
The global event dispatcher was also the thing I was referring to when I said maybe we don't need the assertion anymore. I didn't remember that we still have it.
@ef4 Could we solve this for now by changing the assert to a warn that mentions the remaining things that may need the global event dispatcher?
It sounds like we would need an optional feature here. Because you'd want a way for people who've opted into never using the event dispatcher to avoid seeing a warning.
A single optional feature could:
- disable the global event dispatcher
- remove the assertion as in this PR
- make all the things that would have relied on the global event dispatcher throw instead
I think we'd want that if we were to actually deprecate the event dispatcher, but in this case, it would only warn when you create nested applications, which would enable @NullVoxPopuli's explorations.
changed to warn here: https://github.com/emberjs/ember.js/pull/20915 -- this will allow me to remove my patch in the new REPL stuff i'm working on