Material-ui: [DatePicker] Composant de port

@oliviertassinari J'aimerais savoir s'il est prévu d'implémenter ce composant dans la nouvelle version .Je voudrais aider .S'il vous plaît faites le moi savoir .Merci

La meilleure façon de démarrer une migration d'un composant est de regarder les problèmes ouverts. Cela permet de mieux comprendre les limites de la mise en œuvre actuelle. J'ai supprimé le DatePicker et le TimePicker du jalon de la version v1 afin que nous puissions le faire plus tôt. Néanmoins, votre aide est la bienvenue.

Quelques réflexions sur le composant :

• C'est très difficile car si nous fournissions une mauvaise expérience utilisateur, les gens feraient mieux de s'appuyer sur les sélecteurs natifs de la plate-forme
• La manipulation de la date peut être complexe. Voyons si nous pouvons profiter d'une autre bibliothèque.
• Desktop UX est pauvre, nous devons le repenser.
• Il manque de puissance de composition. Nous devons exposer les API de niveau inférieur

En laissant juste mon opinion concernant l'importance du sélecteur de date (et du sélecteur d'heure), je pense qu'il y a 3 composants principaux qui définissent si vous avez affaire à un bon framework d'interface utilisateur ou non, et ils sont : Autocomplete , Datatables et Datepickers .

J'ai essayé beaucoup de frameworks différents, et ces trois composants sont ceux qui me donnent le plus de maux de tête, principalement en raison de leurs mauvaises options d'implémentation et d'internationalisation, de capacités asynchrones et de pagination, pour n'en nommer que quelques-uns des problèmes.

Donc, pour faire court : je préfère que ces trois composants arrivent dans leur état complet, mais gardez aussi à l'esprit que, du moins à mon avis, il y aura beaucoup de gens qui ne choisiront pas un framework d'interface utilisateur qui manque de certains de ces composants.

Quoi qu'il en soit, MUI v1 a l'air très prometteur, j'ai hâte de l'essayer quand il sera complètement sorti !

Je préfère plutôt que ces trois composants arrivent dans leur état complet

@GabrielDuarteM Je suis d'accord, l' DatePicker et TimePicker doit être aussi bonne que l'implémentation native pour être compétitive. Sinon, c'est inutile. Pour le moment, je n'utiliserais pas les sélecteurs v0.x sur une application prête pour la production. Je préfère utiliser les cueilleurs de la plate-forme.
Nous publierons très probablement la v1.0.0 sans ces composants, je ne pense pas qu'ils soient cruciaux, les sélecteurs natifs se sont beaucoup améliorés au fil des ans.

Concernant la saisie semi-automatique, vous pouvez trouver un exemple ici .

Nous utilisons aujourd'hui de manière intensive le timepicker et le datepicker MUI dans notre application de production. Nous ne pourrons donc malheureusement pas migrer vers la v1.0.0 sans une solution basée sur Material Design. L'utilisation de sélecteurs d'heure/date natifs n'est pas une bonne solution et je ne suis pas d'accord pour dire qu'ils ne sont pas "cruciales" pour avoir un package d'interface utilisateur de composant Material Design React bon et complet.

Je suis d'accord avec @skirunman , les DatePicker et TimePicker sont très importants dans les applications de production, de plus l'implémentation native dans la plupart des navigateurs est très limitée, par exemple dans Chrome pour Android, vous ne pouvez pas choisissez le mois et l'année et je pense que cette partie est cruciale lorsque l'utilisateur veut choisir par exemple l'anniversaire.

Permettez-moi d'ajouter plus de détails sur mes opinions:

C'est très difficile car si nous fournissions une mauvaise expérience utilisateur, les gens feraient mieux de s'appuyer sur les sélecteurs natifs de la plate-forme

Désapprouve fortement. Les sélecteurs natifs ont généralement des capacités limitées et ne correspondent certainement pas à la conception matérielle.

La manipulation de la date peut être complexe. Voyons si nous pouvons profiter d'une autre bibliothèque.

Je pense que la mise en œuvre d'un sélecteur d'heure et de date basé sur la conception matérielle laissera pas mal d'utilisateurs actuels dans le froid. L'utilisation d'une autre bibliothèque pour ce qui est actuellement, et devrait être, un composant central de MUI, affaiblit l'attrait global de MUI.

Desktop UX est pauvre, nous devons le repenser.

Je ne sais pas pourquoi vous dites cela tant que cela suit les directives de conception des matériaux.

Il manque de puissance de composition. Nous devons exposer les API de niveau inférieur

C'est une bonne chose à avoir, mais pas une exigence pour la v1.0.0 IMO.

@skirunman Nous sommes d'accord, nous avons besoin de ce composant. Ce qui est en jeu ici, c'est la priorité temporelle. Nous pensons qu'il y a plus de valeur à obtenir en publiant d'abord la v1 et en implémentant le DatePicker/TimePicker plus tard. (les gens peuvent toujours utiliser la version principale).
Cela vient aussi du besoin des principaux contributeurs. Par exemple, je pourrais ne jamais travailler dessus car ce n'est pas quelque chose dont j'ai besoin.

C'est sans dire que si un contributeur a une implémentation du composant, nous allons certainement le revoir et le fusionner une fois que nous en serons tous satisfaits :).

Je n'ai commencé que récemment à regarder react-infinite-calendar , mais cela pourrait être un remplacement intéressant pour le calendrier v0 pour certains. Cela fonctionne différemment en étant défilant entre les mois au lieu d'un pas de mois explicite, mais il a quelques fonctionnalités supplémentaires demandées telles que la sélection de plage (demandée via https://github.com/callemall/material-ui/issues/7574) et regarde vers être assez composable (au premier abord)

Y a-t-il des plans pour que ce problème avance?

@DoWhileGeek Le plan le plus récent que j'avais consistait à ajouter une nouvelle page dans la documentation avec :

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

des exemples comme.

@oliviertassinari Je recherche spécifiquement une résolution sur #7781, c'est un peu un dealbreaker pour nos gars ux.

@DoWhileGeek, vous êtes libre de PR une solution à #7781 pour la branche 0.x; l'équipe de base se concentre sur une version 1.0. C'est pourquoi toutes ces questions ont été fermées.

+1 Nous sommes vraiment intéressés par le sélecteur natif v1. S'il vous plaît laissez-nous savoir si vous travaillez là-dessus maintenant
PS Nous sommes enthousiasmés par le matériel ui v1

Je verrouille ce problème pour empêcher d'autres commentaires de type +1.

Cet avis apparaît déjà dans la Pickers :

Avis
Nous revenons actuellement aux contrôles d'entrée natifs. Si vous êtes intéressé par la mise en œuvre ou avez mis en œuvre un riche sélecteur de conception de matériaux avec une UX géniale, faites-le nous savoir aux numéros 4787 et 4796 ! Nous pourrions ajouter un lien ou une démo de votre projet dans la documentation.

Comme discuté ici , le plan est de revenir aux contrôles natifs dans la démonstration du composant Pickers et de promouvoir un projet externe qui est prêt à assumer la tâche _dédiée_ du Datepicker , Timepicker ou les deux.

Si vous êtes intéressé à prendre en charge les cueilleurs en tant que projet extérieur, beaucoup de gens veulent que cela réussisse, alors partagez-le avec nous et nous allons :

• lier en évidence à votre projet
• fournir une démo dans la documentation de material-ui
• orienter les collaborateurs dans votre direction.

Compte tenu de la popularité de material-ui et de la demande pour ces cueilleurs, un propriétaire de projet de cueilleurs est susceptible de recevoir toute la renommée et la gloire sur Internet qui vont de pair avec un projet populaire.

Intéressé? Veuillez envoyer un ping à @oliviertassinari sur gitter .

@rosskevin @oliviertassinari Je travaille actuellement sur le TimePicker et j'espère avoir une première version fonctionnelle (il manque peut-être encore quelques animations ou le mode paysage) disponible ce week-end. :arc-en-ciel:

Une fois la plupart du temps terminé, je commencerai par le DatePicker .

@leMaik je viens de remarquer ce projet https://github.com/dmtrKovalenko/material-ui-pickers par @dmtrKovalenko

Peut-être pourriez-vous tous les deux discuter de la jonction de projets ? Je n'ai pas creusé pour trouver des différences, mais cela pourrait valoir la peine d'être pris en considération.

Notez également que nous sommes récemment passés à une organisation github mui-org . Si vous décidez tous les deux de vous joindre et d'héberger le projet sous le mui-org veuillez nous le faire savoir.

@rosskevin
Il semble que ce serait beaucoup plus complexe de rejoindre des projets. Parce que nous avons utilisé le moment comme dépendance entre pairs et implémentons de nombreux contrôles pour afficher les dates (comme le sélecteur de date/heure), au lieu de nos projets @leMaik, c'est une solution beaucoup plus légère pour afficher les sélecteurs d'heure :smile:
Qu'en est-il du passage à l'organisation, je ne suis pas contre, mais je ne comprends pas vraiment ce que cela signifie ? Déplacer simplement le référentiel sous l'organisation ?

Concernant l'organisation : oui - ce serait juste de la déplacer sous l'organisation et peut-être que la popularité de material-ui elle-même pourrait lui donner plus de visibilité (et plus de mainteneurs). Mais ce n'est qu'une pensée, aucune raison pour laquelle cela doit être là, juste que nous ouvrons maintenant les portes à des projets complémentaires sous l'org.

@rosskevin @dmtrKovalenko Je ne voudrais pas _fusionner_ les projets car ils adoptent une approche assez différente (nous réalisons un projet avec un composant qui ne fait qu'une seule chose). Peut-être pourrions-nous transformer les sélecteurs de matériel en un sélecteur de date uniquement (et s'appuyer sur cette excellente base, en ajoutant des animations et tout) et conserver notre sélecteur de temps en tant que sélecteur de temps et déplacer les deux sous l'organisation ? :pensée:

@leMaik
En ce qui concerne la refonte de la date - je pense que non, car pour certains projets, il serait très utile d'avoir une approche générale pour travailler avec les dates, les sélecteurs de matériel fournissent tous les composants pour cela. Sélecteur de date-heure également, qui n'est pas répertorié dans les spécifications de conception de matériau. ??

C'est bien d'implémenter comme https://material.angular.io/components/datepicker/overview

J'ai trouvé une bonne et flexible bibliothèque de sélecteur de date :
https://github.com/gpbl/react-day-picker

J'ai réussi à créer un sélecteur de dates à distance à l'aide des entrées de texte material-ui :

@saraivinha85 Doux ! ??

Seriez-vous prêt à partager votre mise en œuvre pour que d'autres puissent en tirer des leçons ? (Même juste un aperçu serait génial !)

@mbrookes Pas de problème :
https://codesandbox.io/s/9l7kry52or

Ce projet pour le sélecteur de temps est bon https://github.com/TeamWertarbyte/material-ui-time-picker

Salut. Comme le composant est assez important et que nous utilisons déjà la prochaine version, faut-il se demander s'il y a une estimation à ce sujet, ou peut-être un moyen d'aider ?

Vérifié d'autres DatePickers, ne fonctionne pas vraiment assez bien avec aucun, donc un groupé devrait être la meilleure solution (surtout pour travailler avec redux-form ou redux-form-material-ui@next que nous utilisons également).

Pour l'instant, il semble que la meilleure solution soit d'utiliser https://github.com/dmtrKovalenko/material-ui-pickers. Je l'utilise avec formik.

Merci, je vais essayer. Un sélecteur de date en tant que modal est-il une exigence de Material Design ?

Une implémentation de quelque chose de similaire au sélecteur de date influencé par le matériel et aux sélecteurs de plage de dates utilisés sur le site bêta de Google Flights serait bien.

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

comment puis-je utiliser uniquement monthPicker ou yearPicker, pourriez-vous s'il vous plaît donner un guide ?

@taoxueweilong Veuillez écrire un problème ici . Il n'y a pas de meilleur endroit pour donner un conseil :)

Bonjour amis développeurs...
J'ai une implémentation de datepicker utilisant Material UI ici
https://github.com/chingyawhao/material-ui-next-datepicker

Je pense que je pourrais être disponible pour contribuer à Material UI si quelqu'un peut me dire comment commencer

impressionnant!

Le mer. 2 mai 2018 à 11h13, Ching Yaw Hao [email protected]
a écrit:

Bonjour amis développeurs...
J'ai une implémentation de datepicker utilisant Material UI ici
https://github.com/chingyawhao/material-ui-next-datepicker

Je pense que je pourrais être disponible pour contribuer à Material UI si quelqu'un peut
guilde moi comment commencer

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/mui-org/material-ui/issues/4787#issuecomment-385914554 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AacMkVQOH0GRO7JsIyggzHidwmypEPdHks5tuXjQgaJpZM4JSThr
.

@chingyawhao Le guide de contribution est en grande partie complet, mais de nouveaux composants vont maintenant dans packages/material-ui-lab . Je m'en remettrai à @oliviertassinari pour savoir si c'est un candidat approprié.

@mbrookes Je vais essayer de faire une pull request à material-ui-lab ce week-end

@chingyawhao Merci d'avoir partagé le projet. Je pense que la meilleure étape, pour l'instant, est de le documenter avec les alternatives dans la documentation .
Il y a déjà beaucoup de travail à faire dans l'autre partie de la bibliothèque. Je pense que le sélecteur de date est un élément complexe à maîtriser. Par exemple, jetez un œil à toutes les utilisations de bootstrap-datepicker . D'un point de vue stratégique, je pense que plus on peut reporter ce volet à la communauté, mieux c'est. D'après les statistiques de téléchargement, nous pouvons estimer qu'environ 13% des personnes ont besoin d'un sélecteur de date, d'un sélecteur d'heure ou de quelque chose entre les deux. Il vaudrait peut-être mieux se concentrer sur les 87 % des autres.

@oliviertassinari a compris...
Pouvez-vous m'informer lorsque vous êtes prêt à commencer à développer, je peux peut-être vous aider ?

@chingyawhao que ne faites-vous pas équipe avec @dmtrKovalenko sur https://github.com/dmtrKovalenko/material-ui-pickers , je suis sûr qu'il y a beaucoup de place à l'amélioration

@stunaz Je pense qu'ils ont des points de vue différents sur l'apparence, cependant, évidemment https://github.com/dmtrKovalenko/material-ui-pickers est bien mieux adapté à la conception globale du matériel actuel-ui-next, ainsi qu'au point UX .

@up-to-you mon objectif final est de suivre la représentation des sélecteurs dans les champs de texte du bureau. Ces sélecteurs sont dans des popovers au lieu de dialogues.

Le projet sur lequel je travaillais nécessite un composant plus personnalisé du sélecteur de date qui ne limite pas l'utilisateur à sélectionner la date dans le sélecteur, l'utilisateur peut également saisir la date dans une entrée de texte masqué.

Mon projet permettra ce niveau de personnalisation, vous ne pouvez importer que le composant de calendrier qui est le sélecteur sans l'entrée ou la boîte de dialogue ou le popover contenant.

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

Et au fait, j'ai aussi sorti le timepicker XD

@chingyawhao est-il possible de déclencher le popover via un IconButton (ala via une parure). J'ai mes propres entrées masquées, mais j'aimerais pouvoir afficher un sélecteur de date en appuyant sur un bouton.

@techniq ouais , certainement... cela ressemble à ce que j'ai fait dans mon projet
Si vous avez besoin d'un exemple, créez un problème dans mon repo

Pourquoi est-ce fermé ? On dirait (ici - https://material-ui.com/demos/pickers/) que cela n'a pas été résolu.

Pour info, mon problème actuel est qu'il n'y a pas de bonne solution pour datetime-local, puisque Firefox ne le prend pas en charge nativement. Lors du passage au matériel 1.0, nous avons constaté que les utilisateurs de Firefox ne pouvaient tout simplement pas utiliser nos champs datetime.

Il semble que la plupart des discussions ci-dessus portent sur une bonne implémentation de la date ou de l'heure, mais aucune de celles-ci ne traite du tout le problème du fonctionnement de la date et de l'heure.

@rogerstorm a financé ce numéro avec 120 $. Voir sur IssueHunt

Salut!

Pouvons-nous obtenir une mise à jour sur l'état d'avancement de DataPicker ?

Il devient difficile d'évaluer cela dans ces longs fils.

Et il semble que @dmtrKovalenko s'engage régulièrement dans Material-UI-Pickers depuis un certain temps.

Pour être précis:

1. Le problème d'origine répertoriait les éléments de la case à cocher et aucun d'entre eux n'a été coché. Est-ce exact?
   
   
   Il semble que @dmtrKovalenko ait des tests, de la documentation, des démos, etc. Peut-être qu'il n'a pas tout fait, mais est-il exact de dire que _rien_ ne peut être coché à ce stade ?

2. J'aimerais entendre @dmtrKovalenko sur ce problème. Avez-vous eu des discussions avec l'équipe Material UI pour intégrer votre matériel de sélection d'interface utilisateur ?

@jasonkylefrank Rien n'est coché car rien n'a été fait dans le référentiel officiel et, pour être juste, il est peu probable qu'il le soit de si tôt. (Nous n'étions que cette semaine en train de discuter de la fermeture de tous les problèmes de sélecteur de date / timepicker par déférence pour les solutions tierces.)

@dmtrKovalenko A fait un excellent travail, et aucune raison de ne pas utiliser ses composants même s'ils ne sont pas "officiels".

Nous ne prévoyons aucun travail sur les composants DatePicker et TimePicker.
Je pense qu'il faut s'en remettre à la communauté. @dmtrKovalenko l' a tué !
Nous devons mettre à jour la documentation pour refléter cette position, afin que nous puissions clore le problème.

@rogerstorm si le problème est résolu par material-ui-pickers, puis-je obtenir mes 120 $ de IssueHunt? ??

Je sais que tu plaisantais à moitié, mais : cc @rogerstorm