Mechanismus zur Anpassung des Legacy-Designs
Der alte Mechanismus zur Anpassung des Designs verwendet --GW- CSS-Variablen, um die Designinformationen an die Komponenten weiterzugeben. Es verwendet die Variablenüberschreibungen aus den CSS-Dateien, die unter den Einträgen styleOverrides und variableOverrides in .themesConfig.json als benutzerdefinierte Designdefinition hinzugefügt wurden. Diese beiden Dateien bilden den Mechanismus für die manuelle Theming-Definition. Wechseln Sie zu einer Version der Dokumentation, die älter als 10.0 ist, um weitere Informationen zu diesem Mechanismus zu erhalten.
Migrieren zu Design-Token
Bei der Entscheidung, ob es an der Zeit ist, auf Design-Token zu migrieren, müssen Sie Folgendes berücksichtigen:
- Legacy-Komponenten können nicht nur mit Design-Token gestylt werden, Sie müssten eine benutzerdefinierte
--GW--Variable zum Entwerfen der Token-Zuordnung hinzufügen – weitere Informationen finden Sie hier. - Neue Komponenten, die in Version 10.0.0 oder höher eingeführt wurden, sollten nicht mit dem alten Theming-Mechanismus gestylt werden, nur Design-Token können verwendet werden, um Stilüberschreibungen zu definieren, wenn Sie Breaking Changes während Upgrades vermeiden möchten, da
--JDS-CSS-Variablen nicht Teil unserer API-Oberfläche sind
Um Design-Token in einer bereits vorhandenen Anwendung zu verwenden, die mit einem alten Designmechanismus gestylt ist, müssen Sie Folgendes tun:
- Stellen Sie sicher, dass Tokendefinitionsdateien zu Ihrem Repository hinzugefügt werden
- Aktualisieren Sie Ihre
.themesConfig.json-Datei - Führen Sie den Transformationsprozess für Design-Token in CSS-Variablen aus
Eine detaillierte Anleitung finden Sie hier. Nach diesen Schritten sieht Ihr .themesConfig.json ähnlich aus wie in diesem Beispiel:
{
"sampleTheme": {
"name": "sampleTheme",
"variableOverrides": "styles/sampleTheme/variableOverrides.css",
"styleOverrides": "styles/sampleTheme/styleOverrides.css",
"tokens": {
"input-path": "src/tokens/sampleTheme/**/*.json",
"output-file-name": "tokenOverrides.css"
}
}
}
Wie bereits erwähnt, haben Stilüberschreibungen, die über --GW- CSS-Variablen definiert werden, Vorrang vor Stilüberschreibungen, die in Token definiert sind. Dies ist wichtig, wenn Sie Ihr Design nicht vollständig auf Design-Token migrieren möchten, sondern es vorziehen, beide Designmechanismen gleichzeitig zu verwenden. In dieser Situation müssen Sie die entsprechende --GW--Variable entfernen, um etwas mit einem Design-Token zu stylen. Möglicherweise haben Sie eine benutzerdefinierte Schriftfamilie in Ihre variableOverrides.css-Datei angewendet:
--GW-FONT-FAMILY: 'Some Custom Font', 'Helvetica', 'Arial', sans-serif;
In diesem Fall müssen Sie das entsprechende Token so konfigurieren, dass es Ihre benutzerdefinierte Schriftart verwendet, und dann den Eintrag mit --GW-FONT-FAMILY aus variableOverrides.css entfernen.
{
"jds": {
"font-family": {
"body": {
"type": "fontFamilies",
"value": "'Some Custom Font', 'Helvetica', 'Arial', sans-serif",
"description": "Global font-family for body text"
}
}
}
}
Wenn Sie bereit sind, vollständig auf Design-Token zu migrieren und alle Reste nach dem alten Designmechanismus zu entfernen, müssen Sie Folgendes tun:
- Ersetzen Sie alle Verwendungen von Legacy-Komponenten – da sie nicht nur mit Design-Token gestaltet werden können.
- Entfernen Sie die Einträge
variableOverridesundstyleOverridesvon.themesConfig.json - Entfernen Sie alle Verwendungen von
--GW-CSS-Variablen in Ihrem Code und ersetzen Sie sie durch benutzerdefinierte CSS-Variablen, die aus Design-Token generiert werden - weitere Informationen dazu finden Sie auf dieser Seite.
Neue Komponenten - hinzugefügt in 10.0 oder späteren Versionen
Wenn Sie noch nicht bereit sind, Design-Token zu verwenden, aber Komponenten verwenden möchten, die in Version 10.0 oder höher eingeführt wurden, können Sie sie nicht mit --GW- CSS-Variablen gestalten. Für solche Fälle gibt es einen Workaround - Sie können überprüfen, welche --JDS- CSS-Variablen in diesen Komponenten verwendet werden und Wertüberschreibungen für diese Variablen zu variableOverrides.css hinzufügen. Sie müssen jedoch bedenken, dass --JDS-Variablen NICHT Teil unserer API sind und sich ihre Namen jederzeit ändern können, was zu Breaking Changes zwischen den Releases führt - auch kleinere - daher ist es wichtig, die Kompromisse der verfügbaren Optionen zu analysieren, bevor Sie sich für die Verwendung dieser Lösung entscheiden.
Welche Themes werden in der Basiskonfiguration von Jutro verfügbar gemacht?
Jutro stellt einige gebrauchsfertige Themes in @jutro/theme und @jutro/theme-styles packages bereit. Diese Themes können verwendet werden, wenn die von Guidewire definierten Themes den gesamten Theming-Anforderungen der Anwendung entsprechen. Falls jedoch Änderungen erforderlich sind, können Sie nach Bedarf manuell ein neues benutzerdefiniertes Theme mit einer der von Guidewire bereitgestellten Optionen festlegen.
Jutro bietet die folgenden Themes:
Enterprise
Das Standard-Theme. Es wird automatisch vom @jutro/theme-Paket angewendet.
Consumer
10.0.x hinzugefügt wurden. Sie müssen Design-Token verwenden.Einfaches benutzerdefiniertes Theme aus dem @jutro/theme-styles-Paket. Ähnlich wie das Theme „Enterprise“, nur dass dieses Theme viel weniger umfassend ist.
So verwenden Sie es in Ihrer Anwendung:
import { consumerThemeConfig } from '@jutro/theme-styles';
...
start(Jutro, {
themeConfig: consumerThemeConfig,
});
General
10.0.x hinzugefügt wurden. Sie müssen Design-Token verwenden.Dies ist das Theme für jedes Ski-Release, das auf das Flaine-Release folgte. Es verwendet Farben, die für Ski-Releases bestimmt sind, zusätzlich zum Theme „Enterprise“ und bietet ein generisches Ski-Badge, das für bestimmte Ski-Releases in ein spezielles Badge geändert werden kann. Verfügbar in @jutro/theme-styles.
So verwenden Sie es in Ihrer Anwendung:
import { generalThemeConfig } from '@jutro/theme-styles';
...
start(Jutro, {
themeConfig: generalThemeConfig,
});
Design-Token und Micro-Frontends
Da sich der Theming-Mechanismus in der Anwendung nicht geändert hat, sondern nur die Art und Weise, wie das Theming verwaltet wird (nun durch Design-Token), müssen Sie keine Änderungen vornehmen, damit das Theming mit Micro-Frontends verwendet werden kann.
Folgendes muss jedoch beachtet werden. Bei Verwendung einer Shell-App mit dem alten Theming-Mechanismus und einem Micro-Frontend mit Design-Token kann es vorkommen, dass Komponenten keine neuen Werte erhalten oder nicht wie erwartet ausgeführt werden. Es können auch Probleme beim Styling auftreten. Wenden Sie sich bei Problemen an Ihren Ansprechpartner bei Guidewire. Wir werden in künftigen Versionen detailliertere Anleitungen zur Verwendung des alten Mechanismus in Kombination mit Design-Token in Micro-Frontends zur Verfügung stellen.