Material-ui: [RFC] Migration zu styled-components

@kybarg Danke für das Öffnen dieser Ausgabe! CSS-in-JSS ist ein sich bewegendes Feld, Entscheidungen, die wir in der Vergangenheit getroffen haben, sind möglicherweise nicht mehr gültig, wenn sich Probleme und Lösungen ändern.

Warum nicht früher gestylte Komponenten?

Wir haben die verschiedenen verfügbaren Styling-Lösungen verglichen , bevor wir uns für JSS entschieden haben.

Auf Styled-Components haben wir aus folgenden Gründen verzichtet:

• Kosten der Entnahme. css-in-js-perf-tests ist eine gute Ressource, styled-components verwenden intern Glamour.
  
  
  
  • 126 kb entpackt über 22 kb für JSS
  
  
  • Die Zeit bis zum ersten Malen ist langsamer. Vergleichen Sie die Zeit bis zum ersten Malen auf den entsprechenden Demos von https://github.com/MicheleBertoli/css-in-js , JSS schneidet 40 % besser ab.
  
  
• Das Offenlegen des Klassennamens und der CSS-Deep-Selector-Power ermöglichen eine performante Implementierung. Zum Beispiel mit dem <Grid /> : #6010.
• Keine serverseitige Rendering- Parallelität möglich. Es verlässt sich auf einen Singleton, um die Stile zu sammeln, während JSS bei jeder Anfrage eine neue Instanz instanziiert, um Stile zu sammeln. Dampfen ist wirklich begrenzt.

Tatsächlich gab es gestylte Komponenten noch nicht einmal, als @nathanmarks anfing, daran zu arbeiten, sich vom Inline-Stil zu entfernen.

Die Vergleichstabelle

Unterstützt globales CSS

Mit https://github.com/cssinjs/jss-global können Sie Sachen schreiben wie

const styles = {
  '<strong i="35">@global</strong> body': {
    color: 'green'
  }
}

Einfach zu überschreiben

Wie ist das nicht einfach? Auf der Material-UI-Seite haben wir eine vordefinierte Injektionsreihenfolgetabelle. Im User-Land können sie Aphrodisiakum verwenden, das die großartige Aphrodite-Override-API implementiert.

Keine Wrapper-Komponenten

Wir haben keine Wrapper-Komponente auf der Material-UI-Seite. Wir hätten withStyles verwenden können, tun dies aber aus Leistungsgründen nicht. Wir stellen diese Komponente höherer Ordnung den Benutzern zur Verfügung, um die Kontextimplementierung zu abstrahieren.

Thematisierung

Wir verwenden intern jss-theme-reactor . JSS stellt eine Low-Level-API bereit, die dies ermöglicht.

ReactNative-Unterstützung

Das ist ein guter Punkt, die React-with-Styles- API ist ziemlich interessant. Das ist etwas, was wir verbessern könnten!

Die Zukunft

Für die Zukunft denke ich, dass der vielversprechendste Weg darin besteht, eine API zu haben, die es ermöglicht, die Stilimplementierung zu wechseln . Das würde uns zwei Vorteile bringen:

• Material-UI ist weniger an eine Styling-Lösung gekoppelt
• Benutzer, die auf ihrer Seite styled-components / aphrodite/... verwenden, können sich den intern verwendeten JSS- Overhead sparen.

React-Toolbox folgt diesem Weg . Meine einzige Sorge wäre der Overhead, den es hinzufügt. Ich meine, lohnt es sich?

Ich füge der Schleife @kof und @mxstbr hinzu.

@kybarg Eigentlich bin ich mir nicht sicher, ob ich ganz verstehe, was Sie vorschlagen.
Wir verwenden nicht react-jss , wie Ihre Frage vermuten lässt.

Wenn Sie wir sagen, sprechen Sie von Benutzern oder Material-UI?

Meine Punkte sind:

• styled-components ist eine viel höhere Bibliothek als der JSS-Kern, Sie können sie sicher in Ihrer Anwendungsschicht verwenden.
• Die obige Vergleichstabelle bezieht sich auf React-JSS, nicht auf JSS-Core und ist eine subjektive Meinung von Max. Es ist teilweise nicht wahr und teilweise nur ein Blick aus einer bestimmten Perspektive, die wir aus der Tabelle nicht sehen.
• Wir arbeiten an dynamischem Regel-Rendering für effizienteres dynamisches Styling, jss-theme-reactor macht das jetzt schon, es geht nur um eine Optimierung, die für MUI wahrscheinlich nicht sehr relevant ist.
• Was MUI intern verwendet, sollte für den Endbenutzer völlig unbedenklich sein. Alles, was ein Benutzer tun muss, sollte möglich sein, ohne zu wissen, was MUI intern verwendet oder zumindest seine mehr oder weniger reguläre cssinjs-Syntax für das Thematisieren.
• Wir müssen Anwendungsfälle finden, die MUI derzeit nicht unterstützt, und sie lösen. Ich helfe gerne beim Integrationsprozess und stehe auf gitter zur Verfügung.
• Was ist überhaupt React-Native-Support? Ist es nicht nur eine Teilmenge der Webplattform? Wenn ja, sollte es einfach funktionieren, andernfalls lassen Sie mich wissen, was JSS können muss, um React-Native zu unterstützen, hier ist das Problem .

Diese Tabelle ist in der Tat sehr subjektiv und basiert auf meiner eigenen Erfahrung. FWIW, styled-components funktioniert mit jeder Komponentenbibliothek von Drittanbietern:

import { Button } from 'material-ui'

const MyButton = styled(Button)`
  // Only these styles will be overridden
  background: red;
`

Dies funktioniert, solange die Komponenten das Prop className intern an einen DOM-Knoten anhängen:

const MaterialUIButton = (props) => {
  /* ... */
  // As long as props.className is attached, the above usage will work
  return <button className={`bla ${props.className}`} />
}

Was ist überhaupt React-Native-Support? Ist es nicht nur eine Teilmenge der Webplattform?

Nein, das ist nicht ganz so einfach 😉 Das Hinzufügen von Unterstützung zu JSS sollte jedoch nicht schwierig sein, da Sie lediglich das Stilobjekt an StyleSheet.create() übergeben müssen. Dies erfordert etwas mehr Aufwand von der styled-components -Seite, damit CSS-Strings funktionieren.

Ich spreche jetzt schon seit einer Weile mit @javivelasco und finde es toll, wohin er mit react-toolbox geht. Seine Implementierung ist erstaunlich, und ich würde gerne sehen, dass alle Komponentenbibliotheken von Drittanbietern sie übernehmen. Pingen Sie ihn, damit er sich hier mit seinen Ideen einbringen kann!

Keine serverseitige Rendering-Parallelität möglich. Es verlässt sich auf einen Singleton, um die Stile zu sammeln, während JSS bei jeder Anfrage eine neue Instanz instanziiert, um Stile zu sammeln. Dampfen ist wirklich begrenzt.

Völlig unabhängig, haben Sie etwas dagegen, in dieser Ausgabe Ihre Ideen für eine API zu kommentieren, die dies ermöglichen würde? Wir haben uns noch nicht entschieden, was wir tun werden, daher würden wir uns sehr über Ihren Beitrag freuen.

Hallo, ich habe in Gitter nachgefragt. Nur um die Meinung anderer zu bekommen, werde ich es auch hier posten:

Ich weiß, dass material-ui _next_ stark in eine benutzerdefinierte jss-Lösung investiert wird.
Hat jemand einen ernsthaften Vorteil der Verwendung von jss gegenüber styled-components entdeckt?

Während jss gut ist, da es mehrere Muster wie Decorators (Injectstyles) und Plugins ermöglicht, denke ich, dass der einfache Ansatz von Styled-Components viel sauberer ist, da keine Decorators, benutzerdefinierten Setups und Plugins erforderlich sind, da dies nicht erforderlich ist.

In styled-comp ist jede Komponente bereits gestylt, sodass keine Stile übergeben werden müssen. und Sie übergeben Requisiten, die ausgewertet werden können, um einen anderen Stil zu erzeugen
kein Setup (createJss)
keine Plugins (Präfix)
kein JSON-DSL

Jemand muss diesen Thread sperren.

@rainice jss hat keine Dekorateure, ein HOC ist ein Implementierungsdetail von „react-jss“ und wird hier nicht verwendet.

Warum sollte das gesperrt werden? Es ist eine vernünftige Diskussion IMO

Weil Endbenutzer-basierter Inhalt hier (nicht Lib-Betreuer) sehr oberflächlich ist und dies verständlich ist, weil sie nicht eine einzige Codezeile hinter dem gelesen haben, was sie verwenden.

Da die Wahl der Styling-Lösung ausführlich diskutiert wurde, die Gründe für die Entscheidung dokumentiert wurden und die Entwicklungsarbeit für die nächste Hauptversion im Gange ist, ist dies kein nützliches Thema, daher werde ich es schließen.

Hoffentlich sind die Leute reif genug, um nicht weiter in einem geschlossenen Thread zu posten, aber wir können ihn sperren, wenn es nötig ist.

Ich wünschte, wir hätten diesen Thread mit einer weniger gekoppelten Styling-Lösung vorantreiben können!
Ich denke jedoch, dass unsere Priorität vorerst darin liegen sollte, die Migration/Gesamtverbesserung der Komponenten abzuschließen.

@mxstbr danke für gestylte Komponenten

Dies funktioniert, solange die Komponenten die Eigenschaft className intern an einen DOM-Knoten anhängen

es könnte sich lohnen, dies irgendwo in Ihrer Bedienungsanleitung hervorzuheben, wenn mui:next veröffentlicht wird. Dieser Kommentar hat mich gerade gerettet.

Flex-Stile für IE10 funktionieren nicht mit jss, aber mit Stilkomponenten wie einem Zauber

@yhaiovyi Material-UI unterstützt IE10 nicht.

Herstellerpräfix evtl. Wird bald für jss behoben, bedeutet jedoch nicht, dass es alle Probleme beheben wird, wenn mui nie auf IE10 getestet wurde

Jedenfalls habe ich bisher keine anderen Probleme als css flex mit IE10 gefunden

Sieht so aus, als hätten wir 3 Möglichkeiten (könnte einfacher sein, aber nicht alles sind Blumen), um Material-UI-Stile mit Styled Components zu überschreiben. Hier ist mein Kern .

Sie können auch eine Styled-Components-API wie mit wenigen Codezeilen erhalten: https://material-ui-next.com/customization/css-in-js/#styled -components-api-15-lines-

Sie können auch styled-jss verwenden, Beispiel: https://codesandbox.io/s/32mvjyjyxq

Der einzige Nachteil von JSS im Allgemeinen ist das Fehlen der automatischen Vervollständigung in Code-Editoren, wie auch hier gesagt , aber die Vorteile sind da, das Parsen von CSS in js wie in styled-components ist ein bisschen überladen

Bearbeiten: Ich habe gerade das oben erwähnte Problem bemerkt, interessant

Was ärgerlich ist, ist der Kontext von Mui und withStyles HOC scheinen nicht gut mit dem Core-React-jss und styled-jss ThemeProvider https://codesandbox.io/s/32mvjyjyxq zu spielen (ich habe versucht, ein Typography aber das geht nicht, edit: nvm, fummele immer noch dran)

Ich frage mich, ob es sich später (nach v1, denke ich) nicht lohnen würde, src/styles/withStyles und MuiThemeProvider + JSSProvider Double Layer zu vereinfachen und etwas Einfacheres zu haben, wie React-jss und Styled-jss

Voll dafür!

Am 13. März 2018 um 13:55 Uhr schrieb „Cyril Auburtin“ [email protected] :

Was nervig ist, ist Muis Kontext und withStyles HOC scheinen nicht zu spielen
gut mit dem Kern React-jss und Styled-jss ThemeProvider
https://codesandbox.io/s/32mvjyjyxq

Ich frage mich, ob es sich später (nach v1, denke ich) nicht lohnt, es zu vereinfachen
src/styles/withStyles und MuiThemeProvider + JSSProvider Double Layer

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/mui-org/material-ui/issues/6115#issuecomment-372655385 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AADOWAbwLOnRoypx9ANCZnKyalZyD0M9ks5td8HNgaJpZM4L-GwD
.

css in js wie in styled-components zu parsen ist etwas überladen

Genauso wie das Parsen von Objekten in CSS :wink: Das Parsen von Strings ist ungefähr gleich schnell, es spielt ehrlich gesagt keine Rolle. https://github.com/A-gambit/CSS-IN-JS-Benchmarks/blob/master/RESULT.md

Lösung | Verwenden Sie CSS | Verwenden Sie Inline-Stile | Mount-Zeit (ms) | Renderzeit (ms)
:--- | :--- | :--- | :--- | :---
...
gestaltete Komponenten | + | - | 182 | 146,84
styled-components-decouple-cell | + | - | 213,53 | 152.39
...
reagieren-jss | + | - | 198,97 | 297,74

@mxstbr Ein vollständiger CSS-Parser, der zur Laufzeit in js geschrieben wurde, hat definitiv einen Preis. Dieser Maßstab misst nicht seine Kosten.

Ein vollständiger CSS-Parser, der zur Laufzeit in js geschrieben wurde, hat definitiv seinen Preis.

Sicher, aber nicht mehr als ein vollständiger CSS-Parser, der Objekte statt Strings verarbeitet. Darüber hinaus wurden CSS-Parser, die mit tatsächlichen CSS-Strings arbeiten, lange Zeit optimiert und erforscht, geschweige denn diejenigen, die Objekte verarbeiten. :erröten:

Ich wäre neugierig, Bootstraps-CSS als Objekt mit Ihrem Parser vs. Bootstraps-CSS mit Stylis, unserem Parser, zu benchmarken, aber ich bin mir ziemlich sicher, dass der Unterschied bestenfalls vernachlässigbar sein wird.

Ich wäre neugierig, Bootstraps-CSS als Objekt mit Ihrem Parser vs. Bootstraps-CSS mit Stylis, unserem Parser, zu benchmarken, aber ich bin mir ziemlich sicher, dass der Unterschied bestenfalls vernachlässigbar sein wird.

Ja, das wäre ein geeigneter Benchmark, ich habe ein bisschen getestet, das Arbeiten mit Objekten ist viel schneller, etwa 10-20x schneller.

Aber andererseits hängt es davon ab, welche jss-Plugins Sie einbinden würden, wir haben viele syntaktische Zucker-Plugins.

Auch Tbh. es spielt keine Rolle, ob wir alle zum ISTF wechseln.

Ich habe ein bisschen getestet, das Arbeiten mit Objekten ist viel schneller, etwa 10-20x schneller.

Sicher, aber 10 ms (so lange brauchen Stylis, um das gesamte Bootstrap-Stylesheet zu parsen) im Vergleich zu 1 ms für das Parsen des gesamten CSS einer Anwendung spielen im Großen und Ganzen keine Rolle, wissen Sie? Es wird niemandes App machen oder kaputt machen.

Wie auch immer, lasst uns aufhören, Leute in dieser Ausgabe mit mehr Benachrichtigungen als nötig zu nerven.

Übrigens. Dieser Benchmark scheint genauer zu sein: http://necolas.github.io/react-native-web/benchmarks/ Ich bin mir nicht sicher, ob er sich nach der ersten Analyse nicht auf einen Cache verlässt.

@mxstbr Auch wenn diese Ausgabe jetzt gesperrt ist, tut ein bisschen gesunder Wettbewerb allen gut. Kommen Sie jederzeit wieder - Sie finden uns im gitter-Chat, wenn ein Thema nicht der geeignete Ort für eine Diskussion ist.

Dieses Problem ist mehr als ein Jahr alt. Leute, hört bitte auf, es zu kommentieren. Wir können die Diskussion auf eine neue verschieben. Seit Beginn der Diskussion hat sich viel verändert.

Aber versuchen wir, Sperrprobleme zu vermeiden. Wir müssen so viel Feedback wie möglich sammeln, um bessere Entscheidungen treffen zu können.

Ich denke, das Sperren von Problemen als Mittel, um dies klar zu kommunizieren, ist in Ordnung, niemand war dadurch beleidigt, noch wurde die Meinungsfreiheit genommen. In diesem Fall ist es wirklich in Ordnung.

Ich öffne wieder, um mehr Feedback zu sammeln. Ich bin gespannt, ob dies etwas ist, woran die Leute noch interessiert sind:

Wir haben eine laufende Entwicklerumfrage , deren Ergebnisse wir verwenden werden, um unsere ROADMAP zu aktualisieren.
Wir haben mit der Styles-Lösung folgende Anforderungen:

1. Bündelgröße . Wir möchten, dass die Leute eine einzelne Komponente verwenden können, ohne dafür 20 KB gzipped bezahlen zu müssen. Nach Rang:
   
   
   
   1. emotion ist der beste Kandidat in diese Richtung: 10kB gzipped . Es wird jedoch von wenigen Menschen genutzt. Wenn Sie sich die Download-Statistiken ansehen, stammen 80 % aus Storybook ?
   
   
   2. styled-components wiegen ca. 16 KB gzipped . Sein Vorteil ergibt sich aus der Anzahl der Personen, die es verwenden. Vielleicht 20 % der React-Benutzer?
   
   
   3. JSS mit einem React-Wrapper-Gewicht von etwa 15 KB gzipped. Wenn Sie sich die Download-Statistiken ansehen, kommt ein Großteil der Nutzung von Material-UI.
   
   
2. Leistung . Wir möchten, dass Menschen unsere Komponenten individuell anpassen können. Sie sollten so schnell wie möglich sein. Der Benchmark, den ich machen konnte, ergibt folgendes Ranking:
   
   
   
   1. Emotion
   
   
   2. jss
   
   
   3. gestylte Komponenten
   
   
3. Anpassungs-API . Das Anpassen einer Variante sollte einfach sein, das Anpassen eines verschachtelten Elements sollte einfach sein, das Hinzufügen einer neuen Variante sollte einfach sein. Im Moment haben wir eine classes -API, eine theme.overrides -API und die Möglichkeit, globale deterministische Klassennamen zu haben.
4. Interoperabilität . Die Verwendung !important ist keine Lösung.
5. RTL-Unterstützung

Ich habe nur gestylte Komponenten, Emotion und JSS erwähnt, aber sie sind verschiedene Alternativen: Linaria, SASS usw.

Ich glaube, es könnte sich lohnen, die folgenden zwei Punkte hinzuzufügen, da sie dazu beitragen könnten, die Entscheidung zu beeinflussen, wann Sie Zeit hätten, an der CSS-in-JS-Bibliothek zu arbeiten, die von Material-UI verwendet wird:

• https://github.com/mui-org/material-ui/issues/15660
• https://github.com/cssinjs/jss/issues/1102
  Kurz gesagt, diese beiden Probleme decken die Inkonsistenz von JSS ab, die sich auf die Entwicklererfahrung auswirkt.

@o-alexandrov Verfolgt JSS die gleiche Strategie wie Styled-Components? Ich verstehe deinen Punkt nicht. Könnten Sie das klären? Was ist der Unterschied? Wie ist es besser oder wert?

@oliviertassinari
In der vorherigen Nachricht habe ich nichts über styled-components gesagt, außer dass ich die Idee begrüße, die Verwendung von styled-components oder einer anderen CSS-in-JS-Bibliothek zu evaluieren, die die perfekte Balance hätte aus:

• Entwicklererfahrung (Vertrautheit und Flexibilität, weitere Beiträge, tatsächliche Nutzung durch Entwickler usw.)
• Leistung

Die Links zu den beiden obigen Themen diskutieren nur den aktuellen negativen Aspekt der Arbeit mit JSS.
Ich habe vergessen, wo ich das Folgende gesehen habe, aber ich erinnere mich, dass Sie einen guten Punkt gemacht haben, dass wir, um Entscheidungen treffen zu können, zuerst alle Arten von Benchmarks hinzufügen sollten, damit die Entscheidungen einfacher bewertet werden können.

Mir persönlich gefällt:

• styled-components über jss für eine viel breitere Akzeptanz in der Community.
  Ich glaube, dass die Annahme durch die Community der Schlüsselaspekt ist, den Material UI berücksichtigen sollte.

@o-alexandrov Ok, in diesem Fall markiere ich Ihren ersten Kommentar als nicht zum Thema gehörend. In v5 wollen wir die Kernkomponenten von der Styling-Lösung isolieren. Ich wünschte, wir könnten Naked-, JSS-, Emotion-, Linaria- und Styled-Components-Versionen (als Standard) der Komponenten bereitstellen. Das ist die Vision. Jetzt wird die Umsetzung herausfordernd!

Bündelgröße

styled-components hat sich in @5.0.0-beta.8 als 12.3kB verbessert

Anpassungs-API

Wenn sie https://github.com/styled-components/styled-components/pull/2625 entweder im Paket oder im externen Paket einführen, glaube ich, dass die API-Parität zu Mui ist, da es an einer API für nicht-gestylte Komponenten mangelt, die wir manchmal brauchen könnten , besonders in Legacy-Systemen, aber ich glaube nicht, dass Sie diese API in Mui selbst so oft brauchen würden.

Außerhalb davon

Ich bin mir nicht sicher, welche Informationen Sie sammeln möchten, da styled-components meiner persönlichen Erfahrung nach die Funktionen bietet, die wir benötigen.

Interoperabilität.

Was ist das für Sie in diesem Zusammenhang? Soweit ich weiß, können Sie Dinge in styled-components wie in jedem anderen Framework überschreiben.

RTL-Unterstützung

Basiert das nicht darauf, wie wir die Komponenten codieren? Was genau hat styled-components oder eine CSS-in-JS-Bibliothek dafür zu bieten?

Meine Gedanken

Geschwindigkeit

Früher war es im Vergleich zu anderen Lösungen langsamer, aber die Unterstützung und der erstaunliche Einsatz der Mitwirkenden haben es zu einem Punkt gebracht, an dem es sogar noch schneller als JSS wird.

Größe

v5 wird noch schlanker, wie ich schon sagte, 12.3kB von 16.2kB , die ihre Bemühungen zu diesem Thema darstellen.

Vertrautheit

Die Leute sind mit der API vertraut, da sie die beliebteste ist. Tatsächlich nennen die meisten Leute styled-components und beziehen sich eher auf die API als auf das eigentliche Paket, als wir größtenteils die styled(...) ... API verwendeten.

Nativ reagieren

Es wiegt so viel für Mui, dass es das Web ist, aber die Leute werden deswegen weiterhin styled-components annehmen.

Kern Team

Starkes Kernteam, bis heute 81 Ausgaben und 14 PRs offen, das sind gute Zahlen für die Anzahl der Personen, die das Paket verwenden.

Außerdem verwenden Leute wie @mxstbr das Paket tatsächlich in spectrum , also hat er praktische Erfahrung mit der Verwendung des Pakets, das ist erstaunlich, das heißt, er weiß tatsächlich, wie es sich anfühlt, das Paket zu verwenden.

Nahm es

Gut, könnte nicht besser sein https://www.styled-components.com/docs/tooling

Für UI-Autoren

Bis heute hat die Einführung von styled-components für Design System-Komponenten stark zugenommen; Atlassian, GitHub, Orbit und viele andere.

Das ist gut für Mui, da du nicht alleine sein wirst, also beschäftigen sich wahrscheinlich die Leute bereits mit möglichen Situationen, denen du begegnen könntest, und sie haben herausgefunden, wie man damit umgeht.

TL;DR

Ich unterstütze styled-components .

Ich mag JSS, weil die Objektsyntax für CSS für mich einfacher geworden ist, manchmal bin ich faul und übergebe diese Stile sogar einfach als style={{styles.dialogTitle}} -Inline-Stil, es ist später einfach, sie umzugestalten

Und es kann auf verschiedene Arten verwendet werden, mit einem Element-Wrapper wie styled-components https://material-ui.com/styles/basics/#styled -components-api

@caub https://www.styled-components.com/docs/advanced#style -objects

Ich mag gestylte Komponenten sehr, aber ich habe kürzlich festgestellt, dass sie eine Reihe von Problemen mit sich bringen, die es schwierig machen, Tree-Shaking konsistent zum Laufen zu bringen. Ich weiß, dass das Material-UI-Team gerade eine Menge Arbeit geleistet hat, um Tree-Shaking für diese Bibliothek voll funktionsfähig zu machen, und natürlich sollte jede Regression darauf vermieden werden.

Glücklicherweise werden die meisten Probleme mit Tree-Shaking durch die Verwendung von babel-plugin-styled-components und der Einstellung pure: true gelöst (siehe https://www.styled-components.com/docs/tooling#dead-code-elimination ). Aber es gibt noch einige verbleibende Probleme. Zum Beispiel:
https://github.com/styled-components/babel-plugin-styled-components/issues/245

Ein weiterer Grund ist, dass die Verwendung einer externen Hilfsfunktion in Ihren Stilen das Baumschütteln unterbrechen kann (es sei denn, Sie konfigurieren terser/uglify so, dass diese bestimmte Funktion ignoriert wird), z.

const Button = styled.button`
  font-size: ${externalHelperFunction()};
`

Ich denke, es sollte möglich sein, all diese Probleme zu beheben, damit Tree-Shaking richtig funktioniert, aber es kann sicherlich schwierig sein und funktioniert nach derzeitigem Stand nicht einfach ideal. Ich denke eigentlich immer noch, dass ein Wechsel zu Styled-Components eine gute Idee sein könnte, aber nur, wenn diese Probleme gelöst werden können.

@mbrowne Ich konnte kein Problem mit Tree-Shaking- und Styled-Komponenten reproduzieren. Das Problem enthält kein reproduzierbares Beispiel, also habe ich versucht, es mit zu replizieren

// components.js
import React from "react";
import styled from "styled-components/macro";

const Wrapper = styled.div`
  color: blue;
`;

export function MyComponent() {
  return <Wrapper>styled</Wrapper>;
}

MyComponent.displayName = "FancyName";

export function OtherComponent() {
  return "only";
}

// App.js
import React from 'react';
import { OtherComponent } from "./components";

/* code */

mit einem Standard create-react-app . MyComponent erscheint nicht im Produktionspaket.

Hat nur rollup damit Probleme? Ich würde mich über ein reproduzierbares Beispiel freuen, um das Problem zu verstehen.

@eps1lon Ich denke, das Problem tritt auf, wenn die statische Eigenschaft für die formatierte Komponente festgelegt wird. Können Sie das versuchen?

const Wrapper = styled.div`
  color: blue;
`;

Wrapper.displayName = "FancyName";

export function MyComponent() {
  return <Wrapper>styled</Wrapper>;
}

export function OtherComponent() {
  return "only";
}

@mxstbr Ja, obwohl in beiden Fällen styled-components gebündelt sind. Während das Festlegen des displayName auf MyComponent MyComponent nicht in das Paket aufgenommen hat, enthält es immer noch styled-components . Es entfernt im Grunde alles, was mit MyComponent gemacht wurde, weshalb ich ursprünglich dachte, dass es richtig Tree-Shakes ist (habe nur nach FancyName gesucht.

Aber es enthält immer noch styled-components . Selbst wenn Sie der Meinung sind, dass ein styled -Call Nebenwirkungen hat, würde ich dies in Betracht ziehen

import React from "react";
import styled from "styled-components";

export function Wrapper() {
  // nonsense
  return styled.div``;
}

export function MyComponent() {
  return <Wrapper>styled</Wrapper>;
}

export function OtherComponent() {
  return "only";
}

als nebenwirkungsfrei beim Importieren { OtherComponent } , aber gestylte Komponenten werden immer noch im Bundle erscheinen (dies gilt auch ohne das Makro). Entweder ist das ein Fehler oder ich übersehe etwas Großes. Eben

// Wrapper.js
import React from "react";
import styled from "styled-components";

export default function Wrapper() {
  // side-effect free module even if styled has side-effects
  const Component = styled.div``;
  return <Component />;
}

// components.js
// commenting this out removes styled-components from the bundle
export { default as Wrapper } from "./Wrapper";

export function OtherComponent() {
  return "only";
}

// index.js
import React from 'react';
import ReactDOM from 'react-dom';
import { OtherComponent } from "./components";
import * as serviceWorker from './serviceWorker';

ReactDOM.render(<OtherComponent />, document.getElementById('root'));

// If you want your app to work offline and load faster, you can change
// unregister() to register() below. Note this comes with some pitfalls.
// Learn more about service workers: https://bit.ly/CRA-PWA
serviceWorker.unregister();

enthält styled-components (https://github.com/eps1lon/styled-components-shake).

Könnte ein Fehler in React-Scripts, Webpack oder Styled-Components sein. In jedem Fall ist das Debuggen dieser Probleme ohne Repro unglaublich schwierig.

Macht Sinn, danke, dass du das untersucht hast.

Für diesen Anwendungsfall ist es meiner Meinung nach nicht wichtig, ob styled-components im Bundle enthalten ist (da alle Komponenten es verwenden sollten), sondern ob die Komponenten, die Sie nicht verwenden, enthalten sind – was nicht der Fall ist Hört sich so an, also ist das gut, oder?

@mxstbr Es könnte ein wichtiges Anliegen sein, wir haben ein paar Komponenten, die nicht gestylt und generisch sind (Modal, Popper, TextareaAutosize, useMediaQueries usw.), sagen wir, jemand verwendet

import { Modal } from '@material-ui/core';

mit SAS. Wir würden eine Erhöhung um +5 kB gzipped (Stand heute) erwarten, nicht +20 kB gzipped.

Unter der Annahme, dass wir @material-ui/unstyled vorantreiben, macht es in der Praxis möglicherweise keinen Unterschied, da die Leute dieses Paket verwenden könnten.

@eps1lon Entschuldigung, ich dachte, das Problem mit statischen Eigenschaften wäre für andere einfacher zu reproduzieren, da es alle unsere Komponenten zu betreffen schien ... es stellt sich heraus, dass es viele verschiedene Dinge gibt, die das Problem auslösen, aber zumindest in In einigen einfachen Fällen funktioniert es.

Ich habe hier eine reproduzierbare Demo erstellt:
https://github.com/mbrowne/CRA-error-template/tree/styled-components-tree-shaking
git clone --single-branch --branch styled-components-tree-shaking [email protected]:mbrowne/CRA-error-template.git

Beachten Sie, dass nur Component1 den Baum korrekt schüttelt.

Die gute Nachricht ist, dass ich denke, dass diese Probleme alle lösbar sind, und @mxstbr scheint hier sehr engagiert zu sein. Ich werde bald an einer PR arbeiten, die zumindest das Problem der statischen Requisiten angeht (ich habe bereits einen funktionierenden POC mit einem separaten Babel-Plugin, das ich geschrieben habe).

Ich habe eine PR in Babel-Plug-in-styled-components eröffnet, um die Tree-Shaking-Probleme anzugehen. Wenn jemand hier helfen möchte, es zu testen, würde @mxstbr das begrüßen (und ich natürlich auch):
https://github.com/styled-components/babel-plugin-styled-components/pull/248

Hallo zusammen, wo ist dieses Ticket derzeit? Ich würde mich sehr freuen, mich einzubringen und einige gestylte Komponenten für MUI zu schreiben, wenn dies tatsächlich die Richtung ist, in die das Projekt in v5 geht

Ich schätze, es sei denn, wir wollen das auf einmal machen (ich bezweifle, dass wir das wollen). Wir sollten entweder damit beginnen, dass styled-components das Design aus jss liest oder jss das Design aus formatierten Komponenten liest. Das Ziel sollte sein, dass wir Styles pro Komponente migrieren können.

Dies sollte wahrscheinlich auf einem anderen Zweig passieren. Obwohl wir nicht alles auf Master auf einmal ändern wollen, sollten wir es wahrscheinlich mit einer Änderung (in v5) veröffentlichen. Sonst wird das noch verwirrender.

Das Löschen des Kommentars wurde angefordert.

Hey Leute, ich bin auch bereit, einen Beitrag zu leisten ... ein separater Zweig scheint eine vernünftige Sache für uns zu sein ... lasst uns das tun ...!

@caprica-Six Danke für die Energie, aber ein neuer Zweig ist nicht notwendig. Wir sollten in der Lage sein, schrittweise eine gestylte Komponentenversion bereitzustellen (+ jss und Emotion) (während v4 instabil) und gleichzeitig die nicht gestylte Geschichte voranzutreiben. Ich habe einen POC, den ich einreichen muss. Gestylte Komponenten (v5 Beta) + dynamische Requisiten sind etwas langsamer als das, was wir mit JSS und statischen Stilen haben, aber das sollte immer noch akzeptabel sein.

@oliviertassinari können wir uns irgendwo damit beschäftigen? Ich habe irgendwie darauf gewartet, dass ein Betreuer mich in die richtige Richtung weist, bevor ich mich auf etwas einlasse

Warum ziehst du Emotion nicht gestylten Komponenten vor? Es scheint, dass der Grund dafür ist, dass "[Emotion] von wenigen Leuten verwendet wird. Wenn Sie sich die Download-Statistiken ansehen, stammen 80 % aus dem Bilderbuch?", aber das ist falsch. Es wird häufiger verwendet als gestylte Komponenten ( Vergleich ) und ich verstehe nicht, warum 80% der Downloads von Storybook kommen. Es wächst eindeutig viel schneller als das Bilderbuch.

Ich stelle diese Frage, weil ich es satt hatte, gestylte Komponenten zu verwenden (aufgrund mehrerer Probleme, auf die ich gestoßen bin) und nach einer Alternative gesucht habe, und ich habe Emotion entdeckt. Ich habe es getestet und nur Vorteile gegenüber Styled-Components festgestellt.

Es ist leichter, schneller und hat mehr Funktionalitäten: Eigenschaftsweiterleitung, TypeScript out-of-the-box (und perfekt unterstützt im Vergleich zu styled-components), Next.js SSR out-of-the-box (ohne die _app. js- und _document.js-Dateien, wofür ich beim ersten Mal eine Stunde gebraucht habe)

Und außerdem wird es mehr verwendet als gestylte Komponenten und hat eindeutig eine Dynamik.

@lcswillems Ich denke, dass wir auch Emotionen für Menschen unterstützen sollten, die es bevorzugen. Aber ich denke nicht, dass es der Standard sein sollte.

• "leichter": Ungenau: https://bundlephobia.com/[email protected] (12,2 kB) vs https://bundlephobia.com/result?p=@emotion/ styled + https://bundlephobia.com/result?p=@emotion/core + https://bundlephobia.com/result?p=emotion-theming (13,1 kB ohne Berücksichtigung gemeinsamer Abhängigkeiten)
• "Next.js SSR out-of-the-box": Ich denke, dass es ein erhebliches Problem ist, Inlining

Danke für deine Antwort und die Korrektur.

• "leichter": du hast recht
• „Next.js SSR out-of-the-box“: Ich verstehe jetzt, warum sie SSR out-of-the-box machen können und warum ihr Weg, dies zu tun, nicht der gute ist.
• "Mehr verwendet als gestylte Komponenten": Ich bin mir nicht sicher, ob dies zuverlässig ist. Aber meine Quelle ist möglicherweise auch nicht zuverlässig.
• "schneller": Ich habe nur veraltete Benchmarks gesehen, also nein, ich habe keine.

Das Hauptproblem, mit dem ich konfrontiert bin, ist die Weiterleitung / Filterung von Props: https://github.com/styled-components/styled-components/issues/439 . Es passiert mir sehr oft und es ist mühsam, die Filterung jedes Mal manuell durchzuführen.

Aber mit Ihren Ausführungen scheint Emotion weniger eine gute Alternative zu sein.

"leichter": Ungenau: https://bundlephobia.com/[email protected] (12,2 kB) vs https://bundlephobia.com/result?p=@emotion/ gestylt + https://bundlephobia.com/result?p=@emotion/core + https://bundlephobia.com/result?p=emotion-theming (13,1 kB ohne Einnahme

Im Falle von Emotion werden Sie höchstwahrscheinlich kein @emotion/styled -Paket zugunsten von css -Requisiten + @jsx -Pragma verwenden. Außerdem benötigen Sie möglicherweise kein emotion-theming Paket, das ThemeContext ist bereits in @emotion/core enthalten. Es sind also 12,2 KB gegenüber 6,5 KB.

Einfügen

Nur neugierig: Was bedeuten diese Updates für Benutzer der @material-ui/styles -Bibliothek für Nicht-MUI-Komponenten? In meiner Firma verwenden wir es als Basis für eine große interne Komponentenbibliothek, wobei wir es bewusst gegenüber styled-components gewählt haben, und wir sind sehr zufrieden damit.

Ich dachte nur, ich schaue vorher vorbei, ob für das @material-ui/styles -Paket irgendeine Art von Abwertung geplant ist, damit ich entsprechend planen kann.

Wie auch immer, danke für all die großartigen Sachen, die ihr alle weiterhin bereitstellt!

@nickjohnson-dev Die Migration zu React-jss sollte unkompliziert sein. Würde das für Ihre Organisation funktionieren?

@oliviertassinari Ich denke, es ist wahrscheinlich, dass es so wäre. Solange wir die öffentliche API der Komponenten selbst größtenteils gleich halten können ( classes prop-basierte lokale Überschreibungen, globale Überschreibungen im Thema möglich), denke ich nicht, dass es ein Problem ist, die Implementierungsdetails zu ändern.

Erwarten Sie, dass es eine offizielle Dokumentation für die Migration von @material-ui/styles zu den anderen Styling-Optionen gibt, nachdem MUI stärker entkoppelt ist? Auf den ersten Blick sehe ich keine fehlenden Funktionen in react-jss , die wir in @material-ui/styles nutzen, aber ich bin mir nicht sicher, ob ich etwas Besonderes vermisse, das das MUI-Paket leistet hinter den Kulissen.

@nickjohnson-dev Wir werden unser Bestes geben.

Wenn ich das richtig verstehe, tritt folgendes Problem auf.
Wir haben das wiederverwendbare ComponentA . Wir machen das ComponentB , das ComponentA verwendet.

const ComponentA = ({className}) => (
  <div className={className}>
    <div className='inner' />
  </div>
);

const ComponentB = ({ className, classNameInner }) => (
  <div className={className}>
    <div className='inner'>
      <ComponentA className={classNameInner} />
    </div>
  </div>
)

const StyledComponentB = styled(ComponentB)`
     ???
`;

Beachten Sie, dass sowohl ComponentA als auch ComponentB das Element mit demselben className='inner' haben. Wie werden wir das Element $#$ .inner ComponentB ausrichten?

Hallo @oliviertassinari , danke, dass du all die Gedanken hinter dem Styling für die nächste Version von Material UI geteilt hast.

Und danke auch für Material UI. Im Moment baue ich darauf ein Designsystem auf.

Hinsichtlich der Einführung styled-components scheint es eine getroffene Entscheidung zu sein, und die Arbeit an diesem Ziel hat bereits begonnen.

Ich teile jedoch einige der Beobachtungen von @croraf und @lcswillems

Etwas Großartiges aus dem aktuellen Design der Material-UI ist die Eigenschaft classes .

Es ist eine einfache Idee, die bei der Anpassung des Stils und der Wartbarkeit sehr hilfreich ist, da die Eingabe von classes Teil der öffentlichen Schnittstelle ist. Wenn ich zum Beispiel etwas anpassen muss und einen Selektor wie & .Component-root verwende, garantiert nichts, dass Component diese CSS-Klasse über Versionen hinweg beibehält. Wenn ich mindestens <Component classes={{root: ....}} /> habe, kann ich einen Typprüfungsfehler (bei Verwendung von TypeScript) über die Schnittstellenänderung erhalten.

Als Autor von Komponenten kann ich entscheiden, öffentliche (und unterstützte) Klassen zu dokumentieren und andere undokumentiert zu lassen.

Ich habe style-components ungefähr 2 Jahre lang verwendet. Stimmt, das ist beliebt und hat sich stark weiterentwickelt. Aber in den MUI-Dokumentationsbeispielen sehe ich das gleiche Problem, das @croad erwähnt: Die Verwendung eines untergeordneten Selektors & .inner ist sehr zerbrechlich, da Sie die Stile an Unterkomponenten weitergeben können (und aus meiner eigenen Erfahrung kann ich sagen das ist kein Sonderfall ... ist mir ein paar Mal passiert). Zwei mögliche Lösungen sind:

• Verwenden Sie &.inner und dann überall ${props.className}.inner . Ich habe das viele Male gemacht, und es ist schmerzhaft zu schreiben.
• Verwenden Sie > .inner , aber dann hängt es von der Komponentenstruktur ab. Fügen Sie etwas zusätzliche div in der Mitte hinzu und es bricht.

Stimmt, dass JSS nicht beliebt ist. Ich erfahre davon wegen MUI. Aber nachdem ich so lange mit styled-components gearbeitet hatte, fand ich den Ansatz der MUI-Stile erfrischend und einfacher zu handhaben (nach einer Weile fügte es eine Menge zusätzlicher Arbeit hinzu, wenn das Styled HOC überall vorhanden war, und ich fing an, diese zu hassen HOCs ... zumindest ist das meine persönliche Erfahrung). Emotion passt mehr oder weniger zum aktuellen Ansatz. Und nachdem ich Ihre Kommentare und einige Probleme mit der JSS-Leistung in bestimmten Fällen gelesen habe, überlege ich, Emotion für das Designsystem zu verwenden.

Ich sehe Sie jedoch so überzeugt von styled-components , dass ich gerne weitere Beispiele dafür sehen würde, wie Sie Stilanpassungen mit classes Requisiten lösen können. Die in aktuellen MUI-Dokumentationen verfügbaren teilen die Probleme, die ich oben erwähnt habe.

Gibt es andere Möglichkeiten, styled-components mit der Klassenstütze zu verwenden? Was denkst du darüber?

JSS ist gut genug und sehr praktisch zu bedienen. Gibt es einen triftigen Grund wegzuziehen?

Persönlich denke ich, dass styled-component eine Art Rückschritt ist und JSS war der Hauptgrund für mich, diese Bibliothek zu verwenden, um ehrlich zu sein.

@powerfulj Warum bevorzugst du JSS gegenüber Styled-Komponenten? Ich musste mich zwischen den beiden entscheiden und gestylte Komponenten schienen mir besser zu sein.

@lcwillems
Ich mag es, weil ich denke, dass es keine neue Komponente einführt und Sie stattdessen nur mit Eigenschaften arbeiten. Wenn Sie wirklich eine neue wiederverwendbare Komponente mit Stil benötigen, können Sie diese ganz einfach mit der JSS-Lösung erstellen.

Außerdem ist es schneller, vom Inline-Stil in den JSS-Stil zu konvertieren, was für mich praktisch ist, da ich normalerweise Inline-Stile während der Implementierung verwende und sie dann in JSS konvertiere, wenn sie größer und wiederverwendet werden.

Die negative Seite ist, wenn Sie etwas CSS (wie von Browser-Entwicklungstools) haben und es in JSS konvertieren müssen, müssen Sie etwas mehr Zeit aufwenden, um die Syntax anzupassen. Mit styled-component geht das schneller.

Nur um meine Erkenntnisse zu diesem Thema zu teilen.
Ich habe versucht, einige Demos zu styled-components zu migrieren, wie von #16947 gefordert. Das Problem ist mit dem Standarddesign. makeStyles akzeptiert Optionen, bei denen defaultTheme übergeben werden kann. Es gibt einen makeStyles Wrapper, der defaultTheme bereitstellt. Dann wird der Hook useStyles überprüfen, ob ThemeProvider ein Thema bereitstellt, und falls nicht, wird defaultTheme .

Scheint, dass es in styled-components keine solche Funktionalität gibt. In Abwesenheit von ThemeProvider kann defaultTheme nur mit der Methode .attrs injiziert werden. Wir können etwas Ähnliches wie makeStyles Wrapper erstellen

import styledWithoutDefault from 'styled-components';
import defaultTheme from './defaultTheme';

const styled = Component => {
  return styledWithoutDefault(Component).attrs({ theme: defaultTheme });
};

export default styled;

Aber die Methode .attrs überschreibt nur das Thema, das von ThemeProvider bereitgestellt wird, falls vorhanden. Und ich weiß derzeit nicht, wie ich dieses Problem lösen soll.

Ein weiteres Problem ist, dass makeStyles die Voreinstellung jss-plugin-default-unit verwendet und es scheint, dass styled-components dies nicht sind. Styled-Components werden also nicht px zum Rückgabewert der Funktion spacing() $ hinzugefügt.
Die mögliche Lösung für das letzte Problem besteht darin, Styled-JSS und nicht Styled-Components zu verwenden.

Ich freue mich über Ihre Ideen/Vorschläge.

@fyodore82 .attrs funktioniert als Funktion (siehe https://www.styled-components.com/docs/api#attrs), also reicht das:

```js
.attrs(({ theme = defaultTheme, ...props }) => ({ ...props, theme }))
````

@croraf

Ich mag es, weil ich denke, dass es keine neue Komponente einführt und Sie stattdessen nur mit Eigenschaften arbeiten

Ich denke, Sie haben eine wirklich schöne Sache von Styled-Komponenten verpasst: die css Requisite . Es ermöglicht Ihnen, CSS zu einer Komponente hinzuzufügen, ohne eine neue erstellen zu müssen.

Außerdem ist es schneller, vom Inline-Stil in den JSS-Stil zu konvertieren, was für mich praktisch ist, da ich normalerweise Inline-Stile während der Implementierung verwende und sie dann in JSS konvertiere, wenn sie größer und wiederverwendet werden.

Beachten Sie bei der CSS-Prop, dass eine Komponente mit CSS-Prop kein style -Attribut hat, sie ist bereits in eine formatierte Komponente konvertiert und hat daher ein class . Wenn das CSS größer und wiederverwendet wird, können Sie auch eine neue Komponente erstellen.

Die negative Seite ist, wenn Sie etwas CSS (wie von Browser-Entwicklungstools) haben und es in JSS konvertieren müssen, müssen Sie etwas mehr Zeit aufwenden, um die Syntax anzupassen. Mit styled-component geht das schneller.

Ich stimme zu. Das ist der Hauptgrund, warum ich es nicht benutzt habe. Der größte Teil des online geschriebenen CSS ist in CSS geschrieben, nicht in JSS. Wenn Sie also Code von StackOverflow verwenden möchten, müssen Sie ihn zuerst in JSS konvertieren, was sehr schmerzhaft ist.

Andere zusätzliche Argumente, die mich dazu veranlasst haben, Styled-Komponenten zu verwenden:

• Es ist schmerzhafter, JSS zu schreiben: Sie müssen Anführungszeichen hinzufügen, Sie haben keine Syntaxhervorhebung (oder ich konnte keine finden).
• Für Neulinge ist es schwerer zu verstehen. Jeder kennt CSS, daher könnte jeder Code mit Styled-Komponenten leicht lesen, was bei JSS nicht der Fall ist (JSS-Syntax ist im Allgemeinen etwas seltsam und insbesondere für Pseudoselektoren und Medienabfragen).
• Code ist viel weniger lesbar. Um diesen Punkt zu veranschaulichen, habe ich dieses Kartenkomponentenbeispiel mit Styled-Komponenten umgeschrieben, um zu zeigen, wie viel klarer es mit ihnen sein kann.

JSS-Version:

import React from 'react';
import { makeStyles, useTheme } from '@material-ui/core/styles';
import Card from '@material-ui/core/Card';
import CardContent from '@material-ui/core/CardContent';
import CardMedia from '@material-ui/core/CardMedia';
import IconButton from '@material-ui/core/IconButton';
import Typography from '@material-ui/core/Typography';
import SkipPreviousIcon from '@material-ui/icons/SkipPrevious';
import PlayArrowIcon from '@material-ui/icons/PlayArrow';
import SkipNextIcon from '@material-ui/icons/SkipNext';

const useStyles = makeStyles(theme => ({
  card: {
    display: 'flex',
  },
  details: {
    display: 'flex',
    flexDirection: 'column',
  },
  content: {
    flex: '1 0 auto',
  },
  cover: {
    width: 151,
  },
  controls: {
    display: 'flex',
    alignItems: 'center',
    paddingLeft: theme.spacing(1),
    paddingBottom: theme.spacing(1),
  },
  playIcon: {
    height: 38,
    width: 38,
  },
}));

export default function MediaControlCard() {
  const classes = useStyles();
  const theme = useTheme();

  return (
    <Card className={classes.card}>
      <div className={classes.details}>
        <CardContent className={classes.content}>
          <Typography component="h5" variant="h5">
            Live From Space
          </Typography>
          <Typography variant="subtitle1" color="textSecondary">
            Mac Miller
          </Typography>
        </CardContent>
        <div className={classes.controls}>
          <IconButton aria-label="previous">
            {theme.direction === 'rtl' ? <SkipNextIcon /> : <SkipPreviousIcon />}
          </IconButton>
          <IconButton aria-label="play/pause">
            <PlayArrowIcon className={classes.playIcon} />
          </IconButton>
          <IconButton aria-label="next">
            {theme.direction === 'rtl' ? <SkipPreviousIcon /> : <SkipNextIcon />}
          </IconButton>
        </div>
      </div>
      <CardMedia
        className={classes.cover}
        image="/static/images/cards/live-from-space.jpg"
        title="Live from space album cover"
      />
    </Card>
  );
}

Styled-Components-Version:

import React from 'react';
import styled from 'styled-components';
import { useTheme } from '@material-ui/core';
import MuiCard from '@material-ui/core/Card';
import MuiCardContent from '@material-ui/core/CardContent';
import MuiCardMedia from '@material-ui/core/CardMedia';
import IconButton from '@material-ui/core/IconButton';
import Typography from '@material-ui/core/Typography';
import SkipPreviousIcon from '@material-ui/icons/SkipPrevious';
import MuiPlayArrowIcon from '@material-ui/icons/PlayArrow';
import SkipNextIcon from '@material-ui/icons/SkipNext';

export default function MediaControlCard() {
  const theme = useTheme();

  return (
    <Card>
      <Details>
        <CardContent>
          <Typography component="h5" variant="h5">
            Live From Space
          </Typography>
          <Typography variant="subtitle1" color="textSecondary">
            Mac Miller
          </Typography>
        </CardContent>
        <Controls>
          <IconButton aria-label="previous">
            {theme.direction === 'rtl' ? <SkipNextIcon /> : <SkipPreviousIcon />}
          </IconButton>
          <IconButton aria-label="play/pause">
            <PlayArrowIcon />
          </IconButton>
          <IconButton aria-label="next">
            {theme.direction === 'rtl' ? <SkipPreviousIcon /> : <SkipNextIcon />}
          </IconButton>
        </Controls>
      </Details>
      <CardMedia
        image="/static/images/cards/live-from-space.jpg"
        title="Live from space album cover"
      />
    </Card>
  );
}

const Card = styled(MuiCard)`
  display: flex;
`

const Details = styled.div`
  display: flex;
  flex-direction: column;
`

const CardContent = styled(MuiCardContent)`
  flex: 1 0 auto;
`

const CardMedia = styled(MuiCardMedia)`
  width: 151px;
`

const Controls = styled.div`
  display: flex;
  align-items: center;
  padding-left: ${props => props.theme.spacing(1)}px;
  padding-bottom: ${props => props.theme.spacing(1)}px;
`

const PlayArrowIcon = styled(MuiPlayArrowIcon)`
  height: 38px;
  width: 38px;
`

Schließlich konnte ich keinen Vorteil bei der Verwendung von JSS feststellen.

css-Eigenschaft ist sehr nett und löst im Grunde die Nachteile, die ich erwähnt habe. (Nachahmer bilden gestylte Komponenten :D )

Was den Vergleich der beiden Beispiele betrifft, finde ich es nicht sehr lesbar und es verdoppelt sich die Anzahl der Komponenten.

@lcwillems

Nicht für die eine oder andere Lösung argumentieren, sondern nur ein paar Ihrer Punkte aufgreifen:

Wenn Sie Code von StackOverflow verwenden möchten, müssen Sie ihn zuerst in JSS konvertieren, was sehr schmerzhaft ist

Es gibt eine VSCode-Erweiterung zum Konvertieren von CSS in CSS-in-JS, obwohl sie nicht immer perfekt funktioniert. Trotzdem würde ich es nicht als schmerzhaft bezeichnen.

Sie haben keine Syntaxhervorhebung

Ich verstehe diese Argumentation nicht ganz. Es ist nur ein JS-Objekt, daher funktioniert die Syntaxhervorhebung eines beliebigen Editors:

(aber vielleicht suchst du etwas spezifischeres?)

Was den Vergleich der beiden Beispiele betrifft, finde ich es nicht viel lesbarer. Während das Fehlen von className-Requisiten wohl sauberer ist, ist aus dem JSX-Hauptcodeblock nicht ersichtlich, ob sich die Komponenten auf native MUI-Komponenten oder neu gestaltete Komponenten beziehen, ohne dass die styled() -Komponenten mit Querverweisen versehen werden müssen. Bei einem größeren Bauteil könnten diese weit entfernt sein.

Die styled() -Aufrufe sind (für mich) weniger lesbar als das JSS-Objekt (obwohl ich mir vorstellen kann, dass man sich daran gewöhnt).

@powerfulj Warum bevorzugst du JSS gegenüber Styled-Komponenten? Ich musste mich zwischen den beiden entscheiden und gestylte Komponenten schienen mir besser zu sein.

Weil ich selbst ein Typescript-Entwickler bin und es vorziehe, alles in Typescript-Objekten zu erstellen. Besonders hasse ich die Saiten.

Obwohl wir den CSS-Code aufgrund des Unterschieds in den JSS-Code übertragen müssen, lese ich immer noch lieber den JSS-Code, weil die Struktur wie das traditionelle CSS aussieht (klassenorientiert), ich würde mehr Zeit damit verbringen, den gestylten Komponentencode zu lesen, weil es länger ist und kann hier und dort sein.

Ich denke, die Leute haben diese Änderung nur beansprucht, weil sie in der Vergangenheit Erfahrung mit Styled-Komponenten haben. Es gibt mir das Gefühl, "warum wählen wir nicht eine Bibliothek, mit der wir vertraut sind, aber ohne offensichtlichen Nutzen?".

Aus meiner Sicht ist JSS einfach praktisch, wir können Objekte organisieren, indem wir alle Javascript-Möglichkeiten wie verwenden

{
...sharedJSS1,
...sharedJSS2,
wie auch immer
}

Außerdem haben wir nahtlose dynamische Designs in Typen integriert und wir haben alle Typhinweise sowohl von className- als auch von CSS-Typen erhalten.

Für neue Entwickler würden besonders die Typescript-Entwickler JSS einfach lieben.

Zu Ihrer Information, es ist möglich, einige Verschachtelungen in gestylten Komponenten vorzunehmen, wenn Sie nicht immer eine separate Komponente für alles haben möchten. Es wird im Allgemeinen davon abgeraten, da die Verwendung separater Komponenten mit aussagekräftigen Namen gemäß der Philosophie der gestylten Komponenten als sauberer und besser lesbar angesehen wird, aber die Dokumentation sagt, dass es in Ordnung ist, wenn es "sparsam verwendet" wird. Und natürlich steht es jedem, der diese Philosophie nicht teilt, frei, mehr zu verschachteln. Als Beispiel dafür, was ich mit Verschachtelung meine:

const Wrapper = styled.div`
  display: block;

  .inner {
    flex: 1;
  }
`

...
  <Wrapper>
    <div class="inner">...</div>
  </Wrapper>

Siehe https://www.styled-components.com/docs/faqs#can -i-nest-rules für weitere Details.

Diskussionen über bevorzugte Programmierstile können ewig weitergehen.

Nachdem ich styled-components eine Weile verwendet habe, gefällt mir der JSS-Ansatz besser, weil:

• Wenn die Stile länger werden, verschiebe ich sie normalerweise in eine separate Datei.
  Ich habe das auch mit styled-components gemacht, und ich finde, dass die useStyles / makeStyles einfacher zu schreiben, zu lesen und zu warten sind. Z.B. import useStyles from './MyComp.styles' vs. import {XStyled, YStyled,...} from './MyComp.styles' ... die Aufrechterhaltung dieser ...Styled Variationen mit ihren Eingaben in TS ist ärgerlich.
• Ich neige dazu, die Dinge progressiv zu machen: Zuerst beginne ich mit einem Entwurf mit Divs und Klassen, und dann refaktoriere ich sie in Komponenten. Wenn ich styled-components verwende, mache ich das, indem ich innere Klassen verwende (wie im Beispiel von @mbrowne), aber es erfordert mehr Refactoring-Arbeit. Ich fand den useStyles -Ansatz viel angenehmer, um mit diesem Workflow zu arbeiten.
• Vorlagenliterale sind gut zum Einfügen von CSS-Code, aber schrecklich, wenn Sie Design-/Prop-Variablen verwenden müssen. Das Problem des Einfügens von Code lässt sich mit einem Plugin leicht lösen, aber das Bearbeiten mit Variablen und Funktionen innerhalb des Vorlagenliterals nicht so sehr.

Aber das sind meine persönlichen Vorlieben, deine können anders sein.

Meine größte offene Frage betrifft die Nutzung classes .

Die Beispiele für die Verwendung von className und inneren Klassen haben Probleme (siehe meinen vorherigen Kommentar). Die css -Requisite in styled-components ist keine Option, um diese Probleme zu lösen. Anders als die Funktion css in Emotion ist die Prop css darauf angewiesen, dass sie an eine Komponente angehängt wird (was bedeutet, dass Sie sie nicht in einem useStyle/makeStyles/classes -Codestil verwenden können).

Das Anhängen von Stilen an eine Komponente ist keine geringfügige Designentscheidung. Für mich ist es das Gute und das Schlechte von JSS. Styled-Komponenten und Emotion verlassen sich auf Babel-Plugins und interagieren mit React, um das Caching und die Generierung von Klassennamen für SSR zu handhaben. Das Gute an JSS ist, dass es kein Babel-Plugin benötigt. Der schlechte Teil ist, dass SSR in JSS mehr Arbeit erfordert, und ich habe Fehler gesehen, die in diesem Bereich gemeldet wurden.

Zurück zu MUI, ich habe den Eindruck, dass das Übernehmen von Stilkomponenten bedeutet, className und innere Klassen als einzige Möglichkeit zum Anpassen von Stilen zu verwenden. Das Styling wird konsistenter über Frameworks hinweg: Sie können styled oder css prop verwenden, solange die Komponente die className verwendet, sind Sie gut.

Aber für mich ist das Entfernen der classes Requisite ein Rückschritt. Diese Requisite hilft beim Dokumentieren und Eingeben von Anpassungen des Überprüfungsstils. Vielleicht ist es möglich, einen Mittelweg zu finden, wie die Verwendung von gestylten Komponenten, aber die Beibehaltung der Unterstützung für classes (ohne die Notwendigkeit des Hacks der inneren Klasse). Ich konnte in der styled-components-API nichts finden, was in diesem Fall hilft. Aus diesem Grund kann es gut sein, die technischen Probleme von JSS zu bewerten. Denn wenn Popularität das Hauptproblem ist, wird Emotion auch immer beliebter (siehe https://2019.stateofcss.com/technologies/css-in-js/#tools-section-overview), und es kann ein einfacher Weg sein makeStyles neu schreiben.

@dfernandez-asapp Sie haben einige hervorragende Punkte gemacht, indem Sie nur auf einen kleinen Teil dieser fwiw geantwortet haben. @styled-components unterstützt die Verwendung eines jss-ähnlichen Objekts anstelle einer Zeichenfolge https://www.styled-components.com/docs/advanced# Stil -Objekte

Obwohl es ziemlich enttäuschend ist, haben styled-components die erstklassige Typoskript-Unterstützung entfernt und stimmen Ihnen insgesamt zu, dass es wie ein Rückschritt in den anderen von Ihnen beschriebenen Wegen zu sein scheint

Zu Ihrer Information, es ist möglich, einige Verschachtelungen in gestylten Komponenten vorzunehmen, wenn Sie nicht immer eine separate Komponente für alles haben möchten. Es wird im Allgemeinen davon abgeraten, da die Verwendung separater Komponenten mit aussagekräftigen Namen gemäß der Philosophie der gestylten Komponenten als sauberer und besser lesbar angesehen wird, aber die Dokumentation sagt, dass es in Ordnung ist, wenn es "sparsam verwendet" wird. Und natürlich steht es jedem, der diese Philosophie nicht teilt, frei, mehr zu verschachteln. Als Beispiel dafür, was ich mit Verschachtelung meine:

const Wrapper = styled.div`
  display: block;

  .inner {
    flex: 1;
  }
`

...
  <Wrapper>
    <div class="inner">...</div>
  </Wrapper>

Siehe https://www.styled-components.com/docs/faqs#can -i-nest-rules für weitere Details.

Jede Art von Unterstützung dafür? Oder müssen wir überall Schnur anbringen?

Ich verstehe nicht, warum es so viel Hype um gestylte Komponenten gibt. Es fühlt sich wie ein Schritt zurück an, um ehrlich zu sein. Typisierte CSS-Eigenschaften von JSS mit TypeScript sind viel bequemer und einfacher zu warten, außerdem gibt es eine Syntaxprüfung als Teil von JS - jeder moderne/konfigurierte Editor wird Ihnen sagen, wenn Sie jemals einen Tippfehler machen, und Ihnen sogar bei der automatischen Vervollständigung helfen, wenn dies gewünscht wird.

edit: Es ist getippt, siehe Antwort von South-Paw unten.

@martinjlowm sieht so aus, als hätte es Tippings für mich?

Siehe: https://styled-components.com/docs/advanced#style -objects

Du sagst, du verstehst den Hype nicht... aber ich verstehe auch nicht den ganzen Hass, den er bekommt. 🤷‍♂

Emotionen und gestylte Komponenten sind meiner Meinung nach enorme Verbesserungen gegenüber CSS-Stilobjekten

@martinjlowm sieht so aus, als hätte es Tippings für mich?

...

Siehe: https://styled-components.com/docs/advanced#style -objects

Du sagst, du verstehst den Hype nicht... aber ich verstehe auch nicht den ganzen Hass, den er bekommt. 🤷‍♂

Emotionen und gestylte Komponenten sind meiner Meinung nach enorme Verbesserungen gegenüber CSS-Stilobjekten

Ich verstehe! Mir war nicht bewusst, dass es solche Objekte unterstützt. Meine Bedenken betrafen CSS in Template-Strings - aber wenn Objekte eine Option sind, dann habe ich nichts dagegen!

Offensichtlich ist JSS auch nicht perfekt, ich weiß - wiederverwendbare servergenerierte Blätter wären ein Killer-Feature - unterstützen styled-components das irgendwie? Weiß jemand?

Im Moment fühlt es sich dumm an, die vom Server generierten Stylesheets löschen und den Client zwingen zu müssen, alle Stile neu zu rendern :(

@martinjlowm sieht so aus, als hätte es Tippings für mich?
...
Siehe: https://styled-components.com/docs/advanced#style -objects
Du sagst, du verstehst den Hype nicht... aber ich verstehe auch nicht den ganzen Hass, den er bekommt. 🤷‍♂
Emotionen und gestylte Komponenten sind meiner Meinung nach enorme Verbesserungen gegenüber CSS-Stilobjekten

Ich verstehe! Mir war nicht bewusst, dass es solche Objekte unterstützt. Meine Bedenken betrafen CSS in Template-Strings - aber wenn Objekte eine Option sind, dann habe ich nichts dagegen!

Offensichtlich ist JSS auch nicht perfekt, ich weiß - wiederverwendbare servergenerierte Blätter wären ein Killer-Feature - unterstützen styled-components das irgendwie? Weiß jemand?

Im Moment fühlt es sich dumm an, die vom Server generierten Stylesheets löschen und den Client zwingen zu müssen, alle Stile neu zu rendern :(

Ich möchte auch klarstellen, dass getaggte Vorlagenliterale auch eingegeben werden können. TypeScript markiert sie korrekt als ungültig und der Sprachdienst liefert die Vorschläge zur automatischen Vervollständigung usw.

@South-Paw

Emotionen und gestylte Komponenten sind meiner Meinung nach enorme Verbesserungen gegenüber CSS-Stilobjekten

Ich bin immer noch verwirrt, warum sich ein React-Entwickler darauf einlässt. Wenn Sie Ihr CSS in Template-Strings einfügen möchten, warum verwenden Sie nicht einfach Angular und fügen Ihr HTML auch in Template-Strings ein? Die Stärke von React besteht darin, dass JSX-Elemente wirklich nur JS-Objekte sind, die Sie über jede Menge Möglichkeiten zum Untersuchen und Transformieren verfügen, und das Gleiche gilt für JSS.

Die ganze Sache, die die CSS in der JS-Bewegung antreibt, ist die Tatsache, dass JS CSS weit überlegen ist, wenn es darum geht, dynamische Dinge zu tun, und die Leistungsfähigkeit von JS-Objekten ist kein kleiner Teil davon.

Die Tatsache, dass styled-components Objekte unterstützt, ist eine Art Ablenkungsmanöver:

• Es unterstützt sie, sagt aber aus irgendeinem Grund: "Dies ist besonders nützlich, wenn Sie vorhandene Stilobjekte haben und schrittweise zu Stilkomponenten wechseln möchten." Sie sehen anscheinend keinen Wert darin, Objekte manipulieren zu können, und es hört sich so an, als würden Stilobjekte in ihrer API immer als Bürger zweiter Klasse behandelt.
• Die Dokumente machen nicht klar, ob es reale CSS-Selektoren wie diese mit JSS unterstützt:

{
  color: 'black',
  '&$error': {
    color: 'red'
  }
}

Auch Emotion zollt dem Wert von Stilobjekten gebührenden Respekt und behandelt sie eher als Bürger erster Klasse:

Das Schreiben von Stilen mit Objekten ist ein starkes Muster, das direkt in den Kern der Emotion eingebaut ist.

@lcswillems Sie unterschätzen, wie mühsam es ist, ständig all diese kleinen HOCs zu erstellen (und die Tatsache, dass die meisten Autoimport-Systeme nicht intelligent genug sind, um zu wissen, ob Sie @material-ui/core/Card als Card importieren möchten MuiCard (und wenn Sie Importanweisungen immer noch von Hand schreiben, verschwenden Sie Ihre Zeit erheblich))

const Card = styled(MuiCard)`
  display: flex;
`

const Details = styled.div`
  display: flex;
  flex-direction: column;
`

const CardContent = styled(MuiCardContent)`
  flex: 1 0 auto;
`

const CardMedia = styled(MuiCardMedia)`
  width: 151px;
`

So etwas verursacht eine schreckliche Entscheidungsermüdung, da Sie ständig entscheiden müssen, wie Sie jeden Wrapper und jede verpackte Komponente benennen.

Davon spricht @dfernandez-asapp, wenn er sagt:

(Nach einer Weile, wenn das Styled HOC überall ist, ist das viel zusätzliche Arbeit und ich fing an, diese HOCs zu hassen ... zumindest ist das meine persönliche Erfahrung.)

HOCs müssen so ziemlich sterben. Es ist ein veraltetes Muster. Zum Beispiel kam react-redux mit dem useSelector Hook heraus, der 100-mal bequemer ist als der connect HOC, Apollo wechselte von HOCs zu Hooks, dasselbe gilt für useStyles Hook in dieser Bibliothek ist praktischer als withStyles .

Der Aufwand beim Konvertieren von Copy-Paste-CSS in JSS ist ein viel lösbareres Problem. Wenn Interesse besteht, erstelle ich sogar eine VSCode-Erweiterung zur Automatisierung oder für eine Website.

Wenn Interesse besteht, werde ich sogar eine VSCode-Erweiterung zur Automatisierung erstellen

@jedwards1211 Es gibt paulmolluzzo.convert-css-in-js , aber wenn Sie es für JSS verbessern können, wäre das sicher willkommen.

Ja, sieht so aus, als könnte ich es definitiv verbessern, es konvertiert nur CSS-Eigenschaften, keine Regeln und Selektoren.

@jedwards1211 Ich habe gelesen, was Sie gesagt haben, und für einen Moment einen Schritt zurücktreten - es erinnert mich nur an Kommentare von Leuten, die über die Verwendung von Tabulatoren über Leerzeichen streiten. Die Realität ist, dass es nicht wirklich einen Unterschied macht, was Sie verwenden, solange es am Ende ein nützliches Produkt ergibt.

Hinterlassen Sie Ihre Meinungen/Hot Takes auf Twitter oder Reddit und wir können sie dort drüben diskutieren – aber lassen Sie uns dieses Problem nicht weiter mit sinnlosen Flame Wars auf Template-Strings vs. Objekten für CSS entgleisen … Ich denke, wir sind uns alle einig, dass wir besser sind als das 😄

Danke für den Hinweis, dass es sich nicht lohnt, den Status quo in MUI zu ändern? 😉

Meine Hauptsorge ist, wenn meine Webpack-Bundles mit einer Mischung aus Styled-Components-Code und JSS-Code aufgebläht werden, weil es zu viel vorhandenes JSS in unserer App gibt, um es herauszureißen und durch etwas anderes zu ersetzen, und/oder weil ich dabei bleiben möchte JSS für unsere Stile sowieso.

Um fair zu sein, ich interessiere mich nicht für Tabs oder Leerzeichen, aber wenn ich ein halbes Dutzend HOCs für jede von mir erstellte Komponente schreiben müsste, würde mir meine Arbeit keinen Spaß machen. Alle existierenden Werkzeuge waren in der Lage, ein nützliches Produkt herzustellen; Wenn irgendetwas in allen Fällen wirklich bequem zu verwenden wäre, gäbe es keine ständigen Veränderungen im Ökosystem, und wir würden diese Debatten nicht führen. Es macht also wirklich einen Unterschied, wenn man darüber nachdenkt.

@jedwards1211 Selbst wenn Sie gezwungen sind, Styled Components zu verwenden, gibt es eine alternative css prop -Syntax, die in v4 eingeführt wurde und die Sie verwenden können - zumindest müssen Sie sich auf diese Weise keine Sorgen machen Vergeben von Präfixen für gestylte Komponenten (MuiCard, StyledCard etc.).

import { Avatar } from '@material-ui/core';

// CSS is separate from the markup 👍
const avatarStyle = css`
  width: 32px;
  height: 32px;
  border-radius: 50%
`;

// No wrappers, prefixes in the markup (such as <MuiAvatar>, <StyledAvatar> etc.) 👍
function SomeComponent(props) {
  return <div> ... <Avatar css={avatarStyle} /> ... </div>
}

@jedwards1211 Ihr Beispiel kann auch wie folgt vereinfacht werden, wenn Sie formatierte Komponenten verwenden

const Card = styled(MuiCard)`
  display: flex;

  ${MuiCardContent} {
    flex: 1 0 auto;
  }

  ${MuiCardMedia} {
    width: 151px;
  }
`

const Details = styled.div`
  display: flex;
  flex-direction: column;
`

@koistya die css Requisite ist irgendwie cool, obwohl ein wichtiger Vorbehalt darin besteht, dass sie mit einem Babel-Plugin implementiert ist, also ist sie nicht jedermanns Sache, insbesondere nicht für Leute, die tsc verwenden, um ihre tsx-Dateien zu kompilieren. Ich nehme auch an, dass TypeScript oder zumindest Flow sich beschweren würde, dass die Komponente keine css -Prop hat.

Ich denke, ich bin hauptsächlich nur unglücklich über die potenzielle Störung, die dies in meiner App verursachen würde. @oliviertassinari erwähnte neulich, dass er darüber nachdenke, styled-components zum Standard in MUI v5 zu machen. Und das wäre hoffentlich optional und JSS könnte immer noch verwendet werden, aber wir werden sehen, ob sie das durchziehen können, wissen Sie. Es war ein Schock -- Hat es wirklich ein gründliches Referendum über die Präferenzen der gesamten Benutzerbasis gegeben? Ich hätte Emotion erwartet, wenn überhaupt, weil es jetzt viel beliebter ist.

Ich nehme auch an, dass TypeScript oder zumindest Flow sich beschweren würde, dass die Komponente keine CSS-Prop hat.

Kann konfiguriert werden.

Hat es aber wirklich ein gründliches Referendum über die Präferenzen der gesamten Nutzerbasis gegeben?

Das ist unmöglich. Wir können nur davon ausgehen, dass die Leute, die sich auf GitHub engagieren, "unsere" Benutzer sind. Diese Ausgabe ist die am meisten positiv bewertete, die wir je hatten .

Ich hätte Emotion erwartet, wenn überhaupt, weil es jetzt viel beliebter ist.

Wie haben Sie die Popularität gemessen?

⚠️ Emotion wird von Entwicklern deutlich seltener gewählt als gestylte Komponenten (/6, soweit ich mich erinnere). Wenn Sie die Downloads auf npm berücksichtigen, entfernen Sie Storybook und reagieren Sie auf die Anzahl der Downloads (es ist riesig).

@eps1lon hier ist, was ich mir angesehen habe: https://2019.stateofcss.com/technologies/css-in-js/

Ich habe mich jedoch geirrt, leider war alles, woran ich mich erinnerte, der scheinbare Aufwärtstrend, obwohl dies kein Diagramm der Popularität im Laufe der Zeit ist (sehr fragwürdiges Diagrammdesign):

Kann konfiguriert werden

Gibt es tatsächlich eine Möglichkeit, TypeScript davon auszugehen, dass alle JSX-Elemente eine css -Prop unterstützen? Ich kenne keine Möglichkeit, Flow dafür zu konfigurieren.

BEARBEITEN : Zum Glück habe ich einen Weg für TypeScript gefunden, nicht sicher, ob es einen Weg für Flow gibt.

Diese Ausgabe ist die am meisten positiv bewertete, die wir je hatten.

Ich verstehe. Seufzen

FWIW, einer der Hauptverantwortlichen für styled-components , scheint eine unfreundliche Haltung gegenüber Typensystemen zu haben:

https://github.com/styled-components/styled-components/issues/3012#issuecomment -583878486

Ich würde mich viel beruhigter über die Idee fühlen, zu Styled-Components zu migrieren, wenn sie sich anscheinend um die Entwicklungserfahrung von TS/Flow-Benutzern kümmern würden ...

@jedwards1211 es gibt ein Babel-Makro für css falls das hilft. Besonders wenn ich von css/scss/less komme, glaube ich nicht, dass jeder gerne auf den "gestylten" Weg umsteigt.

Was sind aber die Ziele? Was ist mit der Leistung? Einige Systeme unterstützen zB Atomic CSS. Von Tailwinds kommend, macht es die Dinge viel sauberer und vielleicht schneller.

@hc-codersatlas einige Benchmarks finden Sie in packages/material-ui-benchmark .

@koistya Wenn ich es richtig gelesen habe, sieht die Emotion viel schneller aus als der Rest.

@oliviertassinari "treffen" die meisten Entwickler tatsächlich diese Wahl? Gemäß Ihrer Erwähnung von „React-Select“ und „Storybook“ werden die meisten Entwickler wahrscheinlich alles verwenden, was mit den UI-Komponenten gebündelt ist, und „Material-UI“ ist eine große 1. Wenn das Gebündelte nicht schrecklich ist, wird keine 1 ihre Paketgröße und -ausgaben erhöhen mehr Aufwand mit einem anderen System zusätzlich zu dem, was das UI-Framework bereits verwendet.

Die meisten dieser UI-Frameworks stammen von großen Konzernen, dh einige Leute treffen tatsächlich diese "Wahl".

z. B. verwendet Tülle gestylte Komponenten, die viele Unternehmen an 1 Punkt verwenden / verwendeten.

Und in diesem Sinne, was bedeutet npm downloads? Die Verwendung in Unternehmen bedeutet wahrscheinlich Firewalls und internes npm-Caching, was diese Metriken verzerrt.

Wenn es eine Änderung geben wird, wechseln Sie bitte auf die beste 1 basierend auf dem technischen Wert und nicht auf etwas wie Popularität. Ich sage voraus, dass, wenn material-ui irgendeine Bibliothek verwendet, es die beliebteste sein wird, da mui selbst eines der beliebtesten ui-Frameworks ist.

@South-Paw Ihre vorgeschlagene Vereinfachung würde nicht funktionieren, Sie können ${MuiCardContent} in Ihrem Beispiel nicht verwenden, da MuiCardContent keine gestylte Komponente ist.

https://styled-components.com/docs/advanced#referring -to-other-components

Im Grunde gibt es keine Möglichkeit, alle einzelnen HoC-Wrapper zu vermeiden. Nachdem ich eine Weile darüber nachgedacht hatte, wurde mir jedoch klar, dass es im Grunde die gleiche Menge an Eingabe- / Namensentscheidungen ist, die man mit JSS treffen muss.

@mbrookes @oliviertassinari wie würden bedingte Stile und innere Komponentenstile gehandhabt?
Was wäre zum Beispiel ein styled-components basierendes Äquivalent des Folgenden?

// conditional class name
<MenuItem classes={{selected: classes.selectedItem}}>...</MenuItem>

// inner component class name
<Dialog classes={{paper: classes.dialogPaper}}>...</Dialog>

Ich habe mich über die Idee des Wechsels zu styled-components beruhigt, aber ich möchte sicherstellen, dass es einen soliden Plan für die Handhabung dieser Art von Anwendungsfällen gibt, da ich davon ausgehe, dass die API sehr unterschiedlich sein oder sich darauf verlassen müsste auf Klassennamen im BEM-Stil.

@jedwards1211 ah mein Fehler. Ich hatte den Eindruck, dass das Beispiel gestylte Komponenten wäre - aber das wird in der Tat nicht funktionieren, wenn sie es nicht sind 👍

@jedwards1211 clsx ist etwas, das ich in der Vergangenheit für bedingte Klassen gepaart mit styled-components gesehen habe - meinst du das so?

Projekte, die ich im Moment durchführe, verwenden styled-components, die MUI-Komponenten nach Bedarf umhüllen, also habe ich überhaupt kein bedingtes Styling von MUI verwendet

@South-Paw das (oder classnames ) könnte ein internes Detail der Lösung sein, aber was ich meine ist, da styled-components Wrapper nur ein einziges className AFAICT injizieren, würde es Es ist nicht wirklich eine bequeme Möglichkeit, mehrere Überschreibungsklassennamen an eine Komponente zu übergeben. Stattdessen müssen wir möglicherweise etwas wie <Dialog Paper={StyledPaper}>...</Dialog> tun, und ich bin mir nicht einmal sicher, was für das ausgewählte Klassenbeispiel MenuItem ist.

@jedwards1211 hätten Sie die Zeit, ein kurzes Beispiel zu machen, damit ich besser verstehen kann, was der von Ihnen beschriebene Anwendungsfall ist und wo Ihrer Meinung nach das Problem liegt? Ich würde gerne versuchen, mit einer Lösung zu helfen, aber ich verstehe einfach noch nicht, wofür das gilt 😄

Ja, ich habe heute Abend keine Zeit, aber morgen werde ich es tun.
Außerdem arbeite ich an jss-codemorphs und plane schließlich, eine VSCode-Erweiterung zum Konvertieren von eingefügtem CSS in JSS zu erstellen.

war noch nie ein Fan der Styled-Components-Syntax oder der Art und Weise, wie das Paket gewartet wird, kein Fan dieses Vorschlags. Eines der Dinge, die ich an Material ui am meisten mag, ist die aktuelle Styling-Lösung.

Es ist interessant festzustellen, dass ich gelesen habe, dass Facebook möglicherweise auch eine CSS-in-JS-Lösung als Open-Sourcing anbietet. Es könnte sich lohnen, sich das auch anzusehen, wenn es herauskommt.

Zum eigentlichen Thema. Ich mag gestylte Komponenten nicht, weil die Typescript-Erfahrung nicht großartig ist. Die Typen schaden oft mehr, als dass sie helfen. Langsame Kompilierungszeiten, wahnsinnige Schnittstellen (zu verstehen, wie gestylte Komponenten über die Schnittstelle funktionieren, ist ein Albtraum aufgrund all dieser verschachtelten Pick -Magie). Solange styled-components diese Art von DX hat, würde es sich für material-ui als Rückschritt anfühlen, dies zu übernehmen.

Es ist interessant festzustellen, dass ich gelesen habe, dass Facebook möglicherweise auch eine CSS-in-JS-Lösung als Open-Sourcing anbietet.

@venikx Wie wahrscheinlich wird es passieren? Das letzte Mal, als ich von etwas gehört habe, das darauf hindeuten könnte, war es in https://reactpodcast.simplecast.fm/75 , es schien ein 5-Jahres-Ziel zu sein.

Wow wirklich? Ich wusste nicht, dass sie bereits einen „Zeitplan“ angegeben haben. Aus irgendeinem Grund nahm ich an, dass es ungefähr zur gleichen Zeit wie der Concurrent Mode kommen würde. Schade.

Abgesehen davon bleibt mein Punkt zu den gestylten Komponenten bestehen. Ich ziehe es vor, die Art und Weise, wie Stile von reinem Material-ui behandelt werden, zu verwenden, anstatt gestylte Komponenten zu verwenden. Die Eingaben von styled-components scheinen für den Compiler da zu sein und nicht so sehr für die Dokumentation.

Eine weitere ärgerliche Sache (aber das ist wahrscheinlich wieder eine persönliche Vorliebe) ist, wie Sie mit der dynamischen Anwendung von Stilen auf eine Komponente umgehen. Ich bevorzuge das Hinzufügen oder Entfernen von Klassennamen gegenüber dem Einbetten dieser Logik in die Stilkomponente.

Material-ui api ist im Moment wirklich sauber imho.

Ich mag gestylte Komponenten nicht, weil die Typescript-Erfahrung nicht großartig ist.

Ich habe styled-components und Typescript bisher in mindestens 4 großen Projekten zusammen verwendet und hatte keine Probleme mit den Typen - sie können etwas haarig sein, wenn sie Dinge in einer Komponentenbibliothek tun, aber das liegt an MUIs Seite - nicht auf der Verbraucherseite.

Langsame Kompilierungszeiten

Ich habe dies in keinem Projekt erlebt, an dem ich gearbeitet habe, das sie verwendet - haben Sie irgendwo ein Beispiel dafür, was Sie meinen?

wahnsinnige Schnittstellen (zu verstehen, wie gestylte Komponenten über die Schnittstelle funktionieren, ist ein Albtraum aufgrund all dieser verschachtelten Pick-Magie)

Sie könnten auch in Betracht ziehen, zum @types- Projekt beizutragen, wenn Sie glauben, dass Sie sie irgendwie verbessern können - ich bin sicher, jeder würde jede Arbeit darin zu schätzen wissen, wenn es eine Verbesserung gegenüber dem ist, was jetzt da ist!

Ich bevorzuge das Hinzufügen oder Entfernen von Klassennamen gegenüber dem Einbetten dieser Logik in die Stilkomponente.

Nichts hindert Sie daran, Klassen mit with styled-components zu verwenden:

const Box = styled.div`
  height: 160px
  width: 160px;
  background-color: black;

  .red {
    background-color: red;
  }
`;

// simple usage
<Box className="red" />

// get more complex with conditionals and using something like clsx (https://www.npmjs.com/package/clsx)
const isRed = true;
<Box className={clsx({ red: isRed })} />

Erwähnenswert ist, dass es trotz einiger anders lautender Kommentare 150 👍 und 27 🎉 in der übergeordneten Ausgabe und nur 18 👎 und 9 😕 gibt. Scheint, als gäbe es eine lautstarke Minderheit, die diese Diskussion nicht mag, und eine Mehrheit, die denkt, dass es ein positiver Schritt ist 🤷‍♂

@South-Paw das Problem bei der Abstimmung ist, dass die einzige Wahl ist: JSS vs. styled-components. Beim Gesang geht es darum, gestylte Komponenten nicht zu mögen und nicht, dass sie JSS mögen. Vielleicht, wenn die Abstimmung

Am Ende des Tages ist alles besser als JSS. Es ist alt. Es ist langsam und sperrig (Bündelgröße) und sollte verschoben werden. Die Stimmen stützen Ihre Schlussfolgerung also überhaupt nicht.

Könnten Sie alle zum Spectrum-Chat wechseln oder etwas, das diese Ausgabe nicht mit Lärm über Leute füllt, die gegeneinander kämpfen, um zu sehen, wer den Streit gewinnt?

Ich verfolge den Thread für Diskussionen zu diesem Thema vom Kernteam.

Ich denke, Sie unterschätzen das Urteilsvermögen des Kernteams, und ich persönlich bin der Meinung, dass Sie aufhören sollten, über dieses Thema zu streiten, und dem Kernteam mehr vertrauen sollten. Am Ende des Tages liegt es am Kernteam, über die Richtung der Material UI zu entscheiden.

Wenn Sie wirklich eine starke Meinung dazu haben, Material UI ist erstaunlich MIT-lizenziert, forken Sie es und fahren Sie mit der Vision fort, die Sie haben. Ich ermutige Sie dazu, vielleicht lernen wir in Zukunft aus der vielfältigen Umgebung.

Aber bitte, ich bitte Sie, lassen Sie das Kernteam seine Arbeit machen, vertrauen Sie ihm, denn es sind wirklich kompetente Leute mit erstaunlichen Fähigkeiten.

Hier gibt es etwas Schönes zu sehen

Am Ende des Tages ist alles besser als JSS. Es ist alt.

@hc-codersatlas alt == ausgereift - könnten Sie bitte erläutern, warum das ein Problem ist?

Ok scheint ein heißes Problem zu sein, aber kann bitte jemand diese einfache Information bestätigen: Ist es derzeit möglich, in aktuellen Mui-Versionen (4 oder 5) eine styled-components -ähnliche Syntax mit getaggten Vorlagenliteralen zu verwenden, die wie CSS aussehen? ?
Ich konnte keine eindeutige Ja- oder Nein-Antwort auf diese Frage finden. Ich interessiere mich nicht wirklich für die zugrunde liegende Technologie, nur für die Entwicklerfreundlichkeit. Das Kopieren und Einfügen von CSS aus InVision ist in einigen Fällen grundsätzlich sehr nützlich.

In diesem Problem geht es um die in Material-UI verwendete Styling-Lösung. Ihre Frage scheint zu sein, wie Sie Ihre App stylen / die Komponenten neu gestalten, für die Sie eine beliebige Lösung verwenden können:

https://material-ui.com/guides/interoperability/

JSS bietet grundlegende Unterstützung für Template-Literale als Plug-in.

Ich habe gerade die Implementierung eines sehr umfassenden CSS-zu-JSS-Konverters abgeschlossen:

• https://codemodsquad.github.io/jss-codemorphs/
• VSCode-Erweiterung: https://marketplace.visualstudio.com/items?itemName=vscodeshift.jss-codemorphs

Hoffentlich entfällt das mühsame Kopieren und Einfügen von CSS in JSS-Stile.

@jedwards1211 siehe das
https://css2js.dotenv.dev/

@nainardev Ich habe festgestellt, dass und andere Dienstprogramme sehr begrenzt sind. Sie konvertieren CSS-Attribute, konvertieren jedoch keine Selektoren, verschachtelten Selektoren, Animations-Keyframes, Medienabfragen usw. Aus diesem Grund habe ich mein Tool sehr umfassend gemacht, es kann konvertieren hoffentlich jedes ausgewachsene CSS, das Sie darauf werfen.

Könnte diese Antwort irgendwo verpasst haben, möchte sie aber trotzdem ansprechen. Wir sind dabei, zu Material UI-Komponenten zu migrieren und unsere Styling-Lösung zu evaluieren ( less vs. makeStyles vs. styled-components ). Der größte Teil unseres Stylings erfolgt über weniger Dateien und der größte Teil des neuen MUI-Codes verwendet makeStyles , was ich klarstellen möchte, ist, da dies Teil von v5 sein wird, was können wir tun, um die technischen Schulden rund um das Styling zu reduzieren?

1. Wird es makeStyles in v5 geben? Wie wird es mit styled-components und Themen funktionieren? Wie sieht das beispielsweise mit styled-components aus:

const useStyles = makeStyles((theme) => ({
  paper: {
    padding: theme.spacing(2),
    textAlign: 'center',
    color: theme.palette.text.secondary,
  },
}));

1. (v4) Gibt es eine bessere Möglichkeit, das theme -Objekt in einer formatierten Vorlagenzeichenfolge abzurufen, damit ich es mehrmals verwenden kann?

const StyledContainer = styled.div`
  color: ${({ theme }) => theme.palette.primary.main};
  padding: ${({ theme }) => theme.spacing(1)};
  background-color: ${({ theme }) => theme.palette.background.paper};
`;

1. Unter der Annahme, dass makeStyles in v5 vorhanden ist, sollten wir Leistungseinbußen erwarten, wenn wir sowohl den styled-components -Designanbieter als auch den Material-UI-Designanbieter für eine große Codebasis verwenden?

Ich liebe die Verwendung von Material UI, danke für all die harte Arbeit!

@Egilster

1. Ja, entweder von @material-ui/styles oder von respond-jss, wird angezeigt.
2. Ja https://material-ui.com/guides/interoperability/#theme ,

const StyledContainer = styled.div`
  ${({ theme }) => `
  color: ${theme.palette.primary.main};
  padding: ${theme.spacing(1)};
  background-color: ${theme.palette.background.paper};
  `}
`;

1. Die Hauptprobleme sind 1. Konfigurations-Overhead, einmalige Kosten, 2. Laden von zwei CSS-in-JS-Laufzeiten, was einen gzippten Overhead von ~15 kB hat, ähnliche Kosten, um zu sagen, einschließlich Sentry: https://bundlephobia.com /result?p=@sentry/browser.

Vielen Dank für eine schnelle Antwort, sehr geschätzt.

1. Ja material-ui.com/guides/interoperability/#theme

Das ist ziemlich cool. Einige Workaround-Tools würden wahrscheinlich folgen, das Projekt, das ich migriere, verwendet kein TS, aber VSCode / Sprachserver scheint keine Ahnung zu haben, was theme in diesem Fall ist, und ich verliere styled-components auch Syntaxhervorhebung.

Nochmals vielen Dank, werde diese Entwicklung weiter verfolgen.

@oliviertassinari Wenn es eine Migration zu Styled-Components gibt, bedeutet das, dass wir uns nicht mehr auf CSS-APIs wie <ListItem classes={{ selected: myCustomClassName}}> verlassen können?

@jedwards1211 Die classes -API bleibt bestehen.

In Ordnung. Ich bin etwas verwirrt, wie MUI dann intern styled-components verwenden würde, da styled-components nur eine einzige Klasse auf das Root-Element anwenden können.

const MyRoot = styled('div')`
  // some nice styles
`;

const MyAwesomeChild = styled('div')`
  // some nice styles
`;

export function AwesomeRoot(props) {
  return (
    <MyRoot className={props.classes?.root}>
      <MyAwesomeChild className={props.classes?.child}/>
      {props.children}
    </MyRoot>
  );
}

Macht das Sinn @jedwards1211 ?

@yordis Ich weiß, es scheint so einfach zu sein, aber wie würden Sie zusammengesetzte Selektoren wie https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/Button/Button.js umgestalten?

Ich kann mir wirklich keinen Weg vorstellen, dieses bestehende Verhalten mit styled-components , daher könnte es mehr Breaking Changes verursachen, als die Leute erwarten.

  outlined: {
    '&$disabled': {
      border: `1px solid ${theme.palette.action.disabledBackground}`,
    },
  },

Der vorhandene Code und die benutzerdefinierten Überschreibungen der Benutzer hängen wahrscheinlich in einigen Fällen auch von CSS-Spezifitäten ab.

Vielleicht das? Ich bin mir nicht sicher, ob ich folgen soll, da sich dies für mich grundlegend anfühlt. Wahrscheinlich fehlen mir Kontext und / oder Informationen.

const MyOutlinedComponent = styled('div')`
  ${props.disabled && `
      border: `1px solid ${({ theme }) => theme.palette.action.disabledBackground}`,
  `}
`;

<MyOutlinedComponent disabled/>

@yordis möglicherweise. Wie ich bereits sagte, obwohl die Leute wahrscheinlich nicht darüber nachdenken, wie viele Breaking Changes dies für Benutzer verursachen wird, glaube ich nicht, dass dieses Beispiel Breaking Changes verhindern würde.

Würde es Ihnen etwas ausmachen, echte Beispiele und echte potenzielle Breaking Changes zu teilen?

Es ist schwer, Ihnen zu folgen, wenn Sie keine starken Fälle teilen. Basierend auf Ihren Nachrichten denke ich, dass Sie dieses Thema nicht vollständig verstehen, oder ich treffe möglicherweise falsche Urteile. Bitte helft mir zu verstehen, vielleicht bin ich der falsche.

@oliviertassinari werden Theme-Überschreibungen in v5 immer noch ohne Änderung funktionieren? Damit das folgende Überschreibungsbeispiel funktioniert, müsste MUI anscheinend immer noch JSS-generierte Klassennamen zusätzlich zu einem styled-components generierten Root-Klassennamen anwenden.

const theme = createMuiTheme({
  overrides: {
    MuiButton: {
      root: {
        '&$disabled': {
          color: myCustomColor,
        },
      },
    },
  },
});

@yordis , nachdem ich mehr darüber nachgedacht hatte, stellte ich fest, dass zusammengesetzte Selektoren für Stile, die über classes Prop übergeben wurden, glücklicherweise immer noch funktionieren würden. Ich bin mir jedoch nicht sicher, ob es um Themenüberschreibungsstile geht.

Ich hatte das Vergnügen, beide Styled-Komponenten über MUI zusammen mit einfachem MUI-Styled unter Verwendung von style={object} zu verwenden.

Nehmen Sie eine Ergebnislistenseite, die 50 Karten enthält, jede mit Medienkarussells, Informationen, Klick-Handlern, Schaltflächen usw.

Die Verwendung von gestylten Komponenten verlängerte die Renderzeit um fast eine halbe Sekunde; im Vergleich zu const useStyles = makeStyles oder style={object}.

Ich muss das Ergebnis dieser Roadmap-Planung akzeptieren; aber es wird definitiv einen Knick in unsere Pläne für die Einführung der Benutzeroberfläche werfen, wenn es nicht mit etwas anderem vollständig von oben nach unten überschrieben werden kann.

@Icehunter könnten Sie Ihre Ergebnisse und Ihr Beispielprojekt online veröffentlichen, damit die Leute es sich ansehen können?

@Icehunter könnten Sie Ihre Ergebnisse und Ihr Beispielprojekt online veröffentlichen, damit die Leute es sich ansehen können?

Das Beispielprojekt wäre schwierig, da es proprietären Code enthalten würde. Ich werde bald ein gerendertes Bild und den Abschnitt mit den Timing-Ergebnissen auf der Registerkarte "Leistung" veröffentlichen.

Nehmen Sie eine Ergebnislistenseite, die 50 Karten enthält, jede mit Medienkarussells, Informationen, Klick-Handlern, Schaltflächen usw.

@Icehunter schickst du Requisiten zu diesen Styles? Egal, ob es sich um 50 oder 500 Karten handelt, die Anzahl der generierten Klassen sollte gleich sein. hört sich so an, als ob Ihr spezifisches Beispiel proprietären Code enthält, der nicht freigegeben werden kann, aber wäre es möglich, dass Sie dieses Problem mit Code reproduzieren, den Sie freigeben können?

styled() / styled.div APIs erhöhen den Aufwand für das Rendern von _jedem_ Element, sodass es selbst mit dem Caching von Klassennamen langsamer sein kann. Mit makeStyles können Sie eine Gruppe von Stilen einmal anhängen und dann einfach Klassennamen manuell zuweisen, was oft erheblich schneller ist.

Ich habe ein CodeSandbox-Beispiel zusammengestellt, um zu veranschaulichen, dass Lösungen, die auf gestylten Komponenten styled basieren, 3-4x langsamer sein können als eine MUI makeStyles :

styled APIs sind praktisch, aber ich schließe mich @Icehunters Meinung an, dass es ein Leistungsproblem sein kann, wenn es stark in Listen/Tabellen verwendet wird. Es ist schön, makeStyles als Backup zu haben.

@schnerd Danke, dass du diese Beispiele zusammengestellt hast, sie veranschaulichen das Anliegen wirklich gut. Nur als Randbemerkung, die dem Beitrag vorangestellt wird: "Es ist nicht schwer zu sehen ..." kann als eine Art herablassend rüberkommen und hat nicht wirklich zu einer ansonsten hervorragenden Reihe von Beispielen beigetragen

@tuxracer Entschuldigung – aktualisiert.

@Icehunter Ich verstehe nicht, was du damit meinst, du hast die gängigen Stile mit SC oder JSS verwendet?

@Icehunter Ich verstehe nicht, was du damit meinst, du hast die gängigen Stile mit SC oder JSS verwendet?

Eigentlich beides. Am Ende haben wir uns für makeStyles entschieden, aber entweder das oder die Verwendung von styled={object} hat uns die gleichen Leistungsergebnisse gebracht.

Wir befinden uns in einem Migrationsprozess, um die Leistung der gesamten Komponentenbibliothek und der Hauptseite zu verbessern.

Stapelweise ist es in nextjs geschrieben.

Nur um es klar zu stellen (editieren):

Ich habe SC wie beabsichtigt verwendet und mui-Komponenten verpackt. Sehr langsam ausgefallen.

Dann habe ich mui-Komponenten mit makeStyles und/oder style={object} aus einem freigegebenen Datei-Setup und lokal (simulierte Kaskadierung) verwendet. Viel viel schneller.

Ich möchte diese Idee überhaupt nicht blockieren; aber wenn es Standard ist; Dann sollte es eine Möglichkeit geben, die Standardauswahl global von oben nach unten zu überschreiben und Ihre eigene zu injizieren.

Vielleicht das? Ich bin mir nicht sicher, ob ich folgen soll, da sich dies für mich grundlegend anfühlt. Wahrscheinlich fehlen mir Kontext und / oder Informationen.

const MyOutlinedComponent = styled('div')`
  ${props.disabled && `
      border: `1px solid ${({ theme }) => theme.palette.action.disabledBackground}`,
  `}
`;

<MyOutlinedComponent disabled/>

Vielleicht bin ich zu spät für dieses Spiel. Aber ich denke, @jedwards1211 sucht nach einer Möglichkeit, wie dies mit SC ausgedrückt werden kann: https://codesandbox.io/s/magical-snow-5bzd8

Ich selbst habe das an manchen Stellen. Es wäre also schön, wenn es einfach wäre, zu v5 zu migrieren, wenn dieser Tag kommt

Eigentlich bin ich mir nicht sicher, wie so etwas mit styled-components funktionieren wird.

Wenn beispielsweise Material UI in Zukunft das Überschreiben der Standardvarianten von Typography unterstützen wird, denke ich, dass JSS einfacher ist als styled-components.

@heb-mm hier gibt es einen ausführlichen RFC, in dem @oliviertassinari diesen Thread am 7. März erwähnt hat.

Ich brauchte weniger als eine Minute, um nach oben zu scrollen und die Erwähnung zu sehen.

Bearbeiten: Für diejenigen, die sich fragen, heb-mm hat ihren Kommentar jetzt gelöscht.

Ich habe ein CodeSandbox-Beispiel zusammengestellt, um zu veranschaulichen, dass Lösungen, die auf gestylten Komponenten styled basieren, 3-4x langsamer sein können als eine MUI makeStyles :

@schnerd Ich habe Ihren Benchmark aktualisiert, um die interne styled API der Material-UI einzuschließen, die styled-components imitieren sollte. Ich war überrascht zu sehen, wie unglaublich langsam es im Vergleich zu den anderen Optionen ist. Siehe https://codesandbox.io/s/css-in-js-comparison-ljtjz?file=/src/App.js

Weiß jemand, ob @emotion/styled (das im Grunde die gleiche API wie styled-components hat) genauso langsam wäre? Ich frage mich nur, ob es etwas an ihrer Implementierung gibt, das besser optimiert werden könnte.

Weiß jemand, ob @emotion/styled (das im Grunde die gleiche API wie styled-components hat) genauso langsam wäre? Ich frage mich nur, ob es etwas an ihrer Implementierung gibt, das besser optimiert werden könnte.

https://codesandbox.io/s/css-in-js-comparison-sej1m

Ungefähr so ​​schnell wie gestylte Komponenten. Immer noch nicht so schnell wie makeStyles. Das Problem, das ich zum größten Teil sehe, ist die Objekterstellung und die Unterschiede zwischen Objekt-Caching/Memoisierung.

Hmm, das könnte unsere Migrationspläne zu MUI ziemlich durcheinanderbringen. Wir bewegen uns derzeit weg von styled-components zugunsten des Material-UI-Styling-Systems, nachdem wir auf eine Menge Probleme bei der Verwaltung unseres CSS, Themes und der Leistung gestoßen sind. styled components war anfangs in Ordnung, wir haben unsere eigene Designlösung darauf aufgebaut, aber als die Benutzeroberfläche wuchs, wuchs auch das CSS. Wir verwenden TypeScript, daher war die Tatsache, dass wir ein JS-Objekt anstelle eines Inline-CSS-Strings problemlos umgestalten konnten, ein großes Verkaufsargument. 😕

Ich bin also ziemlich neu bei Material UI und habe auch gerade die Alpha-Version von v5 gesehen. @ldiego08 du sagtest:

Wir bewegen uns derzeit weg von gestylten Komponenten zugunsten des Material-UI-Styling-Systems

Normalerweise verwende ich gestylte Komponenten, wenn ich mit React arbeite. Was ist das Material-UI-Styling-System und was ist die empfohlene Art und Weise, Stile und CSS in der Material-UI in Zukunft zu verwenden? Ich habe diese Seite gelesen und es ist mir nicht klar, ob Sie für CSS-IN-JS sind oder nicht: https://material-ui.com/system/basics/. Normalerweise ziehe ich es vor, CSS nicht in Objektsyntax zu schreiben, und ich habe die Vorteile der Verwendung von CSS-IN-JS genossen, da Sie die "normale CSS-Syntax" verwenden können, aber auch die Leistungsfähigkeit von JS zur Hand haben.

Danke für jede Hilfe, um loszulegen!

Ich weiß nicht, warum die Styled-Components-API so beliebt ist. Es ist langsamer, Sie müssen alles in die Komponente packen, anstatt nur den Klassennamen zu generieren. Und was hat es mit getaggten Template-Literalen auf sich? Wir wollten CSS nicht in CSS-Dateien schreiben, weil es viel besser ist, es in Javascript-Strings zu schreiben? :D Die Objektsyntax ist viel leistungsfähiger, wenn es um Komposition und Refactoring usw. geht. Für mich sind einfache CSS- und CX-Funktionen für Emotionen, die ein CSS-Objekt verwenden und den Klassennamen zurückgeben, die flexibelste und leistungsfähigste API. Das einfache Generieren von Klassennamen mit Emotionen und die Verwendung der Klassen-API ist also super flexibel und leistungsstark. Ich verstehe also nicht, warum Sie Leistung und Flexibilität gegen eine "bequemere Entwickler-API" eintauschen sollten (für manche Leute ist es für mich eine schreckliche API).

Ich weiß nicht, warum die Styled-Components-API so beliebt ist. Es ist langsamer, Sie müssen alles in die Komponente packen, anstatt nur den Klassennamen zu generieren. Und was hat es mit getaggten Template-Literalen auf sich? Wir wollten CSS nicht in CSS-Dateien schreiben, weil es viel besser ist, es in Javascript-Strings zu schreiben? :D Die Objektsyntax ist viel leistungsfähiger, wenn es um Komposition und Refactoring usw. geht. Für mich sind einfache CSS- und CX-Funktionen für Emotionen, die ein CSS-Objekt verwenden und den Klassennamen zurückgeben, die flexibelste und leistungsfähigste API. Das einfache Generieren von Klassennamen mit Emotionen und die Verwendung der Klassen-API ist also super flexibel und leistungsstark. Ich verstehe also nicht, warum Sie Leistung und Flexibilität gegen eine "bequemere Entwickler-API" eintauschen sollten (für manche Leute ist es für mich eine schreckliche API).

Ich hatte die gleiche Sorge :) Vielleicht klärt es die Dinge ein wenig auf:
https://github.com/mui-org/material-ui/issues/6115#issuecomment -580449539

@martinjlowm Ja , wir sind auf derselben Seite :) Ich denke, dass der klügste Weg für das Material-UI-Team darin besteht, eine Art Plug-in-Lösung zu implementieren und nicht mit einer CSS-in-js-Lösung zu koppeln, sodass die Leute wählen können, was sie verwenden möchten und Sparen Sie auf diese Weise etwas Bündelgröße. Und auch das Beibehalten von Klassen und die createMuiTheme-API, denn das ist der mächtigste Teil davon. Für mich geht es bei css in js um einfaches dynamisches Styling basierend auf dem Komponentenstatus, Vertrauen beim Refactoring oder Löschen von CSS oder ganzen Komponenten (hier ist der Objektansatz überlegen), Leistung (nicht das Herunterladen einer Reihe nicht verwendeter Stile aus einer Reihe externer Stylesheets). , etc .. Und wieder verstehe ich nicht, warum Leute gerne Strings mit einigen Editor-Hervorhebungen schreiben. Ich meine, Sie müssen ${} verwenden, um auf Requisiten aus dem Kontext zuzugreifen. Für etwas Komplexeres als das Festlegen des Hintergrunds oder des div-Elements ist dieser Ansatz meiner Meinung nach chaotisch und nicht lesbar. Ich beschimpfe es nicht, sage nur, was ich denke und versuche zu beweisen, dass nicht jeder Entwickler gestylte Komponenten mag, und selbst wenn sie es tun würden, sehe ich nicht, wie es ein gutes Geschäft sein sollte, Leistung und Flexibilität dafür einzutauschen :)

@vdjurdjevic In der Tat ist die Kopplung von Material-UI an eine CSS-in-js-Lösung fast ein garantiertes Rezept für Konflikte, wenn CSS-in-js-Praktiken unweigerlich in verschiedene Richtungen wachsen.

Wie wäre es mit einem Adaptermuster, das Styling mit einem bestimmten CSS-in-js-Anbieter anwendet? Die Stile selbst sollten in einem einheitlichen Format innerhalb der material-ui-Pakete definiert werden. Es ist die Anwendung dieser Stile, die von den entsprechenden Adaptern unterschiedlich durchgeführt wird.

Etwas in der Art von:

import {EmotionAdapter, StyledComponentAdapter, ThemeProvider} from "@material-ui/core/styles";
...
return 
    (<ThemeProvider theme={theme} adapter={EmotionAdapter}>
        ...
    </ThemeProvider>)

@vdjurdjevic Ich stimme Ihren Gedanken zu https://github.com/mui-org/material-ui/issues/6115#issuecomment -652762320 ziemlich zu. Vielleicht gefällt Ihnen diese Zusammenfassung unserer Richtung, die ich kürzlich unter https://github.com/mui-org/material-ui/issues/16947#issuecomment -653797178 veröffentlicht habe.

Ich verstehe nicht, warum Leute gerne Strings mit einigen Editor-Hervorhebungen schreiben

Ein paar Gründe aus meiner Sicht:

• Nahe daran, warum wir nicht React.createElement('div', {}) schreiben.
• Leute mit begrenzter Erfahrung in der Webentwicklung (es gibt viele) haben Mühe, die JavaScript-API zu lernen, mit der CSS-Syntax fühlt es sich einfacher an. Nehmen Sie die Designer als Beispiel, fragen Sie die in Ihrem Team, was sie darüber denken :).
• Kopieren und Einfügen zwischen Entwicklertools und Quelle ist nicht möglich (ich hasse dieses hier).

@oliviertassinari Ok, das sind ein paar solide Punkte, dem stimme ich zu :) Aber trotzdem wären für mich (kein Designer, kein Anfänger, Senior-Entwickler) gestaltete Komponenten und getaggte Vorlagenliterale niemals eine Option. Ich habe Ihre Zusammenfassung für die Richtung der weiteren Entwicklung gelesen und freue mich zu hören, dass die CSS-Engine optional sein wird. Ich habe nichts gegen gestylte Komponenten als Standard (wenn das die Mehrheit der Benutzer mag), solange ich das ändern kann. Und um ehrlich zu sein, denke ich, dass ich für mein nächstes Projekt bei JSS mit v4 bleiben werde, es hat einige nette Funktionen (wie Plugins zum Erweitern und Zusammenstellen). Ich musste ein Stylis-Plugin schreiben, damit Emotionen etwas Ähnliches haben.

PS. Ich bin auch kein großer Fan von JSX :) Es wird schnell chaotisch, man landet bei Pfeilcode und für Komponenten, die dynamische Elemente rendern sollen, bleibt einem nichts anderes übrig, als createElement zu verwenden. Ich sage nicht, dass es besser ist, direkt mit createElement zu arbeiten, sondern nur, dass JSX nicht ideal ist. Meiner Meinung nach hat Flutter das beste DX, ich hoffe, dass es eines Tages gut mit der Webplattform umgehen kann.

@oliviertassinari Gemäß unseren laufenden Leistungstests, wie in https://github.com/mui-org/material-ui/issues/6115#issuecomment -643398897 angegeben, hoffe ich nur, dass das Materialteam nicht nur gestylte Komponenten auswählt, weil sie beliebt sind. Es ist langsam. War schon immer. Persönlich ist es ein Punkt, ein Entwickler zu sein, dass Sie Dinge wie die JS-Notation von CSS lernen müssen.

Es ist Teil des Jobs.

Das Leben von Entwicklern einfacher zu machen, ist Teil unserer Arbeit als Paketbetreuer (für meine eigenen Projekte, von denen ich spreche), aber es gibt eine Grenze zwischen es einfach zu machen und es leistungsfähig zu machen.

Deshalb verwende ich nur makeStyles und habe es immer getan, seit es eingeführt wurde.

Mein letzter Teamarchitekt hörte nicht zu und pflügte mit gestylten Komponenten voran, und jetzt ist die Site langsam. Ich bin in einem Testzweig auf makeStyles umgestiegen und habe 50 % (10 Sekunden) bei TTI auf Mobilgeräten gespart, aber genau wie Sie in diesem Kommentar gesagt haben, ist die JS-Notation nicht jedem bekannt, daher wurde sie nicht akzeptiert.

Internes Material kann wählen, was es will, aber bitte machen Sie es standardmäßig performant.

[Frage nach StackOverflow verschoben.]

@haysclark Bitte verwenden Sie StackOverflow für Supportfragen, anstatt sie an einen RFC zu heften.

@haysclark Bitte verwenden Sie StackOverflow für Supportfragen, anstatt sie an einen RFC zu heften.

@mbrookes Danke für den Hinweis!

Weiß jemand, ob @emotion/styled (das im Grunde die gleiche API wie styled-components hat) genauso langsam wäre? Ich frage mich nur, ob es etwas an ihrer Implementierung gibt, das besser optimiert werden könnte.

https://codesandbox.io/s/css-in-js-comparison-sej1m

Ungefähr so ​​schnell wie gestylte Komponenten. Immer noch nicht so schnell wie makeStyles. Das Problem, das ich zum größten Teil sehe, ist die Objekterstellung und die Unterschiede zwischen Objekt-Caching/Memoisierung.

Ich habe mich gefragt, wie die Leistung der Box-Komponente mit Ihrer Profilerstellung verglichen werden würde, und habe die Box von Chakra-UI zur Sicherheit hinzugefügt, und die Ergebnisse waren ... überraschend: P
https://codesandbox.io/s/css-in-js-comparison-forked-mg3gx?file=/src/App.js

@Nvveen hast du Chakra-UI v1 ausprobiert? Es wurde umgeschrieben und sollte hoffentlich besser sein. Es gibt auch Emotion v11, obwohl noch in der Beta-Phase.

@Nvveen hast du Chakra-UI v1 ausprobiert? Es wurde umgeschrieben und sollte hoffentlich besser sein. Es gibt auch Emotion v11, obwohl noch in der Beta-Phase.

Habe es gerade mit dem neusten RC probiert, aber kein merklicher Unterschied; es ist immer noch etwa 1,5x bis 2x so langsam wie normales SC. Die größte Frage für mich ist, warum die MUI-Box so langsam ist.

@Nvveen hast du Chakra-UI v1 ausprobiert? Es wurde umgeschrieben und sollte hoffentlich besser sein. Es gibt auch Emotion v11, obwohl noch in der Beta-Phase.

Habe es gerade mit dem neusten RC probiert, aber kein merklicher Unterschied; es ist immer noch etwa 1,5x bis 2x so langsam wie normales SC. Die größte Frage für mich ist, warum die MUI-Box so langsam ist.

Es verwendet Jss. SC ist zumindest etwas besser.

Auf meinem Computer wirkt sich die Reihenfolge, in der die Testfälle ausgeführt werden, auf die Ergebnisse aus. Vergleichen

1. Box zuerst https://codesandbox.io/s/css-in-js-comparison-forked-tqlg1?file=/src/App.js
   

2. Box zuletzt https://codesandbox.io/s/css-in-js-comparison-forked-js6th?file=/src/App.js
   

@oliviertassinari Garbage Collection und Jit von v8 ist die Ursache. Es ist besser, Testläufe wirklich isoliert / getrennt zu haben. Die späteren Tests haben besseren Jit, aber hin und wieder löst es die Garbage Collection aus.

Es sieht so aus, als ob Emotion, SC und Chakra alle nahe an einer theoretischen Maximalleistung liegen, wenn jede kleine Komponente ihre eigenen Stile zum Montieren hat, wobei der MUI-Stil noch nicht ganz vollständig optimiert ist. Die einzige Möglichkeit, eine bessere Leistung zu erzielen, scheint darin zu bestehen, ein Stylesheet für den gesamten Komponentenbaum wie in makeStyles/pure CSS zu haben. Ich schätze, die zusätzlichen 30 ms für Emotion, SC usw. sind der unvermeidliche Mehraufwand für jede kleine Komponente, die sicherstellen muss, dass ihre Styles gemountet sind.

@jedwards1211 Wenn es darum geht, das dx zu behalten, hat Atlassian eine Lib erstellt, die es in CSS kompiliert, namens compiled