Problem with simple string attributes on downgraded component when ng-if is used
#16212
Comments
|
Interesting. I don't think |
It turns out it does 😃 Changes to Under the hood, Note that there is another This is roughly equivalent to the following: scope.$watch(..., () => {
// The `ngIf` expression changed, let's insert the components...
...
/* 1 */ scope.$evalAsync(/* Initialize the `xyz` attributes */);
/* 2 */ scope.$watch(..., /* Update the `[xyz]` attributes */);
/* 3 */ scope.$watch(..., /* Run `ngOnChanges()` */);
});The above callbacks will be executed in the order: When this all happens outside of a Working on a fix... |
gkalpak
added a commit
to gkalpak/angular
that referenced
this issue
May 3, 2017
Previously, non-bracketed inputs (e.g. `xyz="foo"`) on downgraded components were initialized using `attrs.$observe()` (whihc uses `$evalAsync()` under the hood), while bracketed inputs (e.g. `[xyz]="'foo'"`) were initialized using `$watch()`. When the downgraded component was created during a `$digest` (e.g. by an `ng-if` watcher), the nno-bracketed inputs were not initialized in time for the initial call to `ngOnChanges()` and `ngOnInit()`. This commit fixes it by using `$watch()` to initialize all inputs. `$observe()` is still used for subsequent updates, because it is more performant. Fixes angular#16212
gkalpak
added a commit
to gkalpak/angular
that referenced
this issue
May 3, 2017
Previously, non-bracketed inputs (e.g. `xyz="foo"`) on downgraded components were initialized using `attrs.$observe()` (which uses `$evalAsync()` under the hood), while bracketed inputs (e.g. `[xyz]="'foo'"`) were initialized using `$watch()`. If the downgraded component was created during a `$digest` (e.g. by an `ng-if` watcher), the non-bracketed inputs were not initialized in time for the initial call to `ngOnChanges()` and `ngOnInit()`. This commit fixes it by using `$watch()` to initialize all inputs. `$observe()` is still used for subsequent updates on non-bracketed inputs, because it is more performant. Fixes angular#16212
3 tasks
gkalpak
added a commit
to gkalpak/angular
that referenced
this issue
May 3, 2017
Previously, non-bracketed inputs (e.g. `xyz="foo"`) on downgraded components were initialized using `attrs.$observe()` (which uses `$evalAsync()` under the hood), while bracketed inputs (e.g. `[xyz]="'foo'"`) were initialized using `$watch()`. If the downgraded component was created during a `$digest` (e.g. by an `ng-if` watcher), the non-bracketed inputs were not initialized in time for the initial call to `ngOnChanges()` and `ngOnInit()`. This commit fixes it by using `$watch()` to initialize all inputs. `$observe()` is still used for subsequent updates on non-bracketed inputs, because it is more performant. Fixes angular#16212
matsko
pushed a commit
that referenced
this issue
May 4, 2017
Previously, non-bracketed inputs (e.g. `xyz="foo"`) on downgraded components were initialized using `attrs.$observe()` (which uses `$evalAsync()` under the hood), while bracketed inputs (e.g. `[xyz]="'foo'"`) were initialized using `$watch()`. If the downgraded component was created during a `$digest` (e.g. by an `ng-if` watcher), the non-bracketed inputs were not initialized in time for the initial call to `ngOnChanges()` and `ngOnInit()`. This commit fixes it by using `$watch()` to initialize all inputs. `$observe()` is still used for subsequent updates on non-bracketed inputs, because it is more performant. Fixes #16212
matsko
pushed a commit
that referenced
this issue
May 4, 2017
Previously, non-bracketed inputs (e.g. `xyz="foo"`) on downgraded components were initialized using `attrs.$observe()` (which uses `$evalAsync()` under the hood), while bracketed inputs (e.g. `[xyz]="'foo'"`) were initialized using `$watch()`. If the downgraded component was created during a `$digest` (e.g. by an `ng-if` watcher), the non-bracketed inputs were not initialized in time for the initial call to `ngOnChanges()` and `ngOnInit()`. This commit fixes it by using `$watch()` to initialize all inputs. `$observe()` is still used for subsequent updates on non-bracketed inputs, because it is more performant. Fixes #16212
asnowwolf
pushed a commit
to asnowwolf/angular
that referenced
this issue
Aug 11, 2017
Previously, non-bracketed inputs (e.g. `xyz="foo"`) on downgraded components were initialized using `attrs.$observe()` (which uses `$evalAsync()` under the hood), while bracketed inputs (e.g. `[xyz]="'foo'"`) were initialized using `$watch()`. If the downgraded component was created during a `$digest` (e.g. by an `ng-if` watcher), the non-bracketed inputs were not initialized in time for the initial call to `ngOnChanges()` and `ngOnInit()`. This commit fixes it by using `$watch()` to initialize all inputs. `$observe()` is still used for subsequent updates on non-bracketed inputs, because it is more performant. Fixes angular#16212
juleskremer
pushed a commit
to juleskremer/angular
that referenced
this issue
Aug 28, 2017
Previously, non-bracketed inputs (e.g. `xyz="foo"`) on downgraded components were initialized using `attrs.$observe()` (which uses `$evalAsync()` under the hood), while bracketed inputs (e.g. `[xyz]="'foo'"`) were initialized using `$watch()`. If the downgraded component was created during a `$digest` (e.g. by an `ng-if` watcher), the non-bracketed inputs were not initialized in time for the initial call to `ngOnChanges()` and `ngOnInit()`. This commit fixes it by using `$watch()` to initialize all inputs. `$observe()` is still used for subsequent updates on non-bracketed inputs, because it is more performant. Fixes angular#16212
|
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I'm submitting a ... (check one with "x")
Current behavior
Let's say you have ng1+ng4 application with
<test/>component written in ng4 and downgraded to ng1.This component has some string
inputbinding so there are a few ways to pass a value there:<test input="value"/><test [input]="'value'"/>The thing is if you use
ng-ifeither on this component or on any of it's parents and use first way to pass aninputvalue (using simple string attribute) it will beundefinedon the call tongOnInitor on the first call tongOnChanges. It will be set only on the second call tongOnChanges.But in the second case of
[input]binding everything works as expected.See reproduction: http://plnkr.co/edit/qpZwej5dypPblBafnCVp?p=preview
Expected behavior
inputvalue should be set before the call tongOnInitand first call tongOnChanges.Minimal reproduction of the problem with instructions
Reproduction: http://plnkr.co/edit/qpZwej5dypPblBafnCVp?p=preview
Open browser console and you'll see input values for different cases in different component lifecycle hooks.
Press
Toggle visibilitybutton to print logs again.You can also remove
ng-iffrom the parent<div>and see the bug disappears: after page refresh it'll show valid input values in all lifecycle hooks.What is the motivation / use case for changing the behavior?
Current behavior is a bug.
Please tell us about your environment:
I think it doesn't depend on environment.
Language: TypeScript
Node (for AoT issues): -
The text was updated successfully, but these errors were encountered: