fix(core): incorrect error reported when trying to re-create view which had an error during creation #43005
+44
−2
Conversation
crisbeto
force-pushed
the
41383/incomplete-first-pass-error
branch
from
1096454
to
fc546dd
crisbeto
reviewed
Jul 31, 2021
| @@ -30,7 +30,7 @@ | |||
| "master": { | |||
| "uncompressed": { | |||
| "runtime-es2015": 1190, | |||
| "main-es2015": 136546, | |||
| "main-es2015": 137055, | |||
There's only one line that affects the runtime in this PR so I doubt that the size difference comes from it.
AndrewKushnir
approved these changes
Aug 2, 2021
@crisbeto thanks for the fix
Reviewed-for: fw-core, size-tracking
| fixture.detectChanges(); | ||
| }).toThrowError(/No provider for DoesNotExist/); | ||
|
|
||
| expect(() => { |
Nit: I'd propose adding a quick comment here to describe why we do the second check (which looks the same as the previous one), i.e. that it's intentional.
atscott
approved these changes
Aug 2, 2021
reviewed-for: size-tracking
|
FYI, the presubmit went well for the changes in this PR, the changes were reviewed/approved, adding this PR to the merge queue. |
|
Ah, sorry, I think there is a minor comment related to the tests that would be great to address, so I'm adding the "cleanup" label for now. Another presubmit should not be required since additional changes would be in tests only. |
…ch had an error during creation Currently if a view throws an error during creation mode, we mark it as `incompleteFirstPass` so that we can try to recover later. The recovery is only possible inside component views. The problem is that when this was introduced, I forgot to flip the `firstCreatePass` when an error is thrown which meant that calling `renderView` on the same component again is allowed. It will eventually hit an assertion which can be confusing for the end user. This issue only manifests itself when rendering views "manually" through `ViewContainerRef` (e.g. using `NgIf`). These changes flip the `firstCreatePass` back to false on errors so that trying to re-render the same view will throw an error which is consistent to the one that broke the view during creation. Fixes angular#41383.
…iew which had an error during creation
crisbeto
force-pushed
the
41383/incomplete-first-pass-error
branch
from
fc546dd
to
19a1e13
|
The feedback has been addressed. |
atscott
added a commit
that referenced
this issue
Aug 4, 2021
…ch had an error during creation (#43005) Currently if a view throws an error during creation mode, we mark it as `incompleteFirstPass` so that we can try to recover later. The recovery is only possible inside component views. The problem is that when this was introduced, I forgot to flip the `firstCreatePass` when an error is thrown which meant that calling `renderView` on the same component again is allowed. It will eventually hit an assertion which can be confusing for the end user. This issue only manifests itself when rendering views "manually" through `ViewContainerRef` (e.g. using `NgIf`). These changes flip the `firstCreatePass` back to false on errors so that trying to re-render the same view will throw an error which is consistent to the one that broke the view during creation. Fixes #41383. PR Close #43005
|
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. |
TeriGlover
added a commit
to TeriGlover/angular
that referenced
this issue
Sep 16, 2021
…ch had an error during creation (angular#43005) Currently if a view throws an error during creation mode, we mark it as `incompleteFirstPass` so that we can try to recover later. The recovery is only possible inside component views. The problem is that when this was introduced, I forgot to flip the `firstCreatePass` when an error is thrown which meant that calling `renderView` on the same component again is allowed. It will eventually hit an assertion which can be confusing for the end user. This issue only manifests itself when rendering views "manually" through `ViewContainerRef` (e.g. using `NgIf`). These changes flip the `firstCreatePass` back to false on errors so that trying to re-render the same view will throw an error which is consistent to the one that broke the view during creation. Fixes angular#41383. PR Close angular#43005
TeriGlover
added a commit
to TeriGlover/angular
that referenced
this issue
Sep 22, 2021
…ch had an error during creation (angular#43005) Currently if a view throws an error during creation mode, we mark it as `incompleteFirstPass` so that we can try to recover later. The recovery is only possible inside component views. The problem is that when this was introduced, I forgot to flip the `firstCreatePass` when an error is thrown which meant that calling `renderView` on the same component again is allowed. It will eventually hit an assertion which can be confusing for the end user. This issue only manifests itself when rendering views "manually" through `ViewContainerRef` (e.g. using `NgIf`). These changes flip the `firstCreatePass` back to false on errors so that trying to re-render the same view will throw an error which is consistent to the one that broke the view during creation. Fixes angular#41383. PR Close angular#43005
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Currently if a view throws an error during creation mode, we mark it as
incompleteFirstPassso that we can try to recover later. The recovery is only possible inside component views.The problem is that when this was introduced, I forgot to flip the
firstCreatePasswhen an error is thrown which meant that callingrenderViewon the same component again is allowed. It will eventually hit an assertion which can be confusing for the end user. This issue only manifests itself when rendering views "manually" throughViewContainerRef(e.g. usingNgIf).These changes flip the
firstCreatePassback to false on errors so that trying to re-render the same view will throw an error which is consistent to the one that broke the view during creation.Fixes #41383.
The text was updated successfully, but these errors were encountered: