-
Notifications
You must be signed in to change notification settings - Fork 3.4k
md-autocomplete as attribute directive makes more sense #5040
Comments
you got a point. |
+1 |
input datepicker too |
+1 for this, md-autocomplete or md-typeahead would feel more natural as an attribute to a regular input, e.g. . I got stuck with this issue when tried to do an autocomplete input with a label and an icon, which seems impossible so far without over9000 lines of extra styling code. +1 as well for styling datepicker as a regular input. And one more thing: an input can have a floating label or a floating placeholder, and it doesn't grow in height as a result of this floating animation. However, if you add and icon to this input, you cannot have a floating label/placeholder and prevent this input from growing in height. |
+1 |
md-autocomplete attribute would be nice with md-select directive. |
absolutely agree, for now md-autocomplete design looks a bit hard configurable. The best options is to propagate all attributes to child input. |
I think hiding a text input inside a component is not a good idea generally. auto-completion as a behavioral directive makes a lot more sense to me and doesn't force a lot of limitations.
First of all, when you hide a text input inside a component which itself is basically a text input (or at least is quite similar to it) with some additional feature, you will end up providing access to a lot of attributes of the internal input by duplicating them on your component parameters.
placeholder
,ng-disabled
,md-autofocus
andmd-search-text
are examples of this duplication in currentmd-autocomplete
directive. There are other attributes and events of the internal dead input which may be interesting for the user of the md-autocomplete. E.g. one might be interested in adding a popover help with a directive that acts on text inputs and shows up when input get's focused.Secondly, the look and feel of the input is completely controlled by the directive! It seems a quite natural feature to be able to add auto-completion for normal material text inputs. Adding a parameter
md-floating-label
formd-autocomplete
seems a hacky patch for this problem. My opinion about this feature kind of got even stronger after I saw its code! AgetInputElement
function which basically says "if user wants floating label (as issues shows they want!) return this chunk of HTML, else, return another one!". What about having fixed labels?! You might want to add anotherif
to this function! Or you may end up adding a couple of other options likemd-no-float
tomd-autocomplete
directive to forward them tomd-input-container
!To sum up, I think a behavioral directive for auto-completion gives more flexibility, and is better in overall. Actually I'm not the only one who thinks so. Other modules like ui.bootstrap, angular-foundation, ng-autocomplete and probably more of them that I've not checked yet use this behavioral approach for auto-completion.
The text was updated successfully, but these errors were encountered: