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
ngTemplateOutlet modifies its initial context when getting a new context whose shape is the same #24515
Comments
I suspect this code is wrong: https://github.com/angular/angular/blob/master/packages/common/src/directives/ng_template_outlet.ts#L74-L93 |
I got my static constants with some never changing content mutated by this and whole app got messed up by just using ngTemplateOutlet, built in trusted directive. Cannot believe this got no traction for a year, please do something about it. I understand the idea of optimizing it so it doesn't recreate the view, but this could be done much more safely. |
Currently `EmbeddedViewRef.context` is read-only which means that the only way to update it is to mutate the object which can lead to some undesirable outcomes if the template and the context are provided by an external consumer (see angular#24515). These changes make the property writeable since there doesn't appear to be a specific reason why it was readonly to begin with.
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 angular#24515.
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 angular#24515.
Currently `EmbeddedViewRef.context` is read-only which means that the only way to update it is to mutate the object which can lead to some undesirable outcomes if the template and the context are provided by an external consumer (see angular#24515). These changes make the property writeable since there doesn't appear to be a specific reason why it was readonly to begin with.
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 angular#24515.
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 angular#24515.
Currently `EmbeddedViewRef.context` is read-only which means that the only way to update it is to mutate the object which can lead to some undesirable outcomes if the template and the context are provided by an external consumer (see angular#24515). These changes make the property writeable since there doesn't appear to be a specific reason why it was readonly to begin with.
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 angular#24515.
Currently `EmbeddedViewRef.context` is read-only which means that the only way to update it is to mutate the object which can lead to some undesirable outcomes if the template and the context are provided by an external consumer (see #24515). These changes make the property writeable since there doesn't appear to be a specific reason why it was readonly to begin with. 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. |
I'm submitting a...
Current behavior
ngTemplateOutlet modifies the previous context when getting a new context whose shape is the same.
Expected behavior
ngTemplateOutlet should not change its context parameters in any case.
Minimal reproduction of the problem with instructions
https://stackblitz.com/edit/angular-ymixqh?file=src%2Fapp%2Fapp.component.ts
Click on "Swap". The contexts of the ngTemplateOutlets directives are swapped.
We should see "name = context 2" on the first line and "name = context 1" on the second line, but both lines show "name = context 2". The first ngTemplateOutlet has changed the
name
property of the first context when receiving the second context.Note that the problem does not happen if the contexts do not have exactly the same set of properties (for example, when adding "foo: true" in the first context but not in the second, the behavior of ngTemplateOutlet is correct).
What is the motivation / use case for changing the behavior?
It is clearly a bug. It is confusing.
Environment
The text was updated successfully, but these errors were encountered: