Einige weitere Fragen:
6) Werden wir xxxxStyle Requisiten entfernen oder darauf abzielen, diese zu entfernen, und die Benutzer ein xxxClassName für das Überschreiben von Stilen übergeben? Oder werden diese kostenlos sein?
7) Ermöglichen wir das Überschreiben von Stilen über CSS und vereinfachen die Schnittstellen unserer Komponenten. Wenn ich also menuItemStyle in IconMenu überschreiben möchte, erstelle ich eine Überschreibung vom Typ style = StyleSheet.create({ IconMenu: {MenuItem: { color:red }}) ?

@chrismcv Meine persönliche Meinung ist, dass wir definitiv die Lösung nutzen müssen, um diese superspezifischen Requisiten zu entfernen, die wir vorgeschlagen sehen: [TextField] floatLabelFocusStyle prop # 4043 hinzufügen

Bevor wir es wissen, werden die Leute nach Requisiten für Unterkomponentenstile für jeden möglichen Fokus / Aktiv / Schweben / welchen Zustand auch immer fragen.

Ich sehe so viele Probleme, die lauten: "Wie man XXXX stylt", "XXX kann man nicht in JJJJ stylen", "Bitte fügen Sie somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle prop zu XXX hinzu".

@chrismcv in 6. Was denkst du über die allgemeineren xxxxStyle Requisiten gegen Klassennamen? Bei einigen unserer Komponenten müssen Sie auf die eine oder andere Weise erreichbar sein (zum Glück können wir jedoch :hover usw. verwenden!).

@chrismcv Ich denke, dass xxxxStyle Requisiten in die Eigenschaft style gehen sollten, nicht in das Objekt className .

@ Nathanmarks Danke, dass gebootet hast . Dies ist definitiv eines der Hauptprobleme, die wir für die nächsten Versionen angehen müssen 💯.

Außerhalb von Leistungsproblemen

Für mich ist das eines der Hauptanliegen, die ich bei der Lösung habe, die wir wählen werden.
Wir haben nicht viele Benchmarks, wir können uns leicht vorstellen, dass wir mit unserem aktuellen Ansatz viele CPU-Zyklen verloren haben. Die CPU-Zyklen gehen in Speicherzuordnungen und Speicherbereinigung für unser Inline-Objekt verloren.

@oliviertassinari

Ich spiele gerade mit ein paar Lösungen im JS-Stil. Es ist interessant, aber klar, dass es sozusagen noch "frühe Tage" sind.

Eine Sache, an die ich gedacht habe: Sollten wir außerhalb der dynamischen Stileigenschaften (z. B. wenn die Komponente eine color -Stütze hat) die Art und Weise ändern, wie wir das Basisstilobjekt erstellen?

Es scheint, als ob Sie mit den Bibliotheken im JS-Stil einmal die Methode StyleSheet.create() verwenden sollten, um maximale Leistung zu erzielen, und Schlüssel (CSS "Klassen") in diesem Objekt für Requisiten / Zustände wie open={true} Anstatt das Stilobjektliteral dynamisch mit einigen bedingten Eigenschaften zu erstellen und es an die Stylesheet-Factory-Methode zu übergeben, wird jedes Rendering für jeden einzelnen Stil ausgeführt.

Obwohl die Stylesheet-Selektoren in dem Sinne zwischengespeichert werden, dass sie nur einmal in das DOM geschrieben werden (und in einigen Bibliotheken nur dann in das DOM geschrieben werden, wenn dies für render() ), verschwenden wir dennoch Ressourcen mit einigen Berechnungen + Objekterstellung + Speicherbereinigung, wie Sie oben erwähnt haben, wenn wir bei jedem Rendern ein neues Stilobjekt erstellen, nur um es wegzuwerfen.

Hmmm ... Ich habe gestern (Sonntag) hier einen Kommentar hinterlassen. Wurde es gelöscht?

@rvbyron Ich erinnere mich deutlich daran. Ich habe es aber sicher nicht gelöscht.

@rvbyron Ich erinnere mich auch daran. Ich habe keine Ahnung, was passiert ist.

@rvbyron - hatte es in meiner E-Mail, also wieder hier in zitierter Form!

Nun, ich würde gerne sehen, dass eine Reihe von Dingen stattfinden.

A) Ja, auf jeden Fall müssen Sie den Stilparameter des Elements auf Bibliotheksebene nicht mehr verwenden. Alle Komponenten sollten mit className definiert werden. Wenn die Komponenten Stil verwenden, werden alle Power-CSS-Angebote zerstört.
B) Es wäre großartig, wenn classNames automatisch an das Stammelement jeder Komponente angehängt würde (z. B. hätte die RaisedButton-Komponente implizit className = "mui-raise-button" am Stammelement der Komponente). Es würde das Styling viel einfacher machen. Das könnte sogar konfigurierbar sein.
C) Holen Sie sich Themen aus den muiTheme.js-Dateien insgesamt. Eine Theming-Datei muiTheme.SCSS wäre insofern viel besser, als alle vom Theme-Ersteller ausgewählten Eigenschaften angewendet werden könnten und nicht nur die von der Komponente speziell zugelassenen. Natürlich würde dies wahrscheinlich erfordern, dass B implementiert und aktiv ist.
D) React-Look scheint ein guter Kompromiss zu sein, da JSON-Objekte mit Stileigenschaften in classNames konvertiert werden. Es erleichtert das Überschreiben. Wie ich oben in C sagte, möchte ich dennoch, dass die Themenbasis in SCSS erstellt wird. Ich bin ziemlich offen, welches CSS-Hilfspaket ich verwenden soll. Aber ich würde mich von allem fernhalten, der den Stilparameter des Elements über den Parameter className verwenden wollte.

@chrismcv Danke Kumpel!

Ich denke, dass das, was @rvbyron zu sagen hat, wichtig ist, da das JS-Styling in gewisser Weise ein Paradigmenwechsel gegenüber nicht mit JS Styling in ihrem Job , und es erfordert eine andere Denkweise + es schwieriger für Designer machen die in der Regel zu den Projekten beitragen können , die in JS nicht so mächtig sind.

Es ist wichtig, alle Winkel hier zu berücksichtigen.

@oliviertassinari @chrismcv

Eine Sache, die mir bei react-look klar wurde, ist, dass Sie alle Ihre Komponenten in das look HoC einwickeln müssen . Dies scheint ziemlich invasiv zu sein, es entführt sogar die render() -Funktion, speichert super.render() in einem const und führt auf diese Weise Stilauflösungsoperationen durch. Einige andere Lösungen wie Khan / Aphrodite erfordern lediglich einen Funktionsumbruch um die styles.xxxx Referenz von Stylesheet.create() innerhalb von className={} .

Die Entführung der render() -Funktion nur für CSS scheint mir überentwickelt. Es sagt mir, dass die in React integrierte Tooling / Unterstützung für diese Art von tief integrierten Stilfunktionen einfach nicht vorhanden ist. Ich bin mir nicht sicher, ob ein CSS-Helfer HoC das Rendering für alle unsere Komponenten steuert.

Gedanken?

Hallo Material-UI-Team!

Ich verfolge Sie schon eine Weile und jetzt, als ich dieses Thema sah, wollte ich auch mit einigen Gedanken dazu beitragen, warum der Wechsel von Inline-Stilen zu CSS eine gute Idee sein könnte. Ich habe in diesem Repo viele Diskussionen gelesen, die sich mit der Renderleistung, dem Styling von untergeordneten / verschachtelten Elementen, den Medienabfragen, Pseudoelementen usw. befassen. Daher werde ich mich auf etwas anderes konzentrieren, das ich noch nicht besprochen habe. was ich aber auch für relevant halte. Und es ist Stilorganisation. Folgendes meine ich:

• Einige Stile stammen aus den Komponentenstandards (die im Knotenordner festgelegt und nicht berührbar sind).
• Einige stammen aus Komponentenparametern (zum Beispiel setzt der Avatar-Komponentenparameter size={40} Breite, Höhe und Zeilenhöhe auf 40px )
• Wenn die Komponentenstandards angepasst werden (die Themenfarben), stammen die Stile vom Ort der Themenanpassung
• Wenn der Rest der Komponentenstile geändert wird, stammen die Stile aus einer Komponentenimplementierung, die ein weiterer Teil des Codes ist

Wenn es darum geht, die Stile anzupassen, müssen mindestens 4 verschiedene Positionen (👆) angezeigt werden, was es schwierig macht, Probleme zu untersuchen.

Wenn Stile mit CSS geliefert werden, wird der Selektor angezeigt und Sie wissen genau, wo Sie Fehler beheben müssen. Bei Inline-Stilen dauert es einige Zeit, um zu verstehen, woher die jeweilige Eigenschaft stammt und wo und was geändert werden sollte. Und wenn der Entwickler es an der falschen Stelle ändert (sagen wir im Bereich styles anstelle des Parameters size , da nichts tatsächlich sagt, dass size der Stil ist), wirkt sich dies auf den aus ganze width=height=line-height=40px blockieren die Leistung oder führen dazu, dass width/height/line-height wird, wodurch der Parameter size anwendbar ist.

Darüber hinaus ist es schwierig zu untersuchen, auf welche der übergeordneten Elemente bestimmte Eigenschaften angewendet wurden, da im Inspektor nur element.style .

Wenn Stile mit Selektoren (Klassennamen) geliefert werden, können Sie die Stilstruktur wesentlich besser steuern als Inline-Stile.

Update: Ich habe vergessen, den Vorschlag zu erwähnen (um den es in diesem Thema geht):

/component
--component.js
--component.css (or sass that is converted to css when the page is rendering)

Diese Struktur behält die Komponente im Bereich bei, bietet jedoch mehr Kontrolle über das Styling. Eine BEM className-Konvention hilft dabei, unnötige Verschachtelungen zu vermeiden:

.mui-component {}
.mui-component__child {}

Welcher insgesamt hilft bei der Implementierung, Anpassung und Pflege von Material-UI-Stilen.

@chrismcv

Vielen Dank, dass Sie die E-Mail gefunden und in den Kommentar eingefügt haben!

Das Beste aus beiden Welten Verhaltensansatz?

Was ist mit einem "Verhaltens" -Konzept zum Importieren der Styling-Technik, die Ihren Anforderungen am besten entspricht? Ein Import von "StyleTheme" oder "ClassTheme" könnte verwendet werden, um das Verhalten auszuwählen. StyleTheme könnte sich auf das heutige muiTheme-Objektmaterial-ui beziehen und die komponentenorientierten Styling-Entwickler glücklich machen. Oder ClassTheme, das eine SCSS-Datei verwendet, die aus dem Objekt muiTheme.js (synchronisiert) erstellt wurde, was die CSS-zentrierten Entwickler glücklich macht. Das würde bedeuten, dass alle Komponenten dann {... theme.ComponentName} in den Renderelementen aufnehmen müssten.

Um ein sehr vereinfachtes Beispiel anzubieten, hätte eine RoundButton-Komponente die folgende Rendermethode:

render() {
    return (<button {...theme.RoundButton} />);
}

Für das StyleTheme-Verhalten würde theme.RoundButton Folgendes enthalten:

{ 
    style: {
        display: 'inline-block';
        borderRadius: '20px';
        width: '40px';
        height: '40px';
    }
}

Für das ClassTheme-Verhalten würde theme.RoundButton Folgendes enthalten:

{ 
    className: 'mui-round-button'
}

Eine Kombination der beiden könnte als ClassStyleTheme-Verhalten theme abgerufen werden. RoundButton würde beides enthalten:

{ 
    className: 'mui-round-button',
    style: {
        display: 'inline-block';
        borderRadius: '20px';
        width: '40px';
        height: '40px';
    }
}

Die Datei mui-theme.scss wird aus der Datei muiTheme.js generiert und spiegelt in SCSS die genauen Eigenschaften der JS-Datei wider. Das Kamelgehäuse der JS-Namen würde in Standardklassennamen konvertiert:

mui-round-button {
    display: inline-block;
    border-radius: 20px;
    width: 40px;
    height: 40px;
}

Jede CSS-Anpassung an die MUI-Komponenten besteht einfach aus identischen Klassen, die nach dem Laden der Datei mui-theme.scss geladen wurden, wodurch die Eigenschaften des mui-Themas überschrieben werden.

@oliviertassinari

Ich denke, dass die Verwendung von scss (+ CSS-Module für Namespace / Hashing) viele Vorteile hat. Sind Sie zu 100% dagegen? Ich bin wahrscheinlich etwas voreingenommen, weil es das ist, was ich bei der Arbeit gewohnt bin, aber viele Leute sitzen im selben Boot.

Mein Hauptproblem bei der JS-Styling-Situation ist, dass alle Lösungen noch in Arbeit sind. Es gibt nicht viele reale Leistungsbewertungen, die wir uns ansehen müssen. Die Bibliotheken, die wir uns ansehen, sind nicht bewiesen, und ich habe das Gefühl, dass wir viel Zeit damit verbringen, herauszufinden, wie man Stile in JS richtig macht. Das Hauptziel dieser Bibliothek ist die Implementierung der Materialdesignspezifikation, und ich kann nicht anders, als das Gefühl zu haben, dass dies uns im Moment behindert. (Wir müssen auf jeden Fall die Perf Impact-Probleme lösen)

Ich denke, wir haben diesbezüglich unterschiedliche Bedenken.

1. Wo sollen die statischen Stile abgelegt werden (einfach, eine CSS-Datei kann dies tun)
2. So wechseln Sie einige Stile je nach Eingabe (className-Schalter)
3. So wenden Sie dynamische Stile an (Inline-Stile können das)

Alles scheint gut zu sein, wenn Sie eine Anwendung schreiben. Niemand außerhalb Ihres Codes muss etwas ändern.

Aber bei Bibliotheken sind die Dinge anders, alle oben genannten Bedenken sind da, plus die folgenden:

1. Wie können Benutzer die statischen Stile anpassen?
2. Wie kann man ein Thema so implementieren, dass es einfach zu wechseln, anzupassen und zu isolieren ist (verschiedene Teilbäume, verschiedene Themen)?
3. Wie kann vermieden werden, dass der globale Namespace verschmutzt wird, damit wir gut mit anderen spielen können?
4. Wie können die Benutzer die eingebetteten dynamischen Stile überschreiben?
5. Transformer! (RTL, Präfix usw.)

Was wir gerade haben, behandelt irgendwie all diese Bedenken mit diesen Vorbehalten:

1. Performance!
2. Tief verschachtelte Komponenten sind schwer anzupassen, wie @nathanmarks sagte: somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle
3. Wir können die Leistung einiger CSS-Funktionen nicht nutzen.

Wenn wir unseren Styling-Ansatz ändern, müssen wir alles noch einmal machen. In diesem Fall sollten wir alle Fragen beantworten, bevor wir mit der Migration beginnen.

Meiner bescheidenen Meinung nach denke ich, dass CSS und was auch immer sich daraus zusammensetzt, nicht Teil der Zukunft sind. Ich denke, wir sind uns alle einig, dass Inline-Stile unser Leben viel einfacher gemacht haben. Ehrlich gesagt, die einzige Einschränkung, die ich bei Inline-Stilen sehe, ist :hover !

Wir können diese Probleme mit ein bisschen Design lösen.

1. Speichern Sie das Stilobjekt. Für Komponenten mit Status können Sie den Status aufschlüsseln und in eine kleinere Komponente einfügen, damit das darin enthaltene Stilobjekt basierend auf den übergebenen Requisiten gespeichert werden kann, die den Status der höheren Komponente darstellen. Das ist leicht lösbar!
2. Zerbrich sie! Warum haben wir ein ListItem mit vielen kleinen Funktionen? wir können es zerlegen und zusammensetzbar machen, dann müssen wir keine Monstrositäten wie somethingInsideToTheLeftButSlightlyMiddleFocusHoverActiveStyle hinzufügen
3. meh! Alles, womit wir Leistung erzielen, ist :hover Ich denke, wir können damit leben, bis Browser oder Reaktionen etwas dagegen tun.

Mein Punkt ist, dass wir mit unserem aktuellen Styling-Ansatz bereits eine Vielzahl von Bedenken ansprechen. Es gibt Einschränkungen, da wir nicht allen Mustern rund um Inline-Stile folgen. Wenn wir anfangen, unsere Komponenten zu zerlegen und sie viel komponierbarer zu machen, müssen wir uns um nichts wirklich kümmern. take MeuItem Ich habe das herausgenommen und es zusammensetzbar gemacht. Sie sehen, wie einfach es zu verwenden ist und wie die Leistung mit reinem Rendering verbessert werden kann!

Anstatt also unseren Ansatz zu ändern und all diese Probleme erneut zu lösen, investieren wir die Zeit in die Verbesserung dessen, was wir bereits haben. Wir müssen keine Medienabfragen unterstützen, sondern können unsere Komponenten so ändern, dass andere sie problemlos reagieren können. Schwer zu debuggen? Wenn wir unsere Komponenten aufteilen, sind die Inline-Stile kleiner und leichter zu lesen. umstritten! Ich meine, alles, was Sie brauchen, ist ein Haltepunkt, um zu sehen, was an Object.assign zu sehen, woher die Stile kommen.

Das ist natürlich meine eigene Meinung. Ich bin sehr offen für Diskussionen.

@ Alitaheri

Sie sprechen einige großartige Punkte an. Vielen Dank. Ich frage mich, ob eine Art Hybridlösung möglich ist. Es scheint, dass es unabhängig von unserem Blickwinkel eine Reihe von Problemen gibt 😆

Ich habe nächste Woche Zeit, daran zu arbeiten. Lassen Sie uns ein Gespräch führen und sehen, ob wir eine clevere Idee haben.

Ich bin damit einverstanden, das Ausmaß der Änderungen zu minimieren und bereits gelöste Probleme neu lösen zu müssen. Ich habe hier zwei wichtige Ziele:

1. Performance
2. Entwicklererfahrung (Bibliotheken im JS-Stil helfen hier sehr, da Entwickler problemlos Klassen in ihren Anwendungen verwenden können)

Ich muss mehr darüber nachdenken 😄 aber solange wir es schaffen, diese 2 Punkte zu lösen, werde ich mit unserer Lösung zufrieden sein.

Noch eine zufällige Anmerkung - es wäre großartig, wenn wir eine automatisierte Möglichkeit hätten, bestimmte Codekonventionen und Entwurfsmuster für Inline / jsstyle / was auch immer in der gesamten Bibliothek durchzusetzen.

Sind Sie zu 100% dagegen?

@nathanmarks Ich bin nicht zu 100% gegen SCSS (_Ich benutze es bei der Arbeit_). Aber aus meiner Sicht ist es eine Sackgasse .
Einer der Hauptvorteile von React besteht darin, die Rendering-Spezifität von Browsern zu abstrahieren: das DOM.
Soweit ich weiß, besteht das langfristige Ziel des React Core-Teams darin, eine API zum Schreiben plattformübergreifender Komponenten bereitzustellen. Derzeit experimentieren sie in diese Richtung. SCSS wird nicht helfen.

Ich stimme @alitaheri voll und ganz zu. Wir könnten mit diesen beiden Schritten beginnen:

• Verwenden Sie das getStyles -Muster überall, damit wir später einfacher migrieren können.
  Werden wir in der Lage sein, ein Codemod zu verwenden? Wer weiß.
• Aufschlüsselung jeder Komponente wie von @alitaheri vorgeschlagen.

@oliviertassinari Ich stimme der Sackgasse zu - es ist nicht die Zukunft. Ich habe es weitgehend angesprochen, um die Konversation darüber anzuregen, wie JS-Stile für uns funktionieren. Ich wusste, dass einige Leute hier gute Ideen zu den Themen hatten. Ich wünschte, FB wäre mit ihren Experimenten ein kleines Stück weiter!

Ich denke tatsächlich, dass das getStyles() -Muster, das wir derzeit verwenden, seine eigenen Probleme hat. @alitaheri und ich haben uns heute ziemlich gut darüber unterhalten, was zu tun ist, um unser JS-Style-Setup zu verbessern (einschließlich Theming!). Ich werde morgen mit weiteren Informationen antworten, sobald ich die Gelegenheit habe, einige Notizen zu machen!

Nächste Woche bin ich im Urlaub und werde mit einer Lösung für unsere aktuellen Probleme experimentieren, während alle Stile JS-basiert bleiben.

Lesen Sie einfach diesen Beitrag über Lessons Learned At React Amsterdam (https://medium.com/@kitze/lessons-learned-at-react-amsterdam-51f2006c4a59#.o12h794or) und eine der Präsentationen befasste sich mit Lösungen für das Styling in React: http : //slides.com/kof/javascript-style-sheets#/ Eine zeitnahe Präsentation für diese Diskussion.

Eine Anforderung, über die ich immer wieder nachdenke und die ich nicht explizit angegeben habe (zumindest erinnere ich mich), ist die Notwendigkeit, nur Web vs. Web zu unterstützen und nativ zu reagieren. Wenn die Absicht nur im Internet besteht (dh eine native Reaktion ist nicht erforderlich), sind Lösungen eine gute Sache, die das nutzen, was Browser bereits effizient und robust unterstützen und die Menschen sehr vertraut sind. Wenn die Unterstützung von React Native ein Muss ist, eröffnet dies andere Bedürfnisse und Anforderungen. Nur etwas zum Nachdenken und Denken, wenn die Technologieentscheidungen, Kompromisse usw. bewertet werden.

@ Burrows

Vielen Dank für das Teilen dieser Präsentation!

@ Alitaheri

Wir möchten uns vielleicht die in dieser Präsentation erwähnte Bibliothek ansehen ( hier ist eine Demo ). Das könnte uns viel Arbeit ersparen. Ich habe es mir vorher angesehen, aber es gab ein paar Dinge, die mir nicht gefallen haben (wie die Anforderung, jede einzelne Komponente in ein proprietäres HoC zu verpacken). Es gibt jedoch einige Diskussionen darüber, was hier passiert . Er erwähnt, dass die Implementierung solcher Änderungen eine HoC-freie Nutzung ermöglichen würde. Ich bevorzuge diese Methode / dieses Design für das Schreiben von Blättern (auch in aphrodite ).

Alternativ könnten wir immer unsere eigenen Reaktionsbindungen für jss erstellen, die mit mixout funktionieren können.

Der lib-Autor sagte dies auch, was meinen eigenen Gedanken zu diesem Thema entspricht 👍:

Sie müssen jedoch verstehen, dass nicht alles Sinn macht, Stylesheets zu sein. Für die dynamischsten Änderungen sollten Sie Inline-Stile verwenden.

@nathanmarks Die Implementierung ist eher sehr klein und sehr einfach zu mischen: grinsen:
https://github.com/jsstyles/react-jss/blob/master/src/index.js
Ich denke, diese Bibliothek kann uns helfen: +1:

@alitaheri Ja, ich stimme zu!

Ich experimentiere auch mit einigen benutzerdefinierten Bindungen für jss - es gibt einige Probleme / Einschränkungen, die ich angehen möchte. (Man muss jedoch möglicherweise an der Kernbibliothek arbeiten.)

In der React-Community scheint die Meinung vorherrschend zu sein, dass JavaScript-Styling die beste Lösung ist. Dieses Gefühl ist in Ordnung, ich bin nicht anderer Meinung als diejenigen, die es haben. Die Art und Weise, wie das JavaScript-Styling implementiert wird, ist jedoch fast immer unabhängig vom CSS-Entwickler. Die Implementierung bevorzugt allzu oft style=/[element property]= gegenüber className= und verhindert, dass der CSS-Entwickler seine Arbeit erledigt.

Wie ich in einem früheren Kommentar angeboten habe, denke ich, dass die beiden gut zusammenleben könnten. Man muss einfach einen Verhaltensansatz wählen, um die Stileigenschaften anzuwenden. Die Bibliothek muss die direkte Anwendung von Stileigenschaften auf ein Element ermöglichen oder den indirekten Ansatz zum Erstellen eines Klassennamens ermöglichen, der aus diesen Stileigenschaften besteht. Eine Bibliothek, mit der der Entwickler das Verhalten auswählen kann, scheint eine ideale Lösung zu sein.

Es gibt viele Gründe, warum CSS-Entwickler ihren Ansatz nicht einfach aufgeben wollen. Suchen Sie nach "Warum verwenden Sie CSS?", Um herauszufinden, warum die Leute es nützlich finden. Sie werden feststellen, dass die Abstraktion von Stilen und eine leistungsstarke Auswahlsprache zu den Vorteilen zählen. Vergessen wir nicht die enorme Menge an Code, die heute für CSS-Benutzer verfügbar ist.

Auch dies ist keinesfalls als Pro-CSS-Kommentar gedacht. Einige von uns möchten CSS für das Styling verwenden. Dieser Kommentar soll einen architektonisch neutralen Stilansatz fördern, der Entwicklern die Wahl lässt.

@rvbyron Einer der Hauptgründe, warum wir unseren aktuellen Ansatz ändern möchten, besteht darin, die Anpassung der Komponenten auch mithilfe von CSS zu vereinfachen. Wenn Sie eine Bibliothek wie jss verwenden, können Sie die CSS-Funktionen verwenden und gleichzeitig die Vorteile von js-Styles nutzen. Und da diese Stile in CSS umgewandelt werden, können sie ohne den hässlichen Hack !important leicht mit einem zusätzlichen Klassennamen überschrieben werden.

@alitaheri Schön zu hören! Ich freue mich sehr darauf, dass material-ui einen auf className basierenden Ansatz unterstützt.

Wieder fantastisch, um über den className-Ansatz zu hören. Vor diesem Hintergrund habe ich einige Fragen, wie es implementiert werden könnte:

• Wie könnte die Namenskonvention für Klassennamen Ihrer Meinung nach aussehen?
• Werden alle Klassennamen ein "mui-" oder ein anderes Präfix haben?
• Wird die Klasse eine Strichnotation des Komponentennamens sein?
• Wird ein Klassenname auf das Stammelement jeder Komponente angewendet?

@rvbyron

Im Idealfall:

Anpassbares Präfix. Eine Art Dash-Notation für eine bessere Entwicklererfahrung und ein Hash-Suffix, das auch mit einer benutzerdefinierten Design-ID auf eine feste Zeichenfolge gesetzt werden kann (ändert sich also nicht, wenn die Designeinstellungen geändert werden). Einschließlich einer weniger ausführlichen Produktionsoption oder sogar einer Rückruffunktion zum Anpassen. Und ich würde annehmen, dass eine Klasse an der Wurzel normalerweise sowieso immer notwendig sein wird.

Ich denke, es sind viele Anforderungen aufgeführt und Vorschläge angeboten. Gibt es eine Möglichkeit, all diese Diskussionen zu beenden? Was ist die nächste Vorgehensweise? Gibt es irgendwelche Arbeiten zur Implementierung von React-JS in diese Material-Benutzeroberfläche?

@rvbyron Ja , wir experimentieren hinter den Kulissen mit ein paar groben Ideen. Wird dieses Problem aktualisieren, wenn wir konkretere Ideen haben.

Meiner bescheidenen Meinung nach denke ich, dass CSS und was auch immer sich daraus zusammensetzt, nicht Teil der Zukunft sind. Ich denke, wir sind uns alle einig, dass Inline-Stile unser Leben viel einfacher gemacht haben. Ehrlich gesagt, die einzige Einschränkung, die ich bei Inline-Styles sehe, ist: Hover!

Das Problem ist: Schweben ist ein sehr grundlegender, sehr wichtiger Teil von Stilen. Abgesehen vom Futurismus kann es ratsam sein, vorzeitiges Engagement für eine Lösung zu vermeiden, die auf Cheats und Workarounds zurückgreifen muss, um eine native Funktion erneut zu implementieren.

@wtgtybhertgeghgtwtg Wir arbeiten an einer Lösung, die echte Stylesheets verwendet, sodass Funktionen wie :hover unterstützt werden.

Gibt es eine Roadmap und einen Zeitplan für die Veröffentlichung von material-ui v0.16.0, da die wichtigsten Punkte festgelegt wurden (JSS-Stil über className und root-Element classNames)?

@rvbyron Wir haben keine versprochene Zeitachse, aber ab sofort stehen Styling-Ansatz und Leistung im Vordergrund der Version 0.16.0 und daran arbeiten wir derzeit aktiv. Wir werden dieses Problem wahrscheinlich in naher Zukunft für Community-Feedback verwenden, sobald wir uns in einigen anderen Bereichen in Bezug auf Interna, API, Migration usw. auf die richtige Richtung festgelegt haben.

@ Newoga Danke Neil! Ich freue mich über das Update. Was die anderen Probleme betrifft, möchte ich hinzufügen, dass der Wechsel zu einem className-basierten System für viele eine visuell bahnbrechende Änderung sein kann, und ich würde vorschlagen, diese Version auf genau das zu beschränken. Darüber hinaus können andere Änderungen eine Migration wirklich behindern. Ich weiß jedoch, dass Ihr Team die beste Balance finden wird.

@newoga hier drüben wurde jss als die Zukunft des Styling-Systems für Material-UI bezeichnet. Ist dies ein Plan, der konkret genug ist, damit andere in Erwartung der Veröffentlichung von 16.0 jetzt damit beginnen können, jss in unsere Projekte einzubeziehen?

@sorahn noch nicht

@sorahn Dieses Problem wurde entwickelt, um Community-Feedback zu erhalten, was immer noch ein wirklich herausforderndes Problem ist. Es wurden keine offiziellen Entscheidungen getroffen. Ab sofort sollte jeder nur eine Stilbibliothek oder einen Stil auswählen und verwenden, den er bewertet hat und der für ihn und sein Projekt am besten ist.

Das Ziel dieser Stiländerung ist nicht, alle auf einen anderen Standard zu migrieren, sondern die Verwendung und Gestaltung von Material-UI-Komponenten zu vereinfachen, unabhängig davon, welchen Stilansatz Sie damit verwenden.

tl; dr Nein! Tu was für dich am besten ist, nicht was andere sagen :)

@nathanmarks @newoga Danke für das Update!

Wir stoßen bei allen Inline-Stilen auf die Einschränkungen von Responsive Design + serverseitigem Rendering und untersuchen daher die Alternativen. Keine besonders starken Meinungen über CSS-Module oder CSX oder was auch immer, aber wir lieben Material-UI, also wäre es großartig, einfach mitzumachen, was auch immer ihr tun werdet :)

Ich bin auf Medienabfragen gestoßen, habe diesen Thread (und andere) gelesen. Ich ging auf einige der möglichen Lösungen und Artikel ein.

Ich mag die JSS + CSX-Lösung wirklich (aus der Sicht eines Entwicklers).

JSS Vorteile & Leistung

Ähnlich wie bei @sorahn würde ich gerne einen Material- UI -Standard übernehmen. Ich hoffe, @nathanmarks in dieser Richtung diesen Ansatz bestätigt. Es scheint auch, dass beide CSX / JSS-Entwickler bestrebt sind, die Akzeptanz ihrer Bibliotheken zu unterstützen und zu fördern.

@rosskevin Wir arbeiten daran, während wir sprechen - hier gibt es Dinge zu beachten, die in keiner der bisherigen Lösungen behandelt wurden.

Unsere Anforderungen sind viel breiter als die vorhandenen Lösungen, die aufgrund von Designbeschränkungen oder Meinungen unterstützt werden können. Dies liegt hauptsächlich daran, dass die vorhandenen Lösungen für Apps entwickelt wurden, bei denen Sie die volle Kontrolle über den Verbrauch Ihrer Komponenten-APIs haben, im Gegensatz zu einer Bibliothek, in der verschiedene Benutzer ihre Komponenten mit verschiedenen Tools formatieren möchten.

@sorahn Kurze Frage - Was machen Sie mit Herstellerpräfixen beim serverseitigen Rendern? Rendern Sie nur alle Präfixe auf dem Server? Oder passieren Sie die UA?

@nathanmarks Wir senden den Benutzeragenten an den Browser, aber ich persönlich mag es nicht, mich darauf zu verlassen. Wie wäre es, wenn Sie sie alle standardmäßig einfügen und den Benutzern erlauben, sie über Requisiten auf dem muiTheme-Objekt oder im Gegenteil zu überschreiben? Führen Sie standardmäßig keine aus und lassen Sie die Benutzer sich anmelden.

muiTheme: {
  // other stuff...
  stylePrefixes: ['webkit', 'moz', 'ms']
}

@sorahn Sie können tun, was Sie wollen, Präfix, nicht Präfix, all , eine UA übergeben usw.

@ Nathanmarks Ich habe gerade [email protected] veröffentlicht. Wichtigste Änderung - Generierung der deterministischen ID. Hier ist ein Beispiel für ssr mit der Reaktion http://jsstyles.github.io/examples/index.html

Ich werfe hier nur meine $ .02 ein ... obwohl mir die Idee von Inline-Stilen und Aphrodite gefällt, fühlt es sich fast so an, als wäre es einfacher, wenn die Stile in einem Bibliotheksformat in scss wie Bootstrap 4 basieren würden.

Normalerweise kopiere ich buchstäblich die Datei bootstrap.scss und die Datei _variables.scss, während ich eine Datei _mixins.scss erstelle. Mit dieser Kopie unter ./lib/style aktualisiere ich die lokale Datei bootstrap.scss, um auf die lokale Datei zu verweisen Variablen und Mixins, während Sie den Pfad zu den Versionen von node_modules von allem anderen verwenden ...

Anschließend richte ich meine Webpack-Konfiguration so ein, dass ./lib/style Teil des Suchpfads für die sassLoader-Konfiguration ist.

Auf diese Weise kann ich eine main.scss-Datei haben, die Bootstrap usw. lädt. Ich kann von dort aus Referenzvariablen und / oder Mixins innerhalb des restlichen Projekts verwenden, und wenn ich die Ausgabe erstelle / bündle, sind die entsprechenden Stile inbegriffen.

Der Nachteil dabei ist, dass die Verwendung von material-ui als Quelle (nicht vorab erstellt) und Webpack für die Aufnahme von scss in die Bundles vorgeschrieben ist. Das heißt, es wäre wahrscheinlich der einfachste Weg, vorhandene Variablen, Klassen und Styling-Mixins zu verwenden.

Auch hier gefällt mir die Idee des JS-Stylings sehr gut und ich mag das, was Aphrodite zu bieten hat ... Ich habe etwas Ähnliches (wollte es Derma nennen) als Styling-Bibliothek für Inline-Styles durchgearbeitet, aber Aphrodite macht bereits alles, was ich tue geplant und mehr.

Ist die Styling-Lösung fertiggestellt?

Gibt es Updates dazu?

Ja, der Zweig next verwendet jss

Ich bin gerade auf dieses Projekt gestoßen und war sehr aufgeregt darüber, weil es großartig aussah. Die Beispielseite machte es sehr einfach, herauszufinden, wie man die Komponenten verwendet, und es sah so aus, als wäre es weit verbreitet. Ich bin jedoch sehr enttäuscht von den Inline-Stilen und ich bin froh zu sehen, dass ihr von ihnen wegkommt. Eines der Dinge, auf die ich hinweisen möchte, ist, dass alles, was mit dem Layout außerhalb dieser Komponenten zu tun hat, entfernt werden sollte und das Styling der übergeordneten Komponente dies handhaben sollte. Die Komponente der untersten Ebene sollte keine Ränder oder Polster aufweisen, die die umgebenden Elemente wegdrücken würden ... zumal es unmöglich ist, sie zu überschreiben, ohne mit den Inline-Stilen herumzuspielen, was bedeutet, dass ich herumgraben und herausfinden muss, wie es geht Das. Ich habe mich nicht viel weiter mit diesem Projekt befasst, weil ich es leider unbrauchbar finde. Ich habe sicherlich viele Diskussionen über Inline- und CSS-Styling gelesen. Wie auch immer, du hast mich bei TextField verloren. Oben ist ein Rand von 14 Pixel und unten 16 Pixel. Es würde mir nicht allzu viel ausmachen, einen einfachen Stil zu schreiben, um dies zu überschreiben, aber das ist aufgrund des Inline-Stils unmöglich, und es wäre völlig verrückt für mich, eine übergeordnete Komponente erstellen zu müssen, um dies umzukehren, wie beim Umschließen Ihrer Komponente mit einem Div und Rand machen: -14px 0 -16px oder leicht mit einer Berechnung an die Art und Weise anpassen, wie ich es will, aber das in irgendeiner Weise korrigieren zu müssen, sollte eigentlich nicht notwendig sein. Ich würde es viel mehr vorziehen, wenn Sie zulassen würden, dass ein Klassenname als Requisite übergeben wird, wie Sie es bereits getan haben, damit das Layout-Styling auf die Komponente angewendet werden kann, wie es Ihre Community gestalten möchte. Wie auch immer, das sind meine $ .02.

Um dies hinzuzufügen, ist es möglicherweise ideal, Layouttyp-Komponenten für diese zu erstellen oder zusätzliche Requisiten für die Layout-Eigenschaften zu erstellen, z. B. die Verwendung eines Rastersystems wie Foundation und Bootstrap. Verwenden Sie beispielsweise Requisiten wie Größe, Dachrinne, Breite, Säulen usw., beginnen Sie jedoch ohne Styling an der Außenseite dessen, was mit der Komponente sichtbar ist.

Ich bin komplett bei @ jbsmith969

Es wäre völlig verrückt für mich, eine übergeordnete Komponente erstellen zu müssen, um dies umzukehren, wie beim Umschließen Ihrer Komponente mit einem Div und beim Ausführen von Margin: -14px 0 -16px oder bei einer Berechnung nach meinen Wünschen

@ jbsmith969 Ich stimme zu, dass Low-Level-Komponenten keine Layout-Logik haben sollten. Das Erstellen einer höher abstrahierten Komponente für Ihre App-Spezifität klingt jedoch überhaupt nicht verrückt.
IMHO, das ist eines der mächtigsten Muster, die React ermöglicht (dank der Isolationseigenschaften).

@oliviertassinari @ jbsmith969 Genau das haben wir getan! Wir haben unsere CustomTextField -Komponente erstellt, an die ich wie 2 Parameter (Feldname und Farbe) übergebe, und sie macht nur ein kleines bisschen Logik um diese herum und rendert dann mit allem, was wir tun, ein material-ui/TextField wollen.

Es sind die Komponenten ganz unten!

Also nehmen wir mit reagieren unser HTML und setzen es in unser js und das ist in Ordnung und gut. Aber unser CSS nehmen und es in unser HTML schieben? Passt das nicht gut zu jemand anderem?

Was war der Vorteil, von Sass wegzugehen?

Nennen Sie mich altmodisch, aber was ist so falsch daran, unsere js / html und css getrennt zu halten?

Ich suche hier zu Recht nach Antworten ...

Im Zusammenhang mit https://github.com/callemall/material-ui/issues/3614#issuecomment -249095805 wird das Styling einfach zu einer Komponente.

Ich sehe CSS-Klassen als neue Komponenten: (zB btn-danger -ähnlich von Boostrap)

const DangerButton = ({ hoverColor, style, ...others }) => {
    return (
        <MUI.FlatButton
            hoverColor={hoverColor || Colors.pink100}
            style={{ color: Colors.black, ...style }}
            {...others}
        />
    );
};

Übergänge sind allerdings ein Schmerz ..

(Für @ jbsmith969 folgt MUI der Material Design-Spezifikation. Wenn ich der Spezifikation nicht folgen möchte, würde ich eine

@vizath richtig Ich habe definitiv den gleichen Gedanken. Aber was sind die Vorteile dieser Lösung?

Wenn es eine Lösung gäbe, die mindestens so gut funktioniert wie nur CSS, würde ich in Betracht ziehen, sie auszuprobieren. Da es derzeit jedoch keine Lösung gibt (von der ich weiß), die dies ohne Einschränkung tun kann, sehe ich den Appell nicht wirklich.

Warum versucht dieses Repo, eine scheinbar Alpha-Stufe-Idee für eine Lösung in eine ansonsten sehr nützliche Codebasis zu übernehmen? Ich glaube nur noch nicht, dass wir mit dem Tec da sind, und ich denke auch nicht, dass dies der richtige Prüfstand für diesen Tec ist.

@nathanmarks können Sie beraten, wie Sie die Stile von Komponenten mithilfe von JSS next

EDIT: Okay, nur herausgefunden, dass es noch nicht vollständig implementiert ist. Mein Fehler! 😬

Ich habe noch keinen guten Weg gefunden, toten Code in Objektschlüsseln zu entfernen, und mit JSS ist es obligatorisch, Objekte zum Speichern von Stilen zu verwenden.

Zufälliges Beispiel in einer Komponente des Zweigs next (die noch nicht fertig ist): https://github.com/callemall/material-ui/blob/b372f6223ec2528dbe02f100e4802334f88445b7/src/IconButton/IconButton.js#L36
Ich kann nicht zuverlässig feststellen, dass die Klassen primary und accent nicht verwendet werden.

Aus dem gleichen Grund gefiel mir auch nicht, wie MUI zuvor Inline-Stile verwaltete (Lint hätte nicht verwendete Variablen abgefangen, wenn die Stile separat definiert worden wären, siehe https://github.com/callemall/material-ui/blob/). 60a202fdc9645aa00f20c52e5152f168a1b0031b / src / IconButton / IconButton.js # L26).

Was war der Vorteil, von Sass wegzugehen?

@gdaunton Es hängt von der Seite ab, auf der Sie sich befinden,

Aus Anwendersicht wird es die folgende Verbesserung bieten:

• Schnellere Reaktion beim Rendern, da wir uns auf zwischengespeicherte generierte CSS-Blätter verlassen werden.
• Vereinfachtes Überschreiben des Stils, da die CSS-Priorität niedriger als die des Inline-Stils ist und Benutzer die DevTools verwenden können, um das zu ändernde Blatt zu identifizieren.
• Schnelleres Malen beim serverseitigen Rendern.
  
  
  
  • Benutzer können die kritischen CSS-Blätter und nur das auf der Seite verwendete einbinden. Das ist etwas, was man mit _Bootstrap_ NICHT machen kann, da es ein großer Monolith ist 🙈.
  
  
  • Benutzer sollten in der Lage sein, die Klassennamenschlüssel in der Produktion zu hässlich zu machen.
  
  
• Keine Abhängigkeit von der integrierten Kette wie _scss-loader_ oder _Webpack_.

Aus Sicht der Mitwirkenden / Betreuer werden die folgenden Verbesserungen erzielt:

• Kein CSS-Linter mehr
• Kein Preprozessor-CSS mehr
• Keine zu lernende CSS-Syntax
• Eine viel leistungsfähigere Sprache zum Stylen der Komponente: JavaScript
• Öffnen Sie die Möglichkeit, die Style-Engine zu abstrahieren. ZB durch Reagieren mit Stilen

Warum versucht dieses Repo, eine Idee der Alpha-Phase zu übernehmen?

Kommt darauf an, was du mit Alpha-Stage-Idee meinst.
Wir sind weit davon entfernt, der einzige zu sein, der diesen Ansatz verwendet. ZB AirBnB, Khan Academy, ReactNative.

funktionierte mindestens so gut wie nur CSS

CSS wurde von Anfang an entwickelt, um Dokumente und nicht Komponenten zu formatieren .
Das ist eine große Veränderung in unserer Branche.

Aus meiner Sicht ist es scheiße für das Styling von Komponenten.
Personen, die hinter der Webspezifikation stehen, sind sich dieses Problems bewusst und versuchen, es mit dem lokalen Gültigkeitsbereich von _Web Components_ zu beheben.
Haben Sie all diese neuen Projekte bemerkt, seit React gestartet wurde, um CSS zu verbessern und komponentenbasierten Stil zu schreiben?

Ja, der nächste Zweig verwendet jss

@nathanmarks wo kann ich hingehen, um mich über diese Änderung zu

Gefunden: https://github.com/callemall/material-ui/blob/next/docs/customization/themes.md

@bramick scheint es nicht um next da dies ab 0.15.0 funktioniert

Ok, mir fehlt, was es Neues gibt ... Jemand?

@bramick next ist noch nicht vollständig dokumentiert (es gibt jedoch eine Dokumentationsseite). Im Moment müssen Sie den Quellcode lesen und können auf den Quellcode der Dokumentationssite verweisen, um zu sehen, wie er funktioniert. Stellen Sie nur fest, dass ein Teil davon möglicherweise noch ein sich bewegendes Ziel ist.

@oliviertassinari Wow! Vielen Dank für die ausführliche Antwort.

Ich kann nicht sagen, dass ich völlig einverstanden bin, aber Sie haben trotzig ein paar Fragen geklärt, die ich hatte.

Ich stimme zu, wir sollten (und werden) uns einer Welt nähern, in der unsere Stile komponentenbasiert sind, und CSS ist dafür nicht großartig. Allerdings (meiner Meinung nach) müssen noch einige Falten ausgebügelt werden, bevor wir dies in großem Maßstab übernehmen sollten.

Ich bin allerdings neugierig, hat jemand nachgesehen, ob es einen Leistungsunterschied zwischen diesem und Standard-CSS gibt? Ich habe das Gefühl, dass CSS immer noch einen Vorteil gegenüber Javascript hat. Nach dem Laden muss es noch seine Stile generieren und einfügen.

@gdaunton Informationen zur JSS-Leistung finden Sie unter https://github.com/cssinjs/jss/blob/master/docs/performance.md

Es handelt sich um gerendertes Standard-CSS, das der Seite hinzugefügt, aber innerhalb der Komponente erstellt wurde. Ich benutze den Zweig next und er funktioniert ganz gut.

@newoga kannst du mir einen Link zu dem schicken, worauf du dich

@bramick OMG! Das ist wirklich einfach, nicht wahr? Zum Beispiel für Button in next hier suchen.

Ich verstehe den Reiz, CSS nach dem Erfolg von JSX in die JavaScript-Datei einzufügen, bin mir aber nicht sicher, ob es eine gute Idee ist, dasselbe mit dem gesamten CSS einer Anwendung zu tun. Ich weiß, dass JSS einige gute Anwendungsfälle hat, zum Beispiel beim Umgang mit superkomplexen dynamischen Stilen.

Meine größte Sorge ist, dass die Stilinformationen die Komponentendefinition überladen . Das mit JavaScript-Objekten ausgedrückte CSS ist viel ausführlicher und schwieriger zu organisieren . In der Komponente Button , auf die im vorherigen Beitrag verwiesen wurde, besteht beispielsweise fast die Hälfte des Codes aus Stilinformationen. Es gibt keine Trennung von Bedenken mehr. Ich weiß, dass Sie den Stilcode in eine separate Datei verschieben können, aber dann macht es keinen Sinn, ihn an erster Stelle in JavaScript zu haben.

Für Entwickler besteht der größte Nachteil darin, dass sie alle intelligenten Informationen für die CSS-Eigenschaften und ihre Werte

Es macht mir nichts aus, meinen Projekten Komplexität zu verleihen, wenn das mehr Wert bringt. Daher machte mir der zusätzliche CSS-Linter, Pre-Prozessor, Loader und die zusätzliche Syntax, die ich lernen musste, nichts aus. Ich versuche auch, offen über JSS zu bleiben. Es ist nur so, dass es mich nach dem ersten Blick nicht überzeugt hat.

Meine größte Sorge ist, dass die Stilinformationen die Komponentendefinition überladen.

Dies liegt ganz bei Ihnen, hängt davon ab, wie Sie Ihren Code organisieren. Wenn Sie sich an einige Regeln halten, passiert nichts Schlimmes (aus einer Produktionserfahrung von 2 Jahren).

Das mit JavaScript-Objekten ausgedrückte CSS ist viel ausführlicher und schwieriger zu organisieren.

Es ist tatsächlich weniger ausführlich, da Sie eine höhere Wiederverwendung von Code und weniger Wiederholungen haben.

Für Entwickler besteht der größte Nachteil darin, dass sie alle intelligenten Informationen für die CSS-Eigenschaften und ihre Werte verlieren.

Ich denke, das Ziel hier ist es, den Benutzern von Material-UI die Wahl zu geben, alles zu verwenden, was sie für das Styling wollen. Autocompletes für CSS ist ein Argument, das ich oft höre. Meistens kommt es von Leuten, die nicht viel cssinjs benutzt haben und es ist nur die Angst, einige Annehmlichkeiten zu verlieren, die sie früher hatten.

Es macht mir nichts aus, meinen Projekten Komplexität zu verleihen, wenn das mehr Wert bringt.

Ich denke, der springende Punkt ist, die Komplexität zu reduzieren und die Codebasis konsistenter und benutzerfreundlicher und verständlicher zu machen, aber alle komplexen Szenarien werden gleichzeitig behandelt.

Meine größte Sorge ist, dass die Stilinformationen die Komponentendefinition überladen.

In unserem Projekt haben wir die Stilinformationen der Komponenten in separaten Dateien extrahiert und mit Webpack geladen. Der Hauptvorteil besteht darin, dass alles gut organisiert ist und das Webpack den Code pro Komponente bündeln kann, sodass eine Codeaufteilung von js-Code UND Stilinformationen möglich ist.

Auch eine Trennung von Bedenken ist gegeben, wenn Sie die Logik trennen, um Ihre Stilregeln zu erstellen. Ein Beispiel ist, dass wir Style-Factory-Funktionen eingeführt haben, die ähnlich wie Mixins in bekannten CSS-Präprozessoren funktionieren.
Mein Punkt ist, dass Sie so viel mehr Flexibilität gewinnen, um Ihre eigenen spezifischen Workflows zu modellieren und sich am besten an die Anforderungen des Projekts und des Teams anzupassen.

Überprüfen Sie diese https://styled-components.com/

Es ist ziemlich spät im Spiel, Technologien zu ändern, aber ich stimme zu, dass gestylte Komponenten sehr vielversprechend sind. Behandelt SSR, Medienabfragen, ziemlich nette Syntax und so weiter. Im Vergleich zu JSS werden auch Autoprefixing und Theming verarbeitet.

Soweit ich weiß, wird darin postcss verwendet, was zur Laufzeit keine akzeptable Leistung erbringt, da es sich um einen vollständigen CSS-Parser mit vielen Edge-Case-Handlings und Plugins handelt. Ich könnte mir vorstellen, dies in JSS JSON vorzuverarbeiten, aber um ehrlich zu sein, sehe ich nicht viel Wert darin, CSS-Sprache zu verwenden und sie mit JS-Variablen und Funktionsaufrufen zu mischen, anstatt nur JS ganz nach unten zu verwenden.

Um nur zu erwähnen, der aktuelle Build von gestalteten Komponenten beträgt 250 KB, bereits minimiert . Um fair zu sein, liegt das daran, dass sie React und Co bündeln, aber selbst der PostCSS-Parser allein hat 13 KB (nicht minimiert, möglicherweise 2 KB ~), was bereits fast der Größe von JSS oder Fela entspricht.

Es ist zwar wunderbar für das schnelle und einfache Prototyping von (Präsentations-) Komponenten, aber ich sehe keinen Nutzen / keine Funktion, die andere Lösungen nicht bieten können.

Ich stimme zu, ich habe es in einer von mir entwickelten Bibliothek ausprobiert und es war viel zu schwer, um es zu veröffentlichen. Ich bin sicher, dass sie damit Fortschritte machen werden, aber es scheint, dass die JSS-Arbeit hier fast abgeschlossen ist und die meisten der gleichen Vorteile bietet.

Ich habe in letzter Zeit die React -Toolbox verwendet . Sie verwenden CSS-Module für Themen, die im Grunde nur auf sassLoader von Webpack beruhen. Bei mir hat es sehr gut geklappt. Vielleicht lohnt es sich zu untersuchen.

Hey, ich muss der Meinung von @mgcrea zustimmen. Die Unterstützung von React -Toolbox-Themen ist einfach unglaublich - ich wechsle um , da das Anpassen des Erscheinungsbilds von Komponenten der wichtigste Aspekt der Frontend-Story ist.

Ich glaube nicht, dass irgendjemand jemals erwarten sollte, dass gutes altes CSS-Styling jemals ein erstklassiger Bürger in der Material-Benutzeroberfläche ist. Aus diesem Grund wurde react-toolbox gestartet

Zumindest ist das mein Eindruck, nachdem ich viele Themen und Beiträge zu diesem Thema gelesen habe. Ich kann mich vage an Dinge erinnern, bei denen das Team nach einer besseren React Native-Kompatibilität strebt, und an viele Kommentare zu Styling-Edge-Fällen, die mit JSS viel einfacher zu lösen sind.

Diese Informationen gehen jedoch in vielen Diskussionen verloren. Da dies ein so kontroverses Thema ist, denke ich, dass es von unglaublichem Wert wäre, wenn man eine Wiki-Seite über die Projektziele und -philosophie (geschrieben von den Hauptbetreuern) mit einer starken Bemerkung darüber haben könnte, warum das Javascript-Styling so tief verwurzelt ist Rahmen.

Ich mag Material UI wirklich, weil es das aktivste und polierteste Material-Styling-Framework für React ist. Das gesamte JSS bereitet mir jedoch viele Kopfschmerzen, wenn ich einen einheitlichen Stil mit Komponenten von Drittanbietern beibehalten möchte.

Ich selbst schätze die Art und Weise, wie Material-UI das Styling im Gegensatz zu einer Art React-Toolbox ausführt, und hier ist der Grund: In einem unserer Projekte haben wir die Möglichkeit, dass der Benutzer dynamische Themen auswählt:

Da der Benutzer möglicherweise ein Farbpaar auswählt, das wir nicht im Voraus bestimmen können, muss das von uns verwendete Themenschema hochdynamisch sein. Mit, Änderungen am Thema können live erfolgen, b / c alle Stile werden inline generiert: Ich muss ihm nur Primär- / Akzentfarben geben.

In React-Toolbox et. al., dies scheint eher eine lästige Pflicht zu sein, als ich sehen kann.

@jrop Ja, in diesem ganz besonderen Fall benötigen Sie dynamisches JSS, aber für viele Anwendungen ist dies keine wichtige Anforderung, und die aktuelle Geschichte des Anpassen (nicht einmal des Testens der Benutzeroberfläche) von Material-UI ist einfach nicht akzeptabel. Wir erstellen eine sehr visuelle und gestaltete App, die nicht nur den Standard-Material-UI-Look verwenden kann, da wir meistens die Verhaltensteile davon benötigen / wollen.

@DominikGuzei Sie können next Zweig mit jss anpassen. Dies ist nicht das, was Sie in der aktuellen Version sehen.

Leute, ich habe das Gefühl, wir schlagen hier ein totes Pferd. Der Zweig next hat einen anderen (stark verbesserten) Pfad mit Themen gewählt und ermöglicht Überschreibungen. Es verwendet keine Inline-Stile mehr und bietet die Flexibilität, die ich mir gewünscht habe. Für andere, die mehr Anpassbarkeit wünschen, können sie ein HOC über die next -Komponenten verwenden und ihre eigenen Stylesheets schreiben.

@nathanmarks , da diese Entscheidung getroffen wurde (soweit ich das beurteilen kann und recht gut funktioniert 👍), schlage ich vor, dass Sie eine Zusammenfassung schreiben und dieses Problem schließen / sperren, damit diejenigen, die es finden, den Weg nach vorne verstehen.

Wenn man eine Wiki-Seite über die Projektziele und -philosophie (geschrieben von den Hauptbetreuern) mit einer starken Bemerkung darüber haben könnte, warum das Javascript-Styling so tief im Framework verankert ist.

@fgarcia Ich habe Anfang dieser Woche auf einer lokalen Veranstaltung in Paris einen Vortrag über die Entwicklung des von Material-UI verwendeten Styling-Ansatzes gehalten. Vielleicht interessieren Sie sich auch für die Folien und die _Notes_: Eine Reise zu einem besseren Stil . Ich konzentriere mich auf die Herausforderungen, Probleme und Lösungen.

der Benutzer, um dynamische Themen auszuwählen

Der Aspekt der statischen Stilgenerierung von CSS-Modulen hat einige Konsequenzen.
Das Injizieren von Stil zur Laufzeit ist weniger kosteneffizient, ermöglicht uns jedoch Folgendes:

• Gibt uns mehr Flexibilität bei der Stilimplementierung. Beispiel: Für CircularProgress ist ein festes thickness mit der Implementierung der CSS-Keyframe-Animation verknüpft ist. Mit dem dynamischen Stil können wir eine Dickeeigenschaft hinzufügen, damit Benutzer den Wert dynamisch ändern können. ⚠️ nicht missbraucht werden.
• In einer groß angelegten App können nur die erforderlichen Stile für die auf dem Bildschirm angezeigte Komponente eingefügt werden. Reduzieren des Arbeitsaufwands, den der Browser zum Booten der Seite benötigt. Daher schnellere Zeit zum ersten Malen nach der Interaktion. ZB Inlining von kritischem CSS mit SSR.
• Ermöglichen Sie Benutzern die Verwendung eines dynamischen Themas und einer Variation von Komponenten. ZB Ändern der Farbe einer Schaltfläche mit allen erforderlichen Farbvariationen.

@oliviertassinari Das ist toll zu hören. Ich habe vielleicht eine nicht standardmäßige Sichtweise in Bezug auf CSS-Module, aber ich denke nicht, dass sie die ganze Aufregung wert sind. Aus diesem Grund war ich aufgeregt, über material-ui von JSS zu hören. Es scheint viel mehr mit der Philosophie von JavaScript übereinzustimmen als mit CSS-Modulen.

@oliviertassinari danke für die Zusammenfassung der Vorteile. Es ist auf jeden Fall interessant, wenn man sich diese Aspekte ansieht. Der Nachteil von JSS und seinem Ökosystem (auch Post-CSS) ist derzeit, dass alles auf dem neuesten Stand ist und Sie sich nicht auf die gut etablierte Toolkette und Wissensbasis verlassen können, wie dies bei einfachen CSS-Modulen + SASS der Fall ist. Aber das ist der Preis, den Sie für Innovation zahlen. Es hängt nur davon ab, ob Sie bestimmte Anforderungen haben / bereit sind, den Preis für Fehler und den weniger dokumentierten Pfad zu zahlen.

JSS wurde vor CSS-Modulen erstellt. CSS-Module sind schneller populär geworden, weil sie ein Problem für die meisten Benutzer gelöst haben, ohne die Syntax zu radikal zu ändern.

Davon abgesehen verwenden Sie React, was auch eine "neue" Technologie ist. Wenn Sie SASS möchten, sollten Sie vielleicht auch Vanilajs oder Backbonejs auswählen.

@kof React ist eine ganz andere Geschichte, da sie von Hunderttausenden von Entwicklern verwendet und von Facebook verwaltet wird (sie wird nicht über Nacht verschwinden), daher ist sie möglicherweise "neu", aber sehr solide (nicht begegnet) viele Probleme damit bisher).

SASS ist einer der etabliertesten CSS-Präprozessoren und kann in jedem Projekt verwendet werden - es ist sehr solide und bringt viel Wert auf den Tisch. Daher würde ich nur dann etwas wie JSS wählen, wenn dies unbedingt erforderlich ist (z. B. aufgrund dynamischer Themen), aber nicht gerne jahrelange Erfahrung / Frameworks / Wissensdatenbank usw. in einem kommerziellen Softwareprojekt mit mehreren Entwicklern auswerfen. Daher würde ich sogar in Betracht ziehen, nur den dynamischen Themenaspekt in JSS und den Rest mit sass / css-Modulen zu erstellen.

Ich verstehe diese Denkweise, halte sie aber auch für kontraproduktiv und beschuldige sie, die Innovation und die Branche zu verlangsamen.

Warum unterstützt du einfach nicht beide? In JavaScript geschriebene Stile UND in CSS-Modulen geschriebene Stile? Wenn ich mir zum Beispiel https://github.com/callemall/material-ui/blob/next/src/Button/Button.js anschaue, wäre es ziemlich einfach, Klassennamen zu verwenden, die von einer Requisite übergeben wurden ( https://github.com/javivelasco/react-css-themr) anstatt zu verwenden:

const classes = this.context.styleManager.render(styleSheet);

Ist es nicht?

Es sieht nicht so aus, als würde die Diskussion über die Verwendung von JSS oder CSS (noch?) Ein Ende finden. Für mich sieht es im Moment nach fünfzig / fünfzig aus.

In Bezug auf SASS migrieren React -Toolbox derzeit weg. Ich persönlich denke, PostCSS (mit sassLike-Plugins) ist eine bessere Wahl, leistungsfähiger ohne Build-Deps.

Das Styling in allen JS und insbesondere in React befindet sich offensichtlich noch in einem rasanten Entwicklungsstadium. Was auch immer Sie tun, ich würde versuchen, eine Meinung zu vermeiden - passen Sie einfach gut zu einem breiten Spektrum der aktuellen Nutzung.

Fügen Sie einfach eine * className-Requisite hinzu, wo immer es eine * style-Requisite gibt. Zeitraum.

Vollständige Offenlegung: Ich bin ein glücklicher Aphrodite-Benutzer.

Das Hinzufügen eines className erfordert weiterhin !important Hacks, da die Inline-Stile (von style Eigenschaft) Vorrang haben.

@ligaz Natürlich hast du recht. Aphrodite fügt standardmäßig !important zu allem hinzu, sodass meine Überlegungen zu einem "breiten Anwendungsbereich" möglicherweise stark verzerrt sind.

@ligaz @estaub - next ist bereits _ohne_ style codiert und ermöglicht Benutzern des Überschreibens das Überschreiben, indem className (und mehrere Klassennamen für die verschiedenen Teile komplexer Komponenten) angegeben werden. .

Das von den Betreuern eingerichtete Styling-Paradigma für den Zweig next verwendet JSS. Es ist eine Freude, sie zu verwenden und auf individueller oder thematischer Basis leicht zu überschreiben.

Dieses Pferd ist tot. Hören wir auf, es zu schlagen. @oliviertassinari Ich schlage vor, Sie schließen und sperren dieses Problem mit einer Richtungsangabe auf next .

Hallo @rosskevin - kannst du mir Beispiele dafür geben, wie das als nächstes funktioniert?

Ich suche derzeit nach Frameworks für ein neues Projekt. Ich würde gerne die Material-Benutzeroberfläche verwenden, aber wir würden die Änderungen benötigen, die Sie als nächstes erwähnt haben. Ich habe den nächsten Zweig zu einem Testprojekt hinzugefügt und eine einfache Komponente hinzugefügt. Ich sehe einen Inspektor voller Inline-Stile. Vermutlich mache ich also etwas falsch?

Alle weiteren Details wären sehr hilfreich!

Vielen Dank

@giuseppepaul next wird nicht auf npm veröffentlicht, da es sich um Pre-Alpha handelt und noch nicht vollständig ist. Sie können https://github.com/callemall/material-ui.git#next klonen und docs/site ausführen, um festzustellen, dass keine Inline-Stile mehr vorhanden sind. Es hat auch eine angemessene Anzahl von Demos.

Ich veröffentliche meine eigene private Version von next (damit ich die Updates steuern kann) und verwende diese in einer bald erscheinenden Produktionsanwendung.

Dieses Pferd ist tot. Hören wir auf, es zu schlagen. @oliviertassinari Ich schlage vor, Sie schließen und sperren dieses Problem mit einer Anweisung am nächsten.

Das Pferd ist nicht ganz tot. Aber definitiv in einer schwierigen Situation 🔫.
Ich stimme zu, lassen Sie uns dieses Problem schließen.

Ein großes Dankeschön an @nathanmarks für seine harte Arbeit an dieser Geschichte 👏!
Ich habe mit # 5718 weitere Informationen über die bevorstehende Straße gesammelt.

Hallo,
IconButton haben eine CSS3 transition -Eigenschaft für den Ripple-Effekt. In der komplexen Interaktion des Dokuments von Card @next haben Sie der Transformation ein transition hinzugefügt, um einen Übergang hinzuzufügen, wenn sich das Symbol umkehrt.
Wenn ich in meiner App dasselbe mache, überschreibt ein Übergang (Welligkeit oder Umkehrung) den anderen (ein Element kann nicht zwei Eigenschaften haben, andernfalls überschreibt einer den anderen).
Auf Ihr Chevron-Symbol wurden jedoch erfolgreich zwei transitions angewendet. Denn in gewisser Weise führen Sie Übergänge zusammen, die von IconButton bereitgestellt werden, und dem in Ihrem Code definierten. Wie erreichen Sie das?
Einige andere Dinge sind für mich dunkel und ich kann kein verwandtes Dokument finden. theme hat viele Methoden / Eigenschaften wie breakpoints (hier nicht verwendet) transitions (hier verwendet). Gibt es bereits ein Dokument über die theme -Eigenschaft dessen, was MuiThemeProvider.createDefaultContext() zurückgibt, da es nützlich erscheint, insbesondere, dass es in Ihrem Code ausgiebig verwendet wird.
this.context.styleManager.render(styleSheet) ? Was?
Sie verwenden auch jss-theme-reactor was ich im Vergleich zu react-jss immer noch nicht verstehe.

@NitroBAY Dieser Thread ist vorbei. Bitte stellen Sie Ihre Frage auf dem richtigen Kanal. Wenn Sie einen Fehler bemerken oder die Dokumentation verbessern möchten, öffnen Sie ein Problem. Andernfalls können Sie StackOverflow von gitter.im verwenden.