Material-ui: Refactor CSS in Javascript

Ich mag das, aber ich weiß nicht, wie es in der realen Welt funktioniert. Stellen Sie sich vor, Sie haben viele Elemente, jedes Element hat einen benutzerdefinierten Stil. Es wird den Dom riesig machen. Ist das nicht ein Leistungsproblem? (Ich habe eine ähnliche Benutzeroberfläche komplett in react.js mit Stil erstellt und alles hat gut funktioniert, war aber ein kleines Testprojekt)

@ totty90 Ja, ich habe mich das gefragt, aber von den Folien war das Problem bei Facebook, dass alle CSS-Dateien und CSS-Klassen ein Leistungsproblem waren.

Vielleicht könnte @vjeux Licht ins Dunkel bringen und es ist die vorgeschlagene Lösung in dieser Diashow.

Vielleicht ist dies für einige der kleineren Komponenten eine bessere Lösung?

Bearbeiten: Eine andere Sache, bei der ich mir nicht sicher war, war, wie ich mit Medienanfragen und Reaktionsfähigkeit umgehen soll.

Ich habe ihn bereits gebeten, mir eine App aus der realen Welt mit dieser Technik zu zeigen. Dies löst eines der besten Probleme: Eine Komponente wurde in einer einzigen Datei geliefert. Ich kann eine Datei mit Ihnen teilen und Sie erhalten meine Komponente genau wie meine gerendert, ohne dass Sie dies einrichten müssen. Keine CSS-Probleme.

Es gibt ein weiteres Projekt, das eine gute Möglichkeit zur Integration von CSS-in-JS und React bieten soll - https://github.com/js-next/react-style sowie einige erste Arbeiten zu Material UI-Komponenten, die diese verwenden - https: //github.com/SanderSpies/react-material

Dieses Projekt hat momentan mehr Traktion und eine größere Anzahl von Komponenten implementiert, aber Reaktionsmaterial hat den Vorteil, dass Komponenten eigenständig arbeiten, ohne CSS-Dateien bündeln zu müssen. Sie erhalten auch alle Vorteile, die in der Präsentation von @vjeux beschrieben sind .

Es wäre toll, wenn die beiden Projekte kombiniert werden könnten!

Das andere Projekt ist viel schlimmer. Der einzige interessante Teil ist das CSS in js.

Ich mag das Konzept, JS und CSS zu koppeln, aber Inline-Stile sind schlecht für die Browserleistung und die Implementierung von CSP. Verwenden Sie möglicherweise WebPack, wenn Sie besorgt sind?

Webpack scheint die einzige "vernünftige" Möglichkeit zu sein, Stile zu importieren. Haben Sie ein require('component.css'); - aber dann haben Sie eine Abhängigkeit für Ihre Komponente. Sie müssen auch Webpack verwenden! Ich mag diese Lösung nicht. Man sollte in der Lage sein, eine Komponente einfach zu teilen, einfach zu installieren, zu verwenden und zu profitieren.

Der aktuelle Ansatz hier sieht benutzerfreundlich aus. Es ist nicht perfekt, aber das Kopieren einiger Importzeilen ist recht einfach. Obwohl ich vorschlagen würde, dass die erneute Verwendung von Less Benutzer an diesen Präprozessor bindet ...

Es ist schwer, die Dinge einfach zu machen! Hat jemand Vorschläge? Dies ist viel weiter als nur dieses Projekt. Die gesamte Reaktions- / Polymer- / Komponentengemeinschaft benötigt eine Lösung.

PS - Das Koppeln von CSS in Ihrem JS scheint eine schlechte Idee zu sein. Zum einen schreiben Sie am Ende ein Pseudo-CSS mit Kamel-gehüllten Eigenschaften und stringierten Werten, und Sie mischen kognitiv Bedenken, die es schwieriger machen, über Ihren Code nachzudenken. Ich hatte noch nie Probleme beim Schreiben von CSS. Ja, es kann schwierig sein und Dinge können schief gehen (globaler Namespace, unbeabsichtigte Konsequenzen usw.) - aber eine Verlagerung auf JS wird das Problem NICHT beheben. Besseres CSS schreiben ist.

@ pspeter3 hast du irgendwelche Benchmarks? :) :)

Hauptsächlich diese beiden JsPerfs, http://jsperf.com/class-vs-inline-styles/2 und http://jsperf.com/classes-vs-inline-styles. Http://jsperf.com/inline-style-vs-css-class/9 scheint jedoch das Gegenteil zu implizieren. Schlecht für die Leistung war eine Übertreibung. Ich bin sicher, dass Sie mit Stylesheets auch eine schlechte Leistung erzielen können, wenn Sie schlechte Selektoren verwenden. Haben Sie Ratschläge zur Implementierung der Inhaltssicherheitsrichtlinie bei der Verwendung von Inline-Stilen?

@jarsbe

PS - Das Koppeln von CSS in Ihrem JS scheint eine schlechte Idee zu sein. Zum einen schreiben Sie am Ende ein Pseudo-CSS mit Kamel-gehüllten Eigenschaften und stringierten Werten, und Sie mischen kognitiv Bedenken, die es schwieriger machen, über Ihren Code nachzudenken. Ich hatte noch nie Probleme beim Schreiben von CSS. Ja, es kann schwierig sein und Dinge können schief gehen (globaler Namespace, unbeabsichtigte Konsequenzen usw.) - aber eine Verlagerung auf JS wird das Problem NICHT beheben. Besseres CSS schreiben ist.

Ich habe viel CSS und CSS in JS geschrieben. Das erste ist einfacher, aber in großen Projekten wird es chaotisch. Das andere (weil ich nur eine kleine App erstellt habe) würde in einer größeren App besser funktionieren. Versuchen Sie, eine js-App mit allem zu programmieren, was global + zusammengeführt wird, das ist die Hölle !!! (Oder ich habe es immer falsch gemacht ...)

Hier ist ein Test, den ich mit react.js http://jsperf.com/react-class-name-vs-inline-css2 durchgeführt habe

Ja, ich wünschte, es gäbe eine einfache Antwort darauf. :) Letztendlich denke ich, dass beide Ansätze Vorteile haben.

Mein größtes Anliegen beim Einfügen von Stilen in die JS-Komponenten hat mit der Codepflege zu tun. Was passiert beispielsweise mit dem CSS, das für das Cross-Browser-Zurücksetzen benötigt wird? Gehen diese Stile auch in die Komponenten ein? Außerdem erhalten wir viele Vorteile durch die Verwendung von WENIGER wie Mixins, Variablen usw., die wir in JS irgendwie ersetzen und abstrahieren müssten.

Nachdem dies gesagt wurde, haben wir alle CSS-Klassen, die in diesem Projekt verwendet werden, mit "mui" benannt und versuchen, objektorientiertes CSS zu schreiben. In Zukunft sollte es wahrscheinlich einen Prozess geben, mit dem Benutzer auswählen können, welche Komponenten in einen benutzerdefinierten Build heruntergeladen werden sollen.

Danke für das Problem. Wirklich gute Punkte sind Diskussionen!

Was macht den Stil einer Komponente wirklich weniger zu einem Teil dieser Komponente als zu ihrer Struktur (HTML) und Funktionalität (js)? Es scheint mir, dass wir eine Methode zur Minderung eines Problems (Wartbarkeit des Codes) als ein von Natur aus weises Entwurfsmuster verwechselt haben und vergessen haben, dass es sich wirklich um einen Patch handelt. React ist wohl eine elegantere Lösung für die Wartbarkeit von Codeproblemen, als Struktur, Funktionalität und Stil in ihre eigenen Sprachen zu unterteilen. Es hat seine eigenen Probleme (Geschwindigkeit im CSS-Fall), aber wenn wir uns einig sind, dass diese wiedervereinigte Art, Komponenten zu schreiben, gut ist, können wir versuchen, das Geschwindigkeitsproblem zu lösen.

Es sollte beachtet werden, dass ich persönlich denke, dass dies einer der Fehler der Webkomponentenspezifikation ist. Wenn verschiedene Sprachen in einem Modul zusammengefasst werden, stellt React die Idee von HTML und CSS in Frage.

@mcwhittemore Ja, der Stil ist nicht weniger Teil der Komponente als HTML oder JS. Zusammen bilden sie eine Komponente. Dies erfordert nicht, dass die Komponente als eine 'Einheit' geschrieben wird, sondern genau so sollte sie verteilt werden.

Reaktion eng koppelt die Struktur und Funktionalität. Es zwingt Sie in dieses Muster und ich habe festgestellt, dass dies einfach und logisch ist. Ich kann den Code, den ich betrachte, leicht verstehen, mein Gehirn ist nicht überlastet.

Andererseits macht CSS in einer JS-Datei den Code für mich schwieriger zu verstehen. Beschreibungen des visuellen Stils passen nicht gut zu Funktionalität und Struktur. Ich ärgere mich nicht nur darüber, ich bin verwirrt und verlangsamt, da ich mehrere Bedenken bearbeiten muss. Außerdem wird das Styling eng mit der Komponente gekoppelt, was es anderen Autoren erschwert, ihre eigenen Styles zu schreiben.

Ich möchte meine Komponente als einzelnes Bundle verteilen. Lego Block Entwicklung ist der Traum! Es hört sich so an, als wären wir mit diesem Endziel alle auf einer Seite. Inline-CSS klingt nach einer guten Lösung, aber ich glaube nicht, dass es die richtige Lösung ist.

@jarsbe 100% stimmen zu, dass der style.json -Datei verwendet, in der die defaults und permanents mit this.props.style .

{
  "defaults": {
    "backgroundColor": "#efefef"
  },
 "permanents": {
    "width": "100%"
  }
}

Ein weiteres Argument gegen das Styling in JS vs CSS ist, dass das Attribut style nicht die gleichen Fähigkeiten wie ein CSS-Selektor hat. Zum Beispiel denke ich nicht, dass die *:after in der aktuellen weniger implementiert werden können.

@mcwhittemore Der Versuch, ein Pseudo-Element zu bekommen, hat mich genau dazu gebracht zu sagen: "huh? oh ja, das gibt es in diesem Zusammenhang nicht ...". Ja, das Extrahieren in eine andere Datei hilft. Ich muss mir das System auf bespoke.js ansehen, um neue Themen zu gestalten. Ich habe gehört, dass CSS in JS implementiert wird, bin aber müde.

@mcwhittemore warum brauchst du *:after ?

@ totty90 Es ist derzeit Teil des CSS. Es gibt möglicherweise Möglichkeiten, dieses Problem zu lösen, aber es ist keine einfache Situation, in der Sie "Ihr CSS in JS konvertieren". Haben Sie eine Lösung für den Selektor :after oder :before , an den ich gerade nicht denke?

IMO: Nach und: Vorher sind Hacks und ich habe sie nie gebraucht. Ich möchte wissen, wofür Sie sie brauchen, um Ihnen eine Lösung / Meinung zu geben.

@ totty90 Ich werde Sie in einer anderen Ausgabe eines anderen Projekts erwähnen, um dieses nicht zu überladen.

@ hai-cea Unter Berücksichtigung eines SMACSS-Workflows (https://smacss.com/book/categorizing) kann ein guter Ansatz darin bestehen, das CSS für die Kategorien _Base_, _Layout_ und (möglicherweise) _Theme_ in den guten alten CSS-Dateien beizubehalten . _Module_ und _State_ css scheinen mir ein guter Kandidat für den JS-Stil zu sein.

@WRidder Danke für den Link - das macht sehr viel Sinn.

Ein zufälliger Gedanke, bei dem ich nicht wusste, wo ich ihn platzieren soll ... Wie implementieren native Komponenten das Styling? Ich stelle mir vor, dass Reaktionskomponenten nativen Komponenten ähnlich ähnlich sein sollten. Es könnte ein guter Ort sein, um nach Ideen zu suchen.

Ich bin sehr skeptisch gegenüber diesem Ansatz, CSS in JS zu platzieren. In der Präsentation selbst geht es um das Problem der Zuordnung von Stilen zu Komponenten, als ob es nicht eine ganze, mehrjährige Anstrengung gegeben hätte, genau das mit dem Shadow DOM zu tun Standard. Natürlich nutzt React diesen Mechanismus derzeit nicht, aber ich wäre nicht überrascht, wenn er es rechtzeitig tun würde.

Dieser Standard funktioniert, weil er einem Komponentenersteller die Möglichkeit bietet, seiner Komponente einen minimalen Satz grundlegender Stile zuzuordnen, die dann von einem Designer überschrieben werden können, der in das Schatten-DOM greift. Es ist alles andere als klar, wie ein Designer Stile überschreiben würde, die nur in Javascript festgelegt wurden, wenn er die Komponenten nicht selbst verwenden würde, um direkt zu reagieren.

Ich bin gerade von der Reaktion zurückgekommen und danke @vjeux für die Organisation. Ich war auch mit diesem Ansatz skeptisch, aber ich denke, er hat seine Vorteile. Dieses Projekt hat einige Herausforderungen, die ich gerne lösen würde, wenn wir diesen Ansatz wählen würden.

1. Wir möchten, dass diese Komponenten themenfähig sind. Sie hätten einige Standardstile, aber Entwickler sollten in der Lage sein, das Aussehen an ihre Bedürfnisse anzupassen. Derzeit können sie dies tun, indem sie bestimmte Variablen in WENIGER überschreiben. Wie können wir die gleichen Funktionen mit js-Stilen anbieten?
2. Häufig generieren Komponenten verschachtelte untergeordnete Elemente. Wie können Entwickler Stile für verschachtelte untergeordnete Elemente anpassen? Mein Instinkt ist, dass wir nur den Kindern Stilrequisiten zeigen sollten, die anpassbar wären? Aber würde dies unsere Stile eng mit der Dom-Struktur einer Komponente verbinden? Was ich meine ist, wenn wir am Ende die Dom-Struktur einer Komponente ändern, würden wir am Ende auch die Stil-Requisiten ändern?

Vielen Dank für all Ihre Hilfe und Ihr Feedback - ich freue mich auf das, was alle zu sagen haben.

Gab es auf der React-Konferenz ein Video zu dieser Idee?

@vjeux In seinem React Native-Vortrag ein wenig darauf eingegangen - http://conf.reactjs.com/schedule.html#react -native

Er erzählte mir auch von einem Vortrag bei NationJS, aber ich weiß nicht, ob es Audio gibt?
http://blog.vjeux.com/2014/javascript/react-css-in-js-nationjs.html

Hi @ hai-cea,
Mein Team hat sehr kleine Experimente zum Thema Problem. Meine Teamlösung besteht darin, dass die Material-UI-Bibliothek eine Funktion zum Festlegen des Themas bereitstellt:
https://github.com/agencyrevolution/material-ui/blob/css-in-js-experiment/src/index.js

Wenn wir material-ui verwenden, rufen wir diese Funktion mit der Eigenschaft custom define auf. Und material-ui ruft die Aktualisierung dieser Funktion auf. Sie können sehen bei:
https://github.com/agencyrevolution/material-ui/blob/css-in-js-experiment/src/js/scaffold-styles.js

und das Beispiel, das wir in diesen Dateien verwenden:
https://github.com/agencyrevolution/material-ui/blob/css-in-js-experiment/src/js/raised-button.jsx
https://github.com/agencyrevolution/material-ui/blob/css-in-js-experiment/example/src/app/custom-styles.js
https://github.com/agencyrevolution/material-ui/blob/css-in-js-experiment/example/src/app/components/main.jsx

Danke @ cuongcua90 - Ich hatte eine ähnliche Idee wie deine.

Es würde ein Themenobjekt geben, das dafür sorgt, dass alle in custom-variables.less definierten Variablen

//Override Theme Variables
Theme.set({
  textColor: 'red'
});

Um eine detailliertere Steuerung der Stile zu ermöglichen, verwendet jede Komponente Stil-Requisiten, die mit Standardstilen zusammengeführt werden:

//merge styles that are passed in
var styles = this.mergePropStyles(defaultStyles, this.props.style);

Außerdem sind in meinem Test einige andere Herausforderungen aufgetreten:

1. Wie würden wir mit Herstellerpräfixen umgehen?
2. Was ist mit Medienabfragen?

hey @ cuongcua90 und @ hai-cea - was wäre, wenn wir dafür ein anderes Framework nutzen würden? Ich habe nicht viel darüber gelesen, aber es scheint, dass http://jhudson8.github.io/fancydocs/index.html#project/jhudson8/react -css-builder? Focus = Outline gut passt.

Es unterstützt Mixins und Variablen.

Herren,

Ich habe einen css-in-js-Zweig erstellt , um dieses Problem zu

Entwickler haben 2 Punkte für die Anpassung. Zunächst müssen die Standard-Themenvariablen überschrieben werden. Zu den Variablen gehören Komponentenfarben, Schriftarten usw.
https://github.com/callemall/material-ui/blob/css-in-js/example/src/app/app.jsx#L16

Für eine detailliertere Steuerung können Entwickler auch Standardkomponentenstile über Requisiten überschreiben:
https://github.com/callemall/material-ui/blob/css-in-js/example/src/app/components/main.jsx#L10

Hier ist ein Beispiel, wie wir eine Komponente auf der MUI-Seite implementieren würden:
https://github.com/callemall/material-ui/blob/css-in-js/src/js/svg-icons/svg-icon.jsx

Sie können sehen, dass wir uns um das Zusammenführen von Themenvariablen, Stilrequisiten und auch um die automatische Präfixierung basierend auf der Feature-Erkennung kümmern.

Feedback zu diesem Muster?

Das gesamte CSS in ein JS-basiertes System zu verschieben, wäre nett und würde # 316 lösen. Ich bin mir nicht sicher, wie viel in Bezug auf die Wartbarkeit bekannt ist, und einige gängige Stile gelten für _all_ Elemente (z. B. das Zurücksetzen und das Material in less/core/ ), daher bin ich mir nicht sicher, was für den Erhalt geplant ist diese Stile in die Anwendungen der Menschen. Einige offene Fragen, aber auf jeden Fall sehr interessant.

Wir könnten eine Art klassisches Vererbungssystem zum Erstellen von Stilobjekten erstellen. Auf diese Weise kann es für gängige Stile nur ein vererbbares BaseStyle-Objekt geben.

Ich bin gespannt auf das eigentliche Problem, das Sie beim Lösen von CSS in JS lösen möchten.

1- Erleichtern Sie das Erstellen, da wir uns keine Sorgen machen über "Wo ist das CSS, das ich dafür benötige?"
2- Theming-Formular JavaScript?
3- Stile überschreiben?

Diese Probleme bestehen von Anfang an, und in meinem Fall wurde alles durch eine einfache Ordnerstruktur plus eine "Seite. (CSS | less | sass)" mit @import -Regeln gelöst, die sich alle auf die Datei beziehen.

Könnte jemand erklären / erklären / teilen, warum es eine gute Idee ist, CSS in JS zu mischen?

Vielen Dank für Ihre Zeit!

Ich bin nicht der Autor des Pakets, aber das dynamische Erstellen von Stilen mit JS wird in letzter Zeit immer beliebter.

Es gibt eine Reihe von Problemen mit CSS im Allgemeinen. CSS wird mit einer Reihe von statischen Variablen kompiliert, wie z. B. der Größe Ihres Rasters, der Farbe Ihres Haupttyps usw. Sie können sie anschließend nicht mehr ändern, es sei denn, Sie wählen die betroffenen Elemente manuell aus und legen benutzerdefinierte Stile fest, die das kompilierte CSS überschreiben.

Wenn Sie CSS in JS einfügen, wird es vollständig dynamisch, und Sie können jede der zugrunde liegenden Variablen nach Belieben ändern. Dies bedeutet auch (insbesondere im Fall von React), dass Sie die relevanten Stile innerhalb der Komponente behalten können.

Ich bin jedoch nicht zu 100% davon verkauft. Es bedeutet auch, dass Sie kein Styling haben, bis der JS das Laden beendet hat. Keine große Sache im Fall einer App mit nur einer Seite, aber etwas, das in Zukunft einige Überlegungen rechtfertigen könnte. (Oder vielleicht geht das serverseitige Rendern bereits effizient damit um? Ich hoffe auch, von jemandem zu hören, der mehr Erfahrung damit hat.) Eine separate CSS-Datei bedeutet auch, dass der Browser die Stile parallel laden kann .

@dendril - Die Präsentation, die @vjeux hielt, beschreibt die Probleme mit CSS im Maßstab. Einige der Probleme, die die Verwendung von JS zum Erstellen von CSS löst, sind:

• Module, Variablen, Berechnungen und Mixins können vorhandene Tools verwenden, über die JS bereits verfügt - CommonJS-Module, JS-Variablen, JS-Ausdrücke, anstatt eine separate Syntax und eine Reihe von Tools verwenden zu müssen, um sie zu verwalten.
• Sie können vorhandene JS-Tools verwenden, um herauszufinden, wo auf einen bestimmten Stil verwiesen wird. Sie können dies mit FlowType und TypeScript fortsetzen, um Fehler bei der Kompilierung zu erhalten, wenn Sie beispielsweise einen Klassennamen falsch eingeben.
• Sie können die Struktur, das Erscheinungsbild und die Logik an einem Ort definieren. Dies ist ein nützlicher Schritt, um die Wiederverwendung von Komponenten zu vereinfachen. Webkomponenten lösen dieses Problem mit HTML-Importen. Alles mit einer Sprache zu definieren, ist ein anderer Ansatz.
• Dynamische Dinge mit CSS zu tun ist einfacher. Da sowohl das statische als auch das dynamische Design in derselben Sprache implementiert sind, können Sie Konstanten usw. zwischen ihnen teilen.

Als Beispiel habe ich hier eine Implementierung einer Schaltfläche für den Materialdesign-Stil mit TypeScript + -Inline-Stilen: https://github.com/robertknight/passcards/blob/master/webui/controls/button.ts .

• Das Thema + Struktur für die Schaltfläche befindet sich an einer Stelle, was für die Entwicklung und Wiederverwendung nützlich ist. Mithilfe einer IDE können Sie leicht herausfinden, wo auf bestimmte Elemente des Themas verwiesen wird.
• In der Funktion render () kann ich das Styling für die Schaltfläche abhängig von den Requisiten aufbauen, indem ich auf einfache Weise auf Teile des Themas verweise, ohne Klassennamenzeichenfolgen verketten zu müssen.
• Bei der Definition des Themas kann ich JS verwenden, um bestimmte Farben mithilfe von Formeln zu berechnen, die in der Materialdesignspezifikation angegeben sind (siehe colors.premultiplyColor() ).

Hier gibt es einen Kompromiss, der der übliche Kompromiss zwischen deklarativen und imperativen Ansätzen zur Spezifizierung von Dingen ist. Die imperative Sprache (JS) gibt Ihnen viel Kraft. Die Syntax ist ausführlicher und die Flexibilität ist jedoch offen für Missbrauch. Bei komplexen Komponenten mit viel dynamischem Design ist die Balance für JS von Vorteil. Für statisches Styling, das sich leicht in CSS ausdrücken lässt, nicht so sehr. Ich würde diesen Ansatz nicht für dokumentähnliche Inhalte verwenden.

@msikma - Das Angeben von Stilen in JS muss nicht bedeuten, dass Inline-Stile verwendet werden oder auf das Laden Ihrer App gewartet wird. Sie können JS nur als Sprache für die Erstellung der Stile verwenden, die bis zu JS kompiliert werden - im Grunde eine Alternative zu SASS oder LESS. Kombinieren Sie dies mit serverseitigem Rendering, und die tatsächliche Ausgabe, die der Browser erhält, kann CSS ziemlich ähnlich sehen, und das funktioniert gut mit Browser-Entwicklungstools.

@robertknight Vielen Dank für Ihre Antwort. Sie haben gerade genug Informationen hinzugefügt, um die Idee vollständig zu verstehen.

Ich bevorzuge die Entwicklung von SASS / LESS, anstatt der Show mehr JavaScript hinzuzufügen. Wenn Sie am Ende Mechanismen wiederverwenden möchten, können wir LESS verbessern, das in JavaScript codiert ist, und so viel wiederverwenden, wie wir von JavaScript wollen, aber es scheint Es ist einfach, eine neue API zu entwerfen und alles in einer Datei zu mischen.

Ich hoffe, wir finden eine bessere Lösung, denn die deklarative Idee von CSS zu verlieren, ist keine gute Idee, und weniger, wenn wir alles deklarativ statt imperativ machen. \Ö/

@msikma - Das Angeben von Stilen in JS muss nicht bedeuten, dass Inline-Stile verwendet werden oder auf das Laden Ihrer App gewartet wird.

Ist es möglich, Stile global zu deklarieren (indem ein Stilelement dynamisch erstellt wird)? Ich würde es mir vorstellen, da das wichtig ist.

Wie vermeiden Sie es jedoch, auf das Laden des JS warten zu müssen?

@msikma - Ja. In dem Beispiel, mit dem ich verlinkt habe, wird das gesamte Styling in der 'theme'-Variable, die oben in der Datei definiert ist, zur Erstellungszeit in CSS kompiliert. In der Funktion render () gibt es Aufrufe von style.mixin (theme.someElement, otherProps), die ein Objekt mit einer className-Eigenschaft zurückgeben, die die übliche durch Leerzeichen getrennte Liste von Klassennamen ist. Wenn Sie React auf dem Server ausgeführt haben, erhalten Sie eine normale HTML-Zeichenfolge mit Elementen mit den Attributen 'class' und 'style', die auf dem Client gerendert werden können, ohne dass Code ausgeführt wird.

@dendril - Die Alternative zu deklarativem CSS muss nicht unbedingt JS sein. Das JS kann funktional / deklarativ geschrieben werden - das gesamte statische Styling kann ein einfaches Javascript-Objekt sein. Wenn Sie im dynamischen und im statischen Stil auf dieselbe Konstante (z. B. eine Farbe oder Schriftgröße) verweisen müssen, ist dies ganz einfach.

Danke für die Erklärung, hört sich sehr gut an.

Ich komme gerade in diesen Thread, bin aber interessiert, weil ich versuche, ein Projekt mit material-ui zu entwickeln. Ich hatte auf die SASS-Version umgestellt, festgestellt, dass in material-ui kein Rastersystem implementiert ist, und dann festgestellt, dass die SASS-Version nicht synchron ist. Ich bin also sehr gespannt, in welche Richtung dieses Projekt in Zukunft gehen wird. Es scheint, als gäbe es so viele Kompromisse beim Einfügen des CSS in die Komponenten selbst, dass es keine klare Wahl ist. Intuitiv finde ich die Idee etwas gefährlich, weil es eine so radikale Abkehr von bisher etablierten Webentwicklungspraktiken ist. Auf der anderen Seite ist auch React!

@ hai-cea Hast du die JSS-Bibliothek in Betracht gezogen? Ich habe es für ein neues React-Projekt verwendet, an dem ich gearbeitet habe, und bis jetzt gefällt es mir wirklich gut. Das Schöne ist, dass Sie die Möglichkeit haben, globale Klassennamen zu deklarieren, wenn dies in seltenen Fällen erforderlich ist. So ziemlich alles, was Sie in CSS tun können, können Sie in JSS tun, da es eigene Klassen mit Namespace erstellt und diese einem <style> -Tag im <head> hinzufügt.

Es gibt ein neues Projekt zu React-Stilen für Ihre Überlegung. Hier ist ein Link: Radium

Ich habe gerade diesen Thread gesehen und wünschte, ich wäre früher darauf gestoßen. Wir machen CSS in JS unter einem iOS-Thema, das in reapp-ui enthalten ist . Es war einige Monate vor der Veröffentlichung in der Entwicklung.

Eigentlich @ hai-cea bin ich auf einem sehr ähnlichen System gelandet wie deins.

1. Laden Sie " Konstanten " (denken Sie: Farben, Merkmalserkennung). Wir führen tatsächlich zwei Konstantenebenen durch: erstens die Erkennung von Merkmalen und Farben, zweitens die Konstanten für bestimmte Komponenten .
2. Stile für Komponenten laden. Diese haben tatsächlich eine einheitliche Struktur. Objekte mit Schlüsseln, die "ref" => "stylesObj" sind.
3. Animationen laden.

So laden Sie ein Thema zusammen mit den drei Elementen. Und so laden Sie Basisthema mischen und mit Ihren eigenen Variablen abgleichen, um es zu "thematisieren".

Dies hat einige wirklich großartige Vorteile:

1. Benutzer müssen keine zusätzlichen Stile laden, die sie nicht benötigen.
2. Komponenten haben konsistente Namen und Stildeklarationen.
3. Alles ist auf jeder Ebene thematisierbar.
4. Einfach, Themen für andere Plattformen hinzuzufügen.

Wir verwenden für all das den Reaktionsstil und es hat wirklich gut funktioniert. Zusammen mit einem Styled-Mixin , mit dem wir wirklich großartige deklarative Stile hinzufügen können. Das und das Tappable-Mixin geben auch Fokus / Aktiv-Zustände an. Beide werden in kurzer Zeit extrahiert.

Es gibt tatsächlich ein bisschen mehr, was ich bald in offiziellen Dokumenten schreiben möchte.

Unser nächster Schritt besteht darin, ein materielles UI-Thema in Reapp zu erstellen, und ich habe dieses Projekt für eine Weile mit einem Lesezeichen versehen, um darauf zurückzukommen. Ich frage mich, ob wir nicht zusammen daran arbeiten könnten!

@ hai-cea Ihr Theme -Objekt würde tatsächlich sehr gut in die Kontextfunktion von React passen. Falls Sie damit nicht vertraut sind, handelt es sich bei dem Kontext im Grunde genommen um Requisiten, die automatisch an Ihre Komponentenhierarchie weitergegeben werden. Auf jeder Hierarchieebene können Komponenten ihren Kontext nach einem bestimmten Wert abfragen.

In Ihrem Fall würde ich empfehlen, eine Variable theme für den Kontext festzulegen. Es würde ungefähr so ​​funktionieren:

var App = React.createClass({
  childContextTypes: {
    theme: React.PropTypes.instanceOf(Theme)
  },
  getChildContext() {
    return {
      theme: CustomTheme
    };
  },
  // ...

Dann könnten Sie in Ihrer <Button> -Komponente tun

var Button = React.createClass({
  contextTypes: {
    theme: React.PropTypes.instanceOf(Theme)
  },
  getTheme() {
    return this.context.theme || DefaultTheme;
  },
  render() {
    return <button style={this.getTheme().getButtonStyle()}>...</button>;
  }
});

Dinge, die ich an diesem Ansatz mag:

• Es gibt kein globales Theme Objekt
• Ein ganzer Abschnitt der Benutzeroberfläche kann nur durch Ändern des Kontexts in einer einzelnen übergeordneten Komponente thematisiert werden (denken Sie daran, ein ganzes Modal mit einer Deklaration zu thematisieren).

Wie auch immer, tolle Arbeit, die ihr hier macht. Ich hoffe das hilft :)

Hy!
Ich habe eine Bibliothek zum Schreiben von CSS in Reaktionsansichten erstellt. Schauen Sie sich Folgendes an: //github.com/hackhat/smart-css

Was es tut: Schreiben Sie CSS in JavaScript mit Namespaces, Eigennamen, keinen Konflikten und erwarteten Ergebnissen für react.js.

@mjackson Ich mag Ihren Ansatz, den Themenkontext in der Hierarchie nach unten zu senden, sehr, aber diesen Teil

this.getTheme (). getButtonStyles ()

Ist nicht ziemlich skalierbar, da das Thema über den Stil Bescheid wissen sollte. Ich denke, das Thema sollte ein Name, eine Farbpalette und einige Abstandsdefinitionen sein, aber kein vollständiger CSS-Stil. Dies würde wirklich anpassbare und skalierbare Komponenten und Apps ermöglichen.
Was denken Sie?

@ Jackson Ich mag den Kontext Idee. Wir verwenden einen Dekorateur, der im Grunde das Gleiche tut.

@hackhat Ja , wenn Sie Ihre Konstanten richtig machen, können Sie so viele laden, wie Sie möchten, damit Sie sie

Wie auch immer, viel Glück mit allem! Ich denke, wir gehen in die gleiche Richtung, aber das ist gut so. Wenn Sie an einer Zusammenführung interessiert sind, setzen Sie sich mit uns in Verbindung. Da wir eine wirklich große Auswahl an Dingen für iOS und Sie Android entwickelt haben und uns ziemlich intensiv mit CSS / JS-Dingen befasst haben, könnte dies nützlich sein. In beiden Fällen habe ich hier einige Dokumente hinzugefügt, die dazu beitragen: https://github.com/reapp/reapp-ui/issues/29.

Tut mir leid, Threadjack, ich habe gerade eine Gelegenheit für Teamwork gesehen: +1:

@natew Freut mich über Ihr Projekt zu hören. Es sieht so aus, als wären wir auf dem richtigen Weg. :) :)

@mjackson Vielen Dank, dass Sie mir von der Kontextfunktion von React erzählt haben. Ich hatte sie noch nie zuvor verwendet, habe sie jedoch auf der Reaktionskonferenz erwähnt und auch in React Router verwendet gesehen. Scheint eine großartige Lösung zu sein - ich werde es auf jeden Fall ausprobieren.

Wir haben ziemlich gute Fortschritte beim Verschieben von Stilen in js gemacht. Ich denke, einer der größten Vorteile, die ich sehe, ist, dass wir die Stile der einzelnen Komponenten genauer beschreiben. Bisher hatten wir nicht das Bedürfnis, eine Bibliothek wie JSS, Radium oder React Styles aufzurufen. Obwohl ich sonst überzeugt werden kann.

Ich freue mich darauf, diese Architekturänderung abzuschließen, damit wir unsere vorhandenen Komponenten wieder härten können.

Wird diese Änderung es schwierig machen, die Standardstile zu überschreiben?

@ DylanPiercey tolle Frage. Wie @ hai-cea erwähnte, hatten wir nicht das Bedürfnis, Styling-bezogene Bibliotheken zu verwenden. Alle Komponentenstile werden inline definiert, sodass keine Less-Dateien mehr vorhanden sind (außer denen auf der Docs-Site).

Dies ist derzeit unser Ansatz zum Überschreiben von Stilen:

• Komponenten erhalten außerdem eine style -Stütze, um die Inline-Stile eines Komponentenstammelements zu überschreiben. Dies wird vom StylePropable- Mixin durchgeführt.
  
  
  
  • Einige Komponenten verfügen über zusätzliche Requisiten für die Gestaltung interner Komponentenelemente. Komponenten ohne diese zusätzlichen Requisiten können diese Stile nicht überschreiben. Dies ist eine erwartete Änderung nach Abschluss des Refactorings. Wir würden gerne Ihre Gedanken dazu hören. Unsere Argumentation war, dass das Überschreiben dieser Stile von den Materialdesign-Spezifikationen abweicht.
  
  
• Für Benutzer, die noch Less verwenden, erhalten Komponenten eine className -Stütze für ihr Root-Element, sodass Benutzer zusätzliches Styling hinzufügen können (dies ist der aktuelle Zweck für unser Classable- Mixin).
• Eine weitere wichtige Änderung ist das Entfernen aller Less-Dateien einschließlich der Less-Variablen. Dies ändert mui von einem CSS-Framework und einer Menge von Reaktionskomponenten zu einer einzigen Menge von Reaktionskomponenten. Wir glauben, dass diese Verschiebung angemessener ist, da wir weiterhin mehr Material Design-Komponenten fertigstellen.

Eine letzte Sache: Wir werden auch eine Themendatei unter Verwendung der von Kontextfunktion von bereitstellen .

Was denken alle über diesen Ansatz?

Übrigens haben wir Theming über den Kontext mit reapp-ui veröffentlicht . Du machst es so:

const theme = {
  styles: {
    List: {
      self: { background: '#000', ... }
    }
  },
  animations: {},
  constants: {}
}

// top level component
export default React.createClass({
  render() {
    return (
      <Theme {...theme}>
        <RouteHandler />
      </Theme>
    );
  }
});

In der Themendatei erfahren Sie, wie der Kontext festgelegt wird:
https://github.com/reapp/reapp-ui/blob/4355556dee24407e5e7827df7a484944aeaf32cc/helpers/Theme.jsx

Wir fanden es auch hilfreich, Konstanten als Ebene der ersten Ebene zu verwenden, damit Sie alle Arten von Eigenschaften von isRetina bis listBorderColor festlegen können. Diese Konstanten werden dann an Stile übergeben, wenn sie über den Helper geladen werden . Verwendung wie folgt:

import UI from 'reapp-ui';

UI.addConstants({
  borderColor: '#000'
});

UI.addStyles({
  List: c => ({
    firstItem: {
      border: `1px solid ${c.borderColor}`
    }
  })
})

// exports the theme object you need for the <Theme /> helper
export default UI.makeTheme()

Ich dachte, das könnte hilfreich sein, wenn ihr euch darauf einlässt.

@natew Ich habe mich diesem Ansatz c näher erläutern? Ich bin mit der Fettpfeilfunktion von ES6 nicht allzu vertraut. Ist c der neue Konstantenparameter? Derzeit werden Inline-Stile mithilfe der flachen Zusammenführung von React über unser StylePropable-Mixin überschrieben .

Diese Methode behandelt jedoch keine verschachtelten JSON-Objekte, es sei denn, sie werden explizit übergeben. Wir haben über die Verwendung einer rekursiven Zusammenführung gesprochen, dies ist jedoch teuer, da jede Komponente die Zusammenführungsfunktion mehrmals verwenden würde. Angesichts der Tatsache, dass wir bereits ES6 verwenden, sieht dies vielversprechend aus.

Ich liebe die Idee, das CSS von material-ui in Javascript umzugestalten!

Aber ich hatte einige schlimme Probleme, als ich versuchte, Inline-Stile in JS anstelle von WENIGER in einem meiner Projekte zu verwenden ...

Safari: Fehler im Ripple-Stil bei Schaltflächenkomponenten

Das größte Problem war dieses: https://github.com/callemall/material-ui/issues/496
Ich konnte die Safari-Probleme nur mit grunt-autoprefixer umgehen
Aber autoprefixer funktioniert nur für WENIGER / CSS. Zu diesem Zeitpunkt musste ich Inline-Stile aufgeben und meine App auf WENIGER umschreiben. (Das war ein Mist ...)

Pseudo-Stile und Medienselektoren werden nicht unterstützt

Einige CSS-Funktionen wie alle Pseudostile und Medienselektoren werden von den Inline-Stilen von react nicht unterstützt. Am Anfang habe ich WENIGER für die fehlenden Teile und Inline-Stile für den Rest verwendet.

Automatisches Anhängen von "px" an Zahlen

Es gibt eine Reihe von Eigenschaften, bei denen Inline-Stile reagieren, um px an eine Zahl anzuhängen. Zum Beispiel wird aus order: 1 order: 1px , was Unsinn ist.
Der Umgang mit unerwünschten px scheint ein häufiges Problem zu sein, siehe https://github.com/facebook/react/pull/3499

Schlechte Minifizierungsunterstützung

Ich muss für meine Projekte den Closure Compiler von Google mit ADVANCED_MODE verwenden . Als ich versuchte, React Inline-Stile zu verwenden, habe ich mindestens diese Eigenschaften extern bereitgestellt:

/**
* <strong i="27">@type</strong> {*}
*/
var __REACT_DEVTOOLS_GLOBAL_HOOK__;

/**
* <strong i="28">@type</strong> {*}
*/
var Symbol;

/**
* <strong i="29">@type</strong> {*}
*/
var MSApp;

Außerdem musste ich Zeichenfolgen für Eigenschaftsnamen wie backgroundSize und float .
Zum Beispiel anstatt zu verwenden

var iconStyle = {
  backgroundSize: "300px 400px",
  float: "left"
};

Ich musste stattdessen Zeichenfolgen verwenden, um mit dem Closure Compiler von Google in ADVANCED_MODE kompilieren zu können

var iconStyle = {
  'backgroundSize': "300px 400px",
  'float': "left"
};

Aber abgesehen von diesen Problemen war alles in Ordnung!
Versteh mich nicht falsch: Ich denke, Inline-Stile sind der richtige Weg. Es gibt nur ein paar Unebenheiten entlang der Straße. Ich hoffe, dass all diese Probleme von Facebook, dh @vjeux, angegangen werden.

Dank aller Beiträge konnten wir gestern den weniger Refactor für Inline-Styles fertigstellen! Der aktuelle Master enthält eine Vorabversion von v0.8.0, die ihr euch ansehen könnt, und wir würden uns über jedes Feedback freuen, das ihr habt.

Sie können die Dokumentensite auch lokal ausführen, um die aktualisierte Dokumentation zu lesen. Hier einige Highlights zu dem, was wir erreichen konnten:

1. Alle Komponentenstile werden jetzt inline ausgeführt. Dies ermöglichte es uns nicht nur, die Stile der einzelnen Komponenten genauer zu beschreiben, sondern machte auch jede Komponente viel portabler. Da es keine externe Abhängigkeit von weniger / CSS gibt, sollten Sie nur jede Komponente benötigen, die Sie benötigen. Außerdem stehen Stile aus der MUI-Bibliothek nicht in Konflikt mit Stilen aus Ihrer eigenen App.
2. Die Anpassung kann auf 2 Ebenen erfolgen. Sie können Themenvariablen, die alle untergeordneten Komponenten betreffen, mithilfe des Themenkontextobjekts überschreiben. Außerdem akzeptiert jede Komponente eine Stilstütze, mit der Sie eine feinere Kornanpassung implementieren können.
3. Die automatische Herstellerpräfixierung erfolgt durch Feature-Erkennung mithilfe eines benutzerdefinierten, leichten Builds von Modernizr. Präfixierung wird nur bei Bedarf durchgeführt und ist der beste Teil? Es wird automatisch für Sie in jeder Komponente durchgeführt.

Ich möchte diesen Bake für ein oder zwei Wochen im Master haben, bevor ich ihn veröffentliche. In dieser Zeit werden wir daran arbeiten, Beispielcode zusammenzustellen und einige der Site-Stile für Dokumente in Inline-Stile zu konvertieren.

Nochmals vielen Dank für alle Beiträge und Geduld. Wir freuen uns sehr darauf, dies zu veröffentlichen und wieder Probleme zu lösen und neue Komponenten hinzuzufügen. :) :)

Müssen wir etwas anderes tun, als nur die Komponenten zu verwenden?

Beachten Sie, dass ich versuche, es als Meteor-Paket zu verpacken (im Wesentlichen mithilfe von browserify, um alle Komponenten zu bündeln), und möglicherweise etwas falsch mache.

Sieht so aus, als müssten wir einen ThemeManager instanziieren und ihn als untergeordneten Themenkontext für eine Komponente festlegen, in der wir Material-UI-Komponenten verwenden.

BEARBEITEN: theme wurde in muiTheme

Hallo @ukabu , ThemeManager muss nur an der äußersten Komponente Ihrer App instanziiert werden. Es wird dann an alle seine Kinder und Enkel weitergegeben. Weitere Informationen zur Kontextfunktion von React finden Sie hier und hier .

Fügen Sie diesen Code in Ihre äußerste Komponente ein:

Wenn Sie ES6 verwenden

var React = require('react');
var mui = require('mui');
var ThemeManager = new mui.Styles.ThemeManager();
class OuterMostParentComponent extends React.Component {
  // Important!
  getChildContext() { 
    return {
      muiTheme: ThemeManager.getCurrentTheme()
    };
  }
};
// Important!
OuterMostParentComponent.childContextTypes = {
  muiTheme: React.PropTypes.object
};
module.exports = OuterMostParentCompone

Wenn Sie ES5 verwenden

var React = require('react');
var mui = require('mui');
var ThemeManager = new mui.Styles.ThemeManager();
var OuterMostParentComponent = React.createClass ({
  // Important!
  childContextTypes: {
    muiTheme: React.PropTypes.object
  },
  // Important!
  getChildContext: function() { 
    return {
      muiTheme: ThemeManager.getCurrentTheme()
    };
  }
});
module.exports = OuterMostParentComponent

Weitere Dokumentationen zur Verwendung von Designs finden Sie, wenn Sie die Dokumente lokal ausführen und zu #/customization/themes

Vielen Dank. Es funktioniert jetzt: +1:

Jetzt, da alle Stile inline sind, müssen wir noch ein CSS zurücksetzen. Es scheint, dass der src / tree keine CSS-Dateien oder weniger enthält. Planen Sie eine hinzuzufügen?

@ hai- cea @mmrtnz Herzlichen Glückwunsch! Haben Sie Rezepte für Code, der auf CSS-Pseudoklassen basiert ? Ich werde :hover sicher vermissen, siehe https://github.com/reactjs/react-future/issues/13 . @vjeux empfiehlt die Verwendung von onMouseOver aber das ist ein Schmerz. Enthält 0.8.0 einen praktischen Ersatzcode für :hover ?

@paradie Ich habe es mir anders

<div
  style={{color: 'blue'}} 
  hoverStyle={{color: 'red'}}
/>

@vjeux sprechen Sie auf der Ebene des React-Frameworks oder würden Projekte dies individuell implementieren? denn auf der Framework-Ebene wäre das spannend ...

Es bittet jedoch um einige Variationen wie pressedStyle focusedStyle disabledStyle (für Eingaben) usw.

Herzlichen Glückwunsch auch an alle, die an diesem großen Erfolg gearbeitet haben: Lächeln:

Ich habe mich gefragt, ob es vielleicht besser ist, einen spezifischeren Kontextschlüssel für das Thema zu verwenden. zB muiTheme - dann würde dies nicht in Konflikt geraten, wenn es eine andere Bibliothek auf der Seite geben würde, die ebenfalls diesen Kontextschlüssel verwenden möchte, oder wenn ich context.theme in meiner App für meine verwenden möchte eigenes Ding.

@vjeux Das gefällt mir!

@ Paradie

Dies ist ein Dienstprogramm, mit dem ich experimentiert habe, um das Hover-Styling etwas weniger nervig zu machen ...

'use strict';

const React = require('react');

const withHoverStyle = (Component, compType) => {
  class ComponentWithHover extends React.Component {
    _handleMouseOver() {
      const theme = this.context.theme.component[compType];

      React.findDOMNode(this).style.backgroundColor = theme.hoverColor;
    }

    _handleMouseOut() {
      const theme = this.context.theme.component[compType];

      React.findDOMNode(this).style.backgroundColor = theme.color;
    }

    render() {
      const hoverProps = {
        onMouseOver: this._handleMouseOver.bind(this),
        onMouseOut: this._handleMouseOut.bind(this)
      };

      return React.createElement(Component, Object.assign({}, this.props, hoverProps));
    }
  }

  ComponentWithHover.contextTypes = {
    theme: React.PropTypes.object
  };

  return ComponentWithHover;
};

module.exports = withHoverStyle;

https://github.com/troutowicz/geoshare/blob/css-in-js/app/utils/withHoverStyle.js

Kann so verwendet werden:

'use strict';

const React = require('react');
const FlatButton = require('material-ui/lib/flat-button');

const withHoverStyle = require('../utils/withHoverStyle');

class AuthButton extends React.Component {
  render() {
    return <FlatButton {...this.props} />;
  }
}

AuthButton.propTypes = {
  label: React.PropTypes.string,
  onClick: React.PropTypes.func
};

AuthButton.defaultProps = {
  label: 'Login',
  onClick() {}
};

module.exports = withHoverStyle(AuthButton, 'flatButton');

https://github.com/troutowicz/geoshare/blob/css-in-js/app/components/AuthButton.jsx

Ich möchte es auf der React-Ebene und auch auf der Dom-Ebene :) Unklar, wann ich die Zeit habe, es zu implementieren

@troutowicz Danke fürs Teilen!

Hy!
Ich habe gesehen, dass Sie eine Weile über CSS in JS sprechen. Hier ist ein CSS im JS-Lib-Vergleich https://github.com/hackhat/css-in-js-comparison . Bereits Bewertungen 3 Bibliotheken, könnte interessant sein, die verschiedenen Ansätze für dieses Problem zu sehen.

Schauen Sie sich auch https://github.com/hackhat/smart-css an . Sie benötigen onMouseOver nicht, um ": hover" hinzuzufügen.

Hatte jemand Feedback zu meiner Idee, einen anderen Kontextschlüssel für theme ? zB muiTheme

@vjeux Wenn du mich in die richtige Richtung

Ich hoffe, dass dies mit anderen Reaktionsmodulen, die vom Kontext abhängen, vollständig getestet wird, da ich bisher auf mindestens eine Bibliothek gestoßen bin, die den Kontext anderer Bibliotheken blockiert - flocks.js. Der Autor dort arbeitet daran, aber bitte stellen Sie sicher, dass material-ui den React-Router oder andere Module, die Kontexte verwenden, nicht blockiert. Tolle Idee, ich freue mich über Inline-Stile und hoffe, dass dies unser Leben für die Verwendung von Material erleichtert. UI: +1:

@JedWatson Ja, ich denke es ist eine großartige Idee. Das werden wir auf jeden Fall tun.

@ hai-cea genial, froh es zu hören: lächeln:

@anyong / any -

@bparadie Ich möchte in naher Zukunft ein Mixin oder eine Klasse wie @troutowicz 'Beispiel für Pseudo-Selektoren hinzufügen, aber für den onMouseOver . Obwohl ich damit einverstanden bin, dass es ein Schmerz sein kann.

@JedWatson Das ist eine großartige Idee, ich werde in Kürze ein Update machen.

@ukabu Derzeit gibt es keine Pläne zum Lesen einer resets.css -Datei. Wir haben uns dafür entschieden, dass Material-UI nicht mehr nur ein CSS-Framework, sondern nur noch eine Reihe von React-Komponenten ist. Die resets.css können jedoch online gefunden werden, wenn sie benötigt werden.

@mmrtnz Ich verstehe, aber wie es gerade ist, werden einige Komponenten mit den Benutzeragentenstilen nicht richtig angezeigt. Beispiel: Wenn ich kein CSS einbinde, haben h1 obere Ränder (Benutzeragentenstil), die verhindern, dass der Titel AppBar richtig ausgerichtet wird.

@ukabu Ich verstehe, was du meinst, danke, dass du darauf hingewiesen hast. Komponenten, deren Stile von resets.css und anderen zugehörigen Support-CSS-Dateien abhängen, wurden inline neu definiert. Dies scheint ein Beispiel zu sein, das ich beim Refactoring verpasst habe. Wenn weitere Probleme im Zusammenhang mit der Notwendigkeit von resets.css oder einem anderen Stylesheet gefunden werden, können wir diese wieder hinzufügen, jedoch nicht, bevor wir versuchen, das Problem zuerst auf Komponentenebene zu lösen.

Für Schwebeflug usw. habe ich # 684 geöffnet.

Vielen Dank an alle für diese tolle Diskussion. Wir konnten diese Funktion in Version 0.8 veröffentlichen.

Ich freute mich darauf, diese Bibliothek zu verwenden, aber zu sehen, dass alles Inline-Stile verwendet, war eine große Ablehnung. Ich verstehe nicht, warum Sie dies tun würden. Ich habe die Folien darüber gelesen, warum dies getan wurde, aber es macht keinen Sinn, warum Erscheinungsbild und Ansichten zusammengeführt werden und Logik in eine einzige Sache, Trennung von Anliegen Menschen, das ist eine der solidesten Aussagen für Software-Engineering.

Pablo, diese Bedenken sind nicht getrennt. Wenn Sie möchten, dass die Dinge aussehen
anders kann man den Theme Manager verwenden, eine echte Trennung von Anliegen.
Im Übrigen sind die Komponenten und ihre HTML- und CSS-Funktionen genau aufeinander abgestimmt
gekoppelt, und das zu trennen macht die Dinge nur komplexer.

Am Sonntag, 23. August 2015, 05:35 Uhr schrieb Pablo Fierro [email protected] :

Ich freute mich darauf, diese Bibliothek zu nutzen, sah aber, dass alles verwendet wurde
Inline-Stile waren eine große Ablehnung, ich verstehe nicht, warum Sie tun würden
Hier habe ich die Folien gelesen, warum es gemacht wurde, aber es macht keinen Sinn, warum zusammenführen
Aussehen, Ansichten und Logik in einer einzigen Sache, der Trennung von Bedenken
Leute, das ist eine der solidesten Aussagen für das Software-Engineering.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/callemall/material-ui/issues/30#issuecomment -133778140
.

Wout.
(auf dem Handy getippt, entschuldigen Sie die Knappheit)

Ich stimme @pablofierro zu - Inline-Stile können vom Browser nicht zwischengespeichert werden, und wir verlieren ziemlich grundlegende CSS-Funktionen wie :hover , Geschwister-Selektoren oder die Vorstellung von kaskadierenden Stilen.

Es ist ein Kompromiss, Inline-Stile zu verwenden, um statische clientseitige Apps zu aktivieren und Abhängigkeiten von Vorverarbeitungs-Toolchains (Webpack usw.) zu vermeiden. Größere Projekte werden jedoch mit der zusätzlichen Funktion (am häufigsten isomorphe Apps) heruntergelassen. Ich würde die Option lieben, externe Stylesheets oder die Unterstützung von CSS-Modulen zu verwenden , aber es würde die einfacheren Fälle durcheinander bringen.

@ grrowl- Kaskaden gelten in großen Stylesheet-Codebasen ohnehin als schlechte Praxis. Siehe zB BEM- Ansatz.

@ Kagami als schlechte Praxis von wem? Wenn Sie Ihre Stylesheets in wiederverwendbare Module aufteilen (ähnlich der Reaktionsphilosophie), ist dies in hohem Maße wartbar. Selbst auf der Webseite von React wird erwähnt, dass es sich um die Ansicht Ihrer Komponenten und nicht um das Erscheinungsbild handelt. Diese Entscheidung, alles inline zu zwingen, ist einfach lächerlich.

Dies muss geändert werden. Inlining hat sicherlich in einigen Anwendungsfällen seine Vorteile, aber das resultierende Markup ist:

• aufgebläht - eine Tonne Bandbreite wird verbraucht, nur um den Stil herunterzusenden. In jeder Anfrage. 5-fach größer sein könnte Mühle App. Und was ist, wenn Sie eine App mit vielen, vielen DOM-Knoten haben? Und wie wirkt sich das auf den Speicheraufwand und die Leistung aus? Dies bringt eine ganze Reihe von Implikationen mit sich, mit denen wir uns nicht befassen sollten.
• hässlich - viel Spaß beim Lesen dessen, was es erzeugt, es ist ungefähr so ​​angenehm wie das Lesen von rohen / unformatierten minimierten CSS.
• und _stupid_ - bis zur CSS 1-Spezifikation enthielt der WW3C aus einem bestimmten Grund Klassen. Dieses Styling bietet die Flexibilität / das Rapid Prototyping / die Funktionalität, die die Community durch die Erstellung von LESS / SCSS / etc. Gewonnen hat. usw. aus dem Fenster. Sie können bereits sehen, wie das Rad neu erfunden wird. Scrollen Sie durch diesen Thread und sehen Sie sich alle Kommentare an, die verschiedene Bibliotheken / was auch immer vorschlagen, um das CSS aus Javascript zu extrahieren.

Aber warte! Es gibt mehr:

• Keine sofort einsatzbereite IDE-Unterstützung
• Keine Pseudoklassenunterstützung

Leute: _das ist etwas, was jquery tun kann_. Warum müssen wir das bis an die Oberfläche ausgraben? außerdem standardmäßig erzwingen?

Ein lustiger Fallbeispiel

Öffnen Sie die Chrome Developer Tools
Versuchen Sie, einige Stiländerungen an einer Seite vorzunehmen, die mehrere Mui-Komponenten desselben Typs enthält, z. Die <MenuItem ...> in einem Navigationsmenü._

es ändert nur diese Komponente. Was ist mit React Devtools? Nein, das Gleiche.

Ich will kein Schwanz sein - obwohl ich mit Sicherheit wie einer klinge, aber wie .css macht keinen Sinn.

Ich sollte hinzufügen; Ich würde mehr als glücklich sein, eine PR zu erstellen. Ich möchte nur hören, was die Community über die Neuimplementierung zu sagen hat. hoffentlich zu einer Art Konsens über die Vorgehensweise kommen.

Was schlagen Sie stattdessen vor? Für meinen Anwendungsfall (Cordova App) ist der Inline-Ansatz Relais großartig.

@oliviertassinari Es scheint, dass der größte Vorteil von Inline-Stilen darin besteht, dass das Projekt kein externes Stylesheet als Abhängigkeit benötigt.

Wenn dies der Fall ist, würde ich empfehlen, wieder zu Klassen zurückzukehren (wie es scheint, dass viele das wollen und es die Dinge einfacher zu machen scheint) und stattdessen das gesamte CSS über eine Zeichenfolge verfügbar zu machen.

/*styles.css for people who are fine with a separate file*/
.my-styles {...}

// styles.js (expose as "material-ui/theme" or something)

var css = { __html: "injected styles.css content" };

// alternatively we could expose a component.
module.exports = (
    <style dangerouslySetInnerHTMLIfYouAreSureItIsWhatYouWantToDo={ css }/>
);

Auf diese Weise können Benutzer das Thema direkt mit JavaScript verwenden, indem sie:

theme = require("material-ui/theme");

MyJSX = (
    <div>{ theme }</div>
);

Vorteile:

• Es ist nur CSS
• möglicherweise mehrere Themen, ohne dass alles gebündelt wird
• kann über js, css pre processor oder manuell in html importiert werden.

Nachteile:

• Es wurde eine Menge Zeit damit verbracht, alle Stile inline zu machen.

@rozzzly +11111110000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Mit MUI -> http://recordit.co/9mBknPLZUb
Ohne MUI -> http://recordit.co/6MkzWhQiBt

Nun, @rozzzly, ich bin anderer Meinung.

• aufgebläht . Sicher, wir verwenden mehr Bandbreite, um den Stil zu senden, wenn der Benutzer auf der Site ankommt.
  Latenz und nicht Bandbreite sind jedoch der Leistungsengpass für die meisten Websites. für mehr Details .
  Ich denke also, dass das Senden des Stils beim ersten Rendern nach unten verschoben wird. Und genau das ist für die Benutzer wirklich wichtig. Sie müssen nicht auf die RTT (Roundtrip-Zeit) warten, um den Stil zu erhalten.
• hässlich . Ja, es ist nicht leicht zu lesen. Warum musst du es lesen?
• und dumm . Facebook erklärte ihre Motive für die Verwendung von Inline-Stil. Es ist ziemlich überzeugend. Der Link

Ich verwende seit mehr als 6 Monaten ausschließlich Inline-Stile und es war eine befreiende Erfahrung. Stile sind handlicher, flexibler und mit weitaus weniger Überraschungen im Vergleich zu CSS geworden.

Ich persönlich stimme @rozzzly zu, der die Probleme gut beschreibt. Dies ist im Maßstab einfach keine gute Idee. CSS funktioniert. Wir erfinden das Rad neu, nur damit es "tragbarer" ist. Diese verrückte Veränderung läuft darauf hinaus, ein Problem zu beheben - einschließlich CSS. Dies würde 1 Erklärungszeile in der Readme-Datei erfordern. Ganz zu schweigen davon, dass selbst Anfänger mit der Integration von CSS in HTML oder mit ihrem Build-Tool bestens vertraut sind. Das sind keine neuen Leute.

Stattdessen erstellen wir das Styling für Webseiten in JS neu. Es scheint nur albern. Absolut grundlegende Styling-Funktionen wie Pseudo-Elemente? Weg. SASS / WENIGER Zusammenstellung? Weg.

Hallo allerseits. Ich habe angefangen, material-ui in einem Nebenprojekt zu verwenden und habe die Diskussion hier und hier verfolgt .

Ich wollte der Mischung ein paar Punkte hinzufügen:

Ist dies für kleinere Anwendungen sinnvoll?
Ich habe viele kleinere interne Web-Apps für Unternehmen geschrieben, die Bootstrap und dergleichen verwenden. Ich habe nie viel Schmerz empfunden, als ich neben dem Markup und js noch mehr Komponenten-CSS einfügen musste. Es ist eine einmalige Anstrengung. Konflikte waren sehr selten ein Problem und die meiste Zeit leicht zu lösen.

Aber ich habe definitiv Schmerzen, wenn ich jetzt das DOM in meinen Devtools betrachte. Selbst das Sehen der grundlegenden Baumstruktur ist bei allen Inline-Stilen viel schwieriger. Und dieser Schmerz ist keine einmalige Sache - er kommt jedes Mal zurück, wenn ich Devtools öffne.

Entfremden wir hier CSS-versierte Designer mit diesem Ansatz?
Mit all den in JavaScript eingebetteten Stilen scheint es für Designer schwierig zu sein, Arbeiten in CSS-Dateien zu entwerfen und zu bearbeiten. Sind sie jetzt nicht gezwungen, JavaScript, ES6, Transpiler, Buildtools usw. zu lernen, und es ist viel wahrscheinlicher, dass sie etwas kaputt machen?

Vielleicht ist das keine schlechte Sache - ich bin alles für funktionsübergreifende Teams und habe noch nicht mit "Komponentendesignern" zusammengearbeitet, aber ich möchte sicherstellen, dass Designer auch in dieser Diskussion berücksichtigt werden.

Ebenfalls:

+1 für die Trennung von Bedenken - Styling und UI-Logik müssen in meinem Buch getrennt werden
+1 für die Berücksichtigung mangelnder IDE-Unterstützung

Ich stimme absolut zu, dass es Probleme mit CSS gibt, insbesondere im Maßstab. Ich hoffe, diese Diskussion führt in dieser Hinsicht zu einem besseren Ort für uns alle.

Nun, auch ich fand das Gespräch überzeugend, aber in der Praxis verwendete ich meistens CSS mit
Modulbasiertes Umbenennen und möglicherweise Inline-Styling sind am einfachsten
arbeite mit imho.

Am Dienstag, 24. November 2015, 09:49 Uhr Owen Campbell-Moore [email protected]
schrieb:

Für das, was es wert ist, war die Verwendung von Inline-Stilen ein großer Grund, warum ich ein wurde
großer Fan von MUI. Ich fand den Vortrag von Facebook äußerst überzeugend und
Ich persönlich bin der Meinung, dass Stil und Struktur keinen Sinn machen, getrennt zu werden
beim Erstellen von Benutzeroberflächen.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/callemall/material-ui/issues/30#issuecomment -159198060
.

Wout.
(auf dem Handy getippt, entschuldigen Sie die Knappheit)

Interessante Punkte @mpseidel. Ich denke jedoch, da sich immer mehr Frameworks in Richtung Komponenten bewegen, erscheint es mir sinnvoller, JS und CSS als Teil der Komponente zusammenzuhalten, als ein globaleres CSS-Include zu haben, das eine Reihe von Komponenten, Seiten usw. abdeckt. Das Konzept der Theming-Komponenten hat mich am Kopf gekratzt. Ich kenne CSS nicht sehr gut. Vielleicht gibt es eine einfache Möglichkeit für Komponenten, Theming-Stile zu übernehmen, um ihre Standardstile zu überschreiben, damit Komponentenschreiber ihre Komponenten anpassen können ein allgemeiner Themenstil? Wenn ja, würde ich das gerne besser verstehen.

Hier gibt es eine große Diskussion. Und es ist schwer, die allgemeine Richtung zu erraten.
Kann jemand die Wahrscheinlichkeit abschätzen, dass Stile an ihren Platz zurückkehren?

Ich benutze noch kein Material-UI. Und aus meiner "frischen" Sicht sehe ich diese Probleme, die mich davor hüten, dieses Projekt in Zukunft zu verwenden:

• Präsentations- und Logikebenen sind durcheinander
• Leistungsabfall aufgrund von Inline-Stilen
• Es ist schwer, eigene Stile hinzuzufügen
• Hässliches unlesbares DOM

Ich sehe keine Vorteile von Inline-Stilen.

Es wäre besser, weniger / sass / css besser lesbar und wartbar zu machen, als das Styling von Grund auf neu zu erfinden.

Diese Diskussion ist so gut wie abgeschlossen.
Bitte folgen Sie https://github.com/callemall/material-ui/issues/684.

@oliviertassinari .. bedeutet es keinen Weg zurück zu CSS?

Dies bedeutet, dass wir nach Optionen suchen, um den aktuellen Stilansatz zu verbessern (CSS-Module, Radium, Aussehen, reaktionsfähig).