Skip to content

minor fixes here and there #1

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

minor fixes here and there #1

wants to merge 1 commit into from

Conversation

gkalpak
Copy link
Collaborator

@gkalpak gkalpak commented Oct 13, 2016

No description provided.

petebacondarwin
petebacondarwin reviewed Oct 13, 2016
View reviewed changes
modules/@angular/upgrade/src/aot/upgrade_module.ts
@@ -78,8 +78,7 @@ export class UpgradeModule {
// }
// ]);
}
}])
.config(config);
}]);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good spot that we don't need to run the config block twice!
But I think that IAngularBootstrapConfig is a dodgy type and would prefer it to be IInjectable

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or I'll just alias IAngularBootstrapConfig to IInjectable.

modules/@angular/upgrade/test/upgrade_aot_spec.ts
import {
UpgradeModule, ng2ProviderFactory, ng1ServiceProvider, downgradeNg2Component
} from '@angular/upgrade';
import { parseFields } from '@angular/upgrade/src/metadata';
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this reformatting from running the code through the formatting engine?
If not, I don't think there is much point in spending time doing this because the engine has its own weird ways of laying things out.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I did this. Because the lines were too long to fit on my screen. I didn't mean to check them in, but forgot 😇

modules/@angular/upgrade/test/upgrade_aot_spec.ts
@@ -44,7 +47,7 @@ export function main() {

// the ng1 app module that will consume the downgraded component
const ng1Module = angular.module('ng1', [])
// create an ng1 facade of the ng1 component
// create an ng1 facade of the ng2 component
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:-)

modules/@angular/upgrade/test/upgrade_aot_spec.ts
@@ -994,7 +997,7 @@ export function main() {
// create the ng1 module that will import an ng2 service
const ng1Module = angular.module('ng1Module', [])
.factory('ng2Service', ng2ProviderFactory(Ng2Service))
.factory('ng1Service', () => 'ng1 service value');
.value('ng1Service', 'ng1 service value');
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we were explicitly testing that factories work but I guess that .value() is just a proxy for creating a service anyway.

@petebacondarwin
Copy link
Owner

Thanks. Landed as 846bf32

petebacondarwin pushed a commit that referenced this pull request Jan 10, 2019
@alxhub @AndrewKushnir
test(ivy): mark jit_summaries_integration_spec as obsolete in Ivy (an…
11325ba 
…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
petebacondarwin pushed a commit that referenced this pull request Jan 26, 2019
@AndrewKushnir @jasonaden
fix(ivy): proper i18n postprocessing in case of nested templates (ang…
2da82db 
…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
petebacondarwin pushed a commit that referenced this pull request May 6, 2020
@alxhub
perf(compiler-cli): perform template type-checking incrementally (ang…
ecffc35 
…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 #2 main program): throw away old .ngtypecheck files and generate
   new empty ones.

4. (Build #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 #2 main program): The `TypeCheckShimGenerator` now reuses _all_
   .ngtypecheck `ts.SourceFile` shims from build #1's type-check program in
   the construction of build #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 #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
Reviewers

@petebacondarwin petebacondarwin petebacondarwin left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@gkalpak @petebacondarwin