El diseño de selectfuncionalidad en materialize CSS es, en mi opinión, una razón bastante buena para no usarlo.
Tienes que inicializar el elemento de selección con material_select(), como menciona @ littleguy23. Si no lo hace, ¡ni siquiera se muestra el cuadro de selección! En una aplicación jQuery pasada de moda, puedo inicializarla en la función de preparación de documentos. Adivina qué, ni yo ni muchas otras personas estamos usando jQuery en estos días, ni inicializamos nuestras aplicaciones en el gancho de preparación de documentos.
Selecciones creadas dinámicamente . ¿Qué sucede si estoy creando selecciones dinámicamente, como sucede en un marco como Ember que genera vistas sobre la marcha? Tengo que agregar lógica en cada vista para inicializar el cuadro de selección cada vez que se genera una vista, o escribir una vista mixin para manejar eso por mí. Y es peor que eso: cuando se genera la vista, y en términos de Ember didInsertElementse llama, es posible que el enlace a la lista de opciones para el cuadro de selección aún no se haya resuelto, por lo que necesito una lógica especial al observar la lista de opciones para esperar hasta que esté poblado antes de realizar la llamada al material_select. Si las opciones cambian, como podría ocurrir fácilmente, material_selectno tiene idea de eso y no actualiza el menú desplegable. Puedo material_selectvolver a llamar cuando cambian las opciones, pero parece que eso no hace nada (se ignora).
En otras palabras, parece que la suposición de diseño detrás de materializar las casillas de selección de CSS es que están todas allí al cargar la página y sus valores nunca cambian.
Implementación . Desde un punto de vista estético, tampoco estoy a favor de la forma en que materialize CSS implementa sus menús desplegables, que consiste en crear un conjunto paralelo de elementos sombreados en algún otro lugar del DOM. Por supuesto, las alternativas como select2 hacen lo mismo, y puede que no haya otra forma de lograr algunos de los efectos visuales (¿de verdad?). Para mí, sin embargo, cuando inspecciono un elemento, quiero ver el elemento, no una versión de sombra en otro lugar que alguien creó mágicamente.
Cuando Ember derriba la vista, no estoy seguro de que materializar CSS derribe los elementos de sombra que ha creado. En realidad, me sorprendería bastante si lo hiciera. Si mi teoría es correcta, a medida que las vistas se generen y eliminen, su DOM terminará contaminándose con docenas de conjuntos de menús desplegables de sombras que no están conectados a nada. Esto se aplica no solo a Ember sino a cualquier otro marco de front-end OPA basado en plantillas / MVC.
Fijaciones . Tampoco he podido averiguar cómo obtener el valor seleccionado en el cuadro de diálogo para vincularlo a algo útil en un marco como Ember que invoca cuadros de selección a través de una {{view 'Ember.Select' value=country}}interfaz de tipo. En otras palabras, cuando se selecciona algo, countryno se actualiza. Este es un factor decisivo.
Olas . Por cierto, los mismos problemas se aplican al efecto "ola" en los botones. Tienes que inicializarlo cada vez que se crea un botón. Personalmente, no me importa el efecto de ola y no entiendo de qué se trata todo este alboroto, pero si quieres olas, ten en cuenta que pasarás una buena parte del resto de tu vida preocupándote por cómo hacerlo. inicializar cada botón cuando se crea.
Aprecio el esfuerzo realizado por los chicos de materialize CSS, y hay algunos efectos visuales agradables allí, pero es demasiado grande y tiene demasiadas trampas como las anteriores para ser algo que yo usaría. Ahora planeo arrancar materializar CSS de mi aplicación y volver a Bootstrap o una capa encima de Suit CSS. Tus herramientas deberían hacer tu vida más fácil, no más difícil.
<select class="browser-default">