-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Remove unneeded restriction around creating sub-applications #20910
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Remove unneeded restriction around creating sub-applications #20910
Conversation
Development AssetsDiff --- main/out.txt 2025-05-05 18:22:36.000000000 +0000
+++ pr/./pr-15116085569/out.txt 2025-05-19 14:46:34.000000000 +0000
@@ -1,10 +1,10 @@
2.2M └─┬ .
-1015K ├─┬ @ember
+1014K ├─┬ @ember
205K │ ├─┬ -internals
- 69K │ │ ├─┬ views
- 64K │ │ │ └─┬ lib
+ 68K │ │ ├─┬ views
+ 63K │ │ │ └─┬ lib
23K │ │ │ ├── mixins
- 22K │ │ │ ├── system
+ 21K │ │ │ ├── system
10K │ │ │ ├── views
4.3K │ │ │ └── compat
35K │ │ ├─┬ runtime Details
|
From two Chrises:
|
Related: emberjs/rfcs#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 |
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:
|
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 |
A path to unblocking:
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:
so this component is mounting a whole new app, and nothing is is going to mess with the subtree.
This works via using the new
template()
API for the runtime compiler: