Skip to content
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(textfield): Annotate textfield for Closure Compiler. #1386

Merged
merged 3 commits into from
Oct 5, 2017

Conversation

bwobrien
Copy link
Contributor

@bwobrien bwobrien commented Oct 4, 2017

Annotates MDC Textfield for the Closure Compiler.

Resolves #345

@codecov-io
Copy link

codecov-io commented Oct 4, 2017

Codecov Report

Merging #1386 into master will increase coverage by <.01%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1386      +/-   ##
==========================================
+ Coverage   99.91%   99.91%   +<.01%     
==========================================
  Files          69       69              
  Lines        3381     3390       +9     
  Branches      421      422       +1     
==========================================
+ Hits         3378     3387       +9     
  Misses          3        3
Impacted Files Coverage Δ
packages/mdc-textfield/constants.js 100% <100%> (ø) ⬆️
packages/mdc-textfield/foundation.js 100% <100%> (ø) ⬆️
packages/mdc-textfield/index.js 100% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3632f98...a62afab. Read the comment docs.

Copy link
Contributor

@acdvorak acdvorak left a comment

Choose a reason for hiding this comment

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

Overall LGTM, just a few minor comments and a question

* property, so if you choose to duck-type the return value for this method
* in your implementation it's important to keep this in mind. Also note that
* this method can return null, which the foundation will handle gracefully.
* @return {HTMLInputElement|NativeInputType}
Copy link
Contributor

Choose a reason for hiding this comment

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

Add explicit nullable operator(s):

@return {?HTMLInputElement|?NativeInputType}
or
@return {!HTMLInputElement|!NativeInputType|null}
or
@return {HTMLInputElement|NativeInputType|null}

(I'm not sure which variation is more readable, correct, and Closure-friendly...)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done. I think null is generally discouraged when ? would suffice, so I went with {?A|?B}.

getNativeInput_() {
return this.adapter_.getNativeInput() || {
return this.adapter_.getNativeInput() ||
/** @type {NativeInputType} */ ({
Copy link
Contributor

Choose a reason for hiding this comment

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

Add explicit nullability operator:

@type {!NativeInputType}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done, found some more and fixed throughout.

@@ -103,6 +156,15 @@ export class MDCTextfield extends MDCComponent {
};
}

/**
* @return {!{
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we create @record definitions for these collections of methods?

Copy link
Contributor

Choose a reason for hiding this comment

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

These subsets of the adapter API are kind of arbitrary (I assume we only split it like this as an attempt at readability); the only thing that really matters is the collective adapter API. Kind of unfortunate that we have to annotate these at all...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, because they are arbitrary subsets of the adapter API, it didn't make sense to make individual @record or @typedefs for these. Also since these methods are private, the type wouldn't be shared across components like for NativeInputType.

@bwobrien bwobrien merged commit 1152b8d into master Oct 5, 2017
@bwobrien bwobrien deleted the texfield/closure branch October 6, 2017 21:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants