Add test that asserts behavior for when we try to renderComponent into the same element multiple times#21075
Add test that asserts behavior for when we try to renderComponent into the same element multiple times#21075NullVoxPopuli wants to merge 7 commits intomainfrom
Conversation
… with different contents
Estimated Asset SizesDiff --- main/out.txt 2026-02-10 02:24:22.000000000 +0000
+++ pr/./pr-21853935459/out.txt 2026-02-10 06:14:50.000000000 +0000
@@ -1,34 +1,34 @@
╔═══════╤═══════════╤═══════════╗
║ │ Min │ Gzip ║
╟───────┼───────────┼───────────╢
-║ Total │ 352.48 KB │ 203.69 KB ║
+║ Total │ 352.48 KB │ 203.64 KB ║
╚═══════╧═══════════╧═══════════╝
╔══════════════════════╤═══════════╤═══════════╗
║ @ember/* │ Min │ Gzip ║
╟──────────────────────┼───────────┼───────────╢
-║ Total │ 313.87 KB │ 181.83 KB ║
+║ Total │ 313.87 KB │ 181.79 KB ║
╟──────────────────────┼───────────┼───────────╢
-║ -internals │ 36.68 KB │ 25.99 KB ║
-║ application │ 13.24 KB │ 7.99 KB ║
+║ -internals │ 36.68 KB │ 26.02 KB ║
+║ application │ 13.24 KB │ 8.04 KB ║
║ array │ 13.05 KB │ 7.54 KB ║
║ canary-features │ 304 B │ 419 B ║
-║ component │ 2.05 KB │ 1.63 KB ║
+║ component │ 2.05 KB │ 1.59 KB ║
║ controller │ 1.96 KB │ 1.45 KB ║
║ debug │ 11.73 KB │ 8.14 KB ║
║ deprecated-features │ 31 B │ 77 B ║
║ destroyable │ 561 B │ 383 B ║
║ enumerable │ 259 B │ 387 B ║
-║ helper │ 1.08 KB │ 841 B ║
+║ helper │ 1.08 KB │ 816 B ║
║ instrumentation │ 2.43 KB │ 1.78 KB ║
-║ modifier │ 1.22 KB │ 991 B ║
+║ modifier │ 1.22 KB │ 993 B ║
║ object │ 35.98 KB │ 22.1 KB ║
║ owner │ 159 B │ 178 B ║
-║ renderer │ 630 B │ 509 B ║
-║ routing │ 59.37 KB │ 33.94 KB ║
+║ renderer │ 630 B │ 503 B ║
+║ routing │ 59.37 KB │ 33.93 KB ║
║ runloop │ 2.36 KB │ 1.5 KB ║
║ service │ 1 KB │ 858 B ║
-║ template │ 654 B │ 535 B ║
+║ template │ 654 B │ 501 B ║
║ template-compilation │ 429 B │ 366 B ║
║ template-compiler │ 123.33 KB │ 59.61 KB ║
║ template-factory │ 370 B │ 385 B ║Details
|
|
I think I need more tests -- I want to make sure updating renderComponents can update appropriately if so, this could resolve a potentially contentious issue on the RFC (brought up by @void-mAlex and @lifeart , I think?) since the current behavior is not what the RFC states, we could update the RFC and implement I wrote that replace behavior would be the behavior because I thought it would be easier 🙈 |
|
I'm afrade replace behaviour is dangerous itself, because we don't know who owns "replaced" nodes, it may cause memory leaks. I think we should append by default, or |
|
that makes sense to me and I'm happy with that direction |
|
I've added enough tests to assert append / sibling behavior -- however found a bug where if an update happens to the data used by the first (in DOM order) component, it gets moved to the bottom of the output element. This is probably very jarring if anyone has tried this usecase today. |
51489b7 to
d35a8c9
Compare
| if (existing?.glimmerResult) { | ||
| let parentElement = | ||
| into instanceof Element ? (into as unknown as SimpleElement) : (into as Cursor).element; | ||
| let firstNode = existing.glimmerResult.firstNode(); |
There was a problem hiding this comment.
the firstNode here is really the fix for the bug found be the second test in this PR
Big changes occurred since you're last review -- could you re-review?
from the RFC: https://rfcs.emberjs.com/id/1099-rendercomponent/
This is changed because implementation of the renderer did
append(and it was easier)