This repository was archived by the owner on Feb 22, 2018. It is now read-only.
fix(compiler): OneWayOneTime bindings now wait for the model to stablize #1013
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
BREAKING CHANGE
Previously, OneWayOneTime bindings would remove their watch after the
first value assignment. For models that take more than one digest loop
to stablize, this meant the OneWayOneTime bindings took a un-stablized
value.
With this change, these bindings will continue to accept value
assignments until their stablized value is non-null. The assignment may
occur multiple times.
We expect that most uses of OneWayOneTime will be 'ok' with
being called a few times as the model stablizes.
However, applications which depend on OneWayOneTime bindings being
called exactly once will break. The suggested upgrade path is to
move the senstive code into a domWrite callback. e.g. the old code:
@decorator(
map: const { 'one-time': '=>!value' })
class OneTime {
set value(v) => onlyCalledOnce(v);
}
becomes
@decorator(
map: const { 'one-time': '=>!value' })
class OneTime {
var _value;
set value(v) {
if (_value == null) {
scope.rootScope.domWrite(() => onlyCalledOnce(_value));
}
_value = v;
}
}
jbdeboer
added a commit
that referenced
this pull request
May 14, 2014
BREAKING CHANGE
Previously, OneWayOneTime bindings would remove their watch after the
first value assignment. For models that take more than one digest loop
to stablize, this meant the OneWayOneTime bindings took a un-stablized
value.
With this change, these bindings will continue to accept value
assignments until their stablized value is non-null. The assignment may
occur multiple times.
We expect that most uses of OneWayOneTime will be 'ok' with
being called a few times as the model stablizes.
However, applications which depend on OneWayOneTime bindings being
called exactly once will break. The suggested upgrade path is to
move the senstive code into a domWrite callback. e.g. the old code:
@decorator(
map: const { 'one-time': '=>!value' })
class OneTime {
set value(v) => onlyCalledOnce(v);
}
becomes
@decorator(
map: const { 'one-time': '=>!value' })
class OneTime {
var _value;
set value(v) {
if (_value == null) {
scope.rootScope.domWrite(() => onlyCalledOnce(_value));
}
_value = v;
}
}
Closes #1013
dsalsbury
pushed a commit
to dsalsbury/angular.dart
that referenced
this pull request
Jul 16, 2014
BREAKING CHANGE
Previously, OneWayOneTime bindings would remove their watch after the
first value assignment. For models that take more than one digest loop
to stablize, this meant the OneWayOneTime bindings took a un-stablized
value.
With this change, these bindings will continue to accept value
assignments until their stablized value is non-null. The assignment may
occur multiple times.
We expect that most uses of OneWayOneTime will be 'ok' with
being called a few times as the model stablizes.
However, applications which depend on OneWayOneTime bindings being
called exactly once will break. The suggested upgrade path is to
move the senstive code into a domWrite callback. e.g. the old code:
@decorator(
map: const { 'one-time': '=>!value' })
class OneTime {
set value(v) => onlyCalledOnce(v);
}
becomes
@decorator(
map: const { 'one-time': '=>!value' })
class OneTime {
var _value;
set value(v) {
if (_value == null) {
scope.rootScope.domWrite(() => onlyCalledOnce(_value));
}
_value = v;
}
}
Closes dart-archive#1013
dsalsbury
pushed a commit
to dsalsbury/angular.dart
that referenced
this pull request
Jul 16, 2014
BREAKING CHANGE
Previously, OneWayOneTime bindings would remove their watch after the
first value assignment. For models that take more than one digest loop
to stablize, this meant the OneWayOneTime bindings took a un-stablized
value.
With this change, these bindings will continue to accept value
assignments until their stablized value is non-null. The assignment may
occur multiple times.
We expect that most uses of OneWayOneTime will be 'ok' with
being called a few times as the model stablizes.
However, applications which depend on OneWayOneTime bindings being
called exactly once will break. The suggested upgrade path is to
move the senstive code into a domWrite callback. e.g. the old code:
@decorator(
map: const { 'one-time': '=>!value' })
class OneTime {
set value(v) => onlyCalledOnce(v);
}
becomes
@decorator(
map: const { 'one-time': '=>!value' })
class OneTime {
var _value;
set value(v) {
if (_value == null) {
scope.rootScope.domWrite(() => onlyCalledOnce(_value));
}
_value = v;
}
}
Closes dart-archive#1013
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
BREAKING CHANGE
Previously, OneWayOneTime bindings would remove their watch after the
first value assignment. For models that take more than one digest loop
to stablize, this meant the OneWayOneTime bindings took a un-stablized
value.
With this change, these bindings will continue to accept value
assignments until their stablized value is non-null. The assignment may
occur multiple times.
Applications to depend on OneWayOneTime bindings being called exactly
once will break. The suggested upgrade path is to move the senstive
code into a domWrite callback. e.g. the old code:
becomes
However, we expect that most uses of OneWayOneTime will be 'ok' with
being called a few times as the model stablizes.