[MGNLFE-361] [Angular] ngOnChanges function is not triggered on dynamic components Created: 20/Oct/22 Updated: 01/Nov/22 Resolved: 28/Oct/22 |
|
| Status: | Closed |
| Project: | Magnolia Frontend Helpers |
| Component/s: | Angular Renderer |
| Affects Version/s: | 1.3.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Critical |
| Reporter: | Canh Nguyen | Assignee: | Canh Nguyen |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
| Σ Time Spent: | 2d | Time Spent: | 2d |
| Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
| Attachments: |
|
|||||||||||||||||||||||||
| Sub-Tasks: |
|
|||||||||||||||||||||||||
| Template: | ||||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
|||||||||||||||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
|||||||||||||||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
|||||||||||||||||||||||||
| Date of First Response: | ||||||||||||||||||||||||||
| Epic Link: | SPA Editor Backlog | |||||||||||||||||||||||||
| Team: |
| Description |
|
ngOnChanges functions on components that are rendered by @magnolia/angular-editor are not triggered, so logic that is required when input/output changes cannot be executed. |
| Comments |
| Comment by Canh Nguyen [ 26/Oct/22 ] |
According to this quote, @magnolia/angular-editor renders components from component mappings dynamically, so we cannot implement ngOnChanges to listen to change event. I've also checked other lifecycle hooks:
So developers can implement the logic in ngAfterViewInit if the logic needs to call once, or they can use EventEmitter to subscribe for changes. Note: If going with EventEmitter (or implement Subject API in RxJS), it needs to be unsubscribed when the component is destroyed to prevent memory leak. |
| Comment by Christopher Zimmermann [ 28/Oct/22 ] |
|
Closing as "Won't Fix" for the reasons listed above. Workaround: Developers can implement the logic in ngAfterViewInit if the logic needs to call once, or we can use EventEmitter to subscribe for changes. Note: If going with EventEmitter (or implement Subject API in RxJS), you need to unsubscribe when the component is destroyed. |