La conception des selectfonctionnalités dans Materialise CSS est, à mon avis, une très bonne raison de ne pas l'utiliser.
Vous devez initialiser l'élément select avec material_select(), comme le mentionne @ littleguy23. Si vous ne le faites pas, la boîte de sélection ne s'affiche même pas! Dans une application jQuery à l'ancienne, je peux l'initialiser dans la fonction Document Ready. Devinez quoi, ni moi ni beaucoup d'autres personnes n'utilisons jQuery ces jours-ci, ni n'initialisons nos applications dans le hook document ready.
Sélections créées dynamiquement . Que faire si je crée des sélections de manière dynamique, comme cela se produit dans un cadre comme Ember qui génère des vues à la volée? Je dois ajouter une logique dans chaque vue pour initialiser la boîte de sélection à chaque fois qu'une vue est générée, ou écrire un mixin de vue pour gérer cela pour moi. Et c'est pire que cela: lorsque la vue est générée, et en termes Ember didInsertElementest appelée, la liaison à la liste d'options de la boîte de sélection n'a peut-être pas encore été résolue, j'ai donc besoin d'une logique spéciale en observant la liste d'options pour attendre qu'elle soit rempli avant d'appeler le material_select. Si les options changent, comme elles pourraient facilement le faire, material_selectn'a aucune idée à ce sujet et ne met pas à jour la liste déroulante. Je peux appeler à material_selectnouveau lorsque les options changent, mais il semble que cela ne fait rien (est ignoré).
En d'autres termes, il semble que l'hypothèse de conception derrière les boîtes de sélection de CSS matérialise est qu'elles sont toutes là au chargement de la page et que leurs valeurs ne changent jamais.
Mise en œuvre . D'un point de vue esthétique, je ne suis pas non plus en faveur de la manière dont Materialise CSS implémente ses listes déroulantes, qui consiste à créer un ensemble parallèle et ombré d'éléments ailleurs dans le DOM. Certes, des alternatives telles que select2 font la même chose, et il n'y a peut-être pas d'autre moyen d'obtenir certains des effets visuels (vraiment?). Pour moi, cependant, lorsque j'inspecte un élément, je veux voir l'élément, pas une version d'ombre ailleurs que quelqu'un a créée par magie.
Quand Ember démolit la vue, je ne suis pas sûr que Materialise CSS démolit les éléments d'ombre qu'il a créés. En fait, je serais assez surpris si c'était le cas. Si ma théorie est correcte, au fur et à mesure que les vues sont générées et détruites, votre DOM finira par être pollué par des dizaines d'ensembles de listes déroulantes d'ombre non connectées à quoi que ce soit. Cela s'applique non seulement à Ember mais à tout autre framework frontal OPA basé sur MVC / template.
Liaisons . Je n'ai pas non plus été en mesure de comprendre comment obtenir la valeur sélectionnée dans la boîte de dialogue pour se lier à tout ce qui est utile dans un cadre comme Ember qui appelle des boîtes de sélection via une {{view 'Ember.Select' value=country}}interface de type. En d'autres termes, lorsqu'un élément est sélectionné, il countryn'est pas mis à jour. C'est un facteur décisif.
Des vagues . En passant, les mêmes problèmes s'appliquent à l'effet «vague» sur les boutons. Vous devez l'initialiser à chaque fois qu'un bouton est créé. Personnellement, je ne me soucie pas de l'effet de vague et je ne comprends pas de quoi il s'agit, mais si vous voulez des vagues, sachez que vous passerez une bonne partie du reste de votre vie à vous soucier de la façon de le faire. initialisez chaque bouton lors de sa création.
J'apprécie les efforts déployés par les gars de Materialise CSS, et il y a de bons effets visuels là-bas, mais c'est trop gros et a trop de pièges tels que ceux ci-dessus pour être quelque chose que j'utiliserais. Je prévois maintenant d'extraire le CSS matérialisé de mon application et de revenir soit à Bootstrap, soit à une couche au-dessus de Suit CSS. Vos outils devraient vous rendre la vie plus facile, pas plus difficile.
<select class="browser-default">