Material-ui: Suporte React Native

Acabei de descobrir este repositório: https://github.com/lightningtgc/react-native-material-ui
Não sei se é bom, no entanto.

Obrigado @chadobado - Já falamos sobre isso com certeza e seria um projeto divertido para começar. No entanto, estamos com as mãos ocupadas com este projeto no momento. Manterei este problema aberto e atualizarei se algum dia criarmos uma biblioteca nativa.

Esta é realmente uma ótima ideia. Eu tentei testar a portabilidade de material-ui para React-Native. Nós só precisamos de folhas de estilo um pouco, mudar todos div para View , mudar todos h1 , h2 , etc para Text e vai funcionar muito bem. O único problema que encontrei é que o React Native não suporta totalmente boxShadow então é difícil implementar o componente Paper no momento. Além disso, seria ótimo se pudéssemos criar um script para portar automaticamente o código para React-Native, pois não é muito diferente.

altere todos os div para View, altere todos os h1, h2, etc para Text e funcionará muito bem

Não poderíamos usar um transformador de plug-in babel para fazer isso?

Esta é realmente uma ótima ideia

Você tem um projeto de demonstração?

@oliviertassinari

Não poderíamos usar um transformador de plug-in babel para fazer isso?

Não tenho certeza, pois a folha de estilo do React Native é bem diferente do CSS, então será bastante complicado fazer o transformador.

Você tem um projeto de demonstração?

Ainda não porque estou bastante ocupado, mas tentarei mostrar uma pequena demonstração em breve.
Mas aqui está o que precisamos fazer

Folhas de estilo

let styles = {
      root: {
        zIndex: 5,
        width: '100%',
        display: '-webkit-box; display: -webkit-flex; display: flex',
        minHeight: themeVariables.height,
        backgroundColor: themeVariables.color,
        paddingLeft: spacing.desktopGutter,
        paddingRight: spacing.desktopGutter,
      }
}

para

let styles = StyleSheet.create({
      root: {
        // zIndex: 5, (not supported)
        //width: '100%', (number only)
        //display: '-webkit-box; display: -webkit-flex; display: flex', (React Native always use Flex)
        minHeight: themeVariables.height,
        backgroundColor: themeVariables.color,
        paddingLeft: spacing.desktopGutter,
        paddingRight: spacing.desktopGutter,
      }
})

Solução zIndex

JSX

<div {...other} style={this.prepareStyles(styles, style)}>
  <h1 style={styles.text}>Hello world</h1>
</div>

para

<View {...other} style={this.prepareStyles(styles, style)}>
  <Text style={styles.text}>Hello world</Text>
</View>

Também precisamos modificar styles/transition.jsx (React Native use object vez de string ), mixins/style-propable.jsx , pois não precisamos lidar com vários navegadores, etc.

Acabei de publicar uma bifurcação WIP para react-native em https://github.com/lenaten/material-ui-native.
Atualmente apenas Card e RaiseButton estão funcionando, mas sem estilo (WIP lembra?)

@lenaten Interessante!
Eu também queria começar a trabalhar em um wrapper entre este projeto e o mrn (https://github.com/oliviertassinari/react-material).
Parece que seu fork está funcionando apenas com react-native, como você faria para funcionar com o navegador também?
Eu acho que é o ponto mais difícil e deve ser abordado agora, já que você diz que tem dois componentes de trabalho. Eu posso ajudar se você quiser.
Como dito antes, eu também queria investigar https://github.com/binggg/mrn para nossa implementação nativa.

Quando for respondido, acho que podemos mesclar sua bifurcação aqui.

Material-UI é um projeto maduro contra um projeto mrn que perde muitos componentes materiais. Se meu POC funcionar como exceção, mesclá-lo para a estrutura de arquivos de plataforma cruzada deve ser fácil. Não tenho tempo para reinventar a roda e começar do zero o projeto.

De qualquer forma, sua ajuda em pensamentos e código é muito bem-vinda.

@oliviertassinari Eu também.

Minha ideia para fazer material-ui funcionar com navegador e nativo é usar a estrutura de nome de arquivo, semelhante à maneira react-active lida com iOS e Android ao mesmo tempo.

app-bar.native.jsx
app-bar.browser.jsx
common.jsx

ou ainda podemos usar os mesmos componentes para navegador e nativo e então escrever um wrapper para lidar com eles. Por exemplo, react-native usa View , o navegador usa div e faça assim:

div.browser.jsx

export class ... {
  render() {
    return </div>
  }
}

div.native.jsx

export class ... {
  render() {
    return </View>
  }
}

app-bar.jsx

import {div} from "div"

Na verdade, podemos criar um projeto separado para este wrapper.

@quanglam2807 Fico feliz em ouvir isso.

Em relação à organização do código, gosto da ideia de ter extensões de arquivo separadas.
Eu tomaria o exemplo https://github.com/benoitvallon/react-native-nw-react-calculator/tree/master/src/common/components como a maneira de fazer isso.

Em relação à organização do projeto, posso ter mudado de ideia.
Eu acho que é melhor seguir a abordagem do Google e trabalhar em um grande repositório único. Portanto, trabalhar em uma sincronização de fork com material-ui ou aqui pode ser uma boa maneira de fazer isso.

Para começar com nossos arquivos .native , podemos depender de

• https://github.com/binggg/mrn
• ou https://github.com/xinthink/react-native-material-kit

componentes.

@oliviertassinari Também adoro a ideia do modelo de "extensão de arquivo". O mais importante para mim agora é trabalhar com componentes nativos. Se você quiser ajudar com a abstração de código, seja bem-vindo. Comprometo-me a remover o sufixo "nativo" do nome do repositório :)

@lenaten é compatível com o material-ui-native com o tcomb-form-native ou, se não, qual seria o tamanho do projeto?

@mvayngrib parei para trabalhar nesse projeto por um tempo..

@lenaten que pena, obrigado por responder

Tudo bem, comecei a trabalhar neste https://github.com/callemall/material-ui/pull/2611.
Isso vai levar algum tempo!

@oliviertassinari sensacional! muito muito animado

então o empreendimento portuário ainda está aberto? Em caso afirmativo, qual foi o processo estabelecido para implementar os componentes?

@dorthwein Ainda está aberto.

Do meu ponto de vista, o processo é o seguinte:

• [ ] Atualize para a versão mais recente do react- native e remova o projeto . https://github.com/callemall/material-ui/pull/3829
• [ ] Brinque com react-look e veja como podemos usá-lo para o muiTheme que vem do contexto. https://github.com/callemall/material-ui/pull/3829
• [x] Aguarde a reorganização da
• [ ] Comece a trabalhar no aplicativo de documentação que usaremos para mostrar o novo componente.
• [ ] Comece a trabalhar na versão nativa dos componentes.

@oliviertassinari - Posso contribuir com um pouco de tempo para portar alguns dos componentes assim que o caminho a seguir estiver definido. Olhando para a sua lista, a única incógnita no momento é a aparência de reação, certo?

@dorthwein estamos felizes em ouvir isso.
Estou usando react-look aqui #3829. O único problema que tenho é um pequeno. O React Native está exibindo algum aviso sobre o uso incorreto da API StyleSheet . Eu não olhei para isso em detalhes, mas acredito que pode ser resolvido.

@oliviertassinari @dorthwein Estou feliz que esse esforço (ou seja, trazer material-ui para react-native ) não esteja morto. Eu só queria salientar que também há outro novo projeto material-ui to react-native que não foi mencionado neste tópico: https://github.com/react-native-material- design/react-native-material-design . Esse projeto parece ser baseado em https://github.com/binggg/mrn.

@oliviertassinari Vi em outro tópico se o suporte ao iOS fazia sentido para esta porta - acho que sim, especialmente quando você observa como o Google Maps e outros aplicativos do Google Material + iOS estão por aí. Onde fizer sentido e houver um componente iOS pré-existente forte (por exemplo, switches), ele deve ser usado para o switch iOS no iOS. A implementação do Android e iOS também não é um fardo.

@oliviertassinari A estrutura de arquivos component.native.js, component.android.js, component.ios.js também parece fazer mais sentido para mim.

@oliviertassinari Eu tentei colocar os documentos em funcionamento sem sorte. Poucos problemas:

• package.json: react-native não gosta do nome do pacote material-ui - mudar para materialUI resolveu o problema
• A ramificação material-ui/react-native atual está tendo um problema com o empacotador react-native e não está criando o arquivo mainjs.bundle. Não consegui descobrir o que estava acontecendo aqui.
• Não consigo obter um aplicativo react-native funcionando em cima do repositório material-ui existente. Se alguém teve alguma sorte nesta frente, vamos obter um conjunto estável de como contribuir/desenvolver componentes nativos.

@dorthwein Obrigado pelo feedback. O ramo react-native é altamente experimental. Precisamos resolver isso.
Por outro lado, não tenho nenhum problema do meu lado (https://github.com/callemall/material-ui/pull/3829).
Eu deveria tentar começar com um novo git clone .

Sim, então o próximo estágio do meu projeto atual é trabalhar em um aplicativo móvel usando material design - eu gostaria de usar isso, pois todo o nosso material da web também está nisso. Se conseguirmos um ambiente de trabalho, começarei a derrubá-lo junto com nosso projeto.

Estava lendo algumas coisas e notei este boato da página FB React Native.

"O componente mais fundamental para a construção de UI, View é um container que suporta layout com flexbox, estilo, algum manuseio de toque e controles de acessibilidade, e é projetado para ser aninhado dentro de outras views e ter de 0 a muitos filhos de qualquer tipo. mapeia diretamente para a visualização nativa equivalente em qualquer plataforma em que o React esteja sendo executado, seja um UIView,

Também encontrei este recurso - experimentando agora. Parece bastante direto e talvez valha a pena dar uma olhada

https://github.com/necolas/react-native-web

@dorthwein Ótima ideia! Mas se seguirmos esse caminho, acho que desenvolver uma versão apenas para React Native seria melhor.

Podemos reescrever todo o projeto em APIs React Native em vez de códigos separados para Native e DOMs. Surpreendente! Eu nunca pensei sobre isso.

@quanglam2807 sim - dessa forma, novos recursos etc... Fiquem alinhados uns com os outros. O maior desafio eu acho que é ter os estilos e animações funcionando. Outra grande vantagem é que podemos adicionar gradualmente suporte para diferentes componentes.

O lado negativo é que tudo precisará usar caixas flexíveis.

Dado que esta é uma grande refatoração da base de código - quem precisa assinar isso para seguir em frente? Eu ainda preciso brincar e ver o quão robusto o material react-native-web também é.

@quanglam2807 @oliviertassinari outra vantagem com essa abordagem é que o material-ui também será facilmente transferido para https://github.com/ptmt/react-native-desktop .

@oliviertassinari está usando apoiar se funcionar como esperado?

@dorthwein Eu amo a ideia por trás desse projeto. Mas eu não acho que isso ajudaria em um futuro próximo.
Não precisamos primeiro escrever uma versão nativa de nossos componentes antes de podermos usar react-native-web ?

@oliviertassinari não, o que

O processo seria então, em vez de escrever versões nativas de cada componente, teríamos apenas que converter os existentes para usar View em vez de div e style Text em vez de usar coisas como h1 e label.

Definitivamente não é um empreendimento pequeno, mas o processo seria atualizar os componentes existentes em vez de tentar criar e manter várias versões.

O processo seria então, em vez de escrever versões nativas de cada componente, teríamos apenas que converter os existentes para usar View em vez de div e style Text em vez de usar coisas como h1 e label.

Isso soa exatamente como escrever uma versão nativa que, espero, funcione no navegador também. Até onde eu sei react-native-web está trazendo react nativo para a web e não o contrário.
Ainda assim, pode ser muito útil compartilhar o mesmo código :+1:.
Eu vi um pequeno problema com esta lib até agora. Sua implementação StyleSheet.create não suporta valores dinâmicos (necessários para o muiTheme). Poderíamos usar o react look para este caso de uso.

@oliviertassinari, você está certo - eu estava entendendo ao contrário. A etapa 1 parece ainda estar construindo versões nativas de reação dos componentes. A etapa 2 seria potencialmente fundi-los em uma única base de código usando algo como web react-native.

@wordyallen : parece bom 👍

@pgangwani Acabei de começar a mexer com isso... Ainda não está pronto.

Eu tenho usado https://github.com/react-native-material-design/react-native-material-design para preencher a lacuna, mas também é muito áspero nas bordas e sem desenvolvimento ativo

Eu doaria financeiramente para este empreendimento, se pudesse.

Oi pessoal,

Eu trabalho em react-native-material-ui , que é inspirado nesta biblioteca. Sinta-se à vontade para tentar - eu gostaria de ouvir qualquer feedback ;)

@xotahal et. al, Em vez de criar do zero, o que deveríamos fazer IMHO é bifurcar esta biblioteca e portar componentes existentes em vez de recriá-los. A necessidade de entradas de estilo de material é extremamente necessária no espaço RN, se você me perguntar. Obrigado a todos por seus esforços de OSS.

Não acho que haja muito código comum, acho que criar do zero faz sentido. O estilo no RN será 90% diferente deste. E há algumas mecânicas específicas da plataforma, como animações...

Parece que adotar a estrutura de componentes, adereços (e documentos) e ter um upstream claro, mesmo que muitas mudanças, seria benéfico a longo prazo para aqueles que mudam de web para nativo e é da maior importância. O resto torna-se um detalhe de implementação.

Concordo com @jhabdas ; quanto mais semelhantes as APIs puderem procurar para cada componente, menos chocante será para os desenvolvedores trocarem de projetos da web e projetos nativos. Quanto menos chocante a experiência, mais produtivos eles podem ser. Eu esperaria que os detalhes específicos da plataforma fossem abstraídos nos bastidores do componente.

@chadobado ou mantenedor, você poderia renomear este problema para "Suporte React Native" para aumentar a visibilidade ao pesquisar este repositório? Atualmente, a pesquisa "React Native" enterra isso na lista porque o termo é hifenizado no título.

FWIW, isso chamou minha atenção.

@necolas no suporte da Web por react-native-material-kit :

É improvável que você precise portar muito se qualquer folha de estilo como compatibilidade for fornecida pela implementação da Web do React Native

@jhabdas se você jogar um pouco com

Ponto justo @antoinerousseau. Eu continuo pensando em uma citação de James Long no RN:

Pense nisso como um protótipo para uma direção diferente para a web

Se estou entendendo o propósito da biblioteca @necolas está funcionando, parece que uma abordagem sensata seria inverter o problema: em vez de portar o CSS para RN, basta reconstruir tudo no RN e voltar a porta para a web usando um shim. O React Native Material Kit já deu um bom salto no problema.

Como react-native-web parece incrível, vou apenas criar arquivos material-ui.android.js , material-ios.ios.js e material-ui.web.js em meu próprio projeto pessoal e chamá-lo de bom. Se eu seguir a API material-ui envolvendo todo o resto, eventualmente funcionará. Se material-ui me surpreender e simplesmente funcionar, só precisarei remover o .web do .web.js e excluir os outros arquivos. Dessa forma, posso fazer a transição seletiva para material-ui por componente.

@oliviertassinari Então eu adicionei o branch react-native como uma dependência do NPM e instalei todos os plugins do Babel. Recebi esta mensagem ao importar qualquer componente:

EventPluginRegistry: Cannot inject event plugin ordering more than once. You are likely trying to load more than one copy of React.

Meu objetivo é usar material-ui o mais rápido possível por componente. Concedido, eu fiz um git rebase master e deveria ter feito um git rebase next se alguma coisa. Todos os componentes individuais react-native bloqueados pela preparação do trabalho da filial de next agora?

E eu escrevi um código que me permite consumir react-native-vector-icons exatamente da mesma forma que eu consumo ícones material-ui :

// <strong i="19">@flow</strong>

import React from 'react'
import {
  Text,
  View
} from 'react-native'
import Mui from './app/material-ui'
import Icons from './app/material-ui/icons'

export default React.createClass({
  render: function() {
    return (<View>
      <Icons.AccountCircle />
      <Mui.IconAccountCircle />
    </View>)
  }
})

Embora no momento react-native-vector-icons e material-ui tenham sintaxe de importação incompatível. @oblado Eu tive que importar glyphMap e iterar sobre ele e exportar a lista inteira como um objeto grande.

import { glyphMap } from 'react-native-vector-icons/MaterialIcons'

Seria bom se react-native-vector-icons Ícones de material fossem agrupados por categoria como material-ui permitindo exportações individuais de dentro de uma categoria:

import ActionHome from 'material-ui/svg-icons/action/home'

Devemos trabalhar em uma solicitação pull para tornar react-native-vector-icons compatível com as convenções de importação de material-ui ?

@mattferrin O react-native é bastante antigo agora. Não se destina a ser consumido pelos usuários. Foi uma prova de conceito sobre o caminho a seguir.
Até onde eu olhei para esse problema, uma das abordagens promissoras seria reescrevê-lo para segmentar react-native . Então react-native-web faria a parte mais difícil para nós.
No entanto, existem alguns desafios:

• Quanto _react-native-web_ está pronto para produção? Por exemplo, eu não vi testes visuais.
• Como você lida com consultas de mídia?
• Como você lida com uma solução de temas complexos?

vale a pena dar uma olhada no react-with-styles .

Quanto react-native-web está pronto para produção?

@oliviertassinari Atualmente estou portando um site para react-native-web e sinto que vale a pena abraçar. Está faltando um componente href de marca de âncora de plataforma cruzada e pode estar faltando outras sutilezas, mas o ReactDOM subjacente está pronto para produção e é disso que precisamos.

Como você lida com consultas de mídia?

material-ui deveria se importar? Existem maneiras de encontrar as dimensões de um componente ou de uma tela em todas as plataformas. Contanto que os componentes material-ui possam ser passados ​​adereços que controlam o estilo, o que eles fazem, somos de ouro, eu acho.

material-ui realiza consultas de mídia? Precisamos?

Como você lida com uma solução de temas complexos?

Não podemos apenas verificar Platform para omitir ou renomear props não suportados pelo React Native, já que (se a memória não me falha) o preenchimento e a margem são essencialmente revertidos no React Native. Tudo o que teríamos que fazer é envolver o método equivalente createStyleSheet para transformar/filtrar o resultado em estilos compatíveis com plataformas não "web".

Ainda não usei, mas o Fela pretende ser multiplataforma, e acho que isso é importante. Desde que o autor de Fela escreveu React Look e como isso parece ter sido uma escolha prévia, parece uma escolha natural.

Eu também não usei, mas algo como react-tunnel parece bom para o contexto de temas. Poderíamos simplesmente usá-lo e expô-lo, novamente apenas porque parece mais compartilhável pela comunidade. Pode haver um equivalente mais popular.

Quanto react-native-web está pronto para produção? Por exemplo, eu não vi testes visuais.

Existem exemplos interativos aqui: https://necolas.github.io/react-native-web/storybook/

Como você lida com consultas de mídia?

Em JavaScript, usando matchMedia (ou usando Dimension ) para determinar quais estilos e componentes renderizar.

Está faltando um componente href de marca de âncora multiplataforma

Sim, eu não tenho certeza do que uma solução "adequada" deve ser, mas você pode usar View e Text como links por enquanto (somente suporte na web, é claro):

<Text accessibilityRole='link' href={href}>{text}</Text>

Como você lida com uma solução de temas complexos?

O React Native não se importa como você faz isso. Você ainda pode usar context para determinar quais objetos de estilo aplicar. Eu gosto bastante da API do Fela dentro dos componentes, mas a API de implementação e plugin parece um exagero se você usar react-native-web .

Tudo o que teríamos que fazer é envolver o método equivalente createStyleSheet para transformar/filtrar o resultado em estilos compatíveis com plataformas não "web".

O problema é que você expõe uma API de estilo que não é compatível com RN? Nesse caso, sugiro que você exponha uma API de estilo compatível com RN e deixe react-native-web convertê-la em estilos DOM.

@necolas

O problema é que você expõe uma API de estilo que não é compatível com RN? Nesse caso, sugiro que você exponha uma API de estilo compatível com RN e deixe react-native-web convertê-la em estilos DOM.

Bom ponto. react-native-web tem um sentido de :hover por exemplo?

@necolas E o trabalho específico que estou fazendo só precisa oferecer suporte a navegadores evergreen, mas existe a possibilidade de portar para react-native-web custaria material-ui compatibilidade do navegador com versões mais antigas? Eu não sei nada sobre isso realmente. Eu realmente acho que react-native-web é a abordagem certa.

Ele não fornece nada de especial para estilos de foco (nem RN). Gostaria de saber se as implementações de desktop para Windows e Ubuntu agrupam alguma coisa para interfaces de mouse ou deixam isso para você por meio de eventos.

Não tenho certeza de qual suporte ao navegador você precisa, mas talvez seja possível acomodá-lo quando surgirem problemas

Eu acho que pode ser necessário injetar um booleano no contexto da hierarquia do componente via MuiThemeProvider para escolher entre uma API de estilo de componente react-native-web versus uma react-dom .

A melhor resposta é apenas mudar para a API de estilo react-native-web , e isso é o que eu defendo, mas isso provavelmente causaria um transtorno.

@oliviertassinari Poderíamos nos safar mudando material-ui para uma API de estilo react-native ? Talvez permitir que estilos específicos de mouse vazem?

@necolas @oliviertassinari Apenas como um FYI. É desleixado agora, mas tenho trabalhado na portabilidade de um branch (https://github.com/mattferrin/material-ui-build/tree/mine) para ser multiplataforma nos últimos 2-3 dias porque eu realmente preciso disso (para reduzir meu trabalho total a longo prazo).

Eu tenho portado tudo para a sintaxe react-native-web e comentando estilos que não portam, mas acho que vou acabar comentando-os de volta e usando Platform.OS == 'web' para reter o código original essencialmente inalterado quando terminar de portar o site em que estou trabalhando. Nesse ponto, apenas as coisas que eu pessoalmente preciso serão portadas e imperfeitamente.

É uma bagunça total (até eu retocar mais tarde) porque eu empurro para pular entre máquinas Mac e Windows na hora.

Para quem não vê a hora do MUI chegar no RN existem alternativas, e algumas bem bonitas. Estou mantendo uma lista perene aqui: https://habd.as/awesome-react-components/#react -native

Eu sabia que toda a solução de estilo estava mudando, mas perdi a parte em que a biblioteca está sendo reescrita do zero. Isso é minha culpa. Eu tinha assumido, olhando para algum código, que os estilos finais permaneceriam essencialmente os mesmos e que apenas a tecnologia mudaria. Eu estava incorreto. Eu não ignorei completamente o roteiro, apenas fiz suposições que estão muito erradas. Acho que vou ter que desistir da minha tentativa aqui.

@mattferrin Não exatamente do zero (embora em alguns casos isso seja verdade, por exemplo Table ), embora a mudança de estilo da solução exija muitas alterações de API, mas também nos dá a oportunidade de racionalizar a API em outras áreas para muitos componentes . Lamento se seus esforços foram em vão - espero que isso não o afaste do Material-UI!

@mbrookes Não tem. Eu cometi o erro de ramificar master vez de next e subestimar a diferença (e o trabalho total em geral). A culpa foi minha e eu sabia que havia risco. Eu simplesmente retornarei elementos Text vazios como espaços reservados até mais tarde na minha fachada React Native material-ui . Quando eu tiver portado totalmente meu site para react-native-web , voltarei e tentarei rebasear novas alterações em next .

Liberando esse cara hoje: https://carbon-ui.com

Inspirado no material-ui, funciona na web e react-native :)

@tuckerconnelly vc fez meu dia

@tuckerconnelly uau, muito potencial neste projeto... bem feito! Esperamos que a comunidade maior apoie esse esforço! 🍻

@tuckerconnelly Estou um pouco confuso. Descobri que é realmente muito fácil tornar material-ui condicionalmente multiplataforma (apesar do meu erro de ramificar master vez de next e desperdiçar meu tempo). Estou curioso para saber quais benefícios você vê em um projeto independente?

Eu tentei em fevereiro e tive dificuldade com isso, em particular com o componente ripple e com consultas de mídia multiplataforma.

Às vezes é mais fácil começar do zero.

para mim não faz sentido ter componentes React que não funcionem no React Native ... e como os devs do material-ui não consideraram o RN uma prioridade ... é justo / lógico começar em um novo caminho

@tuckerconnelly Não acho que importe como os componentes são implementados. Só espero que ambos os projetos tentem implementar a mesma API (e concordem com os mesmos nomes) para seus componentes. Fico feliz que você tenha trabalhado nisso e compartilhado.

Então, para 2017/2018, após a v1.0.0, o RN será o próximo objetivo do material-ui?

Como visto de:

• A participação da comunidade para v1
• O número de pessoas que querem apoio do RN
• O fato de muitos projetos terem sido baseados ou inspirados no Material-ui para oferecer componentes RN
• A experiência adquirida com tudo isso e o fato de que muito tempo se passou desde que esta edição foi aberta

Se você iniciasse (provavelmente após o lançamento da v1) um projeto para oferecer componentes RN, muitas pessoas o ajudariam. Você só precisa começar e definir um caminho claro e seria bom ir. Você tem uma grande comunidade, vamos usá-la para fazer o melhor produto possível.

O @NitroBAY 1.0 usa JSS em vez de objetos JS para estilização, portanto, depende de cssinjs/jss#368 para suportar React Native. Mas acho melhor desenvolver uma versão paralela para React Native como esta: https://github.com/xotahal/react-native-material-ui. Então podemos rodar a versão React Native na web usando https://github.com/necolas/react-native-web

Então, isso é um não-conserto? Se sim, pode ser marcado como tal?

@jhabdas Eu adoraria ver uma boa biblioteca trazendo a especificação do material para o React Native.
Pelos links postados no tópico, já existe uma boa lista de candidatos.

Se mantivermos essa questão em aberto, trata-se de unificar a web e o nativo. Fornecendo uma API consistente entre as duas plataformas. Eu gostaria de ter tempo para trabalhar nisso, mas não tenho e duvido que vá mudar.
A equipe @callemall/material-ui adoraria ver alguém liderando essa questão.

Ainda suportando carbon-ui :) Eu só adiciono componentes quando preciso deles (não tentando preencher proativamente toda a especificação), mas acho que há uma boa estrutura para as pessoas se unirem.

• Ele gera documentos automaticamente a partir dos comentários do componente
• Tem site de documentos (carbon-ui.com)
• Suporta nativo e web com os mesmos componentes

Ajudaria quem quiser adicionar componentes :)

@tuckerconnelly O que você acha sobre https://github.com/xotahal/react-native-material-ui? Não funciona na web devido a um bug com Elevation, mas se aplicarmos seu código https://github.com/tuckerconnelly/carbon-ui/blob/master/src/style/Elevation.js , acho que sim trabalharia. @oliviertassinari ressalta que precisamos decidir sobre um projeto principal para trabalharmos juntos.

@quangbuule espere você dizer que devemos desenvolver aplicativos como aplicativos RN e depois usar essa ferramenta para transformar o RN em uma versão WEB?
Nunca ouvi falar dessa coisa, mas tudo bem. Mas então isso significa que não usaríamos mais material-ui mas mais um fork RN?

@NitroBAY Nós basicamente

Desculpe por todas as perguntas noob, mas eu aterrissei em ReactLand desde cerca de 1 semana.

Você acha que seu pacote vai substituir este?
Sua abordagem parece ser multi-plataforma e muito boa. Material-ui adere apenas à web porque não tem tempo, mas tem tempo para o próximo, por quê?
Você diz que next usa uma abordagem isomórfica em next mas se eu pegar qualquer componente, ou seja, papel, ele funcionará apenas para a web, pois há um componente div .
Quem é we , você faz parte deste time?
Independentemente das considerações técnicas, você não acha que usar MD no IOS pode incomodar os usuários?

EDIT: off topic mas ninguém me respondeu, que vantagens traz jss-theme-reactor quando se trata de compará-lo com jss-react ?

@NitroBAY :

1. Eu não sou o desenvolvedor deste projeto ou de qualquer projeto React Native. Mas acompanho essa edição há meses e, no momento, estou ansioso para começar a contribuir com react-native-material-ui .
2. paper ou a coisa da sombra agora está funcionando na web, iOS, Android. Então não é grande coisa.
3. material-ui master branch usa objetos para definir as folhas de estilo, mas para melhorar o desempenho (aumento de 30%), os contribuidores mudam para JSS (CSS em JS) no branch next . No momento, JSS não é compatível com React Native.
4. O Google usa o Material Design no iOS e acho que os usuários não se importam muito. Claro, você deve modificar algumas peças para encaixar na plataforma como alterar a cor da barra de status, usando ícone de compartilhamento iOS, etc. Eu costumava material-ui para o meu Windows 10 & MacOS aplicativo e eu não vi muitos usuários reclamaram sobre isso (http://moderntranslator.com/). Alguns até disseram que o MD era mais fácil de usar.

Mas ainda não entendi de que maneira o branch next pode funcionar no RN se os componentes estiverem usando elementos HTML como span ou div . Posso ter perdido alguma coisa, mas para desenvolver no RN você precisa usar componentes do RN, não é?
Estou citando você:

ela se tornará a versão oficial para web e nativa. Eu acho que está tudo bem, considerando que o material-ui está usando uma abordagem semelhante com a próxima ramificação.

Mas talvez eu não tenha entendido direito. Você quer dizer que o branch next nos tornará capazes de usar componentes no RN?

@NitroBAY : next branch tornará material-ui menos compatível com React Native. Além disso, mesmo que o componente RN não suporte span ou div, usando regras condicionais, você pode algo assim:

if (platform === 'web') return <span/>;
else return <View />;

Você pode verificar: https://github.com/necolas/react-native-web

Oh ok, eu pensei que você queria dizer que eles fizeram RN compatível.

O TL;DR é que este projeto não tem interesse em suporte multiplataforma por meio da API React Native, e esse esforço deve ser movido para https://github.com/xotahal/react-native-material-ui?

Os documentos do carbon-ui são melhores e já funcionam na web. Qual é o benefício do react-native-material-ui?

Então todos concordam que material-ui vai ser parado para ser usado e recomendado daqui a pouco ? Então é uma pena que os donos deste pacote não queiram RN ?

carbon-ui parece que terá problemas de desempenho por não usar StyleSheet e por injetar tantas fontes da web

Calma gente! Ainda está vindo.

TL;DR: Se você construir um componente para React Native, ele funcionará em RN e web. Mas se você construir um componente para web, ele não funcionará no RN. E material-ui é feito para web, otimizado para web => Para que funcione no RN, o desempenho tem que ser sacrificado (pelo menos, no momento). Assim, acho melhor manter os dois projetos separados até que o RN esteja mais maduro.

otimizado para web => Para que funcione no RN, o desempenho tem que ser sacrificado (pelo menos, no momento)

Você tem algum dado para compartilhar sobre isso?

Aqui estão minhas descobertas para a RNW até agora:

• https://github.com/necolas/react-native-web/blob/89ad493ce5ef3b37998af397156903ade1ada34b/performance/README.md
• https://github.com/necolas/react-native-web/pull/343#issuecomment -279177085

@necolas #4066

Hmm, eu posso olhar para usar StyleSheet com Uranium. Eu direi, não notei nenhum problema de desempenho relacionado a CSS, mas vou ver se consigo me integrar melhor com o seu material do StyleSheet.

O maior sucesso de desempenho vem do Animated: https://github.com/animatedjs/animated/issues/48 Mas isso afeta todos os aplicativos RNW.

A injeção de fontes da Web diminui significativamente o desempenho? Ele as carrega diretamente das fontes do Google, então elas provavelmente já estão armazenadas em cache no sistema do usuário.

A coisa mais importante, eu acho, é que todos se unam atrás de uma única biblioteca. E eu não acho que o material-ui vai suportar o React Native.

@necolas O TL;DR é que o caminho a seguir não é claro .

A = reagir-nativo
B = a web

1. A plataforma mais restrita

Uma abordagem possível é segmentar a plataforma mais restrita, começando com react-native . Em seguida, para estender os recursos para a web. Para estender os recursos para a web, poderíamos estar usando:

• https://github.com/necolas/react-native-web
• https://github.com/taobaofed/react-web

No entanto, isso vem com uma compensação, ganharíamos o compartilhamento de código. Mas estou esperando perder em algumas dimensões.

Trazendo a API nativa para a web

A API precisa ser reimplementada para funcionar com o navegador. Qual é a sobrecarga?

Lidando com a API da Web ausente no nativo

À medida que partimos da plataforma mais restrita, precisaríamos reimplementar alguns recursos disponíveis na web. E as consultas de mídia? Herança CSS, animações CSS?
Quem implementaríamos eventos de acessibilidade e teclado sem sobrecarregar a versão nativa?

2. A plataforma menos restrita

Outra solução é começar a partir da plataforma menos restrita, portanto, a web. Em seguida, crie reimplementar recursos nativos ausentes.

No entanto, isso vem com uma compensação, ganharíamos o compartilhamento de código. Mas estou esperando perder em algumas dimensões.

Trazendo a API da Web para o nativo

Vamos ter que fazer sacrifícios, estou esperando que algum recurso da web seja muito difícil de implementar nativo, por exemplo, as consultas de mídia CSS, as animações CSS. (regras CSS avançadas)

Lidando com API nativa ausente na web

Alguns dos recursos ausentes da API da Web estão relacionados ao manuseio de toque, rolagem e exibição de lista infinita, componentes nativos como um DatePicker ou um Drawer.

3. Compartilhamento de contrato

Uma terceira solução pode ser configurar uma infraestrutura para compartilhar API e testes e reimplementar os componentes nas duas plataformas subjacentes. Da minha percepção, é como o react-native está se aproximando do iOS e do Android.
Em seguida, usando uma abordagem mista das duas anteriores para preencher totalmente o contrato. Quero dizer, usando ramificação de código quando isso faz sentido e compartilhamento de código o máximo que pudermos.
Por exemplo:

• Por que usar animado.js no navegador quando podemos usar transições CSS?
• Por que implementar a lógica do Drawer no react-native quando podemos usar o componente nativo?

Acho que a opção 3 é a mais promissora. É como tentei resolver o problema em react-swipeable-views .

https://github.com/tuckerconnelly/uranium suporta consultas de mídia multiplataforma :)

A beleza do RN é que você tem uma biblioteca simples de APIs abstratas e primitivas, e as implementações de baixo nível são atendidas. Animado é o mesmo - biblioteca simples para animações, implementações de baixo nível (animações nativas no iOS/Android, transições css na web) são cuidadas.

Eu acho que o arquivo animated.js pode ser alterado para usar transições css. Com certeza melhoraria o desempenho.

@quanglam2807 esse tópico é muito longo, o que devo analisar?

Para estender os recursos para a web, poderíamos usar: https://github.com/necolas/react-native-web , https://github.com/taobaofed/react-web

react-web está muito longe de ser IMO funcional ou funcionalmente correto.

A API precisa ser reimplementada para funcionar com o navegador. Qual é a sobrecarga?

Sobrecarga em que dimensões? Difícil de determinar em termos de tamanho do pacote. Você provavelmente seria capaz de descartar parte do seu código existente; mas se você dependesse de qualquer coisa além das exportações principais da RNW, isso aumentaria rapidamente. Em componentes de estilo pesado para mobile.twitter.com, tenho visto uma redução de 20-40% no tamanho do componente convertendo estilos de módulos css para RNW StyleSheet. Em termos de desempenho de tempo de execução, atualmente não está

E as consultas de mídia?

Você pode usar matchMedia para alterar estilos e estrutura de componentes, embora os benefícios de usar consultas de mídia para alterar componentes não sejam claros para mim.

Herança CSS, animações CSS?

O RNW suporta animações CSS (embora eu precise adicionar uma API para definir quadros-chave). Qual é a pergunta relacionada à herança CSS?

Como implementaríamos eventos de acessibilidade e teclado sem sobrecarregar a versão nativa?

Não tenho certeza do que isso significa. Suspeito que o limite para "inchaço" em um aplicativo nativo seja muito maior do que em um aplicativo da web.

então talvez comparar como react-native-web lida com estilos para renderizar performances css com performances css-modules seja menos pertinente agora

Por que seria isso?

Seria ótimo ter um tipo de web react-native que usa algo como afrodite ou jss

Ambas as bibliotecas são mais lentas, maiores e não são adequadas para fornecer estilos determinísticos

@necolas material-ui está fornecendo um grande esforço para mudar de um método css-in-js para um método de folha de estilo (css em <style> ). Eles têm feito esforços ativos há meses para trocar os componentes. Os motivos estão aqui . Pelo que li, usar jss é uma grande vantagem e parece ser a solução mais perfeita para lidar com estilo até agora.

Aliás lendo o Roadmap.md novamente o suporte RN está no Roadmap.

Estou muito interessado em usar o Material-UI com react-native, alguma palavra sobre o progresso?

@wswoodruff Você pode conferir este por enquanto - https://github.com/xotahal/react-native-material-ui

Atualmente, temos três bibliotecas incríveis para isso:

• react-native-material-kit ★3110 - Trazendo o Material Design para React Native .

• react-native-material-design ★2447 - React Native Material Design Components

• react-native-material-ui ★1040 - Componentes de design de material altamente personalizáveis ​​para React Native.

Aproveitar!

Há também a menos conhecida Carbon UI se você for universal. Mas para o meu tempo eu provavelmente ficaria com um desses .

isso foi tocado algumas vezes neste tópico, mas quero chamá-lo novamente por causa de como isso afeta meu interesse nessa mudança: o principal benefício do suporte react-native que vejo não é realmente sobre react-native , mas sim sobre ser construído nas primitivas que permitem que os mesmos componentes sejam usados ​​em _both_ native e web.

se esse tipo de primitivo fosse usado, outras ferramentas como react-sketchup e -pdf também poderiam ser habilitadas.

pessoalmente, esses são mais interessantes para mim do que os nativos, mas seriam ativados pelas mesmas alterações.

@jhabdas Como está sua experiência usando o Carbon UI? Bcz para mim parece muito bom, mas ainda não usei.

@deadcoder0904 ainda não o usei pessoalmente. provavelmente tente entrar em contato com um dos caras no vermelho infinito. eles administram o boletim informativo do RN e devem ser os especialistas no assunto. se e quando eu construir outro aplicativo RN (ok, quando...) eu não estarei juntando as coisas desta vez ou construindo outro clichê — IMHO o espaço é resolvido por clichês e componentes existentes .

Aqui estão alguns dos obstáculos que eu posso pensar que precisariam ser superados para tornar o MUI disponível no React Native. Assumindo v1 MUI e mantemos JSS, o padrão classes e outras coisas que são neste momento partes fundamentais do design da API do MUI.

• O JSS precisa dar suporte ao RN, ou seja, criar objetos de estilo de forma que withStyles funcione. Mais sobre isso em https://github.com/cssinjs/jss/issues/368#issuecomment -376708219.
• Supondo que não haja hacky wrapper ou transformação babel, precisaremos aumentar o padrão classes para que funcione da mesma forma, mas leva em conta o fato de que no RN ele deve passar um array para style , e provavelmente deve ser nomeado styles . Talvez isso possa ser resolvido descartando classnames e adicionando auxiliares espalháveis ​​que nos bastidores alternam entre manipulação de classes/className e estilos/estilos.
  Pode ser:
  js const styleProps = props.composeStyles( 'root', (raised || fab) && 'raised', fab && 'fab', fab && mini && 'mini', color === 'inherit' && 'colorInherit', flat && color === 'primary' && 'flatPrimary', flat && color === 'secondary' && 'flatSecondary', !flat && color === 'primary' && 'raisedPrimary', !flat && color === 'secondary' && 'raisedSecondary', size !== 'medium' && `size${capitalize(size)}`, disabled && 'disabled', fullWidth && 'fullWidth', ); return <ButtonBase {...styleProps} ... />
  composeStyles aceitaria uma lista de nomes de estilo (e ignoraria valores falsos). Na web, olharia em props.classes e produziria {classNames} . No nativo, ele procuraria em props.styles e geraria um {style} .
  Originalmente eu pensei em this.composeStyles com um decorador, mas ao invés disso withStyles poderia simplesmente passar um auxiliar de composição de estilo como parte dos adereços.
• Como outros mencionaram depois de tudo isso para fazer os componentes básicos de estilo funcionarem, precisaremos de trabalho extra para fazer animações, toques, etc... funcionarem.
• No entanto, para animações, não considero isso uma coisa ruim. É uma pequena perda para transições simples, onde você está apenas fazendo a transição automática opacity , backgroundColor , etc., podemos querer ajudantes que mantenham isso simples. Mas pelo que eu vi, as implementações reais de transição de material além daquelas parecem excessivamente complicadas/enigmáticas e não escalam bem. react-transition-group tem alguns bons ideais para lidar com a parte de baixo nível das coisas (manuseio de entrada/saída, etc), mas é problemático / no caminho em outros. Além disso, em vez do design baseado em transições css, acho que o caminho a seguir seria usar a nova API de animações da Web e exigir o polyfill para isso.
  Em outras palavras, acho que há espaço para a criação de uma nova biblioteca para lidar com animações no React que usa Web Animations no navegador e a API Animated no React Native e é uma melhoria geral em como o MUI lida com a animação.
• O MUI precisa abandonar a expectativa de que o comportamento em cascata esteja disponível. E a configuração do tema precisa ser aprimorada para oferecer suporte à aplicação fácil de modificações ao tema em uma subárvore.
  No momento, coisas como AppBar + Icons funcionam definindo a cor do texto, usando um color='inherit' explícito e assumindo que a cor cairá em cascata. E é possível que seja o mesmo em outras partes do MUI.
  Não há cascata como esta no React Native. Em vez disso, você deve declarar seus estilos explicitamente para cada View. Para estes tipos de coisas o AppBar e outros componentes precisarão ser capazes de fornecer facilmente uma versão modificada do tema eles são fornecidos com uma modificação como mudar o tema dentro desse contexto para dark para que os ícones obtenham o ícone de contraste correto cores (e pode ser baseado na especificação de cores do ícone real em vez da cor do texto). Observe que isso pode ter implicações em coisas como menus aninhados em barras de aplicativos.
• Como uma extensão deste problema em cascata. O MUI também é projetado em torno de coisas como <Button>Text</Button> , onde é assumido que o MUI pode apenas estilizar o fontFace/color, etc. uma mistura de elementos e nós de texto e os nós de texto obtêm o estilo certo.
  Isso desmorona no React Native. Todo o texto deve fazer parte de um <Text> , todos os estilos de texto devem estar nos estilos desse componente e um elemento de texto não pode conter filhos que não sejam de texto (ou seja,).
  Existem algumas opções:
  
  
  
  • O padrão <Button text='Text' /> funciona muito melhor no React Native. Infelizmente, isso é fundamentalmente diferente do ethos da MUI, então não é uma opção.
  
  
  • Poderíamos mapear os filhos e substituir strings por elementos Text com estilo. No entanto, isso é frágil, no momento em que você envolve a corda em qualquer coisa, ela se desfaz (mesmo o react-intl a faria desmoronar). ECA.
  
  
  • Não é a maneira mais bonita de fazer isso, teríamos que esperar, e eu não entendo 100% das implicações de desempenho. Mas poderíamos usar a nova API de contexto do React 16.3 e expor um <MuiText>Text</MuiText> . Basicamente, componentes MUI como Button teriam provedores que forneceriam informações sobre os estilos do contexto atual (fonte, cor do texto, etc...) e o MuiText apenas consumiria esses dados e os aplicaria a um elemento Text.
  
  

Hoje a v1 foi lançada então quais são os planos do React Native❓

Para o React Native Material Support, existe uma bela biblioteca chamada React Native Paper, que será mantida e suportada pela equipe CallStack.

Mas existem planos para portar isso para o React Native porque acho que o Paper funciona perfeitamente ❓

Se não, então você provavelmente pode fechar este problema :)

Obrigado por compartilhar @deadcoder0904. Eu adicionei Paper a Awesome React Components . Não ouvi falar de CallStack. No começo eu li como Call-Em-All. Adivinhando que eles não são os mesmos peeps, ya?

@jhabdas Não, eles não são iguais

@dantman Aqui estão meus pensamentos sobre a melhor maneira de obter suporte nativo

• se aderir ao jss não é um requisito absoluto, acho que fela é uma alternativa viável:
  
  
  
  • fela-native suporta consultas de mídia e usa StyleSheet.create corretamente
  
  
  • É insanamente extensível . Poderíamos reescrever regras para propriedades da web para seus proxies react-native, remover coisas como :hover regras nativas e provavelmente recuperar qualquer sintaxe perdida do jss.
  
  
• react-native-animatable tem suporte a quadros-chave e provavelmente também pode ser usado em vez de transition-group, que pode ou não funcionar com native .
• Eu concordo em subverter a visão sem cascata do react-native. Pode ser opt-in no provedor e no consumidor com adereços cascade e inherit .
  Todas as bibliotecas react-native com as quais tentei trabalhar foram dolorosas ou inutilizáveis ​​devido a APIs excessivamente rígidas e estilos não substituíveis, com exceção daqueles que usam @shoutem/theme para permitir substituições (como nativo-base) .

Ainda aguardando esse suporte. Usando lindamente na Web, mas desenvolvo em mobile também!

alguma atualização sobre suporte reagir nativo?

@oliviertassinari Pretendo fazer um fork e começar a explorar o caminho de implementação que descrevi acima. Minha prioridade será fazer com que os componentes que preciso para outro projeto funcionem, então provavelmente não terei suporte robusto ao React Native em breve, mas tentarei mantê-lo "sincronizado" com o mestre o máximo que puder na esperança de que um dia seja útil (ou possivelmente mesclado)

@micimize Obrigado por me avisar. Desejo-lhe boa sorte neste projeto! :) Sobre por que ainda não trabalhamos no react-native. Acho que vem em vários sabores. Mais importante ainda, não temos nenhum mantenedor do núcleo interessado em fazer isso. Eu posso entender isso, o uso do react-dom cresce mais rápido que o react-native e é difícil.

Atualização sobre isso: Migramos uma parte substancial da funcionalidade para um estado um pouco utilizável, incluindo listas, botões, cartões, ícones, controles de seleção, campos de texto e pano de fundo. Infelizmente, quando finalmente estávamos desenvolvendo nosso próprio aplicativo no react-native, uma infinidade de problemas surgiram e nos obrigaram a mudar para o Flutter.

Em algum momento eu gostaria de voltar e salvar alguns dos trabalhos que fizemos, principalmente a porta da solução de estilo withStyles / classes que alavancou CSS-shorthand-properties e algumas outras coisas legais, mas não é mais uma prioridade para mim.

@rogerstorm financiou esta edição com US$ 200. Veja no IssueHunt

Trabalhar no problema seria um custo de oportunidade para nós. Estou fechando. Vamos duplicar o melhor suporte aos casos de uso do navegador.

@oliviertassinari , isso significa que o suporte nativo de reação está fora do escopo e em um futuro próximo (por exemplo, 1 ano) não estará no radar?

sim

https://github.com/lightningtgc/react-native-material-ui Não é nada além de outro pacote npm fraudulento