Material-ui: Support React Native

Je viens de découvrir ce repo : https://github.com/lightningtgc/react-native-material-ui
Je ne sais pas si c'est bon, cependant.

Merci @chadobado - Nous en avons parlé à coup sûr et ce serait un projet amusant à commencer. Cependant, nous avons les mains pleines avec ce projet pour le moment. Je garderai ce problème ouvert et je le mettrai à jour si jamais nous créons une bibliothèque native.

C'est en fait une excellente idée. J'ai essayé de tester le portage de material-ui vers React-Native. Nous n'avons besoin que d'un peu de feuilles de style, changez tous les div en View , changez tous les h1 , h2 , etc en Text et ça marchera très bien. Le seul problème que j'ai trouvé est que React Native ne prend pas entièrement en charge boxShadow , il est donc difficile d'implémenter le composant Paper pour le moment. De plus, ce serait formidable si nous pouvions créer un script pour porter automatiquement le code sur React-Native car ce n'est pas très différent.

changez tous les div en View, changez tous les h1, h2, etc. en Text et cela fonctionnera très bien

Ne pourrions-nous pas utiliser un babel-plugin-transformer pour le faire ?

C'est effectivement une excellente idée

Vous avez un projet de démo ?

@oliviertassinari

Ne pourrions-nous pas utiliser un babel-plugin-transformer pour le faire ?

Je ne suis pas sûr car la feuille de style de React Native est assez différente de CSS donc ça va être assez compliqué de faire le transformer.

Vous avez un projet de démo ?

Pas encore car je suis assez occupé mais je vais essayer de vous montrer une petite démo bientôt.
Mais voici ce que nous devons faire

Feuilles de style

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,
      }
}

à

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,
      }
})

Solution zIndex

JSX

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

à

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

Nous devons également modifier styles/transition.jsx (React Native utilise object au lieu de string ), mixins/style-propable.jsx car nous n'avons pas besoin de gérer plusieurs navigateurs, etc.

Je viens de publier un fork WIP pour réagir-native dans https://github.com/lenaten/material-ui-native.
Actuellement, seuls Card et RaiseButton fonctionnent, mais sans style (WIP, vous vous souvenez ?)

@lenaten Intéressant !
Je voulais aussi commencer à travailler sur un wrapper entre ce projet et mrn (https://github.com/oliviertassinari/react-material).
Il semble que votre fork ne fonctionne qu'avec react-native, comment le feriez-vous également fonctionner avec le navigateur ?
Je pense que c'est le point le plus difficile et qu'il faut l'aborder maintenant, puisque vous dites que vous avez deux volets de travail. Je peux t'aider si tu veux.
Comme dit précédemment, je voulais également enquêter sur https://github.com/binggg/mrn pour notre implémentation native.

Quand on y répond, je pense que nous pourrions fusionner votre fourchette ici.

Material-UI est un projet mature contre un projet mrn qui manque de nombreux composants matériels. Si mon POC fonctionne comme excepté, le fusionner dans une structure de fichiers multiplateforme devrait être facile. Je n'ai pas le temps de réinventer la roue et de repartir de zéro.

Quoi qu'il en soit, votre aide dans les pensées et le code est la bienvenue.

@oliviertassinari Moi aussi.

Mon idée pour que material-ui fonctionne à la fois avec le navigateur et en natif est d'utiliser une structure de nom de fichier, similaire à la façon dont react-active gère iOS et Android en même temps.

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

ou nous pouvons toujours utiliser les mêmes composants pour le navigateur et le natif, puis écrire un wrapper pour les gérer. Par exemple, react-native utilise View , le navigateur utilise div puis procédez comme ceci :

div.navigateur.jsx

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

div.native.jsx

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

app-bar.jsx

import {div} from "div"

Nous pouvons en fait créer un projet séparé pour ce wrapper.

@quanglam2807 Je suis heureux de l'entendre.

Concernant l'organisation du code, j'aime l'idée d'avoir des extensions de fichiers séparées.
Je prendrais l'exemple de https://github.com/benoitvallon/react-native-nw-react-calculator/tree/master/src/common/components comme moyen de le faire.

Concernant l'organisation du projet, j'ai peut-être changé d'avis.
Je pense qu'il vaut mieux suivre l'approche de Google et travailler sur un grand référentiel unique. Par conséquent, travailler sur une synchronisation de fourche avec material-ui ou ici pourrait être un bon moyen de le faire.

Pour commencer avec nos fichiers .native , nous pourrions compter sur

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

Composants.

@oliviertassinari J'aime aussi l'idée du modèle "extension de fichier". Le plus important pour moi maintenant, c'est de travailler sur des composants natifs. Si vous souhaitez aider à l'abstraction de code, vous êtes le bienvenu. Je m'engage à supprimer le suffixe "natif" du nom du dépôt :)

@lenaten est

@mvayngrib J'ai arrêté de travailler sur ce projet pendant un certain temps..

@lenaten c'est dommage, merci d'avoir répondu

D'accord, j'ai commencé à travailler dans ce https://github.com/callemall/material-ui/pull/2611.
Cela va prendre du temps !

@oliviertassinari génial ! très très excité

L'effort portuaire est-il donc toujours ouvert ? Si oui, quel a été le processus défini pour la mise en œuvre des composants ?

@dorthwein C'est toujours ouvert.

De mon point de vue, le processus est le suivant :

• [ ] Mettez à niveau vers la dernière version de react-native et supprimez react-native-webpack-server . Je l'ai déjà fait sur ce projet . https://github.com/callemall/material-ui/pull/3829
• [ ] Jouez avec react-look et voyez à quel point nous pouvons l'utiliser pour le muiTheme qui vient du contexte. https://github.com/callemall/material-ui/pull/3829
• [x] Attendez la réorganisation des dossiers pour que nous ayons un endroit pour mettre les nouveaux composants
• [ ] Commencez à travailler sur l'application de documentation que nous utiliserons pour présenter le nouveau composant.
• [ ] Commencez à travailler sur la version native des composants.

@oliviertassinari - Je peux consacrer un peu de temps au portage de certains des composants une fois que la voie à suivre est définie. En regardant votre liste, la seule inconnue pour le moment, c'est le look réagir, n'est-ce pas ?

@dorthwein nous sommes heureux de l'entendre.
J'utilise react-look ici #3829. Le seul problème que j'ai est mineur. React Native affiche un avertissement concernant une mauvaise utilisation de l'API StyleSheet . Je ne l'ai pas regardé en détail mais je pense que cela peut être résolu.

@oliviertassinari @dorthwein Je suis content que cet effort (c'est-à-dire porter material-ui à react-native ) ne soit pas mort. Je voulais juste souligner qu'il y a aussi un autre nouveau projet material-ui à react-native qui n'a pas été mentionné dans ce fil : https://github.com/react-native-material- design/react-native-material-design . Ce projet semble être basé sur https://github.com/binggg/mrn.

@oliviertassinari J'ai vu dans un autre fil si le support d'iOS avait du sens pour ce port - je pense que c'est absolument le cas, surtout quand vous regardez comment Google Maps et d'autres applications Google Material + iOS existent. Lorsque cela a du sens et qu'il existe un composant iOS préexistant fort (par exemple des commutateurs), il doit être utilisé pour le commutateur iOS sur iOS. La mise en œuvre d'Android et d'iOS n'est pas non plus un fardeau.

@oliviertassinari La structure de fichier component.native.js, component.android.js, component.ios.js me semble également la plus logique.

@oliviertassinari J'ai essayé de faire fonctionner la documentation sans succès. Quelques problèmes :

• package.json : react-native n'aime pas le nom du package material-ui - le changement en materialUI a résolu le problème
• La branche material-ui/react-native actuelle rencontre un problème avec le packager react-native et ne crée pas le fichier mainjs.bundle. Je n'ai pas réussi à comprendre ce qui se passait ici.
• Je n'arrive pas à obtenir une application réactive native qui fonctionne au-dessus du référentiel material-ui existant. Si quelqu'un a eu de la chance sur ce front, voyons comment contribuer/développer un ensemble de composants natifs.

@dorthwein Merci pour les commentaires. La branche réactive native est hautement expérimentale. Nous devons résoudre cela.
En revanche, je n'ai aucun problème de mon côté (https://github.com/callemall/material-ui/pull/3829).
Je devrais essayer de partir d'un nouveau git clone .

Oui, donc la prochaine étape de mon projet actuel consiste à travailler sur une application mobile utilisant la conception de matériaux - j'aimerais l'utiliser car tous nos contenus Web y sont également. Si nous pouvons créer un environnement de travail, je commencerai à l'assommer avec notre projet.

Je lisais des trucs et j'ai remarqué cette information de la page FB React Native.

« Composant le plus fondamental pour la création d'une interface utilisateur, View est un conteneur qui prend en charge la mise en page avec flexbox, le style, une gestion tactile et des contrôles d'accessibilité, et est conçu pour être imbriqué dans d'autres vues et pour avoir de 0 à de nombreux enfants de tout type. View mappe directement à l'équivalent de la vue native sur la plate-forme sur laquelle React s'exécute, qu'il s'agisse d'une UIView,

J'ai également trouvé cette ressource - l'essayer maintenant. Cela semble assez simple et vaut peut-être le coup d'œil

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

@dorthwein Excellente idée ! Mais si nous suivons cette voie, je pense que développer une version pour React Native uniquement serait mieux.

Nous pouvons réécrire l'ensemble du projet sous React Native APIs au lieu de codes séparés pour Native et DOM. Incroyable! Je n'y ai jamais pensé.

@quanglam2807 ouais - de cette façon, les nouvelles fonctionnalités, etc... Restez en ligne les unes avec les autres. Le plus gros défi, je pense, est alors de faire fonctionner les styles et les animations. Un autre grand avantage est que nous pouvons progressivement ajouter la prise en charge de différents composants.

L'inconvénient est que tout devra utiliser des boîtes flexibles.

Étant donné qu'il s'agit d'une refactorisation majeure de la base de code, qui doit tous signer cela pour aller de l'avant ? J'ai encore besoin de jouer et de voir à quel point les trucs Web natifs sont également robustes.

@quanglam2807 @oliviertassinari un autre avantage de cette approche est que material-ui sera également facilement transféré vers https://github.com/ptmt/react-native-desktop .

@oliviertassinari utilise react-native-web quelque chose que les responsables de ce projet peuvent soutenir si cela fonctionne comme prévu ?

@dorthwein J'adore l'idée derrière ce projet. Mais je ne pense pas que cela aiderait dans un avenir proche.
Ne devons-nous pas d'abord écrire une version native de nos composants avant de pouvoir utiliser react-native-web ?

@oliviertassinari non, ce que fait react-native-web c'est d'utiliser le composant le plus "natif" selon la plateforme. Ainsi, par exemple, étant donné une balise View, il utiliserait un div dans le navigateur, un UIView dans iOS et quel que soit l'équivalent de UIView est Android.

Au lieu d'écrire des versions natives de chaque composant, le processus consisterait alors à convertir les versions existantes pour utiliser View au lieu de div et style Text au lieu d'utiliser des éléments tels que h1 et label.

Ce n'est certainement pas une petite entreprise, mais le processus consisterait alors à mettre à jour les composants existants au lieu d'essayer de créer et de maintenir plusieurs versions.

Au lieu d'écrire des versions natives de chaque composant, le processus consisterait alors à convertir les versions existantes pour utiliser View au lieu de div et style Text au lieu d'utiliser des éléments tels que h1 et label.

Cela ressemble exactement à l'écriture d'une version native qui, espérons-le, fonctionnera également dans le navigateur. Pour autant que je sache, react-native-web apporte une réaction native sur le Web et non l'inverse.
Pourtant, cela peut être très pratique de partager le même code :+1:.
J'ai vu un petit problème avec cette bibliothèque jusqu'à présent. Leur implémentation StyleSheet.create ne prend pas en charge les valeurs dynamiques (nécessaires pour le muiTheme). Nous pourrions utiliser React Look pour ce cas d'utilisation.

@oliviertassinari ta droite - je le comprenais à l'envers. Il semble que l'étape 1 soit toujours en train de créer des versions réactives natives des composants. L'étape 2 serait potentiellement de les fusionner en une seule base de code en utilisant quelque chose comme le web natif de réaction.

@wordyallen :

@pgangwani Je viens de commencer à jouer avec... Ce n'est pas encore prêt.

J'ai utilisé https://github.com/react-native-material-design/react-native-material-design pour combler le vide, mais c'est aussi très rugueux sur les bords et aucun développement actif

Je donnerais financièrement à cette entreprise, si je le pouvais.

Salut les gars,

Je travaille sur react-native-material-ui , qui s'inspire de cette bibliothèque. N'hésitez pas à essayer - j'aimerais entendre vos commentaires ;)

@xotahal et. al, Au lieu de créer à partir de zéro, ce que nous devrions faire, à mon humble avis, est de forger cette bibliothèque et de porter les composants existants plutôt que de les recréer. Le besoin d'entrées de style matériel est cruellement nécessaire dans l'espace RN, si vous me demandez. Merci à tous pour vos efforts OSS.

Je ne pense pas qu'il y ait beaucoup de code commun, je pense que créer à partir de zéro a du sens. Le style en RN sera 90% différent de celui-ci. Et il y a pas mal de mécanismes spécifiques à la plate-forme comme les animations...

Il semble qu'adopter la structure des composants, les accessoires (et les documents) et avoir un amont clair, même si beaucoup de choses changent, serait bénéfique à long terme pour ceux qui passent du Web au natif et est de la plus haute importance. Le reste devient un détail de mise en œuvre.

Je suis d'accord avec @jhabdas ; plus les API peuvent se ressembler pour chaque composant, moins il sera difficile pour les développeurs de sortir des projets Web et des projets natifs. Moins l'expérience est choquante, plus elles peuvent être productives. Je m'attendrais à ce que les détails spécifiques à la plate-forme soient résumés dans les coulisses du composant.

@chadobado ou mainteneur, voudriez-vous renommer ce problème en « Support React Native » pour augmenter la visibilité lors de la recherche de ce référentiel ? La recherche actuelle de "React Native" enterre cela dans la liste car le terme est coupé dans le titre.

FWIW, cela a attiré mon attention.

@necolas sur le support Web pour react-native-material-kit :

Il est peu probable que vous ayez besoin de porter beaucoup de feuilles de style, voire aucune, car la compatibilité est fournie par l'implémentation Web de React Native.

@jhabdas si vous jouez un peu avec React Native, vous verrez que ce n'est pas si simple. L'API StyleSheet est géniale mais vous devez réécrire pas mal de choses ;)

Point juste @antoinerousseau. Je repense à une citation de James Long sur RN :

Considérez-le comme un prototype pour une direction différente pour le Web

Si je comprends que le but de la bibliothèque @necolas fonctionne, il semble qu'une approche saine serait d'inverser le problème : plutôt que de porter le CSS sur RN, il suffit de reconstruire le tout dans RN et de revenir au port Web à l'aide d'une cale. React Native Material Kit a déjà une bonne longueur d'avance sur le problème.

Puisque react-native-web semble génial, je vais juste créer des fichiers material-ui.android.js , material-ios.ios.js et material-ui.web.js dans mon propre projet personnel et l'appeler bon. Si je suis l'API material-ui en enveloppant tout le reste, cela finira par fonctionner. Si material-ui me surprend et fonctionne, je n'aurai qu'à supprimer le .web du .web.js et supprimer les autres fichiers. De cette façon, je peux passer sélectivement à material-ui par composant.

@oliviertassinari J'ai donc ajouté la branche react-native tant que dépendance NPM et installé tous les plugins Babel. J'ai eu ce message lors de l'importation d'un composant :

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

Mon objectif est d'utiliser material-ui le plus tôt possible par composant. Certes, j'ai fait un git rebase master et j'aurais dû faire un git rebase next si quoi que ce soit. Toutes les composantes react-native individuelles sont-elles bloquées par la préparation du travail de la filiale next ce moment ?

Et j'ai écrit du code qui me permet de consommer react-native-vector-icons exactement de la même manière que je consomme des icônes 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>)
  }
})

Bien que pour le moment react-native-vector-icons et material-ui aient une syntaxe d'importation incompatible. @oblador J'ai dû importer glyphMap et l'itérer et exporter la liste entière en un seul gros objet.

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

Ce serait bien si les icônes de matériaux react-native-vector-icons étaient regroupées par catégorie comme material-ui permettant des exportations individuelles à partir d'une catégorie :

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

Devrions-nous travailler sur une pull request pour rendre react-native-vector-icons compatible avec les conventions d'import material-ui ?

@mattferrin La react-native est assez ancienne maintenant. Il n'est pas destiné à être consommé par les utilisateurs. C'était une preuve de concept concernant la voie à suivre.
Pour autant que j'aie examiné ce problème, l'une des approches prometteuses serait de le réécrire pour cibler react-native . Ensuite, react-native-web ferait le plus dur pour nous.
Cependant, il y a quelques défis :

• Combien de _react-native-web_ est prêt pour la production ? Par exemple, je n'ai pas vu de tests visuels.
• Comment gérez-vous les requêtes des médias ?
• Comment gérez-vous une solution de thème complexe ?

réagir avec les styles vaut également la peine d'être examiné.

Quelle est la quantité de react-native-web prête pour la production ?

@oliviertassinari Je porte actuellement un site Web vers react-native-web , et je pense que cela vaut la peine d'être adopté. Il manque un composant href de balise d'ancrage multiplateforme et peut manquer d'autres subtilités, mais le ReactDOM sous-jacent est prêt pour la production et c'est ce dont nous avons besoin.

Comment gérez-vous les requêtes des médias ?

Les material-ui devraient-ils s'en soucier ? Il existe des moyens de trouver les dimensions d'un composant ou d'un écran sur toutes les plateformes. Tant que les composants material-ui peuvent être passés à des accessoires qui contrôlent le style, ce qu'ils font, nous sommes en or, je pense.

material-ui effectue-t-il des requêtes multimédias ? Avons-nous besoin?

Comment gérez-vous une solution de thème complexe ?

Ne pouvons-nous pas simplement vérifier Platform pour omettre ou renommer les accessoires non pris en charge de React Native, car (si ma mémoire est bonne) le remplissage et la marge sont essentiellement inversés dans React Native. Tout ce que nous aurions à faire est d'envelopper la méthode équivalente createStyleSheet pour transformer/filtrer le résultat dans des styles compatibles non spécifiques à la plate-forme "web".

Je ne l'ai pas encore utilisé, mais Fela vise à être multiplateforme, et je pense que c'est important. Depuis que l'auteur de Fela a écrit React Look et que cela semble avoir été un choix préalable, cela semble être un choix naturel.

Je ne l'ai pas non plus utilisé, mais quelque chose comme react-tunnel semble bien pour le contexte de thème. Nous pourrions simplement l'utiliser et l'exposer, encore une fois uniquement parce qu'il semble plus partageable avec la communauté. Il existe peut-être un équivalent plus populaire.

Quelle est la quantité de react-native-web prête pour la production ? Par exemple, je n'ai pas vu de tests visuels.

Il y a des exemples interactifs ici : https://necolas.github.io/react-native-web/storybook/

Comment gérez-vous les requêtes des médias ?

En JavaScript, utilisez matchMedia (ou utilisez Dimension ) pour déterminer les styles et les composants à afficher.

Il manque un composant href de balise d'ancrage multiplateforme

Oui, je ne sais pas ce que devrait être une solution "correcte", mais vous pouvez utiliser des liens similaires à View et Text pour le moment (support Web uniquement, bien sûr) :

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

Comment gérez-vous une solution de thème complexe ?

React Native ne se soucie pas de la façon dont vous procédez. Vous pouvez toujours utiliser context pour déterminer les objets de style à appliquer. J'aime bien l'API de Fela dans les composants, mais l'implémentation et l'API du plugin semblent exagérées si vous utilisiez react-native-web .

Tout ce que nous aurions à faire est d'encapsuler la méthode équivalente createStyleSheet pour transformer/filtrer le résultat dans des styles compatibles non spécifiques à la plate-forme « Web ».

Le problème est-il que vous exposez une API de style qui n'est pas compatible RN ? Si tel est le cas, je vous suggère d'exposer une API de style compatible RN et de laisser react-native-web convertir en styles DOM.

@necolas

Le problème est-il que vous exposez une API de style qui n'est pas compatible RN ? Si tel est le cas, je vous suggère d'exposer une API de style compatible RN et de laisser react-native-web la convertir en styles DOM.

Bon point. Est-ce que react-native-web a un sens de :hover par exemple ?

@necolas Et le travail particulier que je fais ne doit prendre en charge que les navigateurs à feuilles persistantes, mais y a-t-il une possibilité que le portage vers react-native-web coûterait material-ui compatibilité du navigateur avec les anciennes versions ? Je ne sais rien à ce sujet vraiment. Je pense vraiment que react-native-web est la bonne approche.

Il ne fournit rien de spécial pour les styles de survol (le RN non plus). Je me demande si les implémentations de bureau pour Windows et Ubuntu regroupent quelque chose pour les interfaces de souris ou vous le laissent via des événements.

Je ne sais pas de quel support de navigateur vous avez besoin, mais je pourrais peut-être vous adapter en cas de problème

Je pense qu'il pourrait être nécessaire d'injecter un booléen dans le contexte de la hiérarchie des composants via MuiThemeProvider pour choisir entre une react-native-web par rapport à une API de style de composant react-dom .

La meilleure réponse est de simplement passer à l'API de style react-native-web , et c'est ce que je préconiserais, mais cela causerait probablement un bouleversement.

@oliviertassinari Pourrions-nous passer de material-ui à une API de style react-native ? Peut-être laisser passer des styles spécifiques à la souris ?

@necolas @oliviertassinari Juste pour info . C'est bâclé en ce moment, mais je travaille sur le portage d'une branche (https://github.com/mattferrin/material-ui-build/tree/mine) pour qu'elle soit multiplateforme depuis 2-3 jours parce que je j'en ai vraiment besoin moi-même (pour réduire mon travail total à long terme).

J'ai tout porté sur la syntaxe react-native-web et commenté les styles qui ne sont pas portés, mais je pense que je vais finir par les commenter et utiliser Platform.OS == 'web' pour conserver le code d'origine essentiellement inchangé une fois que j'ai fini de porter le site Web sur lequel je travaille. À ce stade, seules les choses dont j'ai personnellement besoin seront portées et imparfaitement.

C'est un gâchis total (jusqu'à ce que je le retouche plus tard) parce que je pousse pour basculer entre les machines Mac et Windows à la volée.

Pour ceux qui ont hâte que MUI vienne chez RN, il existe des alternatives, et certaines sont plutôt jolies. Je maintiens une liste à feuilles persistantes ici : https://habd.as/awesome-react-components/#react -native

Je savais que toute la solution de style changeait, mais j'ai raté la partie où la bibliothèque est en train d'être réécrite à partir de zéro. C'est ma faute. J'avais supposé, en regardant du code, que les styles finaux resteraient essentiellement les mêmes et que seule la technologie changerait. J'avais tort. Je n'ai pas complètement ignoré la feuille de route, j'ai juste fait des hypothèses qui sont très fausses. Je suppose que je vais devoir renflouer ma tentative ici.

@mattferrin Pas tout à fait à partir de zéro (bien que dans certains cas, cela soit vrai, par exemple Table ) bien que le changement de solution de style nécessite de nombreux changements d'API, mais nous donne en outre la possibilité de rationaliser l'API dans d'autres domaines pour de nombreux composants . Je suis désolé si vos efforts ont été vains - j'espère que cela ne vous rebutera pas Material-UI !

@mbrookes Ce n'est pas le cas. J'ai fait l'erreur de bifurquer master au lieu de next et de sous-estimer la différence (et le travail total en général). C'était de ma faute et je savais qu'il y avait un risque. Je retournerai simplement les éléments vides Text comme espaces réservés jusqu'à plus tard dans ma façade React Native material-ui . Lorsque j'aurai entièrement porté mon site Web sur react-native-web je reviendrai et tenterai de rebaser les nouvelles modifications sur next .

Libérer ce gars aujourd'hui : https://carbon-ui.com

Inspiré de material-ui, fonctionne sur le web et sur react-native :)

@tuckerconnelly tu

@tuckerconnelly wow, beaucoup de potentiel sur ce projet... bravo ! Espérons que la communauté au sens large se ralliera à cet effort ! ??

@tuckerconnelly, je suis un peu confus. J'ai trouvé qu'il est en fait assez facile de faire material-ui conditionnellement multiplateforme (malgré mon erreur de bifurquer master au lieu de next et de perdre mon temps). Je suis curieux de savoir quels avantages voyez-vous à un projet indépendant ?

Je l'ai essayé en février et j'ai eu du mal avec, en particulier avec le composant d'ondulation et les requêtes multimédias multiplateformes.

Parfois, il est plus facile de repartir de zéro.

pour moi, cela n'a pas de sens d'avoir des composants React qui ne fonctionnent pas sur React Native ... et puisque les développeurs de material-ui n'ont pas considéré RN comme une priorité ... il n'est que juste/logique de commencer sur un nouveau chemin

@tuckerconnelly Je ne pense pas que la façon dont les composants sont implémentés soit importante. J'espère juste que les deux projets tentent d'implémenter la même API (et conviennent des mêmes noms) pour leurs composants. Je suis content que vous ayez travaillé et partagé.

Alors pour 2017/2018 après la v1.0.0, RN sera-t-il le prochain objectif de material-ui ?

Vu de :

• La participation de la communauté à la v1
• Le nombre de personnes qui souhaitent le soutien des infirmières autorisées
• Le fait que de nombreux projets aient été basés ou inspirés par Material-ui pour proposer des composants RN
• L'expérience acquise grâce à tout cela et le fait que beaucoup de temps s'est écoulé depuis l'ouverture de ce numéro

Si vous lanciez (probablement après le lancement de la v1) un projet pour offrir des composants RN, beaucoup de gens vous aideraient. Vous auriez juste besoin de commencer et de définir un chemin clair et ce serait bien de partir. Vous avez une grande communauté, utilisons-la pour fabriquer le meilleur produit possible.

@NitroBAY 1.0 utilise JSS au lieu d'objets JS pour le style, il s'appuie donc sur cssinjs/jss#368 pour prendre en charge React Native. Mais je pense qu'il vaut mieux développer une version parallèle pour React Native comme celle-ci : https://github.com/xotahal/react-native-material-ui. Ensuite, nous pouvons la version React Native fonctionne sur le Web en utilisant https://github.com/necolas/react-native-web

Alors, est-ce un problème ? Si oui, peut-il être étiqueté comme tel ?

@jhabdas J'aimerais voir une bonne bibliothèque intégrer les spécifications matérielles dans React Native.
D'après les liens postés dans le fil, il y a déjà une bonne liste de candidats.

Si nous gardons ce problème ouvert, il concerne l'unification du Web et du natif. Fournir une API cohérente entre les deux plates-formes. J'aimerais avoir le temps de travailler là-dessus, mais je ne le fais pas et je doute que cela change.
L'équipe @callemall/material-ui aimerait voir quelqu'un prendre la tête de ce problème.

Toujours en charge de carbon-ui :) Je n'ajoute des composants que lorsque j'en ai besoin (je n'essaie pas de manière proactive de remplir l'intégralité des spécifications), mais je pense qu'il existe un bon cadre pour que les gens se rallient.

• Il génère automatiquement des documents à partir des commentaires des composants
• A un site de documentation (carbon-ui.com)
• Prend en charge le natif et le Web avec les mêmes composants

Aiderait tous ceux qui veulent ajouter des composants :)

@tuckerconnelly Que pensez-vous de https://github.com/xotahal/react-native-material-ui ? Cela ne fonctionne pas sur le web à cause d'un bug avec Elevation, mais si on appliquait votre code https://github.com/tuckerconnelly/carbon-ui/blob/master/src/style/Elevation.js , je le pense travaillerait. @oliviertassinari fait valoir que nous devons décider d'un projet principal pour travailler ensemble.

@quangbuule attendez vous dites que nous devrions développer des applications en tant qu'applications RN et ensuite utiliser cet outil pour transformer RN en une version WEB ?
Je n'ai jamais entendu parler de ce truc mais bon. Mais alors cela signifie que nous n'utiliserions plus material-ui mais plutôt un fork RN ?

@NitroBAY Nous

Désolé pour toutes les questions de noob mais j'atterris dans ReactLand depuis environ 1 semaine.

Vous pensez que votre package va remplacer celui-ci ?
Votre approche semble être multi-plateforme et donc très bonne. Material-ui s'en tient uniquement au web car ils n'ont pas le temps mais ils ont le temps pour la suite, pourquoi ?
Vous dites que next utilise une approche isomorphe sur next mais si je prends n'importe quel composant, c'est-à-dire du papier, cela ne fonctionnera que pour le Web car il y a un composant div .
Qui sont we , faites-vous partie de cette équipe ?
Indépendamment des considérations techniques, ne pensez-vous pas que l'utilisation de MD sur IOS peut gêner les utilisateurs ?

EDIT : hors sujet mais personne ne m'a répondu, quels avantages apporte jss-theme-reactor quand il s'agit de le comparer à jss-react ?

@NitroBAY :

1. Je ne suis pas le développeur de ce projet ni d'aucun projet React Native. Mais j'ai regardé ce numéro pendant des mois, et pour le moment, j'ai hâte de commencer à contribuer à react-native-material-ui .
2. paper ou le truc de l'ombre fonctionne maintenant sur le Web, iOS, Android. Ce n'est donc pas grave.
3. material-ui branche master utilise des objets pour définir les feuilles de style mais pour améliorer les performances (30% boost), les contributeurs passent en JSS (CSS en JS) dans la branche next . Pour le moment, JSS n'est pas compatible avec React Native.
4. Google utilise Material Design sur iOS et je ne pense pas que les utilisateurs s'en soucient beaucoup. Bien sûr, vous devez modifier certaines parties pour les adapter à la plate-forme, telles que la modification de la couleur de la barre d'état, l'utilisation de l'icône de partage iOS, etc. J'ai utilisé material-ui pour mon application Windows 10 et macOS et je n'en ai pas vu beaucoup les utilisateurs s'en sont plaints (http://moderntranslator.com/). Certains ont même dit que MD était plus facile à utiliser.

Mais je ne comprends toujours pas de quelle manière la branche next peut fonctionner dans RN si les composants utilisent des éléments HTML tels que span ou div . J'ai peut-être raté quelque chose mais pour développer en RN il faut utiliser des composants RN, n'est-ce pas ?
je te cite :

il deviendra la version officielle à la fois web et native. Je pense que c'est bien étant donné que material-ui utilise une approche similaire avec la branche suivante.

Mais peut-être que je n'ai pas bien compris. Voulez-vous dire que la branche next nous permettra d'utiliser des composants dans RN ?

@NitroBAY : la next rendra material-ui moins compatible avec React Native. De plus, même si le composant RN ne prend pas en charge span ou div, en utilisant des règles conditionnelles, vous pouvez quelque chose comme ceci :

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

Vous pouvez vérifier : https://github.com/necolas/react-native-web

Oh d'accord, je pensais que vous vouliez dire qu'ils rendaient RN compatible.

Le TL;DR indique-t-il que ce projet n'a aucun intérêt pour la prise en charge multiplateforme via l'API React Native, et que cet effort devrait se déplacer vers https://github.com/xotahal/react-native-material-ui ?

Les docs pour carbon-ui sont meilleures, et ça marche déjà sur le web. Quel est l'avantage de react-native-material-ui ?

Donc tout le monde est d'accord pour dire que material-ui va être arrêté pour être utilisé et recommandé dans quelques temps ? Alors c'est dommage que les propriétaires de ce package ne veuillent pas de RN ?

carbon-ui semble avoir des problèmes de performances en n'utilisant pas StyleSheet et en injectant autant de polices Web

Calmez-vous les gars ! C'est encore à venir.

TL; DR : si vous créez un composant pour React Native, il fonctionnera sur RN et sur le Web. Mais si vous créez un composant pour le Web, cela ne fonctionnera pas sur RN. Et material-ui est construit pour le web, optimisé pour le web => Pour que ça marche sur RN, il faut sacrifier les performances (du moins, pour le moment). Ainsi, je pense qu'il est préférable de garder les deux projets séparés jusqu'à ce que RN soit plus mature.

optimisé pour le web => Pour que ça marche sur RN, il faut sacrifier les performances (au moins, pour le moment)

Avez-vous des données à partager à ce sujet ?

Voici mes conclusions pour RNW jusqu'à présent :

• 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, je peux envisager d'utiliser StyleSheet avec Uranium. Je dirai que je n'ai pas remarqué de problèmes de performances liés à CSS, mais je vais voir si je peux mieux m'intégrer à vos trucs StyleSheet.

Le plus gros impact sur les performances vient d'Animated : https://github.com/animatedjs/animated/issues/48 Mais cela affecte toutes les applications RNW.

L'injection de polices Web diminue-t-elle significativement les performances ? Il les charge directement à partir des polices Google, de sorte qu'elles sont probablement déjà mises en cache sur le système de l'utilisateur.

La chose la plus importante, je pense, c'est que tout le monde se rallie à une seule bibliothèque. Et je ne pense pas que material-ui va prendre en charge React Native.

@necolas Le TL;DR est que la voie à suivre n'est pas claire .

A = natif réactif
B=le web

1. La plateforme la plus contrainte

Une approche possible consiste à cibler la plate-forme la plus contrainte, partant donc de react-native . Ensuite pour étendre les fonctionnalités au web. Afin d'étendre les fonctionnalités au Web, nous pourrions utiliser :

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

Cependant, cela vient avec un compromis, nous gagnerions le partage de code. Mais je m'attends à perdre dans certaines dimensions.

Apporter l'API native au Web

L'API doit être réimplémentée pour fonctionner avec le navigateur. Quel est le surcoût ?

Gestion de l'API Web manquante en natif

Comme nous partons de la plate-forme la plus contrainte, nous aurions besoin de réimplémenter certaines fonctionnalités disponibles sur le Web. Qu'en est-il des requêtes médiatiques ? Héritage CSS, animations CSS ?
Qui implémenterions-nous des événements d'accessibilité et de clavier sans gonfler la version native ?

2. La plateforme la moins contrainte

Une autre solution est de partir de la plateforme la moins contrainte, donc du web. Ensuite, création de réimplémentation des fonctionnalités natives manquantes.

Cependant, cela vient avec un compromis, nous gagnerions le partage de code. Mais je m'attends à perdre dans certaines dimensions.

Apporter l'API Web au natif

Nous allons devoir faire des sacrifices, je m'attends à ce que certaines fonctionnalités Web soient vraiment difficiles à implémenter en natif, par exemple, les requêtes multimédias CSS, les animations CSS. (règles CSS avancées)

Gestion de l'API native manquante sur le Web

Certaines des fonctionnalités manquantes de l'API Web concernent la gestion tactile, le défilement et la vue de liste infinie, les composants natifs comme un DatePicker ou un Drawer.

3. Partage de contrat

Une troisième solution pourrait être de mettre en place une infrastructure pour partager des API et des tests, puis de réimplémenter les composants dans les deux plates-formes sous-jacentes. De mon point de vue, c'est la façon dont react-native aborde iOS et Android.
Ensuite, en utilisant une approche mixte des deux précédentes pour remplir pleinement le contrat. Je veux dire, utiliser la branche de code lorsque cela a du sens et partager le code autant que possible.
Par exemple:

• Pourquoi utiliser animation.js sur le navigateur quand on peut utiliser des transitions CSS ?
• Pourquoi implémenter la logique Drawer sur react-native quand on peut utiliser le composant natif ?

Je pense que l'option 3. est la plus prometteuse. C'est ainsi que j'ai essayé de résoudre le problème dans les vues réactives .

https://github.com/tuckerconnelly/uranium prend en charge les requêtes multimédias multiplateformes :)

La beauté de RN est que vous disposez d'une bibliothèque simple d'API abstraites et de primitives, et que les implémentations de bas niveau sont prises en charge. L'animation est la même : une bibliothèque simple pour les animations, les implémentations de bas niveau (animations natives sur iOS/Android, transitions CSS sur le Web) sont prises en charge.

Je pense qu'animated.js pourrait être configuré pour utiliser des transitions CSS. Améliorerait certainement les performances.

@quanglam2807 ce fil est très long, que dois-je regarder ?

Afin d'étendre les fonctionnalités au Web, nous pourrions utiliser : https://github.com/necolas/react-native-web , https://github.com/taobaofed/react-web

react-web est assez loin d'être IMO performant ou fonctionnellement correct.

L'API doit être réimplémentée pour fonctionner avec le navigateur. Quel est le surcoût ?

Frais généraux dans quelles dimensions ? Difficile à déterminer en termes de taille de paquet. Vous seriez probablement en mesure de supprimer une partie de votre code existant ; mais si vous deviez dépendre de quoi que ce soit au-delà des exportations de base RNW, cela s'additionnerait rapidement. Dans les composants de style pour mobile.twitter.com, j'ai constaté une réduction de 20 à 40 % de la taille des composants en convertissant les styles des modules css en RNW StyleSheet. En termes de performances d'exécution, ce n'est actuellement pas loin des css-modules .

Qu'en est-il des requêtes médiatiques ?

Vous pouvez utiliser matchMedia pour modifier les styles et la structure des composants, bien que les avantages de l'utilisation des requêtes multimédias pour modifier les composants ne me soient pas clairs.

Héritage CSS, animations CSS ?

RNW prend en charge les animations CSS (bien que je doive ajouter une API pour définir les images clés). Quelle est la question liée à l'héritage CSS ?

Comment implémenterions-nous l'accessibilité et les événements de clavier sans surcharger la version native ?

Pas sûr de ce que cela signifie. Je soupçonne que le seuil de "gonflement" dans une application native est bien plus élevé que pour une application Web.

alors peut-être que comparer la façon dont react-native-web gère les styles pour rendre les performances css aux performances des modules css est moins pertinent maintenant

Pourquoi serait-ce?

Ce serait génial d'avoir une sorte de web natif réactif qui utilise quelque chose comme aphrodite ou jss

Ces deux bibliothèques sont plus lentes, plus grandes et ne sont pas bien adaptées pour fournir des styles déterministes

@necolas material-ui fournit un gros effort pour passer d'une méthode css-in-js à une méthode de feuille de style (css in <style> ). Ils ont déployé des efforts actifs pendant des mois pour changer les composants. Les raisons sont ici . D'après ce que j'ai lu, l'utilisation de jss est un énorme avantage et semble être la solution la plus parfaite pour gérer le style jusqu'à présent.

Au fait, en relisant le Roadmap.md, le support RN est sur le Roadmap.

Je suis très intéressé par l'utilisation de Material-UI avec react-native, un mot sur les progrès?

@wswoodruff Vous pouvez vérifier celui-ci pour l'instant - https://github.com/xotahal/react-native-material-ui

Actuellement, nous avons trois bibliothèques géniales pour cela :

• react-native-material-kit ★3110 - Apporter la conception matérielle à React Native .

• react-native-material-design ★2447 - Composants de conception de matériaux natifs React

• react-native-material-ui ★1040 - Composants de conception de matériaux hautement personnalisables pour React Native.

Profitez!

Il y a aussi l' interface utilisateur Carbon moins connue si vous devenez universel. Mais pour mon temps, je m'en tiendrais probablement à l' un d'entre eux .

cela a été abordé plusieurs fois dans ce fil, mais je veux le rappeler à nouveau en raison de l'impact que cela a sur mon intérêt pour ce changement : le principal avantage du support de réaction-natif que je vois n'est pas réellement à propos de réaction-native , mais au lieu d'être construit sur les primitives qui permettent d'utiliser les mêmes composants sur _à la fois_ natif et Web.

si ce type de primitive était utilisé, d'autres outils tels que react-sketchup et -pdf pourraient également être activés.

personnellement, ceux-ci sont plus intéressants pour moi que natifs, mais seraient permis par les mêmes changements.

@jhabdas Quelle est votre expérience avec Carbon UI ? Bcz pour moi, ça a l'air plutôt bien mais je ne l'ai pas encore utilisé.

@ deadcoder0904 ne l'a pas encore utilisé personnellement. essayez probablement de contacter l'un des gars au rouge infini. ils dirigent le bulletin RN et devraient être les experts en la matière. si et quand je crée une autre application RN (d'accord, quand ...) Je ne vais pas mettre les choses ensemble cette fois-ci ou construire un autre passe-partout - À mon humble avis, l'espace est résolu par les passe-partout et les composants existants .

Voici quelques-uns des obstacles auxquels je pense qu'il faudrait surmonter pour rendre MUI disponible dans React Native. En supposant que MUI v1 et que nous gardions JSS, le modèle classes et d'autres éléments qui sont à ce stade des éléments clés de la conception de l'api de MUI.

• JSS doit prendre en charge RN, à savoir créer des objets de style de manière à ce que withStyles fonctionne. Plus d'informations à ce sujet sur https://github.com/cssinjs/jss/issues/368#issuecomment -376708219.
• En supposant qu'il n'y ait pas de wrapper hacky ou de transformation babel, nous devrons augmenter le modèle classes pour qu'il fonctionne de la même manière mais tient compte du fait que sur RN, il devrait plutôt passer un tableau à style , et devrait probablement être nommé styles . Peut-être que cela pourrait être géré en supprimant classnames et en ajoutant des aides extensibles qui basculent en arrière-plan entre la gestion des classes/className et les styles/styles.
  Peut-être:
  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 accepterait une liste de noms de style (et ignorerait les valeurs fausses). Sur le Web, il chercherait dans props.classes et produirait {classNames} . En natif, il chercherait dans props.styles et produirait un {style} .
  À l'origine, j'ai pensé à this.composeStyles avec un décorateur, mais au lieu de cela, withStyles pourrait simplement passer une aide à la composition de style dans le cadre des accessoires.
• Comme d'autres l'ont mentionné, après tout cela, pour que les composants de style de base fonctionnent, nous aurons besoin de travail supplémentaire pour faire fonctionner les animations, les touches, etc.
• Cependant, pour les animations, je ne considère pas cela comme une mauvaise chose. C'est une petite perte pour les transitions simples, où vous faites juste automatiquement la transition opacity , backgroundColor , etc. Nous pouvons vouloir des aides qui restent simples. Mais d'après ce que j'ai vu, les implémentations réelles de transition matérielle autres que celles-ci semblent trop compliquées/cryptiques et ne s'adapteront pas bien. react-transition-group a quelques bons idéaux pour gérer la partie de bas niveau des choses (gestion d'entrée/sortie, etc.), mais est problématique/gênant dans d'autres. De plus, au lieu de la conception basée sur les transitions CSS, je pense que la voie à suivre serait d'utiliser la nouvelle API d'animations Web et d'exiger le polyfill pour cela.
  En d'autres termes, je pense qu'il y a de la place pour la création d'une nouvelle bibliothèque pour gérer les animations dans React qui utilise des animations Web dans le navigateur et l'API animée dans React Native et constitue une amélioration générale par rapport à la façon dont MUI gère l'animation.
• MUI doit abandonner l'attente d'un comportement en cascade disponible. Et la configuration du thème doit être améliorée pour prendre en charge l'application facile de modifications au thème dans une sous-arborescence.
  À l'heure actuelle, des éléments tels que AppBar + Icons fonctionnent en définissant la couleur du texte, en utilisant un color='inherit' explicite et en supposant que la couleur descendra en cascade. Et il est possible que ce soit la même chose dans d'autres parties de MUI.
  Il n'y a pas de cascade comme celle-ci dans React Native. Au lieu de cela, vous devez déclarer vos styles explicitement pour chaque vue. Pour ces types de choses, AppBar et d'autres composants devront être en mesure de fournir facilement une version modifiée du thème qui leur est fourni avec une modification comme changer le thème dans ce contexte en dark afin que les icônes obtiennent l'icône contrastante correcte couleurs (et peut être basé sur la spécification réelle des couleurs de l'icône au lieu de la couleur du texte). Notez que cela peut avoir des implications sur des éléments tels que les menus imbriqués dans les barres d'applications.
• Dans le prolongement de ce problème en cascade. MUI est également conçu autour de choses comme <Button>Text</Button> , où il est supposé que MUI peut simplement styliser la fontFace/color, etc. un mélange d'éléments et de nœuds de texte et les nœuds de texte obtiennent le bon style.
  Cela s'effondre dans React Native. Tout le texte doit faire partie d'un <Text> , tous les styles de texte doivent appartenir aux styles de ce composant et un élément de texte ne peut pas contenir d'enfants non textuels (c'est-à-dire).
  Il y a quelques options :
  
  
  
  • Le modèle <Button text='Text' /> fonctionne beaucoup mieux dans React Native. Malheureusement, c'est fondamentalement différent de la philosophie de MUI, ce n'est donc pas une option.
  
  
  • Nous pourrions mapper les enfants et remplacer les chaînes par des éléments de texte stylisés. Cependant, c'est fragile, au moment où vous enveloppez la ficelle dans tout ce qu'elle se désagrège (même react-intl la ferait s'effondrer). Pouah.
  
  
  • Ce n'est pas la plus jolie façon de le faire, nous devrons attendre, et je ne comprends pas à 100% les implications en termes de performances. Mais nous pourrions utiliser la nouvelle API de contexte de React 16.3 et exposer un <MuiText>Text</MuiText> . Fondamentalement, les composants MUI tels que Button auraient des fournisseurs qui fourniraient des informations sur les styles du contexte actuel (police, couleur du texte, etc.) et MuiText consommerait simplement ces données et les appliquerait à un élément Text.
  
  

Aujourd'hui la v1 est sortie alors quels sont les plans de React Native❓

Pour React Native Material Support, il existe une belle bibliothèque appelée React Native Paper qui sera maintenue et prise en charge par l'équipe CallStack.

Mais y a-t-il des plans pour porter cela sur React Native parce que je pense que Paper fonctionne parfaitement bien❓

Sinon, vous pouvez probablement fermer ce problème :)

Merci pour le partage @ deadcoder0904. J'ai ajouté du papier à Awesome React Components . Je n'ai pas entendu parler de CallStack. Au début, je l'ai lu comme Call-Em-All. Je suppose que ce ne sont pas les mêmes potes, hein ?

@jhabdas Non, ils ne sont pas les mêmes

@dantman Voici mes réflexions sur la meilleure façon d'obtenir un support natif

• si s'en tenir à jss n'est pas une exigence absolue, je pense que fela est une alternative viable :
  
  
  
  • fela-native prend en charge les requêtes multimédias et utilise correctement StyleSheet.create
  
  
  • Il est incroyablement extensible . Nous pourrions réécrire les règles des propriétés Web sur leurs proxys réactifs natifs, supprimer des éléments tels que les règles :hover sur les propriétés natives et probablement récupérer la syntaxe perdue de jss.
  
  
• react-native-animatable prend en charge les images clés et pourrait probablement être utilisé à la place de transition-group, qui peut ou non fonctionner avec native .
• Je suis d'accord pour renverser le point de vue sans cascade de react-native. Cela pourrait être opt-in chez le fournisseur et le consommateur avec des accessoires cascade et inherit .
  Toutes les bibliothèques natives avec lesquelles j'ai essayé de travailler ont été douloureuses ou inutilisables en raison d'API trop rigides et de styles impossibles à remplacer, à l'exception de celles qui utilisent @shoutem/theme pour autoriser les remplacements (comme native-base) .

J'attends toujours ce soutien. J'utilise magnifiquement sur le Web mais je développe aussi sur mobile !

aucune mise à jour sur le support réagir native?

@oliviertassinari J'ai l'intention de bifurquer et de commencer à explorer le chemin de mise en œuvre que j'ai décrit ci-dessus. Ma priorité va être de faire fonctionner les composants dont j'ai besoin pour un autre projet, donc je ne serai probablement pas prêt à prendre en charge React Native robuste de sitôt, mais j'essaierai de le garder "synchronisé" avec le maître autant que possible dans l'espoir qu'il sera un jour utile (ou éventuellement fusionné)

@micimize Merci de me l'avoir

Mise à jour à ce sujet : nous avons migré une grande partie des fonctionnalités vers un état quelque peu utilisable, notamment des listes, des boutons, des cartes, des icônes, des contrôles de sélection, des champs de texte et un arrière-plan. Malheureusement, une fois que nous avons finalement développé notre application elle-même sur React-native, une multitude de problèmes sont apparus et nous ont obligés à passer à Flutter.

À un moment donné, j'aimerais revenir en arrière et récupérer une partie du travail que nous avons effectué, principalement le port de la solution de style withStyles / classes qui a tiré parti des propriétés css-shorthand-properties et d'autres choses

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

Travailler sur le problème serait un coût d'opportunité pour nous. je ferme. Nous allons doubler nos efforts pour mieux prendre en charge les cas d'utilisation du navigateur.

@oliviertassinari , cela signifie-t-il que le support natif réactif est hors de portée et que dans un avenir proche (par exemple 1 an) il ne sera pas sur le radar ?

Oui

https://github.com/lightningtgc/react-native-material-ui N'est rien d'autre qu'un autre paquet npm d'arnaque