Material-ui: [DatePicker] Componente de puerto

@oliviertassinari Me gustaría saber algún plan para implementar este componente en la nueva versión. Me gustaría ayudar. Por favor avíseme. Gracias

La mejor forma de iniciar una migración de un componente es mirar los problemas abiertos. Eso da una mejor comprensión de las limitaciones que tiene la implementación actual. Eliminé DatePicker y TimePicker del hito de lanzamiento v1 para que podamos hacer que suceda antes. Aún así, su ayuda es bienvenida.

Algunos pensamientos son uno de los componentes:

• Es muy desafiante, ya que si proporcionáramos una experiencia de usuario deficiente, la gente estaría mejor si confiara en los selectores nativos de la plataforma.
• La manipulación de la fecha puede resultar compleja. Veamos si podemos aprovechar otra lib.
• Desktop UX es pobre, tenemos que repensarlo.
• Falta poder de composición. Necesitamos exponer API de nivel inferior

Dejando mi opinión con respecto a la importancia del selector de fecha (y selector de tiempo), creo que hay 3 componentes principales que definen si está tratando con un buen marco de interfaz de usuario o no, y son: Autocomplete , Datatables y Datepickers .

He probado muchos frameworks diferentes, y esos tres componentes son los que me dan más dolores de cabeza, principalmente debido a sus deficientes opciones de implementación e internacionalización, capacidades asíncronas y paginación, por nombrar algunos de los problemas.

Entonces, para ser breve: prefiero que estos tres componentes lleguen en su estado completo, pero tenga en cuenta que, al menos en mi opinión, habrá muchas personas que no elegirán un marco de interfaz de usuario. que carece de algunos de esos componentes.

De todos modos, MUI v1 parece muy prometedor, ¡estoy deseando probarlo cuando esté completamente lanzado!

Prefiero que estos tres componentes lleguen en su estado completo

@GabrielDuarteM Estoy de acuerdo, la DatePicker y TimePicker debe ser tan buena como la nativa para poder competir. De lo contrario, no tiene sentido. En este momento, no usaría los selectores v0.x en una aplicación lista para producción. Prefiero usar los selectores de la plataforma.
Lo más probable es que lancemos v1.0.0 sin esos componentes, no creo que sean cruciales, los selectores nativos han mejorado mucho a lo largo de los años.

Con respecto al Autocompletar, puede encontrar un ejemplo aquí .

Hacemos un uso extensivo de MUI timepicker y datepicker en nuestra aplicación de producción hoy, por lo que lamentablemente no podremos migrar a la v1.0.0 sin una solución basada en Material Design. El uso de selectores de fecha / hora nativos no es una buena solución y no estoy de acuerdo en que no sean "cruciales" para tener un paquete de interfaz de usuario de componentes de Material Design React bueno y completo.

Estoy de acuerdo con @skirunman , los DatePicker y TimePicker son muy importantes en las aplicaciones de producción, también la implementación nativa en la mayoría de los navegadores está muy limitada, por ejemplo, en Chrome para Android no se puede elijo el mes y el año y creo que esa parte es crucial cuando el usuario quiere elegir por ejemplo el cumpleaños.

Permítanme agregar más detalles sobre mis opiniones:

Es muy desafiante, ya que si proporcionáramos una experiencia de usuario deficiente, la gente estaría mejor si confiara en los selectores nativos de la plataforma.

Totalmente en desacuerdo. Los selectores nativos generalmente tienen capacidades limitadas y ciertamente no encajan con Material Design.

La manipulación de la fecha puede resultar compleja. Veamos si podemos aprovechar otra lib.

Creo que apostar por la implementación de un selector de fecha y hora basado en Material Design dejará a bastantes usuarios actuales en el frío. El uso de otra biblioteca para lo que actualmente es, y realmente debería ser, un componente central de MUI, debilita el atractivo general de MUI.

Desktop UX es pobre, tenemos que repensarlo.

No estoy seguro de por qué dice esto siempre que siga las Pautas de diseño de materiales.

Falta poder de composición. Necesitamos exponer API de nivel inferior

Es bueno tenerlo, pero no es un requisito para la versión 1.0.0 IMO.

@skirunman Estamos de acuerdo, necesitamos ese componente. Lo que está en juego aquí es la prioridad temporal. Creemos que se puede obtener más valor al lanzar v1 primero y luego implementar DatePicker / TimePicker. (las personas siempre pueden usar la versión maestra).
También proviene de la necesidad de los contribuyentes principales. Por ejemplo, es posible que nunca trabaje en ello, ya que no es algo que necesite.

Eso sin decir que si un colaborador tiene una implementación ✨ del componente, definitivamente lo revisaremos y lo fusionaremos una vez que estemos contentos con él :).

Recientemente comencé a mirar react-infinite-calendar , pero podría ser un reemplazo útil para el calendario v0 para algunos. Funciona de manera diferente al ser desplazable entre meses en lugar de pasos de mes explícitos, pero tiene algunas características adicionales solicitadas, como la selección de rango (solicitada a través de https://github.com/callemall/material-ui/issues/7574) y busca ser bastante componible (a primera vista)

¿Hay planes para que este tema avance?

@DoWhileGeek El plan más reciente que tuve fue agregar una nueva página en los documentos con:

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

ejemplos como.

@oliviertassinari Estoy buscando específicamente una resolución sobre el # 7781, es un poco un factor decisivo para nuestros chicos de ux.

@DoWhileGeek eres libre de PR una solución a # 7781 para la rama 0.x; el equipo central se centra en una versión 1.0. Es por eso que se han cerrado todos esos temas.

+1 Estamos muy interesados ​​en el selector nativo v1. Háganos saber si está trabajando en eso ahora
PD: Estamos entusiasmados con el material ui v1

Estoy bloqueando este problema para evitar más comentarios de tipo +1.

Este aviso ya aparece en los documentos Pickers :

Aviso
Actualmente estamos recurriendo a los controles de entrada nativos. Si está interesado en implementar o ha implementado un selector de diseño de materiales rico con una experiencia de usuario increíble, ¡háganoslo saber en el # 4787 y # 4796! Podríamos agregar un enlace o una demostración de su proyecto en la documentación.

Como se discutió aquí , el plan es recurrir a los controles nativos en la demostración del componente Pickers y promover un proyecto externo que esté dispuesto a asumir la tarea _dedicada_ de Datepicker , Timepicker o ambos.

Si está interesado en tomar a los recolectores como un proyecto externo, muchas personas quieren que eso tenga éxito, así que por favor compártanlo con nosotros y lo haremos:

• enlazar de forma destacada con su proyecto
• proporcionar una demostración dentro de los documentos de material-ui
• señale a los colaboradores en su dirección.

Dada la popularidad de material-ui y la demanda de estos recolectores, es probable que el propietario de un proyecto de recolectores reciba toda la fama y gloria de Internet que acompaña a un proyecto popular.

¿Interesado? Haga ping a @rosskevin y @oliviertassinari en gitter .

@rosskevin @oliviertassinari Actualmente estoy trabajando en el TimePicker y espero tener una primera versión funcional (tal vez todavía falten algunas animaciones o el modo horizontal) disponible este fin de semana. :arcoíris:

Una vez que haya terminado la mayor parte del selector de tiempo, comenzaré con DatePicker .

@leMaik Acabo de notar este proyecto https://github.com/dmtrKovalenko/material-ui-pickers por @dmtrKovalenko

¿Quizás ustedes dos podrían hablar de unirse a proyectos? No he profundizado para encontrar diferencias, pero podría valer la pena considerarlo.

También tenga en cuenta que recientemente hemos hecho la transición a una organización github mui-org . Si ustedes dos deciden unirse y alojar el proyecto bajo mui-org , háganoslo saber.

@rosskevin
Parece que sería mucho más complejo unirse a proyectos. Debido a que hemos utilizado el momento como dependencia de pares e implementamos muchos controles para mostrar fechas (como el selector de fecha y hora), en lugar de nuestros proyectos de @ leMaik, es una solución mucho más liviana para mostrar los selectores de tiempo: smile:
¿Qué pasa con el cambio a la organización? No estoy en contra, pero en realidad no puedo entender completamente lo que significa. ¿Solo mueve el repositorio debajo de la organización?

Con respecto a la organización: sí, solo sería moverla bajo la organización y tal vez la popularidad de material-ui en sí podría darle más exposición (y más mantenedores). Pero es solo un pensamiento, no hay razón para que deba estar allí, solo que ahora estamos abriendo las puertas a proyectos complementarios bajo la organización.

@rosskevin @dmtrKovalenko No me gustaría _merge_ los proyectos ya que adoptan un enfoque bastante diferente (hacemos un proyecto con un componente que hace una sola cosa). ¿Quizás podríamos transformar materiales-ui-pickers en solo un selector de fechas (y construir sobre esa gran base, agregando animaciones y todo) y mantener nuestro selector de tiempo como selector de tiempo y mover ambos bajo la organización? :pensando:

@leMaik
En cuanto a rehacer hasta la fecha, creo que no, porque para algunos proyectos sería muy útil tener un enfoque general para trabajar con fechas, los selectores de interfaz de usuario de material proporcionan todos los componentes para eso. Selector de fecha y hora también, que no está incluido en la especificación de diseño de materiales. 😉

Es bueno implementar como https://material.angular.io/components/datepicker/overview

Encontré una biblioteca de selector de fechas buena y flexible:
https://github.com/gpbl/react-day-picker

Se las arregló para crear un selector de fechas a distancia utilizando entradas de texto de material-ui:

@ saraivinha85 ¡Dulce! 🍬

¿Estaría dispuesto a compartir su implementación para que otros aprendan? (¡Incluso solo una esencia sería genial!)

@mbrookes No hay problema:
https://codesandbox.io/s/9l7kry52or

Este proyecto para selector de tiempo es bueno https://github.com/TeamWertarbyte/material-ui-time-picker

Hola. Como el componente es bastante importante y ya usamos la próxima versión, tengo que preguntar si hay una estimación sobre esto, o tal vez una forma de ayudar.

Verificó otros DatePickers, realmente no funciona lo suficientemente bien con ninguno, por lo que uno empaquetado debería ser la mejor solución (especialmente para trabajar con redux-form o redux-form-material-ui@next que también usamos).

Por ahora, parece que la mejor solución es usar https://github.com/dmtrKovalenko/material-ui-pickers. Lo estoy usando con formik.

Gracias, lo probaré. ¿Es un selector de fecha como modal un requisito de Material Design?

Una implementación de algo similar al selector de fechas y de rango de fechas influenciados por el material que se usan en el sitio beta de Google Flights sería genial.

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

¿Cómo puedo usar monthPicker o yearPicker solamente? ¿Podría darnos una guía?

@taoxueweilong Por favor, escriba un problema aquí . Aquí no hay mejor lugar para dar consejos :)

Hola compañeros desarrolladores ...
Tengo una implementación de datepicker usando Material UI aquí
https://github.com/chingyawhao/material-ui-next-datepicker

Creo que podría estar disponible para contribuir a Material UI si alguien me puede guiar cómo empezar

¡increíble!

El miércoles 2 de mayo de 2018 a las 11:13 a.m., Ching Yaw Hao [email protected]
escribió:

Hola compañeros desarrolladores ...
Tengo una implementación de datepicker usando Material UI aquí
https://github.com/chingyawhao/material-ui-next-datepicker

Creo que podría estar disponible para contribuir a Material UI si alguien puede
gremio cómo empezar

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/mui-org/material-ui/issues/4787#issuecomment-385914554 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AacMkVQOH0GRO7JsIyggzHidwmypEPdHks5tuXjQgaJpZM4JSThr
.

@chingyawhao La guía de contribuciones está casi completa, pero los nuevos componentes ahora van en packages/material-ui-lab . Me referiré a

@mbrookes Intentaré hacer una solicitud de extracción a material-ui-lab durante el fin de semana

@chingyawhao Gracias por compartir el proyecto. Creo que el mejor paso, por ahora, es documentarlo junto con las alternativas en la documentación .
Ya hay mucho trabajo por hacer en la otra área de la biblioteca. Creo que el selector de fechas es un componente complejo para hacerlo bien. Por ejemplo, eche un vistazo a todos los usos de bootstrap-datepicker . Desde un punto de vista estratégico, creo que cuanto más tiempo podamos postergar este componente a la comunidad, mejor. A partir de las estadísticas de descarga, podemos estimar que ~ 13% de las personas necesitan un selector de fechas, un selector de tiempo o algo intermedio. Podría ser mejor concentrarse en el 87% de los demás.

@oliviertassinari lo tengo ...
¿Puede notificarme cuando esté listo para comenzar a desarrollar, tal vez pueda ayudar?

@chingyawhao, ¿por qué no te unes a https://github.com/dmtrKovalenko/material-ui-pickers ? Estoy seguro de que hay mucho margen de mejora.

@stunaz Creo que tienen diferentes puntos de vista sobre la apariencia, sin embargo, obviamente https://github.com/dmtrKovalenko/material-ui-pickers se adapta mucho mejor al diseño general del material actual-ui-next, así como al punto UX .

@ up-to-you, mi objetivo final es seguir la descripción de los selectores de material-design en los campos de texto del escritorio. Esos selectores aparecen en ventanas emergentes en lugar de en diálogos.

El proyecto en el que estaba trabajando requiere un componente más personalizado de selector de fechas que no limita al usuario a seleccionar la fecha del selector, el usuario también puede escribir la fecha en una entrada de texto enmascarado.

Mi proyecto permitirá ese nivel de personalización, puede importar solo el componente de calendario, que es el selector sin la entrada o el cuadro de diálogo o ventana emergente que lo contiene.

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

Y por cierto, también lancé el selector de tiempo XD

@chingyawhao es posible activar el popover a través de un IconButton (ala a través de un adorno). Tengo mis propias entradas enmascaradas, pero me gustaría poder abrir un selector de fecha al presionar un botón.

@techniq sí , ciertamente ... eso suena similar a lo que hice en mi proyecto
Si necesita algún ejemplo, cree un problema en mi repositorio

¿Por qué esta cerrado? Parece (aquí - https://material-ui.com/demos/pickers/) que esto no se ha resuelto.

Para su información, mi problema actual es que no hay una buena solución para datetime-local, ya que Firefox no lo admite de forma nativa. Al cambiar al material 1.0, descubrimos que los usuarios de Firefox simplemente no podían usar nuestros campos de fecha y hora.

Parece que la mayor parte de la discusión anterior se trata de una buena implementación de la fecha o la hora, pero ninguno de ellos aborda el problema del funcionamiento de la fecha y la hora.

@rogerstorm financió este número con $ 120. Véalo en IssueHunt

¡Hola!

¿Podemos obtener una actualización sobre el estado del progreso de DataPicker?

Se está volviendo difícil evaluar esto en estos largos hilos.

Y parece que @dmtrKovalenko se ha estado comprometiendo constantemente con Material-UI-Pickers durante un tiempo.

Ser especifico:

1. El problema original enumeraba los elementos de la casilla de verificación y ninguno de ellos se ha marcado. ¿Es eso exacto?
   
   
   Parece que @dmtrKovalenko tiene pruebas, documentación, demostraciones, etc. Tal vez no lo haya hecho todo, pero ¿es correcto decir que en este momento no se puede marcar nada?

2. Me encantaría saber de @dmtrKovalenko sobre este tema. ¿Ha estado en conversaciones con el equipo de Material UI sobre cómo incorporar su selector de material-ui al redil?

@jasonkylefrank Nada está marcado porque no se ha hecho nada en el repositorio oficial y, para ser justos, es poco probable que se haga pronto. (Solo estábamos esta semana discutiendo el cierre de todos los problemas de selector de fecha / selector de tiempo en deferencia a las soluciones de terceros).

@dmtrKovalenko ha hecho un excelente trabajo, y no hay razón para no usar sus componentes aunque no sean "oficiales".

No planeamos ningún trabajo en los componentes DatePicker y TimePicker.
Creo que deberíamos dejarlo en manos de la comunidad. ¡@dmtrKovalenko lo ha estado matando!
Necesitamos actualizar la documentación para reflejar esta posición, para que podamos cerrar el problema.

@rogerstorm, si el problema se resuelve mediante material-ui-pickers, ¿puedo obtener mis $ 120 de IssueHunt? 🤣

Sé que estabas medio bromeando, pero: cc @rogerstorm