fix: ENG-8176 fallback UI for unknown elements #3892
Conversation
🦋 Changeset detectedLatest commit: 8d87cce The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
View your CI Pipeline Execution ↗ for commit 8d87cce.
☁️ Nx Cloud last updated this comment at |
|
Hey, @shubham-builder. you can use this command to run |
There was a problem hiding this comment.
@shubham-builder can you add a test case with an example of such an "unknown element" so we can confirm that this PR fixes it?
packages/sdks/output/angular/scripts/generate-dynamic-renderer.mjs
Outdated
Show resolved
Hide resolved
|
@sidmohanty11 @samijaber Updated the code so the unknown-element is placed correctly within the dynamic-renderer. Also added content assertion check in the test. |
| @@ -190,6 +195,8 @@ export default class DynamicRenderer { | |||
| switch (this.TagName) { | |||
| ${htmlElements.map((el) => `case '${el}': this.TagName = Dynamic${capitalize(el)}; break;`).join('\n ')} | |||
There was a problem hiding this comment.
with this feature now, we should be able to get rid of manual creation of components and this line here (entire switch case)
There was a problem hiding this comment.
This should also fix Angular 16 tests throwing Input annotation errors saying TagName is not defined in other dynamic components
There was a problem hiding this comment.
That would mean using the dynamic-unknown-element for all the known elements as well
So in this case even dynamic-p will render as dynamic-unkonwn-element unless it's code is updated accordingly with support of void elements.
Do we want that in same pr or I think we can take it as separate task to eliminate this switch case and use single function to handle known and unknown elements.
| } | ||
|
|
||
| ngAfterViewInit(){ | ||
| this.renderer.appendChild(this.hostRef.nativeElement.children[1], this.hostRef.nativeElement.children[0]); |
There was a problem hiding this comment.
how does this work? Could you please explain? Can we somehow do this inside ngOnInit? I'm afraid if we'll lose SSRing children with this
There was a problem hiding this comment.
Parent component populates the and the is created inside the ngOnInit (which is necessary as input are initialised there). This changes the order in which the elements should be inserted.
So once the view is created this fixes the order of elements( moving the element to be child of unknown element)
Description
Added fallback UI for unknown element in angular dynamic renderer
Screenshot
If relevant, add a screenshot or two of the changes you made.