fix: allow context of EmbeddedViewRef to be changed and avoid mutating context in NgTemplateOutlet#40360
fix: allow context of EmbeddedViewRef to be changed and avoid mutating context in NgTemplateOutlet#40360crisbeto wants to merge 2 commits intoangular:masterfrom
Conversation
8f83124 to
38174ea
Compare
atscott
left a comment
There was a problem hiding this comment.
reviewed-for: fw-core
reviewed-for: public-api
reviewed-for: size-tracking
|
FYI - it looks like there might be a real failure in g3 due to this change. I haven't gotten a chance to investigate yet, but the bit of code in the template that seems to be broken is and then the failure is |
38174ea to
e6e6d67
Compare
e6e6d67 to
f7ff356
Compare
This comment has been minimized.
This comment has been minimized.
AndrewKushnir
left a comment
There was a problem hiding this comment.
Reviewed-for: public-api
| * The context for this view, inherited from the anchor element. | ||
| */ | ||
| abstract get context(): C; | ||
| abstract context: C; |
There was a problem hiding this comment.
Strictly this is a breaking change in the case that this class EmbeddedViewRef was extended. See playground.
There was a problem hiding this comment.
Do we consider this as something that's meant to be extended, considering that the framework itself constructs it? I believe we've had cases in the past where we've said that constructor changes (also something that would be breaking for extending consumers) aren't breaking.
There was a problem hiding this comment.
I'm not sure but we could avoid the breaking change by just adding a setter, rather than making it a property.
There was a problem hiding this comment.
I wanted to avoid getters and setters, because they generate more code in ES5.
There was a problem hiding this comment.
And actually adding an abstract setter would also be a breaking change!
There was a problem hiding this comment.
Unless a class is specifically noted that it’s meant to be extended, we don’t consider breaking extenders a breaking change. See #32057 (comment)
There was a problem hiding this comment.
So if we are cool that no one outside the framework is going to extend this then I am cool with it
petebacondarwin
left a comment
There was a problem hiding this comment.
Reviewed-for: public-api
| * The context for this view, inherited from the anchor element. | ||
| */ | ||
| abstract get context(): C; | ||
| abstract context: C; |
There was a problem hiding this comment.
So if we are cool that no one outside the framework is going to extend this then I am cool with it
jessicajaniuk
left a comment
There was a problem hiding this comment.
reviewed-for: size-tracking
Currently `NgTemplateOutlet` recreates its view if its template is swapped out or a context object with a different shape is passed in. If an object with the same shape is passed in, we preserve the old view and we mutate the previous object. This mutation of the original object can be undesirable if two objects with the same shape are swapped between two different template outlets. The current behavior is a result of a limitation in `core` where the `context` of an embedded view is read-only, however a previous commit made it writeable. These changes resolve the context mutation issue and clean up a bunch of unnecessary logic from `NgTemplateOutlet` by taking advantage of the earlier change. Fixes #24515. PR Close #40360
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Currently
NgTemplateOutletrecreates its view if its template is swapped out or a context object with a different shape is passed in. If an object with the same shape is passed in, we preserve the old view and we mutate the previous object. This mutation of the original object can be undesirable if two objects with the same shape are swapped between two different template outlets.The current behavior is a result of a limitation in
corewhere thecontextof an embedded view is read-only.These changes are split up into two commits which aim to resolve the issue:
EmbeddedViewRef.contextwriteable so that the object doesn't have to be mutated anymore and there didn't seem to be a good reason why it was read-only to begin with.NgTemplateOutlet.Fixes #24515.