Projekt select
funkcjonalności w materialize CSS jest moim zdaniem całkiem dobrym powodem, aby z niego nie korzystać.
Musisz zainicjować element select za pomocą material_select()
, jak wspomina @ littleguy23. Jeśli tego nie zrobisz, pole wyboru nie zostanie nawet wyświetlone! W staromodnej aplikacji jQuery mogę ją zainicjować w funkcji gotowości dokumentu. Zgadnij co, ani ja, ani wiele innych osób nie używamy obecnie jQuery, ani też nie inicjalizujemy naszych aplikacji w haku Document ready.
Dynamicznie tworzone zaznaczenia . A co, jeśli dynamicznie tworzę selekcje, na przykład w ramach takiej jak Ember, która generuje widoki w locie? Muszę dodać logikę do każdego widoku, aby zainicjować pole wyboru za każdym razem, gdy generowany jest widok, lub napisać mieszankę widoku, aby obsłużyć to za mnie. I jest jeszcze gorzej: kiedy widok jest generowany i w terminologii Ember didInsertElement
jest wywoływany, powiązanie z listą opcji dla pola wyboru mogło jeszcze nie zostać rozwiązane, więc potrzebuję specjalnej logiki obserwującej listę opcji, aby poczekać, aż zostanie wypełniony przed nawiązaniem połączenia z material_select
. Jeśli opcje się zmienią, jak łatwo mogą, material_select
nie ma o tym pojęcia i nie aktualizuje listy rozwijanej. Mogę zadzwonićmaterial_select
ponownie, gdy zmienią się opcje, ale wygląda na to, że nic nie robi (jest ignorowane).
Innymi słowy, wydaje się, że założeniem projektowym stojącym za zmaterializowanymi polami wyboru CSS jest to, że wszystkie one znajdują się podczas ładowania strony, a ich wartości nigdy się nie zmieniają.
Realizacja . Z estetycznego punktu widzenia nie jestem również zwolennikiem sposobu, w jaki materialize CSS implementuje swoje listy rozwijane, czyli tworzenie równoległego zestawu cieni elementów w innym miejscu w DOM. Oczywiście, alternatywy takie jak select2 robią to samo i może nie być innego sposobu na osiągnięcie niektórych efektów wizualnych (naprawdę?). Jednak dla mnie, kiedy sprawdzam element, chcę zobaczyć element, a nie jakąś wersję cienia gdzieś indziej, którą ktoś magicznie stworzył.
Kiedy Ember niszczy widok, nie jestem pewien, czy materialize CSS zburzy utworzone przez siebie elementy cienia. Właściwie byłbym bardzo zaskoczony, gdyby tak się stało. Jeśli moja teoria jest poprawna, w miarę generowania i niszczenia widoków, Twój DOM zostanie zanieczyszczony dziesiątkami zestawów cieni, które nie są z niczym powiązane. Dotyczy to nie tylko Ember, ale wszelkich innych front-endów OPA opartych na MVC / szablonach.
Wiązania . Nie byłem również w stanie dowiedzieć się, jak uzyskać wartość wybraną w oknie dialogowym, aby powiązać z czymś użytecznym w środowisku takim jak Ember, który wywołuje pola wyboru za pośrednictwem {{view 'Ember.Select' value=country}}
interfejsu typu. Innymi słowy, gdy coś jest zaznaczone, country
nie jest aktualizowane. To jest zerwanie umowy.
Fale . Nawiasem mówiąc, te same problemy dotyczą efektu „fali” na przyciskach. Musisz go inicjalizować za każdym razem, gdy tworzony jest przycisk. Osobiście nie obchodzi mnie efekt fali i nie rozumiem, o co w tym wszystkim chodzi, ale jeśli chcesz fal, pamiętaj, że spędzisz znaczną część reszty swojego życia, martwiąc się, jak to zrobić. zainicjuj każdy przycisk po jego utworzeniu.
Doceniam wysiłek włożony w materializację CSS i jest tam kilka fajnych efektów wizualnych, ale jest za duży i ma zbyt wiele pułapek, takich jak powyższe, aby być czymś, czego bym użył. Planuję teraz wydrzeć materializację CSS z mojej aplikacji i wrócić do Bootstrap lub warstwy na wierzchu Suit CSS. Twoje narzędzia powinny ułatwiać Ci życie, a nie utrudniać.
<select class="browser-default">