Material-ui: Unterstützen Sie React Native

Habe gerade dieses Repo entdeckt: https://github.com/lightningtgc/react-native-material-ui
Weiß aber nicht ob es gut ist.

Danke @chadobado - Wir haben sicher darüber gesprochen und es wäre ein lustiges Projekt zu starten. Allerdings haben wir mit diesem Projekt im Moment alle Hände voll zu tun. Ich werde dieses Problem offen halten und aktualisieren, wenn wir jemals eine native Bibliothek erstellen.

Das ist eigentlich eine tolle Idee. Ich habe versucht, die Portierung von material-ui auf React-Native zu testen. Wir müssen nur ein wenig Stylesheets ändern, alle div in View ändern, alle h1 , h2 usw. in Text ändern und es wird super funktionieren. Das einzige Problem, das ich gefunden habe, ist, dass React Native boxShadow nicht vollständig unterstützt, daher ist es im Moment schwierig, die Paper Komponente zu implementieren. Außerdem wäre es großartig, wenn wir ein Skript zum automatischen Portieren des Codes nach React-Native entwickeln könnten, da er nicht sehr unterschiedlich ist.

ändere alle div in View, ändere alle h1, h2 usw. in Text und es wird großartig funktionieren

Könnten wir dafür nicht einen Babel-Plugin-Transformator verwenden?

Das ist wirklich eine tolle Idee

Haben Sie ein Demo-Projekt?

@oliviertassinari

Könnten wir dafür nicht einen Babel-Plugin-Transformator verwenden?

Ich bin mir nicht sicher, da sich das Stylesheet von React Native stark von CSS unterscheidet, so dass es ziemlich kompliziert sein wird, den Transformer zu erstellen.

Haben Sie ein Demo-Projekt?

Noch nicht, weil ich ziemlich beschäftigt bin, aber ich werde versuchen, Ihnen demnächst eine kleine Demo zu zeigen.
Aber hier ist, was wir tun müssen

Stylesheets

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

zu

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

zIndexlösung

JSX

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

zu

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

Wir müssen auch styles/transition.jsx ändern (React Native verwenden object anstelle von string ), mixins/style-propable.jsx da wir nicht mit mehreren Browsern umgehen müssen usw.

Ich veröffentliche einfach ein WIP-Forking zu Reactive-native in https://github.com/lenaten/material-ui-native.
Derzeit funktionieren nur Card und RaiseButton, aber ohne Style (WIP erinnerst du dich?)

@lenaten Interessant!
Ich wollte auch mit der Arbeit an einem Wrapper zwischen diesem Projekt und mrn (https://github.com/oliviertassinari/react-material) beginnen.
Es scheint, dass Ihr Fork nur mit Reactive-Native funktioniert, wie würden Sie es auch mit dem Browser zum Laufen bringen?
Ich denke, das ist der schwierigste Punkt und sollte jetzt angesprochen werden, da Sie sagen, dass Sie zwei Arbeitskomponenten haben. Ich kann helfen, wenn Sie möchten.
Wie bereits erwähnt, wollte ich auch https://github.com/binggg/mrn für unsere native Implementierung untersuchen.

Wenn sie beantwortet ist, denke ich, dass wir Ihre Abzweigung hier wieder zusammenführen könnten.

Material-UI ist ein ausgereiftes Projekt gegen ein mrn-Projekt, das viele Materialkomponenten vermisst. Wenn mein POC wie gewohnt funktioniert, sollte das Zusammenführen mit der plattformübergreifenden Dateistruktur einfach sein. Ich habe keine Zeit, das Rad neu zu erfinden und ein Projekt von Grund auf neu zu starten.

Wie auch immer, Ihre Hilfe in Gedanken und Code ist sehr willkommen.

@oliviertassinari Ich auch.

Meine Idee, dass material-ui sowohl mit Browsern als auch mit nativen Betriebssystemen funktioniert, besteht darin, eine Dateinamenstruktur zu verwenden, ähnlich wie react-active iOS und Android behandelt.

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

oder wir können immer noch die gleichen Komponenten für Browser und native verwenden und dann einen Wrapper schreiben, um sie zu verarbeiten. Zum Beispiel verwendet react-native View , der Browser verwendet div und mach es dann so:

div.browser.jsx

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

div.native.jsx

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

app-bar.jsx

import {div} from "div"

Wir können tatsächlich ein separates Projekt für diesen Wrapper erstellen.

@quaglam2807 Das freut mich zu hören.

Was die Code-Organisation angeht, gefällt mir die Idee, separate Dateierweiterungen zu haben.
Ich würde als Beispiel https://github.com/benoitvallon/react-native-nw-react-calculator/tree/master/src/common/components nehmen.

Was die Projektorganisation angeht, habe ich vielleicht meine Meinung geändert.
Ich denke, es ist besser, dem Ansatz von Google zu folgen und an einem großen einzigen Repository zu arbeiten. Daher könnte es eine gute Möglichkeit sein, an einer Fork-Synchronisierung mit material-ui oder hier zu arbeiten.

Um mit unseren .native Dateien zu beginnen, können wir uns darauf verlassen

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

Komponenten.

@oliviertassinari Ich liebe auch die Idee des Modells "Dateierweiterung". Das Wichtigste für mich ist jetzt die Arbeit mit nativen Komponenten. Wenn Sie bei der Codeabstraktion helfen möchten, sind Sie willkommen. Ich verpflichte mich, das Suffix "native" aus dem Repo-Namen zu entfernen :)

@lenaten ist material-ui-native kompatibel mit tcomb-form-native, oder wenn nicht, wie groß wäre das Projekt?

@mvayngrib Ich habe für eine Weile aufgehört, an diesem Projekt zu arbeiten.

@lenaten das ist schade, danke für die

Okay, ich habe angefangen, in diesem https://github.com/callemall/material-ui/pull/2611 zu arbeiten.
Das wird noch etwas dauern!

@oliviertassinari super ! sehr sehr aufgeregt

Ist die Hafenbemühung also noch offen? Wenn ja, wie wurde der Prozess zur Implementierung von Komponenten festgelegt?

@dorthwein Es ist noch geöffnet.

Der Ablauf ist aus meiner Sicht folgender:

• [ ] Aktualisieren Sie auf die neueste Version von React- Native und entfernen Sie Projekt getan. https://github.com/callemall/material-ui/pull/3829
• [ ] Spielen Sie mit dem Reaction-Look und sehen Sie, wie gut wir es für das muiTheme , das aus dem Kontext kommt. https://github.com/callemall/material-ui/pull/3829
• [x] Warten Sie auf die Neuorganisation des
• [ ] Beginnen Sie mit der Arbeit an der Dokumentations-App, die wir verwenden werden, um neue Komponenten zu präsentieren.
• [ ] Beginnen Sie mit der Arbeit an der nativen Version der Komponenten.

@oliviertassinari - Ich kann ein wenig Zeit beitragen, um einige der Komponenten zu

@dorthwein das freut uns zu hören.
Ich verwende hier React-Look #3829. Das einzige Problem, das ich habe, ist ein kleines. React Native zeigt eine Warnung bezüglich der falschen Verwendung der StyleSheet API an. Ich habe es mir nicht im Detail angeschaut, aber ich glaube, dass es gelöst werden kann.

@oliviertassinari @dorthwein Ich bin froh, dass dieser Versuch (also material-ui auf react-native ) nicht tot ist. Ich wollte nur darauf hinweisen, dass es auch ein weiteres neues material-ui zu react-native Projekt gibt, das in diesem Thread nicht erwähnt wurde: https://github.com/react-native-material- design/react-native-material-design . Dieses Projekt scheint auf https://github.com/binggg/mrn zu basieren

@oliviertassinari Ich habe in einem anderen Thread gesehen, ob die Unterstützung von iOS für diesen Port sinnvoll ist. Wo es sinnvoll ist und es eine starke vorbestehende iOS-Komponente (zB Switches) gibt, sollte es für den iOS-Switch auf iOS verwendet werden. Die Implementierung von Android und iOS ist ebenfalls keine große Belastung.

@oliviertassinari Die

@oliviertassinari Ich habe versucht, die Dokumente einzurichten und zu laufen, kein Glück. Einige Probleme:

• package.json: React-native mag den Paketnamen material-ui nicht - der Wechsel zu materialUI hat das Problem behoben
• Der aktuelle material-ui/react-native-Zweig hat ein Problem mit dem React-native-Packer und erstellt die Datei mainjs.bundle nicht. Ich konnte nicht herausfinden, was hier vor sich ging.
• Ich kann anscheinend keine funktionierende reaktive App über das vorhandene Material-UI-Repo aufbauen. Wenn irgendjemand an dieser Front Glück hatte, können wir hier eine stabile Anleitung zum Beitragen/Entwickeln eines nativen Komponentensatzes erhalten.

@dorthwein Danke für das Feedback. Der reaktive Zweig ist sehr experimentell. Wir müssen das lösen.
Auf der anderen Seite habe ich kein Problem auf meiner Seite (https://github.com/callemall/material-ui/pull/3829).
Ich sollte versuchen, mit einem neuen git clone anzufangen.

Ja, also die nächste Phase meines aktuellen Projekts ist die Arbeit an einer mobilen App mit Materialdesign - ich würde dies gerne verwenden, da all unsere Websachen auch darin enthalten sind. Wenn wir eine Arbeitsumgebung in Gang bringen können, werde ich sie zusammen mit unserem Projekt abbauen.

Ich habe mich über einiges informiert und diesen Leckerbissen von der FB React Native Page bemerkt.

"Die grundlegendste Komponente zum Erstellen einer Benutzeroberfläche, View ist ein Container, der Layout mit Flexbox, Stil, einige Touch-Handhabung und Eingabehilfen unterstützt und so konzipiert ist, dass er in andere Ansichten geschachtelt wird und 0 bis viele untergeordnete Elemente jeglicher Art hat. View ordnet direkt dem nativen Ansichtsäquivalent auf jeder Plattform zu, auf der React ausgeführt wird, sei es ein UIView,

Habe auch diese Ressource gefunden - probiere sie jetzt aus. Scheint ziemlich geradlinig und vielleicht einen Blick wert

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

@dorthwein Tolle Idee! Aber wenn wir diesem Weg folgen, wäre es meiner Meinung nach besser, eine Version nur für React Native zu entwickeln.

Wir können das gesamte Projekt unter React Native APIs umschreiben, anstatt separate Codes für Native und DOMs zu verwenden. Tolle! Darüber habe ich mir noch nie Gedanken gemacht.

@quaglam2807 ja - auf diese Weise neue Funktionen usw. Bleiben Sie in einer Linie. Die größte Herausforderung besteht meiner Meinung nach darin, dass die Stile und Animationen funktionieren. Ein weiteres großes Plus ist, dass wir nach und nach Unterstützung für verschiedene Komponenten hinzufügen können.

Die Kehrseite ist, dass alles benötigt wird, um Flexboxen zu verwenden.

Angesichts der Tatsache, dass dies eine umfassende Überarbeitung der Codebasis ist – wer muss dies alle abzeichnen, um fortzufahren? Ich muss noch herumspielen und sehen, wie robust das Reactive-Native-Web-Zeug auch ist.

@quaglam2807 @oliviertassinari Ein weiterer Vorteil dieses Ansatzes besteht darin, dass material-ui problemlos auch auf https://github.com/ptmt/react-native-desktop portiert werden kann.

@oliviertassinari verwendet

@dorthwein Ich liebe die Idee hinter diesem Projekt. Aber ich glaube nicht, dass es in naher Zukunft helfen würde.
Müssen wir nicht zuerst eine native Version unserer Komponenten schreiben, bevor wir react-native-web ?

@oliviertassinari nein, was react-native-web macht, ist die "

Der Prozess wäre dann, anstatt native Versionen jeder Komponente zu schreiben, dass wir nur die vorhandenen konvertieren müssten, um View anstelle von div zu verwenden und Text zu stylen, anstatt Dinge wie h1 und label zu verwenden.

Auf jeden Fall kein kleines Unterfangen, aber der Prozess würde dann die bestehenden Komponenten aktualisieren, anstatt zu versuchen, mehrere Versionen zu erstellen und zu pflegen.

Der Prozess wäre dann, anstatt native Versionen jeder Komponente zu schreiben, dass wir nur die vorhandenen konvertieren müssten, um View anstelle von div zu verwenden und Text zu stylen, anstatt Dinge wie h1 und label zu verwenden.

Das klingt genau so, als würde man eine native Version schreiben, die hoffentlich auch im Browser funktioniert. Soweit ich weiß, bringt react-native-web Reaction nativ ins Web und nicht umgekehrt.
Trotzdem kann es sehr praktisch sein, denselben Code zu teilen :+1:.
Ich habe bisher ein kleines Problem mit dieser Lib gesehen. Ihre StyleSheet.create Implementierung unterstützt keine dynamischen Werte (benötigt für das muiTheme). Für diesen Anwendungsfall könnten wir einen Reaction-Look verwenden.

@oliviertassinari du hast recht - ich habe es rückwärts verstanden. Schritt 1 scheint immer noch reaktive Versionen der Komponenten zu erstellen. Schritt 2 würde möglicherweise darin bestehen, sie mithilfe von so etwas wie dem reaktiven Web zu einer einzigen Codebasis zusammenzuführen.

@wordyallen : sieht gut aus 👍

@pgangwani Ich habe gerade angefangen, daran herumzuspielen ... Es ist noch nicht fertig.

Ich habe https://github.com/react-native-material-design/react-native-material-design verwendet , um die Lücke zu füllen, aber es ist auch an den Rändern sehr rau und keine aktive Entwicklung

Ich würde dieses Vorhaben finanziell unterstützen, wenn ich könnte.

Hallo Leute,

Ich arbeite an reactive-native-material-ui , das von dieser Bibliothek inspiriert ist. Probieren Sie es aus - ich würde gerne jedes Feedback hören ;)

@xotahalet . al, Anstatt von Grund auf neu zu erstellen, sollten wir IMHO diese Bibliothek verzweigen und vorhandene Komponenten portieren, anstatt sie neu zu erstellen. Die Notwendigkeit für die Materialstileingaben wird im RN-Raum dringend benötigt, wenn Sie mich fragen. Vielen Dank an alle für Ihre OSS-Bemühungen.

Ich glaube nicht, dass es viel gemeinsamen Code gibt, ich denke, es macht Sinn, von Grund auf neu zu erstellen. Das Styling in RN wird sich zu 90% von diesem unterscheiden. Und es gibt einige plattformspezifische Mechaniken wie Animationen ...

Es scheint, dass die Übernahme der Komponentenstruktur, der Requisiten (und der Dokumente) und eines klaren Upstreams, auch wenn sich viel ändert, langfristig von Vorteil für diejenigen wäre, die vom Web zum nativen System wechseln und von größter Bedeutung sind. Der Rest wird zu einem Implementierungsdetail.

Ich stimme @jhabdas zu ; je ähnlicher die APIs für jede Komponente aussehen können, desto weniger störend ist es für Entwickler, von Webprojekten und nativen Projekten zu wechseln. Je weniger erschütternd die Erfahrung, desto produktiver können sie sein. Ich würde erwarten, dass die plattformspezifischen Details hinter den Kulissen der Komponente abstrahiert werden.

@chadobado oder Betreuer, würden Sie dieses Problem bitte in "Support React Native" umbenennen, um die Sichtbarkeit bei der Suche in diesem Repository zu erhöhen? Die Suche nach "React Native" verbirgt dies derzeit in der Liste, da der Begriff im Titel getrennt ist.

FWIW, das ist mir aufgefallen.

@necolas im Websupport für react-native-material-kit :

Es ist unwahrscheinlich, dass Sie viel portieren müssen, wenn ein Stylesheet vorhanden ist, da die Kompatibilität durch die Webimplementierung von React Native gewährleistet wird

@jhabdas Wenn Sie ein bisschen mit feststellen, dass es nicht so einfach ist. Die StyleSheet-API ist großartig, aber man muss einiges umschreiben ;)

Fairer Punkt @antoinerousseau. Ich denke immer wieder an ein Zitat von James Long über RN zurück:

Betrachten Sie es als Prototyp für eine andere Richtung für das Web

Wenn ich den Zweck der Bibliothek verstehe, @necolas funktioniert, scheint es ein vernünftiger Ansatz zu sein, das Problem portieren, erstellen Sie einfach das Ganze in RN neu und portieren Sie das Web mit einem Shim zurück. React Native Material Kit hat das Problem bereits im Griff.

Da react-native-web fantastisch erscheint, werde ich einfach material-ui.android.js , material-ios.ios.js und material-ui.web.js Dateien in meinem eigenen persönlichen Projekt erstellen und es gut nennen. Wenn ich der material-ui API folge, indem ich alles andere einpacke, wird es irgendwann klappen. Wenn mich material-ui überrascht und einfach funktioniert, muss ich nur .web aus .web.js entfernen und die anderen Dateien löschen. Auf diese Weise kann ich selektiv zu material-ui pro Komponente wechseln.

@oliviertassinari Also habe ich den react-native Zweig als NPM-Abhängigkeit hinzugefügt und alle Babel-Plugins installiert. Ich habe diese Meldung beim Importieren einer Komponente erhalten:

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

Mein Ziel ist es, material-ui pro Komponente so schnell wie möglich zu verwenden. Zugegeben, ich habe ein git rebase master und hätte ein git rebase next wenn überhaupt. Sind derzeit alle einzelnen react-native Komponenten durch die next Branchenarbeitsvorbereitung blockiert?

Und ich habe einen Code geschrieben, der es mir ermöglicht, react-native-vector-icons genauso zu konsumieren, wie ich material-ui Symbole konsumiere:

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

Obwohl react-native-vector-icons und material-ui im Moment eine inkompatible Importsyntax haben. @oblador Ich musste glyphMap importieren und darüber iterieren und die gesamte Liste als ein großes Objekt exportieren.

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

Es wäre schön, wenn react-native-vector-icons Materialsymbole nach Kategorien wie material-ui gruppiert wären, um einzelne Exporte aus einer Kategorie zu ermöglichen:

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

Sollen wir an einer Pull-Anfrage arbeiten, um react-native-vector-icons mit den material-ui Importkonventionen kompatibel zu machen?

@mattferrin Der react-native ist jetzt ziemlich alt. Es ist nicht dafür gedacht, von Benutzern konsumiert zu werden. Es war ein Proof of Concept für den weiteren Weg.
Soweit ich dieses Problem betrachtet habe, wäre einer der vielversprechendsten Ansätze, es so umzuschreiben, dass es auf react-native . Dann würde Reactive-Native-Web den schwierigen Teil für uns erledigen.
Es gibt jedoch einige Herausforderungen:

• Wie viel _react-native-web_ ist produktionsreif? ZB habe ich keine Sehtests gesehen.
• Wie gehen Sie mit Medienanfragen um?
• Wie gehen Sie mit einer komplexen Theming-Lösung um?

Reagieren-mit-Stilen ist auch einen Blick wert.

Wie viel React-Native-Web ist produktionsreif?

@oliviertassinari Ich react-native-web und finde, dass es sich lohnt, sie anzunehmen. Es fehlt eine plattformübergreifende Anchor-Tag href-Komponente und möglicherweise fehlen andere Feinheiten, aber das zugrunde liegende ReactDOM ist produktionsbereit und das ist es, was wir brauchen.

Wie gehen Sie mit Medienanfragen um?

Sollte material-ui darum kümmern? Es gibt auf allen Plattformen Möglichkeiten, die Abmessungen einer Komponente oder eines Bildschirms zu ermitteln. Solange material-ui Komponenten Requisiten übergeben werden können, die das Styling steuern, was sie tun, sind wir goldrichtig, denke ich.

Führt material-ui Medienabfragen durch? Müssen wir?

Wie gehen Sie mit einer komplexen Theming-Lösung um?

Können wir nicht einfach Plattform aktivieren, um nicht unterstützte React Native-Requisiten auszulassen oder umzubenennen, da (wenn der Speicher mir recht gibt) Auffüllung und Rand in React Native im Wesentlichen umgekehrt sind. Alles, was wir tun müssen, ist, die äquivalente Methode createStyleSheet umzuwandeln, um das Ergebnis in nicht-"Web"-Plattform-spezifische kompatible Stile umzuwandeln/zu filtern.

Ich habe es noch nicht verwendet, aber Fela zielt darauf ab, plattformübergreifend zu sein, und ich denke, das ist wichtig. Da der Autor von Fela React Look geschrieben hat und dies anscheinend eine vorherige Entscheidung war, fühlt es sich wie eine natürliche Entscheidung an.

Ich habe es auch nicht verwendet, aber so etwas wie react-tunnel scheint gut für den Themenkontext zu sein. Wir könnten es einfach verwenden und veröffentlichen, nur weil es sich von der Gemeinschaft besser teilen lässt. Es könnte ein populäreres Äquivalent geben.

Wie viel React-Native-Web ist produktionsreif? ZB habe ich keine Sehtests gesehen.

Hier gibt es interaktive Beispiele: https://necolas.github.io/react-native-web/storybook/

Wie gehen Sie mit Medienanfragen um?

Verwenden Sie in JavaScript matchMedia (oder verwenden Sie Dimension ), um zu bestimmen, welche Stile und Komponenten gerendert werden sollen.

Es fehlt eine plattformübergreifende Anchor-Tag href-Komponente

Ja, ich bin mir nicht sicher, was eine "richtige" Lösung sein sollte, aber Sie können im Moment View und Text wie Links verwenden (natürlich nur Web-Support):

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

Wie gehen Sie mit einer komplexen Theming-Lösung um?

React Native hat nichts dagegen, wie Sie dies tun. Sie können weiterhin context , um zu bestimmen, welche Stilobjekte angewendet werden sollen. Ich mag die API von Fela innerhalb der Komponenten sehr, aber die Implementierungs- und Plugin-API sieht übertrieben aus, wenn Sie react-native-web .

Alles, was wir tun müssen, ist, die äquivalente createStyleSheet-Methode zu umschließen, um das Ergebnis in nicht-"Web"-Plattform-spezifische kompatible Stile umzuwandeln/zu filtern.

Ist das Problem, dass Sie eine Stil-API bereitstellen, die nicht RN-kompatibel ist? Wenn ja, würde ich vorschlagen, dass Sie eine RN-kompatible Stil-API bereitstellen und react-native-web sie in DOM-Stile konvertieren lassen.

@necolas

Ist das Problem, dass Sie eine Stil-API bereitstellen, die nicht RN-kompatibel ist? Wenn dies der Fall ist, würde ich vorschlagen, dass Sie eine RN-kompatible Stil-API bereitstellen und sie von React-Native-Web in DOM-Stile konvertieren lassen.

Guter Punkt. Hat react-native-web :hover zum Beispiel ein Gefühl für

@necolas Und die spezielle Arbeit, die ich mache, muss nur immergrüne Browser unterstützen, aber gibt es eine Möglichkeit, auf react-native-web portieren, würde material-ui Browserkompatibilität mit älteren Versionen kosten? Darüber weiß ich wirklich nichts. Ich denke wirklich, dass react-native-web der richtige Ansatz ist.

Es bietet nichts Besonderes für Hover-Stile (auch RN nicht). Ich frage mich, ob die Desktop-Implementierungen für Windows und Ubuntu etwas für Mausschnittstellen bündeln oder Ihnen über Ereignisse überlassen.

Ich bin mir nicht sicher, welche Browserunterstützung Sie benötigen, kann aber bei auftretenden Problemen helfen.

Ich denke, es könnte notwendig sein, einen booleschen MuiThemeProvider über react-native-web und einer react-dom API im Komponentenstil zu wählen.

Die beste Antwort ist, einfach zur API im Stil von react-native-web zu wechseln, und das würde ich befürworten, aber das würde wahrscheinlich zu Ärger führen.

@oliviertassinari Könnten wir es schaffen, material-ui auf eine API im Stil von react-native umzustellen? Vielleicht lassen Sie Maus-spezifische Stile durchsickern?

@necolas @oliviertassinari Nur als FYI. Es ist im Moment schlampig, aber ich habe in den letzten 2-3 Tagen daran gearbeitet, einen Branch (https://github.com/mattferrin/material-ui-build/tree/mine) plattformübergreifend zu portieren, weil ich brauche es wirklich selbst (um meine Gesamtarbeit langfristig zu reduzieren).

Ich habe alles in die react-native-web Syntax portiert und Stile auskommentiert, die nicht portiert wurden, aber ich denke, ich werde sie am Ende wieder kommentieren und Platform.OS == 'web' , um den ursprünglichen Code im Wesentlichen beizubehalten unverändert, sobald ich mit der Portierung der Website fertig bin, an der ich arbeite. An diesem Punkt werden nur die Dinge portiert, die ich persönlich benötige und die nicht perfekt sind.

Es ist ein totales Durcheinander (bis ich es später nachbessere), weil ich schnell zwischen Mac- und Windows-Rechnern wechseln muss.

Für diejenigen, die es kaum erwarten können, dass MUI nach RN kommt, gibt es Alternativen, und einige ziemlich gut aussehende noch dazu. Ich führe hier eine Evergreen-Liste: https://habd.as/awesome-react-components/#react -native

Ich wusste, dass sich die gesamte Styling-Lösung änderte, aber ich habe den Teil übersehen, in dem die Bibliothek von Grund auf neu geschrieben wird. Das ist meine Schuld. Ich hatte beim Betrachten von Code angenommen, dass die Endstile im Wesentlichen gleich bleiben würden und sich nur die Technologie ändern würde. Ich war falsch. Ich habe die Roadmap nicht komplett ignoriert, sondern nur Annahmen gemacht, die sehr falsch sind. Ich schätze, ich muss bei meinem Versuch hier aufhören.

@mattferrin Nicht ganz von Grund auf (obwohl das in einigen Fällen stimmt, zum Beispiel Table ), obwohl die Änderung der Stillösung viele API-Änderungen erfordert, uns aber zusätzlich die Möglichkeit gibt, die API in anderen Bereichen für viele Komponenten zu rationalisieren . Es tut mir leid, wenn Ihre Bemühungen umsonst waren - ich hoffe, es schreckt Sie nicht von Material-UI ab!

@mbrookes Hat es nicht. Ich habe den Fehler gemacht, master statt next abzuzweigen und den Unterschied (und die Gesamtarbeit im Allgemeinen) zu unterschätzen. Es war meine Schuld und ich wusste, dass es ein Risiko gab. Ich gebe einfach leere Text Elemente als Platzhalter bis später in meiner React Native material-ui Fassade zurück. Wenn ich meine Website vollständig auf react-native-web portiert habe, kehre ich zurück und versuche, neue Änderungen von next zu rebasieren.

Lass diesen Typen heute frei: https://carbon-ui.com

Inspiriert von material-ui, funktioniert im Web und reaktiv-nativ :)

@tuckerconnelly du

@tuckerconnelly wow, viel Potenzial in diesem Projekt ... gut gemacht! Hier ist zu hoffen, dass die größere Community hinter diesen Bemühungen steht! 🍻.

@tuckerconnelly Ich bin etwas verwirrt. Ich fand, dass es eigentlich ziemlich einfach ist, material-ui bedingt plattformübergreifend zu machen (trotz meines Fehlers, master anstelle von next abzuzweigen und meine Zeit zu verschwenden). Ich bin gespannt, welchen Nutzen Sie für ein unabhängiges Projekt sehen?

Ich habe es bereits im Februar ausprobiert und hatte Schwierigkeiten damit, insbesondere mit der Ripple-Komponente und mit plattformübergreifenden Medienabfragen.

Manchmal ist es einfacher, bei Null anzufangen.

Für mich macht es keinen Sinn React-Komponenten zu haben, die nicht auf React Native funktionieren ... und da die Entwickler von material-ui RN nicht als Priorität betrachteten ... ist es nur fair / logisch, einen neuen Weg zu gehen

@tuckerconnelly Ich glaube nicht, dass es darauf ankommt, wie Komponenten implementiert werden. Ich hoffe nur, dass beide Projekte versuchen, dieselbe API für ihre Komponenten zu implementieren (und sich auf dieselben Namen zu einigen). Ich freue mich, dass Sie daran gearbeitet und geteilt haben.

Wird RN also für 2017/2018 nach der v1.0.0 das nächste Ziel für material-ui sein?

Wie gesehen von:

• Die Community-Teilnahme an v1
• Die Anzahl der Personen, die RN-Unterstützung wünschen
• Die Tatsache, dass viele Projekte auf Material-ui basieren oder inspiriert wurden, um RN-Komponenten anzubieten
• Erfahrungen aus all dem und der Tatsache, dass seit dem Eröffnen dieser Ausgabe viel Zeit vergangen ist

Wenn Sie (wahrscheinlich nach dem Start von v1) ein Projekt starten würden, um RN-Komponenten anzubieten, würden Ihnen viele Leute helfen. Sie müssten nur beginnen und einen klaren Weg definieren und es wäre gut zu gehen. Sie haben eine großartige Community. Lassen Sie uns sie nutzen, um das bestmögliche Produkt zu entwickeln.

@NitroBAY 1.0 verwendet JSS anstelle von JS-Objekten für das Styling, sodass es auf cssinjs/jss#368 angewiesen ist, um React Native zu unterstützen. Aber ich denke, es ist besser, eine parallele Version für React Native wie diese zu entwickeln: https://github.com/xotahal/react-native-material-ui. Dann können wir die React Native-Version im Web mit https://github.com/necolas/react-native-web ausführen

Ist dies also ein Problem, das nicht behoben werden kann? Wenn ja, kann es bitte als solches gekennzeichnet werden?

@jhabdas Ich würde mich einbringt .
Aus den im Thread geposteten Links gibt es bereits eine gute Kandidatenliste.

Wenn wir dieses Problem offen lassen, geht es um die Vereinheitlichung des Webs und des nativen Systems. Bereitstellung einer konsistenten API zwischen den beiden Plattformen. Ich wünschte, ich hätte Zeit, daran zu arbeiten, aber das tue ich nicht und ich bezweifle, dass sich das ändern wird.
Das @callemall/material-ui-Team würde gerne sehen, dass jemand die Führung bei diesem Problem übernimmt.

Ich unterstütze immer noch Carbon-UI :) Ich füge nur Komponenten hinzu, wenn ich sie brauche (und versuche nicht proaktiv, die gesamte Spezifikation auszufüllen), aber ich denke, es gibt einen guten Rahmen für die Leute, hinter denen sie sich sammeln können.

• Es generiert automatisch Dokumente aus den Komponentenkommentaren
• Hat eine Docs-Site (carbon-ui.com)
• Unterstützt native und Web mit gleichen Komponenten

Würde jedem helfen, der Komponenten hinzufügen möchte :)

@tuckerconnelly Was hältst du von https://github.com/xotahal/react-native-material-ui? Es funktioniert im Web aufgrund eines Fehlers mit Elevation nicht, aber wenn wir Ihren Code https://github.com/tuckerconnelly/carbon-ui/blob/master/src/style/Elevation.js angewendet haben, denke ich es würde funktionieren. @oliviertassinari macht einen guten Punkt, dass wir uns für ein Hauptprojekt entscheiden müssen, um zusammenzuarbeiten.

@quangbuule warten Sie, sagen Sie, dass wir Apps als RN-Apps entwickeln und dann dieses Tool verwenden sollten, um RN in eine WEB-Version umzuwandeln?
Ich habe noch nie von dem Ding gehört, aber okay. Aber dann bedeutet das, dass wir nicht mehr material-ui sondern eher eine RN-Gabel?

@NitroBAY Wir portieren material-ui grundsätzlich auf einen RN-Fork und ich denke, wenn es fertig ist, wird es die offizielle Version sowohl für Web als auch für native. Ich denke, es ist in Ordnung, wenn man bedenkt, dass material-ui einen ähnlichen Ansatz mit der nächsten Verzweigung verwendet.

Sorry für all die Noob-Fragen, aber ich lande seit ungefähr 1 Woche in ReactLand .

Sie denken, Ihr Paket wird dieses ersetzen?
Ihr Ansatz scheint plattformübergreifend zu sein und ist daher sehr gut. Material-ui bleibt nur beim Web, weil sie keine Zeit haben, aber sie haben Zeit für das nächste, warum?
Sie sagen, dass next einen isomorphen Ansatz für next aber wenn ich eine beliebige Komponente nehme, z. B. Papier , funktioniert es nur für das Web, da es eine div Komponente gibt.
Wer sind we , sind Sie ein Teil dieses Teams?
Glauben Sie nicht, dass die Verwendung von MD unter IOS die Benutzer ungeachtet technischer Überlegungen verärgern kann?

EDIT: Off-Topic, aber niemand hat mir geantwortet, welche Vorteile bringt jss-theme-reactor im Vergleich zu jss-react ?

@NitroBAY :

1. Ich bin nicht der Entwickler dieses Projekts oder eines React Native-Projekts. Aber ich habe diese Ausgabe monatelang beobachtet und freue mich im Moment darauf, zu react-native-material-ui beizutragen.
2. paper oder das Schattending funktioniert jetzt im Web, iOS, Android. Es ist also keine große Sache.
3. material-ui master Zweig verwendet Objekte, um die Stylesheets zu definieren, aber um die Leistung zu verbessern (30% Steigerung), wechseln die Mitwirkenden im next Zweig zu JSS (CSS in JS). Derzeit ist JSS nicht mit React Native kompatibel.
4. Google verwendet Material Design auf iOS und ich glaube nicht, dass die Benutzer viel dagegen haben. Natürlich sollten Sie einige Teile so ändern, dass sie in die Plattform passen, z. B. die Farbe der Statusleiste ändern, das iOS-Freigabesymbol verwenden usw. Ich habe material-ui für meine Windows 10- und macOS-App verwendet und nicht viele gesehen Benutzer beschwerten sich darüber (http://moderntranslator.com/). Einige sagten sogar, MD sei einfacher zu bedienen.

Aber ich verstehe immer noch nicht, wie der next Zweig in RN funktionieren kann, wenn die Komponenten HTML-Elemente wie span oder div . Ich habe vielleicht etwas übersehen, aber um in RN zu entwickeln, müssen Sie RN-Komponenten verwenden, nicht wahr?
ich zitiere dich:

es wird die offizielle Version sowohl für das Web als auch für die native Version. Ich denke, es ist in Ordnung, wenn man bedenkt, dass material-ui einen ähnlichen Ansatz mit der nächsten Verzweigung verwendet.

Aber vielleicht habe ich es nicht richtig verstanden. Meinen Sie, dass der next Zweig uns in die Lage versetzt, Komponenten in RN zu verwenden?

@NitroBAY : next Branch macht material-ui weniger kompatibel mit React Native. Auch wenn die RN-Komponente span oder div nicht unterstützt, können Sie mit bedingten Regeln Folgendes tun:

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

Sie können überprüfen: https://github.com/necolas/react-native-web

Oh okay, ich dachte du meinst, dass sie RN kompatibel gemacht haben.

Ist der TL; DR, dass dieses Projekt kein Interesse an der Unterstützung mehrerer Plattformen über die React Native API hat und diese Bemühungen nach https://github.com/xotahal/react-native-material-ui verschoben werden sollten

Die Dokumentation für carbon-ui ist besser und funktioniert bereits im Web. Was ist der Vorteil von React-Native-Material-UI?

Also sind sich alle einig, dass material-ui in Kürze nicht mehr verwendet und empfohlen wird? Dann ist es schade, dass Besitzer dieses Pakets keine RN wollen ?

carbon-ui sieht so aus, als würde es Leistungsprobleme geben, wenn StyleSheet und so viele Webfonts eingefügt werden

Beruhigt euch, Jungs! Es kommt noch.

TL;DR: Wenn Sie eine Komponente für React Native erstellen, funktioniert sie auf RN und im Web. Aber wenn Sie eine Komponente für das Web erstellen, funktioniert sie nicht auf RN. Und material-ui ist für das Web gebaut, für das Web optimiert => Damit es auf RN funktioniert, muss die Leistung (zumindest im Moment) geopfert werden. Daher denke ich, dass es besser ist, die beiden Projekte getrennt zu halten, bis RN ausgereifter ist.

optimiert für Web => Damit es auf RN funktioniert, muss die Leistung geopfert werden (zumindest im Moment)

Haben Sie dazu irgendwelche Daten zu teilen?

Hier sind meine bisherigen Ergebnisse für RNW:

• 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, ich kann mir überlegen, StyleSheet mit Uranium zu verwenden. Ich werde sagen, dass ich keine CSS-bezogenen Leistungsprobleme bemerkt habe, aber ich werde sehen, ob ich mich besser in Ihre StyleSheet-Sachen integrieren kann.

Der größte Performance-Hit kommt von Animated: https://github.com/animatedjs/animated/issues/48 Aber das betrifft alle RNW-Anwendungen.

Verringert das Einfügen von Webfonts die Leistung erheblich? Es lädt sie direkt aus Google-Schriftarten, sodass sie wahrscheinlich bereits auf dem System des Benutzers zwischengespeichert sind.

Das Wichtigste, was ich denke, ist, dass sich alle hinter einer einzigen Bibliothek versammeln. Und ich glaube nicht, dass material-ui React Native unterstützen wird.

@necolas Die TL; DR ist, dass der weitere Weg unklar ist .

A=reaktiv-nativ
B=das Internet

1. Die am stärksten eingeschränkte Plattform

Ein möglicher Ansatz besteht darin, auf die am stärksten eingeschränkte Plattform abzuzielen, also ausgehend von reaktiv-nativen . Dann um die Funktionen auf das Web auszudehnen. Um die Funktionen auf das Web auszudehnen, könnten wir Folgendes verwenden:

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

Dies ist jedoch mit einem Kompromiss verbunden, wir würden das Code-Sharing gewinnen. Aber ich erwarte, in einigen Dimensionen zu verlieren.

Die native API ins Web bringen

Die API muss neu implementiert werden, damit sie mit dem Browser funktioniert. Was ist der Overhead?

Umgang mit fehlender Web-API in nativer Sprache

Da wir mit der am stärksten eingeschränkten Plattform beginnen, müssen wir einige im Web verfügbare Funktionen neu implementieren. Wie sieht es mit Medienanfragen aus? CSS-Vererbung, CSS-Animationen?
Wer würden wir Barrierefreiheit und Tastaturereignisse implementieren, ohne die native Version aufzublähen?

2. Die weniger eingeschränkte Plattform

Eine andere Lösung besteht darin, von der weniger eingeschränkten Plattform, also dem Web, zu beginnen. Dann die Neuimplementierung fehlender nativer Features erstellen.

Dies ist jedoch mit einem Kompromiss verbunden, wir würden das Code-Sharing gewinnen. Aber ich erwarte, in einigen Dimensionen zu verlieren.

Bringen Sie die Web-API zum nativen

Wir werden Opfer bringen müssen, ich erwarte, dass einige Webfunktionen wirklich schwer auf native zu implementieren sind, zum Beispiel die CSS-Medienabfragen, die CSS-Animationen. (erweiterte CSS-Regeln)

Umgang mit fehlender nativer API im Web

Einige der fehlenden Web-API-Funktionen sind Touch-Handling, Scrollen und unendliche Listenansicht, native Komponenten wie ein DatePicker oder ein Drawer.

3. Vertragsteilung

Eine dritte Lösung könnte darin bestehen, eine Infrastruktur einzurichten, um APIs und Tests gemeinsam zu nutzen und dann die Komponenten in den beiden zugrunde liegenden Plattformen neu zu implementieren. Aus meiner Sicht ist es, wie sich React-Native iOS und Android nähert.
Verwenden Sie dann einen gemischten Ansatz der beiden vorherigen, um den Vertrag vollständig zu erfüllen. Ich meine, Code-Verzweigung zu verwenden, wenn dies sinnvoll ist, und Code-Sharing so weit wir können.
Zum Beispiel:

• Warum animierte.js im Browser verwenden, wenn wir CSS-Übergänge verwenden können?
• Warum die Drawer-Logik auf reaktiv-native implementieren, wenn wir die native Komponente verwenden können?

Ich denke, dass Option 3 die vielversprechendste ist. So habe ich versucht, das Problem in React-Swipeable-Views zu lösen.

https://github.com/tuckerconnelly/uranium unterstützt plattformübergreifende Medienabfragen :)

Das Schöne an RN ist, dass Sie über eine einfache Bibliothek abstrakter APIs und Primitive verfügen und sich um die Low-Level-Implementierungen kümmern. Animiert ist gleich - einfache Bibliothek für Animationen, Low-Level-Implementierungen (native Animationen auf iOS/Android, CSS-Übergänge im Web) werden berücksichtigt.

Ich denke, animierte.js könnte gejiggert werden, um CSS-Übergänge zu verwenden. Würde die Leistung auf jeden Fall verbessern.

@quaglam2807 dieser Thread ist sehr lang, was sollte ich mir

Um die Funktionen auf das Web auszudehnen, könnten wir Folgendes verwenden: https://github.com/necolas/react-native-web , https://github.com/taobaofed/react-web

react-web ist ziemlich weit davon entfernt, performant oder funktional korrekt zu sein.

Die API muss neu implementiert werden, damit sie mit dem Browser funktioniert. Was ist der Overhead?

Overhead in welchen Dimensionen? In Bezug auf die Bündelgröße schwer zu bestimmen. Sie könnten wahrscheinlich einen Teil Ihres vorhandenen Codes löschen; aber wenn Sie auf etwas über die RNW-Kernexporte hinaus angewiesen sind, summiert sich das schnell. Bei stillastigen Komponenten für mobile.twitter.com habe ich eine Reduzierung der Komponentengröße um 20-40% festgestellt, indem ich Stile von CSS-Modulen in RNW StyleSheet umwandelte. Was die Laufzeitleistung angeht, ist es derzeit

Wie sieht es mit Medienanfragen aus?

Sie können matchMedia , um Stile und Komponentenstruktur zu ändern, obwohl mir die Vorteile der Verwendung von Medienabfragen zum Ändern von Komponenten nicht klar sind.

CSS-Vererbung, CSS-Animationen?

RNW unterstützt CSS-Animationen (obwohl ich eine API hinzufügen muss, um Keyframes zu definieren). Was ist die Frage im Zusammenhang mit der CSS-Vererbung?

Wie würden wir Barrierefreiheit und Tastaturereignisse implementieren, ohne die native Version aufzublähen?

Nicht sicher, was das bedeutet. Ich vermute, dass der Schwellenwert für "Aufblähen" in einer nativen App viel höher ist als bei einer Web-App.

Vielleicht ist es jetzt weniger relevant, zu vergleichen, wie React-Native-Web Stile behandelt, um CSS-Leistungen mit CSS-Modulleistungen zu rendern

Warum sollte das sein?

Es wäre toll, eine Art React-Native-Web zu haben, die so etwas wie Aphrodite oder jss verwendet

Beide Bibliotheken sind langsamer, größer und nicht gut geeignet, um deterministische Stile bereitzustellen

@necolas material-ui bietet einen großen Aufwand, um von einer CSS-in-js-Methode zu einer Stylesheet-Methode (css in <style> ) zu wechseln. Sie bemühen sich seit Monaten aktiv um den Austausch der Komponenten. Gründe sind hier . Von dem, was ich gelesen habe, ist die Verwendung von jss ein großer Vorteil und scheint die bisher perfekteste Lösung für den Umgang mit Stil zu sein.

Übrigens, wenn Sie die Roadmap.md noch einmal lesen, ist der RN-Support auf der Roadmap.

Ich interessiere mich sehr für die Verwendung von Material-UI mit Reactive-Native. Gibt es etwas zum Fortschritt?

@wswoodruff Sie können dies jetzt überprüfen - https://github.com/xotahal/react-native-material-ui

Derzeit haben wir dafür drei großartige Bibliotheken:

• React -native-Material-Kit ★3110 - Materialdesign zu React Native bringen .

• React-Native -Material-Design ★2447 - React-Native-Material-Design-Komponenten

• react-native-material-ui ★1040 - Hochgradig anpassbare Materialdesign-Komponenten für React Native.

Genießen!

Es gibt auch die weniger bekannte Carbon UI, wenn Sie universell sind. Aber für meine Zeit würde ich wahrscheinlich bei einem davon bleiben.

Es wurde in diesem Thread ein paar Mal angesprochen, aber ich möchte es noch einmal erwähnen, weil es mein Interesse an dieser Änderung beeinflusst: Der Hauptvorteil von Reactive-Native-Support, den ich sehe, betrifft nicht React-Native , sondern darauf, auf den Primitiven aufzubauen, die es ermöglichen, dieselben Komponenten _sowohl_ nativ als auch im Web zu verwenden.

Wenn diese Art von Primitiv verwendet würde, könnten auch andere Tools wie React-Sketchup und React-PDF aktiviert werden.

Diese sind für mich persönlich interessanter als native, würden aber durch die gleichen Änderungen ermöglicht.

@jhabdas Wie ist

@deadcoder0904 habe es noch nicht persönlich verwendet. Versuchen Sie wahrscheinlich, einen der Jungs bei unendlich rot zu erreichen. sie betreiben den RN-Newsletter und sollten die Fachexperten sein. ob und wann ich eine weitere RN-App baue (okay, wann ...) Ich werde dieses Mal keine Dinge zusammenbauen oder einen weiteren Boilerplate bauen – IMHO wird der Raum durch vorhandene Boilerplates und Komponenten gelöst.

Hier sind einige der Hürden, die ich mir vorstellen kann, die überwunden werden müssten, um MUI in React Native verfügbar zu machen. Angenommen, v1 MUI und wir behalten JSS, das classes Muster und andere Dinge bei, die zu diesem Zeitpunkt Schlüsselbestandteile des API-Designs von MUI sind.

• JSS muss RN unterstützen, nämlich Stilobjekte so zu erstellen, dass withStyles einfach funktioniert. Mehr dazu unter https://github.com/cssinjs/jss/issues/368#issuecomment -376708219.
• Angenommen, es gibt keine Hacky-Wrapper- oder Babel-Transformation, müssen wir das Muster classes , damit es genauso funktioniert, aber berücksichtigt die Tatsache, dass es auf RN stattdessen ein Array an style pass übergeben sollte , und sollte wahrscheinlich styles heißen. Vielleicht könnte dies gehandhabt werden, indem classnames fallengelassen und verteilte Helfer hinzugefügt werden, die hinter den Kulissen zwischen der Behandlung von Klassen/Klassennamen und Stilen/Stilen wechseln.
  Könnte sein:
  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 würde eine Liste von Stilnamen akzeptieren (und falsche Werte ignorieren). Im Web würde es in props.classes suchen und {classNames} ausgeben. Auf native würde es in props.styles suchen und ein {style} ausgeben.
  Ursprünglich dachte ich an this.composeStyles mit einem Dekorateur, aber stattdessen könnte withStyles einfach einen Stilkompositionshelfer als Teil der Requisiten übergeben.
• Wie andere nach all dem erwähnten, müssen wir zusätzliche Arbeit leisten, damit Animationen, Touchables usw. funktionieren, damit grundlegende gestylte Komponenten funktionieren.
• Für Animationen halte ich dies jedoch nicht für schlecht. Es ist ein kleiner Verlust für einfache Übergänge, bei denen Sie nur opacity , backgroundColor usw. automatisch übergehen. Vielleicht brauchen wir Helfer, die diese einfach halten. Aber von dem, was ich gesehen habe, sehen die tatsächlichen materiellen Übergangsimplementierungen außer diesen übermäßig kompliziert / kryptisch aus und lassen sich nicht gut skalieren. react-transition-group hat einige schöne Ideale für den Umgang mit dem unteren Teil der Dinge (Einstiegs-/Ausstiegsbehandlung usw.), ist aber in anderen problematisch / im Weg. Außerdem denke ich, dass anstelle des auf CSS-Übergängen basierenden Designs der zukunftsweisende Weg darin besteht, die neue Web-Animations-API zu verwenden und dafür das Polyfill zu benötigen.
  Mit anderen Worten, ich denke, es gibt Raum für die Erstellung einer neuen Bibliothek zur Verarbeitung von Animationen in React, die Webanimationen im Browser und die animierte API in React Native verwendet und eine allgemeine Verbesserung gegenüber der Verarbeitung von Animationen durch MUI darstellt.
• MUI muss die Erwartung aufgeben, dass kaskadierendes Verhalten verfügbar ist. Und das Design-Setup muss verbessert werden, um das einfache Anwenden von Änderungen am Design innerhalb eines Unterbaums zu unterstützen.
  Im Moment funktionieren Dinge wie AppBar + Icons, indem sie die Textfarbe festlegen, ein explizites color='inherit' verwenden und davon ausgehen, dass die Farbe nach unten kaskadiert. Und es ist möglich, dass dies in anderen Teilen von MUI genauso ist.
  In React Native gibt es keine solche Kaskadierung. Stattdessen müssen Sie Ihre Stile explizit für jede Ansicht deklarieren. Für diese Art von Dingen AppBar und andere Komponenten müssen in der Lage sein , auf einfache Weise eine modifizierte Version des Themas bieten sie mit einer Modifikation versehen sind , wie das Thema zu ändern in diesem Kontext zu dark erhalten , also Symbole , um das richtigen Kontrast Symbol Farben (und kann auf der tatsächlichen Symbolfarbenspezifikation anstelle der Textfarbe basieren). Beachten Sie, dass dies Auswirkungen auf Dinge wie Menüs haben kann, die in App-Leisten verschachtelt sind.
• Als Erweiterung dieses kaskadierenden Problems. MUI wurde auch um Dinge wie <Button>Text</Button> herum entwickelt, wobei davon ausgegangen wird, dass MUI nur die SchriftartFace/color usw. des Stamms der Schaltfläche formatieren, alles in die untergeordneten Elemente einfügen und React DOM einfügen lassen kann eine Mischung aus Elementen und Textknoten und die Textknoten bekommen das richtige Styling.
  Dies fällt in React Native auseinander. Der gesamte Text muss Teil eines <Text> , alle Textstile müssen sich in den Stilen dieser Komponente befinden und ein Textelement darf keine Nicht-Text-Kinder enthalten (dh).
  Es gibt einige Möglichkeiten:
  
  
  
  • Das Muster <Button text='Text' /> funktioniert in React Native viel besser. Leider unterscheidet sich das grundlegend vom Ethos von MUI, daher ist es keine Option.
  
  
  • Wir könnten die Kinder zuordnen und Strings durch gestylte Textelemente ersetzen. Dies ist jedoch spröde, in dem Moment, in dem Sie die Saite in etwas einwickeln, fällt sie auseinander (selbst Reagieren-Intl würde sie auseinanderfallen lassen). Pfui.
  
  
  • Es ist nicht die schönste Art, es zu tun, wir müssen warten, und ich verstehe die Auswirkungen auf die Leistung nicht zu 100%. Aber wir könnten die neue Kontext-API von React 16.3 verwenden und ein <MuiText>Text</MuiText> . Grundsätzlich hätten MUI-Komponenten wie Button Anbieter, die Informationen über die Stile des aktuellen Kontexts (Schriftart, Textfarbe usw.) bereitstellen würden, und MuiText würde diese Daten einfach verbrauchen und auf ein Textelement anwenden.
  
  

Heute wurde v1 veröffentlicht. Was sind die Pläne von React Native?

Für den Support von React Native Material gibt es eine schöne Bibliothek namens React Native Paper, die vom CallStack-Team gepflegt und unterstützt wird.

Aber gibt es Pläne, dies auf React Native zu portieren, weil ich denke, dass Paper perfekt funktioniert?

Wenn nicht, können Sie dieses Problem wahrscheinlich schließen :)

Danke fürs Teilen von @deadcoder0904. Ich habe Papier zu Awesome React Components hinzugefügt. Ich habe noch nie von CallStack gehört. Zuerst habe ich es als Call-Em-All gelesen. Ich schätze, es sind nicht die gleichen Peeps, ja?

@jhabdas Nein, sie sind nicht gleich

@dantman Hier sind meine Gedanken zum besten Weg, um native Unterstützung zu erreichen

• Wenn das Festhalten an jss keine absolute Voraussetzung ist, denke ich, dass Fela eine praktikable Alternative ist:
  
  
  
  • fela-native unterstützt Medienabfragen und verwendet StyleSheet.create richtig
  
  
  • Es ist wahnsinnig erweiterbar . Wir könnten Regeln für Webeigenschaften in ihre reaktiven nativen Proxys umschreiben, Dinge wie :hover Regeln von nativen entfernen und wahrscheinlich die verlorene Syntax von jss zurückgewinnen.
  
  
• React-native-animable hat Keyframe-Unterstützung und könnte wahrscheinlich auch anstelle von Transition-Group verwendet werden, die mit nativen funktionieren kann oder nicht .
• Ich bin damit einverstanden, die nicht kaskadierende Ansicht von Reaktiv-Native zu untergraben. Es könnte bei Anbieter und Verbraucher mit cascade und inherit Requisiten aktiviert werden.
  Jede reaktive-native Bibliothek, mit der ich gearbeitet habe, war aufgrund zu starrer APIs und nicht überschreibbarer Stile schmerzhaft oder unbrauchbar, mit Ausnahme von denen, die @shoutem/theme , um Überschreibungen zuzulassen (wie native-base). .

Warte immer noch auf diese Unterstützung. Schön im Web verwenden, aber ich entwickle auch auf Mobilgeräten!

irgendein Update zum Support reagieren nativ?

@oliviertassinari Ich beabsichtige, den oben beschriebenen Implementierungspfad

@micimize Danke, dass du es mir

Update dazu: Wir haben einen wesentlichen Teil der Funktionalität in einen einigermaßen brauchbaren Zustand überführt, einschließlich Listen, Schaltflächen, Karten, Symbole, Auswahlsteuerelemente, Textfelder und Hintergrund. Als wir unsere App endlich selbst auf Reactive-Native entwickelt haben, tauchten leider eine Vielzahl von Problemen auf und zwangen uns, zu Flutter zu wechseln.

Irgendwann würde ich gerne zurückgehen und etwas von unserer Arbeit retten, hauptsächlich die Portierung der withStyles / classes Styling-Lösung, die CSS-Shorthand-Eigenschaften und einige andere nette Sachen nutzte, aber das hat keine Priorität mehr Für mich.

@rogerstorm finanzierte dieses Problem mit 200 US-Dollar. Sehen Sie es auf IssueHunt

Die Bearbeitung des Problems wäre für uns Opportunitätskosten. Ich schließe. Wir werden die Browser-Anwendungsfälle besser unterstützen.

@oliviertassinari , bedeutet dies, dass der native Support von

ja

https://github.com/lightningtgc/react-native-material-ui Ist nichts anderes als ein weiteres betrügerisches npm-Paket