Animation prototype squashed #1
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
matsko
pushed a commit
that referenced
this pull request
Jan 11, 2019
…gular#28027) These tests validate the ability of the View Engine TestBed to consume summary metadata, a mechanism which allows the TestBed to use AOT-compiled components & directives in tests. It achieves this through two operations which are independently obsolete in Ivy: 1. It injects CompileMetadataResolver, a View Engine specific compiler internal class which extracts global analysis metadata from classes, and uses it to construct summary metadata. This happens in a beforeEach() block which calls createSummaries(). 2. It uses TestBed.initTestEnvironment to pass summary metadata to the TestBed itself. Any such metadata is ignored in Ivy. Operation #1 makes it impossible to run these tests under Ivy, as the CompileMetadataResolver is not available with an Ivy compiler. Ivy itself does not rely on summary data, and the R3TestBed can depend directly on AOT compiled components without it. Thus, the spirit of thes tests is obsolete in an Ivy world. FW-838 #resolve PR Close angular#28027
matsko
pushed a commit
that referenced
this pull request
Jan 29, 2019
…ular#28209) Prior to this change the postprocess step relied on the order of placeholders combined in one group (e.g. [�#1�|�*1:1�]). The order is not guaranteed in case we have nested templates (since we use BFS to process templates) and some tags are represented using same placeholders. This change performs postprocessing more accurate by keeping track of currently active template and searching for matching placeholder. PR Close angular#28209
matsko
pushed a commit
that referenced
this pull request
May 6, 2020
…ular#36211) This optimization builds on a lot of prior work to finally make type- checking of templates incremental. Incrementality requires two main components: - the ability to reuse work from a prior compilation. - the ability to know when changes in the current program invalidate that prior work. Prior to this commit, on every type-checking pass the compiler would generate new .ngtypecheck files for each original input file in the program. 1. (Build #1 main program): empty .ngtypecheck files generated for each original input file. 2. (Build #1 type-check program): .ngtypecheck contents overridden for those which have corresponding components that need type-checked. 3. (Build angular#2 main program): throw away old .ngtypecheck files and generate new empty ones. 4. (Build angular#2 type-check program): same as step 2. With this commit, the `IncrementalDriver` now tracks template type-checking _metadata_ for each input file. The metadata contains information about source mappings for generated type-checking code, as well as some diagnostics which were discovered at type-check analysis time. The actual type-checking code is stored in the TypeScript AST for type-checking files, which is now re-used between programs as follows: 1. (Build #1 main program): empty .ngtypecheck files generated for each original input file. 2. (Build #1 type-check program): .ngtypecheck contents overridden for those which have corresponding components that need type-checked, and the metadata registered in the `IncrementalDriver`. 3. (Build angular#2 main program): The `TypeCheckShimGenerator` now reuses _all_ .ngtypecheck `ts.SourceFile` shims from build #1's type-check program in the construction of build angular#2's main program. Some of the contents of these files might be stale (if a component's template changed, for example), but wholesale reuse here prevents unnecessary changes in the contents of the program at this point and makes TypeScript's job a lot easier. 4. (Build angular#2 type-check program): For those input files which have not "logically changed" (meaning components within are semantically the same as they were before), the compiler will re-use the type-check file metadata from build #1, and _not_ generate a new .ngtypecheck shim. For components which have logically changed or where the previous .ngtypecheck contents cannot otherwise be reused, code generation happens as before. PR Close angular#36211
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@matsko Here's the ripple demo that is not working as expected