Material-ui: [DatePicker] Port-Komponente

Erstellt am 22. Juli 2016  ·  51Kommentare  ·  Quelle: mui-org/material-ui

  • [ ] Komponente
  • [ ] Tests (zumindest Unit-Tests)
  • [ ] Dokumente
  • [ ] Demo
  • [ ] Tastaturzugänglichkeit #3933
  • [ ] Composable, damit Benutzer zum Beispiel etwas wie #7574 erstellen können
  • [ ] Behebt alte Probleme #7866, #7783, #7781, #7767, #6970, #6944, #6918, #6916, #6886, #6718, #6594, #6439, #6358, #6312, #6134, #5897, #5800, #5743, #5726, #5696, #5664, #5633, #5400, #5329, #5198, #5197, #5188, #5037, #4900, #4765, #4707, #4587 , #4401, #4219, #3794, #3710, #2930, #2203, #2023, #1566, #1261, #1207, #4538, #5144, #7399, #5612
DatePicker

Hilfreichster Kommentar

Wir verwenden heute in unserer Produktions-App ausgiebig den MUI-Timepicker und den Datepicker, sodass wir ohne eine auf Material Design basierende Lösung leider nicht auf v1.0.0 migrieren können. Die Verwendung von nativen Zeit-/Datumsauswahlen ist keine gute Lösung, und ich bin nicht der Meinung, dass sie für ein gutes und vollständiges UI-Paket der Material Design React-Komponente nicht "entscheidend" sind.

Alle 51 Kommentare

@oliviertassinari Ich würde gerne wissen,

Der beste Weg, um eine Migration einer Komponente zu starten, besteht darin, sich die geöffneten Probleme anzusehen. Dies ermöglicht ein besseres Verständnis der Einschränkungen der aktuellen Implementierung. Ich habe DatePicker und TimePicker aus dem Release-Meilenstein von v1 entfernt, damit wir dies früher tun können. Trotzdem ist Ihre Hilfe willkommen.

Einige Gedanken einer der Komponenten:

  • Es ist sehr herausfordernd, als ob wir eine schlechte UX anbieten würden, die Leute würden sich besser auf die nativen Picker der Plattform verlassen
  • Datumsmanipulation kann komplex sein. Mal sehen, ob wir eine andere Bibliothek nutzen können.
  • Desktop UX ist schlecht, wir müssen es überdenken.
  • Es fehlt die Kompositionskraft. Wir müssen APIs auf niedrigerer Ebene bereitstellen

Ich lasse nur meine Meinung zur Bedeutung des Datepickers (und Timepickers) übrig. Ich denke, es gibt 3 Hauptkomponenten, die definieren, ob Sie mit einem guten UI-Framework zu tun haben oder nicht, und sie sind: Autocomplete , Datatables und Datepickers .

Ich habe viele verschiedene Frameworks ausprobiert, und diese drei Komponenten bereiten mir am meisten Kopfschmerzen, hauptsächlich wegen ihrer schlechten Implementierungs- und Internationalisierungsoptionen, asynchronen Kapazitäten und Paginierung, um nur einige der Probleme zu nennen.

Also, um es kurz zu machen: Ich bevorzuge es, wenn diese drei Komponenten in ihrem vollständigen Zustand ankommen, aber bedenken Sie auch, dass es, zumindest meiner Meinung nach, viele Leute geben wird, die sich nicht für ein UI-Framework entscheiden werden dem fehlen einige dieser Komponenten.

Wie auch immer, MUI v1 sieht sehr vielversprechend aus, ich freue mich darauf, es auszuprobieren, wenn es vollständig veröffentlicht ist!

Ich bevorzuge es eher, dass diese drei Komponenten in ihrem vollständigen Zustand ankommen

@GabrielDuarteM Ich stimme zu, die DatePicker und TimePicker muss so gut sein wie die native, um wettbewerbsfähig zu sein. Ansonsten ist es sinnlos. Im Moment würde ich die v0.x-Picker nicht für eine produktionsbereite App verwenden. Ich würde eher die Picker der Plattform verwenden.
Wir werden v1.0.0 höchstwahrscheinlich ohne diese Komponenten veröffentlichen, ich denke nicht, dass sie entscheidend sind, die nativen Picker haben sich im Laufe der Jahre stark verbessert.

Bezüglich der Autovervollständigung finden Sie hier ein Beispiel .

Wir verwenden heute in unserer Produktions-App ausgiebig den MUI-Timepicker und den Datepicker, sodass wir ohne eine auf Material Design basierende Lösung leider nicht auf v1.0.0 migrieren können. Die Verwendung von nativen Zeit-/Datumsauswahlen ist keine gute Lösung, und ich bin nicht der Meinung, dass sie für ein gutes und vollständiges UI-Paket der Material Design React-Komponente nicht "entscheidend" sind.

Ich stimme @skirunman zu , die DatePicker und TimePicker sind in den Produktions-Apps sehr wichtig, auch die native Implementierung in den meisten Browsern ist sehr eingeschränkt, zum Beispiel in Chrome für Android kann man nicht Wählen Sie den Monat und das Jahr aus, und ich denke, dieser Teil ist entscheidend, wenn der Benutzer beispielsweise den Geburtstag auswählen möchte.

Lassen Sie mich meine Meinungen näher erläutern:

Es ist sehr herausfordernd, als ob wir eine schlechte UX anbieten würden, die Leute würden sich besser auf die nativen Picker der Plattform verlassen

Deutlich widersprechen. Native Picker sind im Allgemeinen in ihren Fähigkeiten eingeschränkt und passen sicherlich nicht zu Material Design.

Datumsmanipulation kann komplex sein. Mal sehen, ob wir eine andere Bibliothek nutzen können.

Ich denke, die Implementierung einer auf Material Design basierenden Zeit- und Datumsauswahl wird einige aktuelle Benutzer im Stich lassen. Die Verwendung einer anderen Bibliothek für das, was derzeit eine Kernkomponente von MUI ist und sein sollte, schwächt die Attraktivität von MUI insgesamt.

Desktop UX ist schlecht, wir müssen es überdenken.

Ich bin mir nicht sicher, warum Sie dies sagen, solange es den Material Design Guidelines entspricht.

Es fehlt die Kompositionskraft. Wir müssen APIs auf niedrigerer Ebene bereitstellen

Dies ist nett zu haben, aber keine Voraussetzung für v1.0.0 IMO.

@skirunman Wir stimmen zu, wir brauchen diese Komponente. Hier geht es um die zeitliche Priorität. Wir denken, dass es mehr Wert gibt, zuerst v1 zu veröffentlichen und den DatePicker/TimePicker später zu implementieren. (Die Leute können immer die Master-Version verwenden).
Es kommt auch aus dem Bedarf der Hauptbeitragszahler. Zum Beispiel werde ich vielleicht nie daran arbeiten, da ich es nicht brauche.

Es versteht sich von selbst, dass, wenn ein Mitwirkender eine ✨-Implementierung der Komponente hat, wir diese auf jeden Fall überprüfen und zusammenführen, sobald wir alle damit zufrieden sind :).

Ich habe erst vor kurzem damit begonnen, mir React-Infinite-Calendar anzusehen , aber es könnte für einige ein lohnender Ersatz für den v0-Kalender sein. Es funktioniert anders, indem zwischen Monaten gescrollt werden kann anstelle von expliziten Monatsschritten, aber es verfügt über einige zusätzliche angeforderte Funktionen wie die Bereichsauswahl (angefordert über https://github.com/callemall/material-ui/issues/7574) und sieht aus wie ziemlich komponierbar sein (auf den ersten Blick)

Gibt es Pläne, dieses Thema voranzubringen?

@DoWhileGeek Der neueste Plan, den ich hatte, war das Hinzufügen einer neuen Seite in den Dokumenten mit:

<input type="datetime-local" name="bdaytime">
<input type="date" name="bday" max="1979-12-31">
<input type="time" name="usr_time">

Beispiele wie.

@oliviertassinari Ich suche speziell nach einer Lösung für #7781, das ist ein bisschen ein Dealbreaker für unsere ux-Leute.

@DoWhileGeek es steht Ihnen frei, eine Lösung für #7781 für den 0.x-Zweig zu veröffentlichen; Das Kernteam konzentriert sich auf eine Version 1.0. Aus diesem Grund wurden all diese Probleme geschlossen.

+1 Wir sind wirklich an nativem v1-Picker interessiert. Bitte lass es uns wissen, wenn du gerade daran arbeitest
PS Wir sind gespannt auf Material ui v1

Ich schließe dieses Problem, um weitere Kommentare vom Typ +1 zu verhindern.

Dieser Hinweis erscheint bereits in den Pickers Dokumenten:

Notiz
Wir greifen derzeit auf native Eingabesteuerelemente zurück. Wenn Sie daran interessiert sind, einen umfangreichen Material Design Picker mit einer großartigen UX zu implementieren oder implementiert haben, lassen Sie es uns bitte unter #4787 und #4796 wissen! Wir könnten der Dokumentation einen Link oder eine Demo Ihres Projekts hinzufügen.

Wie hier besprochen , besteht der Plan darin, in der Pickers Komponentendemo auf native Steuerelemente zurückzugreifen und ein externes Projekt zu fördern, das bereit ist, die _dedicated_ Aufgabe der Datepicker , Timepicker oder beides.

Wenn Sie daran interessiert sind, die Pflücker als externes Projekt zu übernehmen, möchten viele Menschen, dass dies gelingt, also teilen Sie uns dies bitte mit und wir werden:

  • verlinken Sie prominent auf Ihr Projekt
  • eine Demo in den Material-UI-Dokumenten bereitstellen
  • weisen Sie Mitarbeiter in Ihre Richtung.

Angesichts der Popularität von material-ui und der Nachfrage nach diesen Pflückern wird ein Pflücker-Projektbesitzer wahrscheinlich den ganzen Internet-Ruhm und Ruhm erhalten, der mit einem beliebten Projekt einhergeht.

Interessiert? Bitte ping @rosskevin und @oliviertassinari auf gitter .

@rosskevin @oliviertassinari Ich arbeite gerade am TimePicker und hoffe, dass dieses Wochenende eine erste funktionierende Version (vielleicht fehlen noch einige Animationen oder der Querformatmodus) verfügbar ist. :Regenbogen:

Sobald die Auswahl die meiste Zeit erledigt ist, beginne ich mit DatePicker .

@leMaik Mir ist gerade dieses Projekt aufgefallen https://github.com/dmtrKovalenko/material-ui-pickers von @dmtrKovalenko

Vielleicht könntet ihr zwei gemeinsame Projekte besprechen? Ich habe mich nicht eingegraben, um Unterschiede zu finden, aber es könnte eine Überlegung wert sein.

Beachten Sie auch, dass wir vor kurzem zu einer Github-Organisation mui-org übergegangen sind. Wenn Sie beide sich entscheiden, sich anzuschließen und das Projekt unter dem mui-org hosten, lassen Sie es uns bitte wissen.

@rosskevin
Es scheint, dass es viel komplexer wäre, an Projekten teilzunehmen. Da wir moment als Peer-Abhängigkeit verwendet haben und viele Steuerelemente zum Anzeigen von Datumsangaben implementiert haben (z.
Was ist mit dem Wechsel zur Organisation, ich bin nicht dagegen, kann aber nicht ganz verstehen, was das bedeutet? Repository einfach unter die Organisation verschieben?

In Bezug auf die Organisation: Ja - es wäre nur, sie unter die Organisation zu verschieben, und vielleicht könnte die Popularität von material-ui selbst ihr mehr Aufmerksamkeit verschaffen (und mehr Betreuern). Aber es ist nur ein Gedanke, kein Grund, warum es da sein muss, nur dass wir jetzt die Türen für ergänzende Projekte unter der Organisation öffnen.

@rosskevin @dmtrKovalenko Ich möchte die Projekte nicht _zusammenführen_, da sie einen ziemlich anderen Ansatz verfolgen (wir machen ein Projekt mit einer Komponente, die nur eine Sache macht). Vielleicht könnten wir Material-UI-Picker nur in einen Date-Picker umwandeln (und auf dieser großartigen Grundlage aufbauen, Animationen und alles hinzufügen) und unseren Time-Picker als Time-Picker behalten und beides unter die Organisation verschieben? :Denken:

@leMaik
In Bezug auf die Wiederherstellung auf nur Datum - ich denke nein, da für einige Projekte eine allgemeine Herangehensweise an die Arbeit mit Datumsangaben sehr hilfreich wäre, Material-UI-Picker stellen alle Komponenten dafür bereit. Auch Datum-Uhrzeit-Auswahl, die nicht in der Material-Design-Spezifikation aufgeführt ist. 😉

Habe eine gute und flexible Datepicker-Bibliothek gefunden:
https://github.com/gpbl/react-day-picker

Es ist gelungen, mit material-ui-Texteingaben eine bereichsbezogene Datumsauswahl zu erstellen:

datepicker

@saraivinha85 Süß! 🍬

Wären Sie bereit, Ihre Umsetzung zu teilen, damit andere von ihnen lernen können? (Auch nur eine Zusammenfassung wäre toll!)

@mbrookes Kein Problem:
https://codesandbox.io/s/9l7kry52or

Dieses Projekt für Zeitauswahl ist gut https://github.com/TeamWertarbyte/material-ui-time-picker

Hi. Da die Komponente ziemlich wichtig ist und wir bereits die nächste Version verwenden, müssen Sie fragen, ob es eine Einschätzung dazu gibt oder vielleicht eine Möglichkeit gibt, zu helfen?

Ich habe andere DatePickers überprüft, funktioniert mit keinem wirklich gut genug, daher sollte ein gebündeltes die beste Lösung sein (insbesondere um mit redux-form oder redux-form-material-ui@next die wir auch verwenden).

Im Moment scheint es die beste Lösung zu sein, https://github.com/dmtrKovalenko/material-ui-pickers zu verwenden

Danke, werde es ausprobieren. Ist eine Datumsauswahl als Modal eine Anforderung von Material Design?

Eine Implementierung von etwas, das der materialbeeinflussten Datumsauswahl und der Datumsbereichsauswahl ähnelt, die auf der Beta-Site von Google Flights verwendet werden, wäre nett.

https://www.google.com/flights/beta

Wie kann ich nur MonthPicker oder YearPicker verwenden, würden Sie bitte eine Anleitung geben?

@taoxueweilong Bitte schreiben Sie eine Frage hier . Hier ist kein besserer Ort, um Ratschläge zu geben :)

Hallo Entwicklerkollegen...
Ich habe eine Implementierung von Datepicker mit Material UI hier
https://github.com/chingyawhao/material-ui-next-datepicker

Ich denke, ich könnte zur Verfügung stehen, um zur Material-Benutzeroberfläche beizutragen, wenn mir jemand helfen kann, wie ich anfangen soll

genial!

Am Mittwoch, 2. Mai 2018 um 11:13 Uhr, Ching Yaw Hao [email protected]
schrieb:

Hallo Entwicklerkollegen...
Ich habe eine Implementierung von Datepicker mit Material UI hier
https://github.com/chingyawhao/material-ui-next-datepicker

Ich denke, ich könnte zur Verfügung stehen, um zur Material UI beizutragen, wenn jemand kann
Gilde mich wie fange ich an


Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/mui-org/material-ui/issues/4787#issuecomment-385914554 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AacMkVQOH0GRO7JsIyggzHidwmypEPdHks5tuXjQgaJpZM4JSThr
.

@chingyawhao Der beitragende Leitfaden ist größtenteils vollständig, aber neue Komponenten kommen jetzt in packages/material-ui-lab . Ob dies ein geeigneter Kandidat ist, überlasse ich

@mbrookes Ich werde versuchen, am Wochenende einen Pull-Request an material-ui-lab zu stellen

@chingyawhao Danke für das Teilen des Projekts. Ich glaube, der beste Schritt ist im Moment, es zusammen mit den Alternativen in der Dokumentation zu dokumentieren .
Im anderen Bereich der Bibliothek gibt es bereits viel zu tun. Ich denke, dass die Datumsauswahl eine komplexe Komponente ist, um sie richtig zu machen. Sehen Sie sich zum Beispiel alle Probleme von bootstrap-datepicker an . Aus strategischer Sicht denke ich, je länger wir diese Komponente der Community überlassen können, desto besser. Aus den Download-Statistiken können wir schätzen, dass ~13% der Leute eine Datumsauswahl, eine Zeitauswahl oder etwas dazwischen benötigen. Es könnte besser sein, sich auf die 87% anderen zu konzentrieren.

@oliviertassinari hat es...
Können Sie mich benachrichtigen, wenn Sie bereit sind, mit der Entwicklung zu beginnen, vielleicht kann ich Ihnen helfen?

@chingyawhao, was machst du nicht mit @dmtrKovalenko auf https://github.com/dmtrKovalenko/material-ui-pickers , ich bin sicher, es gibt noch viel Raum für Verbesserungen

@stunaz Ich denke, sie haben unterschiedliche Ansichten zum Aussehen und https://github.com/dmtrKovalenko/material-ui-pickers viel besser zum Gesamtdesign des aktuellen material-ui-next sowie zum UX-Punkt .

@up-to-you Mein letztes Ziel ist es, der Darstellung von Pickern in Textfeldern im Desktop von material-design zu folgen. Diese Auswahler befinden sich in Popovers anstelle von Dialogen.

Das Projekt, an dem ich gearbeitet habe, erfordert eine angepasstere Komponente von Datepicker, die den Benutzer nicht auf die Auswahl des Datums aus dem Picker beschränkt. Der Benutzer kann das Datum auch in eine maskierte Texteingabe eingeben.

Mein Projekt wird dieses Maß an Anpassung ermöglichen, Sie können nur die Kalenderkomponente importieren, die die Auswahl ohne die Eingabe oder das enthaltende Dialogfeld oder Popover ist.

import {Calendar, Clock} from 'material-ui-next-pickers'

Und den Timepicker habe ich übrigens auch veröffentlicht XD

Material Design

@chingyawhao ist es möglich das Popover über einen IconButton auszulösen (ala über eine Verzierung). Ich habe meine eigenen maskierten Eingaben, möchte aber auf Knopfdruck eine Datumsauswahl öffnen können.

@techniq yup, sicherlich ... das klingt ähnlich wie das, was ich in meinem Projekt gemacht habe
Wenn Sie ein Beispiel benötigen, erstellen Sie ein Problem in meinem Repo

Warum ist das geschlossen? Sieht so aus (hier - https://material-ui.com/demos/pickers/), dass dies nicht behoben wurde.

Zu Ihrer Information, mein aktuelles Problem ist, dass es keine gute Lösung für datetime-local gibt, da Firefox es nicht nativ unterstützt. Beim Wechsel zu Material 1.0 stellten wir fest, dass Firefox-Benutzer unsere Datums-/Uhrzeitfelder einfach nicht verwenden konnten.

Es sieht so aus, als ob sich die meiste Diskussion oben um eine schöne Implementierung von Datum oder Uhrzeit dreht, aber keines davon befasst sich überhaupt mit dem Problem der Datums-/Uhrzeitfunktion.

@rogerstorm finanzierte dieses Problem mit 120 US-Dollar. Sehen Sie es auf IssueHunt

Hallo!

Können wir ein Update zum Status des DataPicker-Fortschritts erhalten?

In diesen langen Threads wird es schwierig, das einzuschätzen.

Und es scheint, dass @dmtrKovalenko sich seit stetig für Material-UI-Pickers engagiert .

Um genau zu sein:

  1. Im ursprünglichen Problem wurden Kontrollkästchenelemente aufgeführt Ist das genau?

    image
    Es scheint, als ob @dmtrKovalenko Tests, Dokumentationen, Demos usw. hat. Vielleicht hat er nicht alles erledigt, aber ist es richtig zu sagen, dass _nichts_ an dieser Stelle abgehakt werden kann?

  2. Ich würde gerne von @dmtrKovalenko zu diesem Thema hören. Haben Sie mit dem Material UI-Team über die Einführung Ihres Material-UI-Pickers gesprochen?

@jasonkylefrank Nichts ist abgehakt, weil im offiziellen Repository nichts getan wurde, und um fair zu sein, ist es unwahrscheinlich, dass dies in

@dmtrKovalenko Hat hervorragende Arbeit geleistet und es gibt keinen Grund, seine Komponenten nicht zu verwenden, obwohl sie nicht "offiziell" sind.

Wir planen keine Arbeiten an den Komponenten DatePicker und TimePicker.
Ich denke, wir sollten es der Gemeinschaft überlassen. @dmtrKovalenko hat es
Wir müssen die Dokumentation aktualisieren, um diese Position zu belegen, damit wir das Problem schließen können.

@rogerstorm Wenn das Problem von Material-

Ich weiß, du warst halb im Scherz, aber: cc @rogerstorm

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen