-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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.
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
feat(md-progress-bar): Create initial ProgressBar implementation. #130
Conversation
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
1 similar comment
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
I signed it! |
@@ -43,3 +43,6 @@ Here's a list of gotchas to keep in mind when writing TypeScript code that will | |||
* **Lambdas need to abide to the type required.** Meaning that if a function requires a function that takes one argument, the lambda cannot be `() => {}`. Use `_` for temporary parameters. This is notable in Promises. | |||
* **Dynamic return values fat arrows can't return non-primitive types without casting.** For example, a fat arrow that return a promise (or Future) generates a warning if using directly, like so: `promiseA.then(() => promiseB)`. In this case simply using a block works as expected; `promiseA.then(() => { return promiseB; })`. | |||
* **Dart does not have [generic methods](http://www.typescriptlang.org/Handbook#generics)** ([issue](https://github.com/dart-lang/sdk/issues/254)). | |||
* **Dart does not have destructuring** but it does have a [proposal](https://github.com/dart-lang/dart_enhancement_proposals/issues/24) for it. | |||
* **Dart does not support type aliases.** Code like `type Nop = () => void` will not compile. | |||
* **Dart does not support [tagged template literals](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#Tagged_template_literals)**. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like you need to rebase again, since these changes came from an earlier commit.
Finished first pass of comments. |
} | ||
|
||
|
||
/** Animations for indeterminate and query mode. */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you point to the resource you used to get those percentage for animations? They seem like magic numbers without context.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack
|
||
/** Animations for indeterminate and query mode. */ | ||
// Primary indicator. | ||
@keyframes md-progress-bar-primary-indeterminate-translate { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible at all to go into more detail about what each keyframe animation is actually doing?
Perhaps @traviskaufman could add more info
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure can 😃
The indeterminate state is essentially made up of two progress bars, one primary (the one that is shown in both the determinate and indeterminate states) and one auxiliary, which essentially mirrors the primary progress bar in appearance but is only shown to assist with the indeterminate animations.
Given the mocks for the indeterminate APIs, you essentially have 4 animations being performed in tandem:
Keyframe Block | Description |
---|---|
primary-indeterminate-translate |
Translation of the primary progressbar across the screen |
primary-indeterminate-scale |
Scaling of the primary progressbar as it's being translated across the screen |
auxiliary-indeterminate-translate |
Translation of the auxiliary progressbar across the screen |
auxiliary-indeterminate-scale |
Scaling of the auxiliary progressbar as it's being translated across the screen |
Because two different transform animations need to be applied at once, the translation is applied to the outer element and the scaling is applied to the inner element, which provides the illusion necessary to make the animation work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added. I just copied the description you gave into the comment.
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. |
1 similar comment
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. |
* | ||
* Defaults to zero. Mirrored to aria-valuenow. | ||
*/ | ||
@Input('value') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The @Input()
decorator should go on the getter, otherwise angular is going to directly set the private property (and not use the setter).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I understand what you are saying here.
I dont think it makes sense to put @Input
on a getter.
It currently is:
@Input('value') _value: number = 0;
@HostBinding('attr.aria-valuenow') get value_() { return this._value; }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should be
private _value: number = 0;
...
@Input()
get value(): number {
...
}
set value(v: number) {
...
}
When the @Input
is on the private member, the setter
is not called when Angular updates value
, which isn't what you want. Angular is smart enough to know that putting @Input
on a getter or a setter means to simply treat that as the bound property.
Needs a fresh rebase |
Rebased, PTAL |
CLAs look good, thanks! |
1 similar comment
CLAs look good, thanks! |
LGTM |
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. |
For #40