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(select): make select work inside form-field #6488

Merged
merged 27 commits into from
Sep 21, 2017

Conversation

mmalerba
Copy link
Contributor

@mmalerba mmalerba commented Aug 15, 2017

Demos:
https://mmalerba-demo3.firebaseapp.com/baseline
https://mmalerba-demo3.firebaseapp.com/select

BREAKING CHANGES:

  • md-select must now be wrapped in an md-form-field
  • MdFormFieldControl now has 2 new properties: controlType, shouldPlaceholderFloat and 1 new method: onContainerClick

@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Aug 15, 2017
@kara
Copy link
Contributor

kara commented Aug 16, 2017

@mmalerba Great work! I played around the demo. It seems mostly good, but one thing I noticed is that sometimes you can click on the trigger without actually opening the panel. It floats the label, but the panel stays closed. If you try to click closer to the underline or the floating label, you can reproduce.

@kara kara removed their assignment Aug 16, 2017
Copy link
Member

@crisbeto crisbeto left a comment

Choose a reason for hiding this comment

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

Code-wise LGTM, but I'm not too sure about the API.

<md-select placeholder="Select">
<md-option value="option">Option</md-option>
</md-select>
<md-form-field>
Copy link
Member

Choose a reason for hiding this comment

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

API-wise, do we really want people to have to wrap every select in a form field? E.g. if you were using option groups, you'd have to write 4 levels of HTML. Aside from having to proxy a few @Input-s, what are the cons of having the form field be consumed by md-select internally?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In the past we've preferred composition style APIs since they're more flexible, even if they are a bit more verbose. I think the extra typing is worth it, but it's a fair point. @jelbourn do you have an opinion?

Copy link
Member

Choose a reason for hiding this comment

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

I do like the consistency of having both select and input inside the same form-field; it makes it clear that the prefix, suffix, hint, and error belong to the form field. Very explicit, no magic. It's also more maintainable for us, since we don't have to forward along every form-field API through select over time.

I don't feel incredibly strongly about it, though. @mmalerba up to you if you think it would be the same amount of work to do it the other way around; it would certainly make the migration easier

@@ -890,31 +893,29 @@ export class MdSelect extends _MdSelectMixinBase implements AfterContentInit, On

/** Calculates the scroll position and x- and y-offsets of the overlay panel. */
private _calculateOverlayPosition(): void {
this._triggerHeight = this.trigger.nativeElement.getBoundingClientRect().height;
this._triggerFontSize = this._measureFontSizeEl.nativeElement.getBoundingClientRect().height;
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure that this would be completely accurate. Why not use getComputedStyle?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you know if getComputedStyle is guaranteed to give me a px value for font-size (as opposed to em, %, etc)? That was my main motivation for not doinggetComputedStyle. Also, I assume getComputedStyle is no worse from a performance perspective?

Copy link
Member

Choose a reason for hiding this comment

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

I'm pretty sure that you'll get a pixel value no matter what. Should be pretty easy to verify. As for performance, it should be pretty close to the getBoundingClientRect call.

@mmalerba
Copy link
Contributor Author

@kara good catch, I fixed the focus and click behavior and also corrected the 1px error in placement of the multi-select dropdown

@@ -515,36 +516,36 @@ describe('MdInput without forms', function () {
fixture.detectChanges();

let inputEl = fixture.debugElement.query(By.css('input')).nativeElement;
let labelEl = fixture.debugElement.query(By.css('label')).nativeElement;
let formFieldEl = fixture.debugElement.query(By.css('.mat-form-field')).nativeElement;
Copy link
Contributor

@rafaelss95 rafaelss95 Aug 19, 2017

Choose a reason for hiding this comment

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

@mmalerba Taking advantage of the fact that you're working on it, would you be able to replace, let by const when possible? It seems that (almost) all the variables here (in whole test file) aren't being reassigned and still are declared as let.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This sounds like something we should do as part o a separate cleanup pass of the whole project, I'm sure there are tools that can analyze and fix this for us

@mmalerba
Copy link
Contributor Author

@kara @jelbourn @crisbeto this is ready for more through review now

@code-tree
Copy link
Contributor

The \xa0 fix doesn't appear to work with AOT?

image

TODO(mmalerba): &nbsp; is currently broken in components with preserveWhitespace: false, so we
evaluate it as a JS string binding instead. Change back to &nbsp; once it works again.
-->
<ng-container *ngIf="empty">{{'\xa0'}}</ng-container>
Copy link
Contributor

Choose a reason for hiding this comment

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

This doesn't appear to work with AOT.

@udayvunnam
Copy link

@mmalerba The Demos are great. Can you be able to provide example code of this?

@joseluisq
Copy link

Awesome!
Definitely I can't wait for the next release!

@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 8, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
cla: yes PR author has agreed to Google's Contributor License Agreement P1 Impacts a large percentage of users; if a workaround exists it is partial or overly painful
Projects
None yet
Development

Successfully merging this pull request may close these issues.