Upgrading a Ng1Component and using $element does not work #13912

kevinverelst · 2017-01-13T12:41:46Z

I'm submitting a ... (check one with "x")

[x] bug report 
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior
Trying to upgrade a ng1 component that uses inline templates and the $element service. The angular2 component will have NO children nodes.

Expected behavior
The child nodes should be available instantly (like in ng1)

Minimal reproduction of the problem with instructions
I'm running a ng1 app and use ngUpgrade to upgrade ng1 components to ng2 ones. The inline template is not instantly available.

MINIMAL DEMO

(function () {
    'use strict';

    angular.module('testComponent', []);

    angular.module('testComponent')
        .component('testComponent', {
            template: '<div><p>This is shitty</p></div>',
            controller: testComponentController
        })

    function testComponentController($element, $timeout) {
        console.log('Instant', $element.children());
        this.$onInit = function () {
            console.log('On Init', $element.children());
            $timeout(function () {
                console.log('After Timeout', $element.children());
            });
        }
    }
}

OUTPUT NG1

Instant [div]
On Init [div]
After Timeout [div]

OUTPUT NG2

Instant JQLite {}
On Init JQLite {}
After Timeout [div.ng-scope]

As you can see, the element is not available until the $timeout.

What is the motivation / use case for changing the behavior?
Gradually upgrade a ng1 application to ng2 instead of having to do a big bang

Please tell us about your environment:
Cordova android/ios/windows Phone hybrid angular 1 app trying to migrate to angular2
Using:

typescript 2.1.4
Angular 2.4.1
Angular 1.5.8

Language: [all | TypeScript X.X | ES6/7 | ES5]
Typescript compiling to ES5

The text was updated successfully, but these errors were encountered:

dbpieter · 2017-01-13T12:59:49Z

Can confirm...

Whereas a pure ng1 component has $element available in $onInit (as per the documentation). An upgraded ng1 component does not have $element available in $onInit until after sometime.

gkalpak · 2017-01-17T12:02:55Z

This sounds like an upgrade (aka upgrade/dynamic) issue, not an upgrade/static one.
@kevinverelst, @dbpieter: Can you confirm?

kevinverelst · 2017-01-17T12:08:48Z

@gkalpak I used import { UpgradeModule } from '@angular/upgrade/static';
as described in the Upgrade documentation

gkalpak · 2017-01-17T16:06:49Z

The title mentions upgradeAdapter.upgradeNg1Component, which is not an upgrade/static API 😕

kevinverelst · 2017-01-18T07:42:11Z

Fair enough, the title is a bit wrong (updated it) but the point is that the $element behaves differently in an ng1 component than in a ng2 component.

gkalpak · 2017-01-18T08:57:16Z

Sure. Just trying to figure out where the problem lies (it makes it easier to fix 😛)

kevinverelst · 2017-01-30T08:26:23Z

Any progress?

gkalpak · 2017-02-03T14:30:10Z

I am still looking into it. In the meantime, it doesn't seem right to try to access the content of the element in $onInit(). Using $postLink seems more appropriate for that purpose (and it works as expected).

…controller Previously, the relative order of the AngularJS compiling/linking operations was not similar to AngularJS's, resulting in inconsistent behavior for upgraded components (which made upgrading to Angular less straight forward). This commit fixes it, by following the compiling/linking process of AngularJS more closely. Main differences: - The components view is already populated when the controller is instantiated (and subsequent hooks are called). - The correct DOM content is available when running the `$onChanges`, `$onInit`, `$doCheck` hooks. Previously, the "content children" were still present, not the "view children". - The same for pre-linking. - The template is compiled in the correct DOM context (e.g. has access to ancestors). Previously, it was compiled in isolation, inside a dummy element. For reference, here is the order of operations: **Before** 1. Compile template 2. Instantiate controller 3. Hook: $onChanges 4. Hook: $onInit 5. Hook: $doCheck 6. Pre-linking 7. Collect content children 8. Insert compiled template 9. Linking 10. Post-linking 11. Hook: $postLink **After** 1. Collect content children 2. Insert template 3. Compile template 4. Instantiate controller 5. Hook: $onChanges 6. Hook: $onInit 7. Hook: $doCheck 8. Pre-linking 9. Linking 10. Post-linking 11. Hook: $postLink Fixes angular#13912

gkalpak · 2017-02-03T21:47:29Z

I have a potential fix for this in #14289 (that will make the compiling/instantiating/linking process more similar to AngularJS's in general).

…controller Previously, the relative order of the AngularJS compiling/linking operations was not similar to AngularJS's, resulting in inconsistent behavior for upgraded components (which made upgrading to Angular less straight forward). This commit fixes it, by following the compiling/linking process of AngularJS more closely. Main differences: - The components view is already populated when the controller is instantiated (and subsequent hooks are called). - The correct DOM content is available when running the `$onChanges`, `$onInit`, `$doCheck` hooks. Previously, the "content children" were still present, not the "view children". - The same for pre-linking. - The template is compiled in the correct DOM context (e.g. has access to ancestors). Previously, it was compiled in isolation, inside a dummy element. For reference, here is the order of operations: **Before** 1. Compile template 2. Instantiate controller 3. Hook: $onChanges 4. Hook: $onInit 5. Hook: $doCheck 6. Pre-linking 7. Collect content children 8. Insert compiled template 9. Linking 10. Post-linking 11. Hook: $postLink **After** 1. Collect content children 2. Insert template 3. Compile template 4. Instantiate controller 5. Hook: $onChanges 6. Hook: $onInit 7. Hook: $doCheck 8. Pre-linking 9. Linking 10. Post-linking 11. Hook: $postLink Fixes angular#13912

…controller (#14289) Previously, the relative order of the AngularJS compiling/linking operations was not similar to AngularJS's, resulting in inconsistent behavior for upgraded components (which made upgrading to Angular less straight forward). This commit fixes it, by following the compiling/linking process of AngularJS more closely. Main differences: - The components view is already populated when the controller is instantiated (and subsequent hooks are called). - The correct DOM content is available when running the `$onChanges`, `$onInit`, `$doCheck` hooks. Previously, the "content children" were still present, not the "view children". - The same for pre-linking. - The template is compiled in the correct DOM context (e.g. has access to ancestors). Previously, it was compiled in isolation, inside a dummy element. For reference, here is the order of operations: **Before** 1. Compile template 2. Instantiate controller 3. Hook: $onChanges 4. Hook: $onInit 5. Hook: $doCheck 6. Pre-linking 7. Collect content children 8. Insert compiled template 9. Linking 10. Post-linking 11. Hook: $postLink **After** 1. Collect content children 2. Insert template 3. Compile template 4. Instantiate controller 5. Hook: $onChanges 6. Hook: $onInit 7. Hook: $doCheck 8. Pre-linking 9. Linking 10. Post-linking 11. Hook: $postLink Fixes #13912

…controller (angular#14289) Previously, the relative order of the AngularJS compiling/linking operations was not similar to AngularJS's, resulting in inconsistent behavior for upgraded components (which made upgrading to Angular less straight forward). This commit fixes it, by following the compiling/linking process of AngularJS more closely. Main differences: - The components view is already populated when the controller is instantiated (and subsequent hooks are called). - The correct DOM content is available when running the `$onChanges`, `$onInit`, `$doCheck` hooks. Previously, the "content children" were still present, not the "view children". - The same for pre-linking. - The template is compiled in the correct DOM context (e.g. has access to ancestors). Previously, it was compiled in isolation, inside a dummy element. For reference, here is the order of operations: **Before** 1. Compile template 2. Instantiate controller 3. Hook: $onChanges 4. Hook: $onInit 5. Hook: $doCheck 6. Pre-linking 7. Collect content children 8. Insert compiled template 9. Linking 10. Post-linking 11. Hook: $postLink **After** 1. Collect content children 2. Insert template 3. Compile template 4. Instantiate controller 5. Hook: $onChanges 6. Hook: $onInit 7. Hook: $doCheck 8. Pre-linking 9. Linking 10. Post-linking 11. Hook: $postLink Fixes angular#13912

angular-automatic-lock-bot · 2019-09-10T23:22:41Z

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}

dbpieter mentioned this issue Jan 13, 2017

upgradeAdapter.upgradeNg1Component $element #10597

Closed

mhevery added the comp: upgrade/static label Jan 13, 2017

kevinverelst changed the title ~~upgradeAdapter.upgradeNg1Component $element~~ Upgrading a Ng1Component and using $element does not work Jan 18, 2017

gkalpak mentioned this issue Feb 3, 2017

fix(upgrade): populate upgraded component's view before creating the controller #14289

Merged

3 tasks

chuckjaz closed this as completed in #14289 Mar 7, 2017

angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 10, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Upgrading a Ng1Component and using $element does not work #13912

Upgrading a Ng1Component and using $element does not work #13912

kevinverelst commented Jan 13, 2017 •

edited

dbpieter commented Jan 13, 2017

gkalpak commented Jan 17, 2017

kevinverelst commented Jan 17, 2017 •

edited

gkalpak commented Jan 17, 2017

kevinverelst commented Jan 18, 2017 •

edited

gkalpak commented Jan 18, 2017

kevinverelst commented Jan 30, 2017

gkalpak commented Feb 3, 2017

gkalpak commented Feb 3, 2017

angular-automatic-lock-bot bot commented Sep 10, 2019

Upgrading a Ng1Component and using $element does not work #13912

Upgrading a Ng1Component and using $element does not work #13912

Comments

kevinverelst commented Jan 13, 2017 • edited

dbpieter commented Jan 13, 2017

gkalpak commented Jan 17, 2017

kevinverelst commented Jan 17, 2017 • edited

gkalpak commented Jan 17, 2017

kevinverelst commented Jan 18, 2017 • edited

gkalpak commented Jan 18, 2017

kevinverelst commented Jan 30, 2017

gkalpak commented Feb 3, 2017

gkalpak commented Feb 3, 2017

angular-automatic-lock-bot bot commented Sep 10, 2019

kevinverelst commented Jan 13, 2017 •

edited

kevinverelst commented Jan 17, 2017 •

edited

kevinverelst commented Jan 18, 2017 •

edited