Material-ui: Produktionsaufbau - Klassennamenkonflikte

Ich habe bereits ein Problem mit diesem Problem gesehen. Es war immer mit duplizierten className-Generatorinstanzen verknüpft. Ohne Reproduktion kann ich nicht mehr helfen.

Ich schließe das Problem vorerst als nicht umsetzbar. Lassen Sie mich wissen, wenn Sie ein Reproduktionsbeispiel haben.

@oliviertassinari Ich konnte das Problem reproduzieren. Hier ist der Webpack-Bin - https://www.webpackbin.com/bins/-KuO6ia3h-JDpBOJncZ3

In meinem Fall habe ich 2 Anwendungsstammwurzeln, die unabhängig voneinander auf 2 verschiedenen Divs montiert sind. Beide verwenden dasselbe Material-ui ThemeProvider das mit JssProvider ThemeProvider umwickelt ist, um insertionPoint von _jss_ zu überschreiben.

Basierend auf der Funktion createGenerateClassName verwenden Sie den Zähler, um eindeutige Klassennamen zu erhalten

export default function createGenerateClassName(): generateClassName {
  let ruleCounter = 0;

  return (rule: Rule, sheet?: StyleSheet): string => {
    ruleCounter += 1;
    warning(
      ruleCounter < 1e10,
      [
        'Material-UI: you might have a memory leak.',
        'The ruleCounter is not supposed to grow that much.',
      ].join(''),
    );

    if (process.env.NODE_ENV === 'production') {
      return `c${ruleCounter}`;
    }

    if (sheet && sheet.options.meta) {
      return `${sheet.options.meta}-${rule.key}-${ruleCounter}`;
    }

    return `${rule.key}-${ruleCounter}`;
  };
}

Und mein Screenshot bestätigt, dass der Zähler aus irgendeinem Grund doppelt vorhanden ist.

Ich brauche Hilfe. Ich weiß nicht, was ich gerade falsch mache.

@darkowic Sie müssen die jss-Instanz zwischen den verschiedenen Reaktionsbäumen teilen. Sie sollten mit solchen Veränderungen gut umgehen können.

@oliviertassinari Ich glaube, ich mache es mit meinem benutzerdefinierten ThemeProvider

  <JssProvider registry={context.sheetsRegistry} jss={context.jss}>
    <MuiThemeProvider
      theme={context.theme}
      sheetManage={context.sheetsManager}
      {...props}
    />
  </JssProvider>

Damit wickle ich jeden meiner Reaktionsbäume ein.

Diese Ausgabe sollte geöffnet werden.

Lassen Sie uns zusammenfassen, was wir bisher wissen. Dieses Problem tritt auf, sobald Sie einen Rendering-Baum mit mehreren Reaktionen verwenden. Der JSS-Anbieter erstellt zwei Klassennamengeneratoren, einen für jeden Baum. Daher kommt es zu Klassennamenkonflikten.
@kof Sollten wir den JssProvider von react-jss , um einen Klassennamengenerator zu akzeptieren?

Umgehung für clientseitige Anwendungen: Sie können Ihre eigenen createGenerateClassName erstellen und ruleCounter außerhalb der Wrapper-Funktion verschieben

import warning from 'warning';

// Returns a function which generates unique class names based on counters.
// When new generator function is created, rule counter is reset.
// We need to reset the rule counter for SSR for each request.
//
// It's an improved version of
// https://github.com/cssinjs/jss/blob/4e6a05dd3f7b6572fdd3ab216861d9e446c20331/src/utils/createGenerateClassName.js
//
// Copied from material-ui due to issue https://github.com/callemall/material-ui/issues/8223

// This counter is moved outside from `createGenerateClassName` to solve the issue
let ruleCounter = 0;

export default function createGenerateClassName() {
  return (rule, sheet) => {
    ruleCounter += 1;
    warning(
      ruleCounter < 1e10,
      [
        'Material-UI: you might have a memory leak.',
        'The ruleCounter is not supposed to grow that much.'
      ].join('')
    );

    if (process.env.NODE_ENV === 'production') {
      return `c${ruleCounter}`;
    }

    if (sheet && sheet.options.meta) {
      return `${sheet.options.meta}-${rule.key}-${ruleCounter}`;
    }

    return `${rule.key}-${ruleCounter}`;
  };
}

Schön, wir hatten einen solchen Anwendungsfall auf dem Server und ich hatte bereits vor, einen kühnen Hinweis in der Dokumentation zu finden, siehe # 5

Aber jetzt haben Sie tatsächlich einen guten Grund gefunden, zwei parallel laufende Anbieter zu unterstützen.

Wir müssen untersuchen, ob es Anwendungsfälle für einen starken Bedarf an mehreren parallelen JssProvidern gibt. Wenn ja, müssen wir uns etwas überlegen, um es zu unterstützen.

@kof Sie haben gerade einen Anwendungsfall für mehrere parallele JssProvider auf der Clientseite gefunden. Und ich denke, die vorgeschlagene Lösung ist einfach zu implementieren :).

Verschieben Sie ruleCounter außerhalb der Wrapper-Funktion

Dies bedeutet, dass ruleCounter auf dem Server niemals zurückgesetzt wird. Das können wir nicht machen.

Auf der Serverseite müssen die JssProvider auf jeden Fall das gleichzeitige asynchrone Rendern eines Reaktionsbaums unterstützen (starker Bedarf). Aber die aktuelle Implementierung macht es bereits unterstützt :)

@darkowic Vorgeschlagene

Auch Anfragen an denselben Endpunkt sollten immer mit denselben Klassennamen antworten.

@kof Sollten wir den JssProvider von react-jss erweitern, um einen Klassennamengenerator zu akzeptieren?

1. Ja, eine Möglichkeit wäre, JssProvider zu erlauben, einen Klassennamengenerator wie diesen zu akzeptieren:

import {createGenerateClassName} from 'react-jss'

const generateClassName = createGenerateClassName()

<JssProvider generateClassName={generateClassName}>
  <App1 />
</JssProvider>

<JssProvider generateClassName={generateClassName}>
  <App2 />
</JssProvider>

1. Eine andere mögliche Option wäre die Angabe eines Präfixes wie eines Anwendungsnamens. Dies könnte funktionieren, wenn wir davon ausgehen, dass wir keine unvorhersehbare Anzahl von Anwendungen haben.

<JssProvider classNamePrefix="app-1">
  <App1 />
</JssProvider>

<JssProvider classNamePrefix="app-2">
  <App2 />
</JssProvider>

Pro 1:

• Der Benutzer muss das Präfix nicht angeben

Pro 2:

• Der Benutzer kann in den DOM-Klassennamen etwas Bedeutendes haben, das die App während der Entwicklung identifiziert
• Benutzer haben mehr Kontrolle über das Präfix.
• Es ist relativ einfach, ein nicht widersprüchliches Präfix zu haben. Entweder haben Sie nur wenige Teilbäume und die Benennung ist bereits einfach genug, oder Sie können diesen Namen ein eigenes Nummernpräfix hinzufügen und sie bei jeder Anforderung zurücksetzen.

Eigentlich ist es sinnvoll, beide Requisiten classNamePrefix und generateClassName . Erstens zum Debuggen, zweitens zur automatisierten Eindeutigkeit von Klassennamen.

Ich bin über https://github.com/facebookincubator/create-react-app/issues/3173 (und den damit verbundenen reduzierten Testfall ) auf dieses Problem gestoßen .

In meinem Fall wurde eine von der Benutzeroberfläche abhängige Komponente (v1.0.0-beta.11) in eine App aufgenommen , die auch material-ui verwendet (dieselben Versionen). In der Entwicklung funktioniert dies einwandfrei, aber in der Produktion ist das Layout aufgrund widersprüchlicher Klassennamen fehlerhaft.

Ich bin mir nicht sicher, ob dies als "Mehrfachreaktions-Rendering-Bäume" und Verschieben von var ruleCounter = 0; vor createGenerateClassName() _ qualifiziert ist.

https://github.com/callemall/material-ui/blob/2361339fd6df9bfbb85ed2ee4da9d42ee6fee71c/src/styles/createGenerateClassName.js#L26 -L28

Leider konnte ich zum Zeitpunkt der Eröffnung von # 7855 keine weiteren Informationen bereitstellen
Dieser Kommentar behandelt im Wesentlichen das Problem, mit dem ich beim Ausführen von Production Build konfrontiert war.

Eine Problemumgehung hierfür in der Pipeline?

Erstellt eine PR, die dies in react-jss https://github.com/cssinjs/react-jss/pull/155 beheben soll

Fassen wir also zusammen.

• Die Hauptursache von @darkowic wird hier beschrieben: https://github.com/callemall/material-ui/issues/8223#issuecomment -331076580 und wird dank @kofs PR behoben: cssinjs / react-jss # 155 und eine neue Warnung wird hinzugefügt, um diese Situation in Zukunft zu verhindern: # 8341.

• Die Problemsymptome von @tlvince sind gleich, aber die Grundursache ist unterschiedlich. Sie verwenden einen einzelnen Renderbaum für die Reaktion. Es könnte mit einer duplizierten installierten Material-UI-Version verknüpft sein. Überprüfen Sie Ihre Warnungen und wenn Sie genau herausfinden können, was los ist, öffnen Sie bitte ein anderes Problem.

• Das Problem von

Ich hatte die kollidierenden Klassennamen und das Hinzufügen eines Präfixes in createGenerateClassName Optionen löste das Problem.

Verwendet , um den großen, umfassenden doc hier

@oliviertassinari danke für die Zusammenfassung!

In einem einzelnen React-Rendering-Baum wird dieses Problem höchstwahrscheinlich durch verschiedene Material-UI-Versionen in Ihrem Build verursacht. Stellen Sie sicher, dass Sie Ihren Abhängigkeitsbaum überprüfen und prüfen, ob Material-UI-Versionen verwendet werden.

yarn list | grep material-ui

Meine Webpack-Konfiguration lautet wie folgt

module.exports = {
    entry: {
        FirstComp: path.join(paths.JS, '/components/FirstComponent/MyFirstComp.js'),
        SecondComp: path.join(paths.JS, '/components/SecondComponent/MySecondComp.js'),
    },
}

Ich habe diese beiden Komponenten und eine gemeinsame Komponente, die mit der Option splitChunks erstellt wird.
Ich habe die standardmäßig exportierte Komponente mit JSSProvider in MyFirstComp und MySecondComp eingeschlossen.
Wie soll ich den JSSProvider für die gemeinsame Komponente verwenden?

@Sewdn Ich denke auch, dass es durch verschiedene Material-UI-Versionen verursacht werden kann. Dieses className-Konfliktproblem wurde gestern in meiner App eingeführt, als ich mit der Migration zu Hooks und dem von makeStyles aus @ material-ui / styles erstellten useStyles-Hook begann, der bei 3.0.0-alpha.1 liegt
Außerdem habe ich "@ material-ui / core" verwendet, das bei 3.6.0 liegt

Plötzlich begannen meine App-Klassen und die Material-UI-Klassen beide mit jss1 und zählten parallel hoch. Das würde alles durcheinander bringen. Mein Header zum Beispiel mit jss5 wurde auch mit dem jss5 von beispielsweise MuiListItem gestaltet.

Nachdem diese Lösung https://github.com/mui-org/material-ui/issues/8223#issuecomment -412349569 von @iamhosseindhv befolgt wurde, wurde den Klassen der Mui-Komponenten das Präfix ac vorangestellt und das Problem behoben.

@christiaanwesterbeek Verwenden Sie den Installationsschritt korrekt? Wir verwenden die Abhängigkeitsinjektion. install() Aufruf

@oliviertassinari Ich fürchte, ich weiß nicht, auf welchen Schritt Sie sich beziehen. Außerdem weiß ich nicht, wozu install() gehört und wo es aufgerufen werden muss. Ich würde gerne mehr darüber erfahren, aber ich muss wissen, wo es dokumentiert ist.

@christiaanwesterbeek Ich beziehe mich auf https://material-ui.com/css-in-js/basics/#migration -for-material-ui-core-users.

@oliviertassinari Scheint, dass install() in der Datei jeder Komponente aufgerufen werden sollte? Vielleicht brauchen wir eine klarere Beschreibung.

Vielleicht irre ich mich, die Installation kann Konflikte nicht lösen.
To switch from the default style implementation to this newest version, you need to execute the following code before importing any Material-UI's components:

import { install } from '@material-ui/styles';

install();

@oliviertassinari Wie installiere before importing any Material-UI's components ?
Der Import wird immer statisch von babel und tsc abgewickelt

@ zheeeng ES- gehoben und synchron in der Reihenfolge aufgelöst, in der sie definiert sind. Wir haben das gleiche Problem mit der Material-UI-Dokumentation. Die Lösung bestand darin, alles in ein bootstrap.js -Modul zu packen und es zuerst zu importieren:
https://github.com/mui-org/material-ui/blob/cb30b43e9c6cd49f9b16536a125456f5ea3a85c5/docs/src/modules/components/bootstrap.js#L1 -L13
Wenn das Problem weiterhin besteht, gehen wir bitte zur Diskussion zu einem anderen Thema über.

@oliviertassinari Ich habe den Importauftrag von verschoben

// entry index.js
import * as React from 'react'
import * as ReactDOM from 'react-dom'
import CssBaseline from '@material-ui/core/CssBaseline'
import { install } from '@material-ui/styles'

zu

import * as React from 'react'
import * as ReactDOM from 'react-dom'
import { install } from '@material-ui/styles'
import CssBaseline from '@material-ui/core/CssBaseline'

Der Code meldet den Fehler Cannot read property 'text' of undefined . Wenn Sie das Themenobjekt untersuchen, ist es leer.
Wenn ich die Importreihenfolge zurückschalte, funktioniert dieser Teil einwandfrei.

const useStyles = makeStyles(
  (theme: Theme) => ({
    root: {
      flexShrink: 0,
      color: theme.palette.text.secondary,
    },
  }),
)

Das gleiche Problem tritt auf, wenn ich die gesamte Anwendung mit <StylesProvider>

@ Zheeeng

Der Code meldet den Fehler Cannot read property 'text' of undefined . Wenn Sie das Themenobjekt untersuchen, ist es leer.

Ich hatte das gleiche Problem. Es wurde behoben, indem entweder "@ material-ui / core" auf 3.6.0 oder @ material-ui / styles auf 3.0.0-alpha.1 aktualisiert wurde. Ich habe was vergessen. Mach lieber beides.

Das genaue Thema, das die an makeStyles übergebene Funktion erhalten würde, war jedoch nicht das Thema, das ich mit createMuiTheme erstellt hatte. Stattdessen erhielt es das Standardthema. Am Ende habe ich mich nicht auf das Thema verlassen, das bestanden werden würde. Stattdessen habe ich das Thema in jede Datei importiert, die von den Stilen benötigt wurde.

@christiaanwesterbeek Ich habe @material-ui/[email protected] und @material-ui/styles/.0.0-alpha.2 installiert und habe immer noch dieses Problem.

Dies scheint nichts mit diesem Problem (8223) zu tun zu haben. Aber hier geht es trotzdem. Importieren Sie einfach das Thema und verlassen Sie sich nicht darauf, dass es an die Funktion übergeben wird, die Sie an makeStyles . Und du bist fertig.

Kann jemand bestätigen, ob der Installationsschritt mit v3.7.0 noch erforderlich ist (https://github.com/mui-org/material-ui/releases/tag/v3.7.0)

@christiaanwesterbeek ja, es ist erforderlich. Wir werden den Installationsschritt in Material-UI v4 entfernen.

@oliviertassinari hey, ich habe dieses Problem mit der neuesten Version 3.9.0 und verwende nicht die @ material-ui / styles. Ich verwende immer noch withStyles von core Ich habe zwei Fragen .

1. sollte ich jetzt auf mui / styes migrieren oder auf v4 warten warten. (große App)
2. Verwenden Sie diese Problemumgehung https://github.com/mui-org/material-ui/issues/8223#issuecomment -331081785 ist die richtige Methode zur Behandlung dieses Problems? Es funktioniert zwar gut im Build, scheint aber nicht zu verstehen, warum es überhaupt passiert.

Vielen Dank

Ich habe dieses Problem mit der neuesten Version 3.9.0

@ w3nda Dies ist zu allgemein, es gibt eine Million verschiedene Gründe für dieses Problem.

sollte ich jetzt auf mui / styes migrieren oder auf v4 warten warten. (große App)

Wir könnten die Hashing-Logik für Klassennamen zurücksetzen. Während es die Leistung auf dem Server erheblich verbessert, hat es erhebliche Kosten für den Client. Vielleicht stellen wir stattdessen ein Flag zur Verfügung, um es zu aktivieren. Also nein, ich denke, dass die beste Option darin besteht, das Kernproblem zu lösen. Haben Sie diese Seite https://material-ui.com/guides/server-rendering/#troubleshooter ausprobiert?

@oliviertassinari Vielen Dank für die schnelle Antwort. Ich weiß wirklich nicht, wie ich das Problem beheben soll, und der von Ihnen erwähnte Link ist für mich nicht relevant, da ich ihn als statische Site verwende.
Der Kommentar, auf den ich verwiesen habe, hat mir geholfen. Sollte er nicht die Ursache für dieses Problem in meinem Fall angeben?

@ w3nda Statische Website hat das gleiche Problem. Sie müssen den HTML-Code generieren, damit die serverseitige Rendering-API verwendet wird. Wenn der Indexzähler zwischen zwei Seiten leckt, ist der Klassenname nicht korrekt. Nun, ich denke, dass ein langsamerer Klassennamengenerator ein guter Kompromiss ist, verglichen mit dem Schmerz, der beim Debuggen eines solchen Problems auftritt (und wie häufig es auftritt). Also, ja, Sie können auf @material-ui/styles upgraden, es ist eine einfache Notluke.

Ich hatte gerade ein ähnliches Problem und es war ein alter Material-UI-Import, der sich in einer unserer Bibliotheken befand. Im Entwicklungsmodus hat es gut funktioniert, aber in der Produktion war es kaputt. Ich bin mir ziemlich sicher, dass dies zuvor funktioniert hat. Ich weiß nicht, ob in diesem Fall eine Warnung ausgegeben werden könnte, auch wenn dies eindeutig unsere Schuld ist.
Ich habe die Versionen aktualisiert, um sie zwischen den Projekten abzugleichen, und alles hat wieder funktioniert.

Hallo, ich verwende Material nur für eine einzelne Eingabe, Schaltfläche und ein Formular auf meiner Website und musste nach diesem Kommentar https://github.com/mui-org/material-ui/issues ein <JssProvider /> / 8223 # issuecomment -331412432

Es ist ärgerlich, diesen JSS-Anbieter zu benötigen. Gibt es eine andere Lösung, die wir tun können, um die endgültige Build-Größe nicht zu erhöhen?

@kopax Wofür verwenden Sie JssProvider ?

Hallo @oliviertassinari , In production vor dem Besuch einer anderen Route (wir verwenden React-Router):

In production nach dem Besuch einer Route oder in development

Ähnliches passiert hier mit einem Formular (seltsame Box-Schatten). Wir müssen eine andere Seite besuchen, um das richtige CSS zu haben, das nur in der Produktion vorkommt:

Beide Probleme werden behoben, wenn wir JssProvider hinzufügen. (behoben: Wir haben das gleiche CSS in production als in development )

Ich habe keine Ahnung. Ich kann mit den bereitgestellten Informationen nicht helfen.

Alles ist auch kaputt. Ich beobachte falsche Reihenfolge jssXX Klassen in der Produktion und als Ergebnis das falsche Styling. Dies geschieht nach dem Aktualisieren der Seite.

Ich kann den Grund noch nicht finden.

@oliviertassinari Vielleicht hilft Ihnen die Versionsnummer, die von [email protected] verwendet wird, uns zu sagen, was los ist:

        "@material-ui/core": "^1.4.0",
        "@material-ui/icons": "^1.0.0",
        "material-ui-chip-input": "1.0.0-beta.6 - 1.0.0-beta.8",

Können Sie sicherstellen, dass die Material-Benutzeroberfläche nur einmal gebündelt

Gut. Es ist möglich. Wir verwenden react-admin , für das Version ~ 1.5 empfohlen wurde.

Ich habe den Fehler in der Produktion behoben, indem ich JssProvider hinzugefügt habe. Jetzt kann ich die Seite normal aktualisieren.

import React from "react";
import { Admin, Resource } from "react-admin";
import JssProvider from "react-jss/lib/JssProvider";

const App = () => (
  <JssProvider>
    <Admin dataProvider={dataProvider}>
      <Resource name="trip" list={RequestsList} className="resourceItem" />
    </Admin>
  </JssProvider>
);

export default App;

@andrewkslv Dies ist genau das, was wir vermeiden wollen. Wir würden es vorziehen, es ohne JssProvider da wir nur eine Input und Button Komponente von @ material-ui verwenden Stattdessen bevorzugen wir für den Rest eine andere Benutzeroberfläche für React-Admin.

@oliviertassinari Ich habe gerade überprüft und ich hatte einige Abhängigkeitsprobleme. Ich habe es behoben, aber immer noch die Fehler mit den folgenden npm ls @material-ui/core :

├─┬ @bootstrap-styled/[email protected]
│ └── @material-ui/[email protected] 
├── @material-ui/[email protected] 
└─┬ [email protected]
  └── @material-ui/[email protected] 

Danach:

rm -rf node_modules/@bootstrap-styled/ra-ui/node_modules/@material-ui/
rm -rf node_modules/ra-ui-materialui/node_modules/@material-ui/
npm ls @material-ui/core
├─┬ @bootstrap-styled/[email protected]
│ └── UNMET DEPENDENCY @material-ui/[email protected] 
├── @material-ui/[email protected] 
└─┬ [email protected]
  └── UNMET DEPENDENCY @material-ui/[email protected] 

Dann funktioniert es jetzt (kein CSS-Problem in der Produktion). Ich denke das ist nicht was ich will ...

Verwandte project @ material-ui-Abhängigkeiten:

• @ bootstrap-styled / [email protected]/package.json#L293
• [email protected]/package.json#L44

Irgendeine Idee was zu tun ist?

@kopax Es ist schwer zu sagen, ohne etwas, das ich debuggen kann. Ich bin froh zu hören, dass es jetzt funktioniert.

Ich habe festgestellt, dass Sie gestylte Komponenten mit Material-UI verwenden. Wenn Sie etwas Zeit haben, würde ich gerne über die Integration auf Gitter sprechen.

Die Arbeitslösung ist nicht natürlich. Dies bedeutet, dass es sich um eine Aufgabe handelt, die nicht mit npm ausgeführt werden kann. Ich werde es nicht benutzen, ich gab dies als Hinweis.

Wir werden am Montag die Chance haben, mich dem Mui Gitter Channel anzuschließen.

Hallo @kopax , hast du es geschafft eine Lösung zu finden?

Nein noch nicht. Nicht ohne den Anbieter. @oliviertassinari Ich bin auf Gitter.

@andrewkslv Deine Lösung hat wirklich für mich funktioniert. Ich verwende auch react-admin und AWS Amplify. Jedes Mal, wenn ich meine Reaktionsanwendung in einem S3-Bucket bereitstellte, war der Stil völlig fehlerhaft, und Ihre Lösung hat mich wirklich gerettet.

Gleiches Problem hier. Warum hilft das Hinzufügen von JssProvider?

Ich habe in Version 4 eine Warnung hinzugefügt, um zu warnen, wenn doppelte Stilinstanzen verwendet werden: # 15422.

Ich weiß es nicht. Ich habe dieses Problem in react-admin angesprochen, als sie eine neue Version der Material-Benutzeroberfläche in das Framework implementierten, aber es wurde ignoriert.

https://github.com/marmelab/react-admin/pull/3102#issuecomment -484228320

Wo finde ich die Lösung für Konflikte mit Produktionsbuild - Klassennamen # 8223?

Vielen Dank,

@oliviertassinari Ich stelle mich diesem Problem erneut, obwohl ich alle Anweisungen befolgt habe. Da es für andere funktioniert, fehlt mir wahrscheinlich etwas Grundlegendes.

https://stackoverflow.com/questions/58938080/jssprovider-not-generating-class-prefix-with-classnameprefix

Ich verwende folgende Versionen der Pakete.

"@ material-ui / core": "^ 4.6.1",
"@ material-ui / icons": "^ 4.5.1",
"reagieren": "^ 16.12.0",
"React-Dom": "^ 16.12.0",
"react-jss": "^ 10.0.0",
"React-Scripts": "3.2.0"

Update: Problem wurde behoben. Es tut uns leid, dass Sie die Dokumentation nicht gründlich durchgearbeitet haben. Dieser Teil der Dokumentation hat mein Problem gelöst.

https://material-ui.com/styles/api/#creategenerateclassname -options-class-name-generator

Aber irgendwie funktionierte die JSSProvider-Lösung, die für alle anderen funktionierte, nicht für mich. Trotzdem danke :)

Danke @KannugoPrithvi , das ist die gute Lösung! https://material-ui.com/styles/api/#creategenerateclassname -options-class-name-generator