Material-ui: [DatePicker] Componente da porta

Criado em 22 jul. 2016  ·  51Comentários  ·  Fonte: mui-org/material-ui

  • [] Componente
  • [] Testes (pelo menos testes de unidade)
  • [] Docs
  • [] Demo
  • [] Acessibilidade do teclado # 3933
  • [] Composto, para que os usuários possam construir algo como # 7574, por exemplo
  • [] Corrige problemas antigos # 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

Comentários muito úteis

Fazemos uso extensivo do timepicker e datepicker MUI em nosso aplicativo de produção hoje, então, infelizmente, não poderemos migrar para a v1.0.0 sem uma solução baseada no Material Design. Usar selecionadores de data / hora nativos não é uma boa solução e eu discordo que eles não são "cruciais" para ter um pacote de IU do componente Material Design React bom e completo.

Todos 51 comentários

@oliviertassinari Eu gostaria de saber algum plano de implementação deste componente na nova versão. Eu gostaria de ajudar. Por favor, me avise.

A melhor maneira de iniciar a migração de um componente é examinar os problemas abertos. Isso dá uma melhor compreensão das limitações da implementação atual. Removi o DatePicker e o TimePicker do marco de lançamento v1 para que possamos fazer isso acontecer mais cedo. Ainda assim, sua ajuda é bem-vinda.

Alguns pensamentos sobre o componente:

  • É muito desafiador, como se estivéssemos fornecendo uma experiência do usuário ruim, as pessoas fariam melhor em confiar nos selecionadores nativos da plataforma
  • A manipulação de datas pode ser complexa. Vamos ver se podemos tirar proveito de outra lib.
  • A UX do desktop é ruim, precisamos repensá-la.
  • Está faltando o poder de composição. Precisamos expor APIs de nível inferior

Apenas deixando minha opinião sobre a importância do selecionador de data (e selecionador de tempo), acho que existem 3 componentes principais que definem se você está lidando com uma boa estrutura de interface do usuário ou não, e são eles: Autocomplete , Datatables e Datepickers .

Eu tentei muitos frameworks diferentes, e esses três componentes são os que me dão mais dores de cabeça, principalmente por causa de suas opções de implementação e internacionalização deficientes, capacidades assíncronas e paginação, para citar alguns dos problemas.

Portanto, para ser breve: prefiro que esses três componentes cheguem em seu estado completo, mas lembre-se também que, pelo menos na minha opinião, muitas pessoas não escolherão um framework de interface do usuário que carece de alguns desses componentes.

De qualquer forma, o MUI v1 parece muito promissor, estou ansioso para experimentá-lo quando for totalmente lançado!

Prefiro que esses três componentes cheguem em seu estado completo

@GabrielDuarteM Eu concordo, a DatePicker e TimePicker precisa ser tão boa quanto a nativa para competir. Caso contrário, é inútil. No momento, eu não usaria os seletores v0.x em um aplicativo pronto para produção. Prefiro usar os selecionadores da plataforma.
Provavelmente lançaremos a v1.0.0 sem esses componentes, não acho que sejam cruciais, pois os seletores nativos melhoraram muito ao longo dos anos.

Sobre o Autocomplete, você pode encontrar um exemplo aqui .

Fazemos uso extensivo do timepicker e datepicker MUI em nosso aplicativo de produção hoje, então, infelizmente, não poderemos migrar para a v1.0.0 sem uma solução baseada no Material Design. Usar selecionadores de data / hora nativos não é uma boa solução e eu discordo que eles não são "cruciais" para ter um pacote de IU do componente Material Design React bom e completo.

Eu concordo com @skirunman , DatePicker e TimePicker são muito importantes nos aplicativos de produção, também a implementação nativa na maioria dos navegadores são muito limitadas, por exemplo no Chrome para Android você não pode escolha o mês e o ano e acho que essa parte é fundamental quando o usuário quer escolher por exemplo o aniversário.

Deixe-me adicionar mais detalhes sobre minhas opiniões:

É muito desafiador, como se estivéssemos fornecendo uma experiência do usuário ruim, as pessoas fariam melhor em confiar nos selecionadores nativos da plataforma

Discordo totalmente. Os selecionadores nativos geralmente têm recursos limitados e certamente não se encaixam no Material Design.

A manipulação de datas pode ser complexa. Vamos ver se podemos tirar proveito de outra lib.

Acho que a implementação de um seletor de data e hora baseado no Material Design deixará alguns usuários atuais de fora. Usar outra biblioteca para o que é atualmente, e realmente deveria ser, um componente central do MUI, enfraquece o apelo geral do MUI.

A UX do desktop é ruim, precisamos repensá-la.

Não sei por que você diz isso, contanto que siga as Diretrizes de design de materiais.

Está faltando o poder de composição. Precisamos expor APIs de nível inferior

É bom ter isso, mas não é um requisito para o IMO v1.0.0.

@skirunman Concordamos, precisamos desse componente. O que está em jogo aqui é em relação à prioridade de tempo. Achamos que há mais valor em lançar o v1 primeiro e implementar o DatePicker / TimePicker depois. (as pessoas sempre podem usar a versão master).
Também decorre da necessidade dos contribuintes principais. Por exemplo, posso nunca trabalhar nisso, pois não é algo de que preciso.

Isso sem dizer que se um contribuidor tem uma implementação do componente, nós definitivamente iremos revisá-la e fundir assim que estivermos todos satisfeitos :).

Só recentemente comecei a olhar para o react-infinite-calendar , mas pode ser uma substituição válida para o calendário v0 para alguns. Ele funciona de forma diferente por ser rolável entre os meses em vez da revisão explícita do mês, mas tem alguns recursos adicionais solicitados, como seleção de intervalo (solicitada via https://github.com/callemall/material-ui/issues/7574) e parece ser bastante harmonioso (à primeira vista)

Há planos para que esse problema avance?

@DoWhileGeek O plano mais recente que eu tinha era adicionar uma nova página aos documentos com:

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

exemplos semelhantes.

@oliviertassinari Estou procurando especificamente por uma resolução sobre o # 7781, é um problema para nossos caras do ux.

@DoWhileGeek você está livre para PR uma solução para # 7781 para o branch 0.x; a equipe principal está focada em uma versão 1.0. É por isso que todas essas questões foram encerradas.

+1 Estamos realmente interessados ​​no selecionador v1 nativo. Por favor, deixe-nos saber se você está trabalhando nisso agora
PS Estamos entusiasmados com o material ui v1

Estou bloqueando esse problema para evitar mais comentários do tipo +1.

Este aviso já aparece nos documentos Pickers :

Perceber
No momento, estamos voltando aos controles de entrada nativos. Se você está interessado em implementar ou implementou um seletor de design de material rico com uma UX incrível, por favor, nos informe nos números 4787 e 4796! Poderíamos adicionar um link ou uma demonstração do seu projeto na documentação.

Conforme discutido aqui , o plano é voltar aos controles nativos na demonstração do componente Pickers e promover um projeto externo que esteja disposto a assumir a tarefa _dedicada_ de Datepicker , Timepicker ou ambos.

Se você estiver interessado em aceitar os selecionadores como um projeto externo, muitas pessoas querem ver isso bem-sucedido, então, compartilhe isso conosco e nós:

  • link com destaque para o seu projeto
  • fornecer uma demonstração dentro dos documentos material-ui
  • apontar colaboradores em sua direção.

Dada a popularidade de material-ui e a demanda por esses selecionadores, o proprietário de um projeto de selecionadores provavelmente receberá toda a fama e glória da Internet que acompanha um projeto popular.

Interessado? Faça ping em @rosskevin e @oliviertassinari no gitter .

@rosskevin @oliviertassinari Estou atualmente trabalhando no TimePicker e espero ter uma primeira versão funcional (talvez ainda faltando algumas animações ou o modo paisagem) disponível neste fim de semana. :arco-íris:

Assim que o seletor estiver pronto na maioria das vezes, começarei com DatePicker .

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

Talvez vocês dois possam discutir a união de projetos? Não procurei encontrar diferenças, mas pode valer a pena considerar.

Observe também que recentemente fizemos a transição para uma organização github mui-org . Se vocês dois decidirem se juntar e hospedar o projeto sob o mui-org por favor nos avise.

@rosskevin
Parece que seria muito mais complexo juntar projetos. Como usamos o momento como dependência de pares e implementamos muitos controles para exibir datas (como selecionador de data e hora), em vez de nossos projetos @ leMaik, é uma solução muito leve para exibir selecionadores de tempo: smile:
Que tal mudar para a org, não sou contra, mas na verdade não consigo entender totalmente o que isso significa? Apenas movendo o repositório na org?

Com relação à org: sim - seria apenas movê-la para a org e talvez a popularidade do próprio material-ui possa dar a ela mais exposição (e mais mantenedores). Mas é apenas um pensamento, não há razão para estar lá, só que agora estamos abrindo as portas para projetos complementares na org.

@rosskevin @dmtrKovalenko Eu não gostaria de _mergir_ os projetos, pois eles têm uma abordagem bem diferente (fazemos um projeto com um componente que faz apenas uma coisa). Talvez pudéssemos transformar material-ui-pickers em um selecionador de data apenas (e construir sobre essa grande base, adicionando animações e tudo mais) e manter nosso selecionador de tempo como selecionador de tempo e mover ambos sob a organização? :pensamento:

@leMaik
Quanto a refazer para apenas data - acho que não, porque para alguns projetos seria muito útil ter uma abordagem geral para trabalhar com datas, os selecionadores de materiais fornecem todos os componentes para isso. Selecionador de data e hora também, que não está relacionado na especificação do material design. 😉

Encontrou uma biblioteca de selecionador de datas boa e flexível:
https://github.com/gpbl/react-day-picker

Gerenciado para criar um selecionador de data com intervalo usando entradas de texto material-ui:

datepicker

@ saraivinha85 Doce! 🍬

Você estaria disposto a compartilhar sua implementação para que outras pessoas possam aprender? (Mesmo apenas uma essência seria ótimo!)

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

Este projeto para seletor de tempo é bom https://github.com/TeamWertarbyte/material-ui-time-picker

Oi. Como o componente é muito importante e já usamos a próxima versão, tenho que perguntar se existe uma estimativa sobre isso, ou quem sabe uma forma de ajudar?

Selecionado outros DatePickers, realmente não funciona bem o suficiente com nenhum, então um agrupado deve ser a melhor solução (especialmente para trabalhar com redux-form ou redux-form-material-ui@next que também usamos).

Por enquanto, parece que a melhor solução é usar https://github.com/dmtrKovalenko/material-ui-pickers. Estou usando com formik.

Obrigado, vamos experimentar. Um selecionador de data como modal é um requisito do Material Design?

Uma implementação de algo semelhante ao selecionador de datas influenciado pelo material e selecionadores de intervalo de datas usados ​​no site beta do Google Voos seria ótima.

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

como posso usar apenas o monthPicker ou yearPicker, você poderia me dar um guia?

@taoxueweilong Por favor, escreva um problema aqui . Aqui não é melhor lugar para dar conselhos :)

Olá colegas desenvolvedores ...
Tenho uma implementação do datepicker usando a IU do material aqui
https://github.com/chingyawhao/material-ui-next-datepicker

Acho que posso estar disponível para contribuir com a IU de materiais se alguém puder me sugerir como começar

incrível!

Na quarta-feira, 2 de maio de 2018 às 11h13, Ching Yaw Hao [email protected]
escreveu:

Olá colegas desenvolvedores ...
Tenho uma implementação do datepicker usando a IU do material aqui
https://github.com/chingyawhao/material-ui-next-datepicker

Acho que posso estar disponível para contribuir com a IU do material se alguém puder
guild me como começar

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/mui-org/material-ui/issues/4787#issuecomment-385914554 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AacMkVQOH0GRO7JsIyggzHidwmypEPdHks5tuXjQgaJpZM4JSThr
.

@chingyawhao O guia de contribuição está quase completo, mas novos componentes agora vão em packages/material-ui-lab . Vou adiar para @oliviertassinari se este é um candidato adequado.

@mbrookes , tentarei fazer uma solicitação de pull para material-ui-lab no fim de semana

@chingyawhao Obrigado por compartilhar o projeto. Acredito que o melhor passo, por enquanto, é documentá-lo junto com as alternativas na documentação .
Já há muito trabalho a fazer na outra área da biblioteca. Eu realmente acho que o selecionador de data é um componente complexo para acertar. Por exemplo, dê uma olhada em todos os isuses do bootstrap-datepicker . Do ponto de vista estratégico, acho que quanto mais pudermos adiar esse componente para a comunidade, melhor. A partir das estatísticas de download, podemos estimar que cerca de 13% das pessoas precisam de um selecionador de data, um selecionador de hora ou algo entre os dois. Pode ser melhor se concentrar nos 87% outros.

@oliviertassinari entendeu ...
Você pode me avisar quando estiver pronto para começar a desenvolver, talvez eu possa ajudar?

@chingyawhao o que você não faz parceria com @dmtrKovalenko em https://github.com/dmtrKovalenko/material-ui-pickers , tenho certeza de que há muito espaço para melhorias

@stunaz , acho que eles têm visões diferentes sobre a aparência, no entanto, obviamente https://github.com/dmtrKovalenko/material-ui-pickers se encaixa muito melhor no design geral do material-ui-next atual, bem como no ponto de UX .

@ up-to-you, meu objetivo final é seguir a descrição dos seletores do material design em campos de texto no desktop. Esses seletores estão em popovers em vez de caixas de diálogo.

O projeto em que eu estava trabalhando requer um componente mais personalizado do selecionador de data que não limita o usuário a selecionar a data no selecionador, o usuário também pode digitar a data em uma entrada de texto mascarada.

Meu projeto permitirá esse nível de personalização, você pode importar apenas o componente de calendário, que é o selecionador, sem a entrada ou a caixa de diálogo ou popover que o contém.

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

E por falar nisso, eu lancei o seletor de tempo também XD

Material Design

@chingyawhao é possível acionar o popover através de um IconButton (ala através de um adorno). Eu tenho minhas próprias entradas mascaradas, mas gostaria de poder exibir um seletor de data ao pressionar o botão.

@techniq sim, certamente ... parece semelhante ao que fiz no meu projeto
Se precisar de algum exemplo, crie um problema no meu repo

Por que está fechado? Parece (aqui - https://material-ui.com/demos/pickers/) que isso não foi resolvido.

Para sua informação, meu problema atual é que não há uma boa solução para datetime-local, já que o Firefox não oferece suporte nativo. Ao mudar para o material 1.0, descobrimos que os usuários do firefox simplesmente não podiam usar nossos campos de data e hora.

Parece que a maior parte da discussão acima é sobre uma boa implementação de data ou hora, mas nenhuma delas aborda a questão da data e hora de funcionamento.

A @rogerstorm financiou este problema com $ 120. Veja em IssueHunt

Olá!

Podemos obter uma atualização sobre o estado do progresso do DataPicker?

Está ficando difícil avaliar isso nesses longos tópicos.

E parece que @dmtrKovalenko tem se comprometido constantemente com os Material-UI-Pickers por um tempo.

Para ser específico:

  1. O problema original listou os itens da caixa de seleção e nenhum deles foi desmarcado. Isso é correto?

    image
    Parece que @dmtrKovalenko tem testes, documentação, demonstrações, etc. Talvez ele não tenha feito tudo, mas é correto dizer que _nada_ pode ser verificado neste momento?

  2. Adoraria ouvir @dmtrKovalenko sobre esse assunto. Você tem discutido com a equipe de IU de materiais sobre como trazer seu seletor de interface de usuário de material para o processo?

@jasonkylefrank Nada é marcado porque nada foi feito no repositório oficial e, para ser justo, é improvável que o seja tão cedo. (Estávamos apenas esta semana discutindo o fechamento de todas as questões do selecionador de data / hora em deferência às soluções de terceiros.)

@dmtrKovalenko Fez um excelente trabalho, e não há razão para não usar seus componentes, embora eles não sejam "oficiais".

Não planejamos nenhum trabalho nos componentes DatePicker e TimePicker.
Acho que devemos encaminhá-lo para a comunidade. @dmtrKovalenko o está matando!
Precisamos atualizar a documentação para refletir esta posição, para que possamos encerrar a questão.

@rogerstorm se o problema for resolvido por material-ui-pickers, posso obter meus $ 120 em IssueHunt? 🤣

Eu sei que você estava meio brincando, mas: cc @rogerstorm

Esta página foi útil?
0 / 5 - 0 avaliações