Release 10.0: Überblick und Hinweise

Überblick

Mit Release 10.0 wurden mehrere Änderungen eingeführt (alle Informationen finden Sie in den Versionshinweisen). In vielen Fällen wurden die Änderungen vorgenommen, um den Ansatz und die Prinzipien des Jutro Design System und der UI-Bibliotheken zu optimieren. Auf dieser Seite werden die wichtigsten Änderungen dargelegt, die wichtigsten Gründe erläutert und einige Orientierungshilfen für den Übergang zu diesem Release gegeben.

Note: Noch wurden nicht alle Komponenten angepasst. In künftigen Releases werden die in diesem Dokument beschriebenen Änderungen auch auf andere Komponenten angewendet.

Folgendes ist zu erwarten:

• Einige Komponenten werden ebenfalls überarbeitet und in kommenden Releases werden neue Versionen eingeführt: Datumskomponenten sowie die Komponenten InputMaskField, Slider Stepper und SwitchField.

• Andere Komponenten werden derzeit überprüft und die entsprechenden APIs werden geändert, hauptsächlich durch Verwerfung einiger der vorhandenen Eigenschaften: Link, Breadcrumb, Fortschrittsbalken und weitere. Es ist von keinen gravierenden Änderungen auszugehen. Die Komponenten werden weiterhin wie bisher verwendet werden können.

Weitere Änderungen können basierend auf der erforderlichen Weiterentwicklung der Design System-Bibliothek eingeführt werden.

Prinzipien des Design System

Für die Bibliotheken wurde eine Reihe von Prinzipien definiert:

1. UX-Ausrichtung

Alle UI-Komponenten entsprechen den UX-Spezifikationen des Design System. Zusätzliche Anpassungsoptionen sorgen für mehr Flexibilität.

2. Non-Breaking Changes

Keine geplanten und häufigen Breaking Changes mehr in unserer Komponenten-API. Wenn sich die zugrunde liegenden Bibliotheken ändern, arbeiten wir im Vorfeld mit unseren Benutzern zusammen, um einen reibungslosen Übergang zu gewährleisten.

3. Verpflichtung

Wir erstellen Jutro-Abstraktionen nur für die Probleme, die nicht durch Frontend-Frameworks gelöst werden können. Die Komplexität der generischen Frontend-Entwicklung soll nicht kaschiert werden, dafür wird ein standardmäßiger und kuratierter Satz von Konfigurationen bereitgestellt.

4. Einfachheit

Enge Kopplung wird vermieden. Wir bieten entkoppelte, primitive und atomare Funktionen, die miteinander kombiniert werden können. Entwickler haben die Kontrolle. Kein Zauber.

Die UI-Komponenten und UI-Bibliotheken wurden so angepasst, dass diese Prinzipien erreicht werden und gewährleistet ist, dass sie auch in Zukunft beibehalten werden können.

Allgemeiner Überblick über die Änderungen

Mit Blick auf die UI-Komponenten werden Sie verschiedene Arten von Änderungen feststellen:

• Entfernte oder verworfene Komponenten
• Neu erstellte Komponenten
• Geänderte vorhandene Komponenten: vereinfachte APIs, aktualisierte Funktionen und vieles mehr

1. Eingestellte Komponenten

Dies betrifft nur Komponenten, die nicht verwendet wurden und die basierend auf dem ersten Prinzip nicht auf einen bestimmten UX-Anwendungsfall ausgerichtet waren.

2. Verworfene Komponenten und legacy-Paket

Komponenten können aus verschiedenen Gründen verworfen werden: Sie entsprechen nicht mehr einem UX-Anwendungsfall, werden aber in einigen Projekten weiterhin verwendet; neue Alternativen sind verfügbar usw.

Als Ausnahmefall erfolgt bei diesem Release die Verwerfung gleichzeitig mit der Verschiebung in ein neues Paket mit der Bezeichnung legacy.

Note: Was müssen Sie tun?

Alle diese Komponenten werden genau so wie vor der Verwerfung ausgeführt. Sie können sie weiterhin verwenden, indem Sie lediglich den Import so ändern, dass sie aus dem legacy-Paket abgerufen werden.

Möchten Sie mehr über Verwerfungen erfahren? Siehe die Seite „Verwerfungen“.

Möchten Sie mehr über das legacy-Paket erfahren? Siehe die legacySeite „legacy-Paket“.

3. Neu erstellte Komponenten

Für einige der verworfenen Komponenten werden neue Alternativen bereitgestellt: Accordion, Button, TextInput, CurrencyInput, PhoneNumberInput, Checkbox, RadioGroup, NumberInput, Select und weitere mehr.

4. Vereinfachte API

Wenn Sie die neue TextInput-Komponente und die alte InputField-Komponente vergleichen, werden Sie den Unterschied bei der API feststellen, bei der die Anzahl der Eigenschaften von mehr als 30 auf 15 reduziert wurde. Das Gleiche gilt für die meisten anderen ersetzten Komponenten.

Sie werden sehen, dass nur relevante Eigenschaften beibehalten werden. Konsistenz ist zwar eine wünschenswerte Option, wird jedoch nicht erzwungen (z. B. verfügen die meisten Eingabekomponenten über eine value-Eigenschaft, während die neue Checkbox-Komponente stattdessen eine checked-Eigenschaft aufweist).

5. Eigenschaftstypen

Die Komponenten enthalten nun spezifischere Typen für die Werteigenschaften und unterstützen nicht mehr jegliche Werte oder mehrere Optionen. Beispiel: Die Eigenschaft NumberInput value hat den Typ number.

6. Ereignisse

Anstatt dass neue benutzerdefinierte Ereignisse erstellt werden, werden die nativen Ereignisse verwendet und an die Anforderungen der jeweiligen Komponente angepasst. Anstatt eines onValueChange-Ereignisses wird z. B. das native Ereignis onChange verwendet.

Die nativen Ereignisse können überschrieben werden. Beispielsweise kann onChange je nach Komponente sogar mehrere Parameter erhalten:

• CurrencyInput übergibt das native Ereignisobjekt sowie den neuen geänderten Wert.
• PhoneNumberInput übergibt das native Ereignisobjekt, den neuen geänderten Wert und einen dritten Parameter mit Validierungsergebnissen.

7. Validierung

Die automatische Validierung ist in den neu implementierten Komponenten nicht verfügbar. Der Entwickler ist für die vollständige Abwicklung des Validierungsprozesses zuständig und entscheidet, welche Validierung wann und wie durchgeführt wird. Die Komponenten enthalten jedoch zwei Mechanismen zur Unterstützung der Validierung durch den Entwickler:

• stateMessages: Diese Komponenteneigenschaft definiert, welche Fehlermeldungen in der Komponente angezeigt werden sollen. Entwickler müssen lediglich die Meldungen übergeben, dann werden sie in der Komponente angezeigt.
• Einige Hilfsparameter: Bestimmte Komponenten (z. B. PhoneNumberInput) enthalten ein Objekt mit dem Ergebnis einiger vordefinierter Validierungen als dritten Parameter des Ereignisses onChange. Diese Informationen können vom Entwickler verwendet werden, um die Benutzereingabe zu validieren.

8. Theming und Design-Token

CSS-Variablen sind nicht mehr Teil der API einer Komponente, sondern sind ein internes Implementierungsdetail.

Erfahren Sie mehr über die API unserer Komponenten.

Bei vorhandenen Komponenten werden die CSS-Variablen nicht geändert und funktionieren weiterhin wie vor diesem Release.

Ein neuer Theming-Mechanismus steht zur Verfügung: Design-Token. Dies wirkt sich nicht auf die Interaktion zwischen Anwendung und Theming aus, ändert jedoch die Art der Definition des Theme und die API der Komponente, da diese nun Teil davon sind.

9. Escape Hatches

Komponenten sind nun an die UX-Spezifikationen angepasst. Dies schränkt in einigen Fällen die Flexibilität von Komponenten ein, um ein Verhalten oder Erscheinungsbild zu erzielen, das außerhalb der Spezifikationen liegt. Als Alternative wurden daher Escape Hatches eingeführt.

Je nach Komponente stehen unterschiedliche Optionen zur Verfügung, wobei die folgenden am häufigsten verwendet werden:

• Design-Token: Der Mechanismus zur Anpassung des Theming.
• Native HTML-Eigenschaften: In vielen Komponenten können jegliche native HTML-Eigenschaften übergeben werden, die dann an das Element der obersten Ebene oder an ein spezifisches Element in der Komponente übergeben werden. Weitere Informationen finden Sie in der Dokumentation zu den einzelnen Komponenten.
• dangerouslySet-Eigenschaften: Ermöglichen das vollständige Überschreiben eines Teils einer Komponente.
• className: Dieses Attribut ist in allen Komponenten vorhanden und ermöglicht das Festlegen des class-Attributs auf das oberste Element der Komponente.
• ref mit imperativen Handlern: ref ist in vielen Komponenten verfügbar, ermöglicht jedoch keinen vollständigen Zugriff auf das Element. Stattdessen auf spezifische Funktionen, die durch die Bibliothek eingeschränkt sind.

10. Entkopplung

Die Komponentenbibliothek ist auf die Darstellungsaspekte der Komponenten ausgerichtet. Der entsprechende Darstellungsaspekt muss in der jeweiligen Komponente festgelegt werden, sodass andere Funktionen entfernt oder zumindest zu Hilfs- oder unterstützenden Funktionen „herabgestuft“ werden.

Einige Beispiele:

• Ereignis-API: legacy Button enthielt einen automatischen Ereignisauslöser für die Ereignis-API, wenn ein Klick erkannt wurde. Er ist in der neuen Button-Komponente nicht enthalten.
• @jutro/auth-Abhängigkeit: Es handelt sich jetzt um eine Peer-Abhängigkeit. Ziel ist, dass keine Komponente die direkte Kopplung mit dem @jutro/auth-Paket enthält. Aktuell ist diese Abhängigkeit jedoch in einigen Komponenten vorhanden, z. B. in Avatar.
• @jutro/router-Abhängigkeit: Es besteht eine Abhängigkeit zwischen dem @jutro/components- und dem @jutro/router-Paket. Bestimmte Komponenten, z. B. Link, wurden in das @jutro/router-Paket verschoben.
• Verknüpfung zwischen Backend und Datenmodell: Die Eigenschaften der Komponenten und die zugehörigen Typen sind nicht an das Datenmodell angepasst, sondern basierend auf der jeweiligen Funktion der Komponente definiert.

Spezifische Änderungen

1. Status der Komponenten

Vorhandene Komponente	Durchgeführte Änderung	Alternative	Kommentare
Accordion	Verworfen und in legacy verschoben	Accordion
AdaptativeDataView	Verworfen und in legacy verschoben	UX-Muster
Address	Verworfen und in legacy verschoben	UX-Muster
AnimationGroup	Eingestellt	Keine – nur zur internen Verwendung
ApplicationHeader	Verworfen und in legacy verschoben	UX-Muster	Andere header-Unterkomponenten bleiben stabil, sind aber nur im Kontext des UX-Musters zu verwenden.
AsyncButton	Verworfen und in legacy verschoben	Button
BreakpointTracker	Verworfen und in legacy verschoben	Keine – nur zur internen Verwendung
Button	Verworfen und in legacy verschoben	Button
ButtonLink	Verworfen und in legacy verschoben	Button
CheckboxField	Verworfen und in legacy verschoben	Checkbox
CheckboxGroupField	Verworfen und in legacy verschoben	CheckboxGroup
Collapse	Verworfen und in legacy verschoben	Keine – nur zur internen Verwendung
ColorSwatch	Eingestellt	Keine
Container	Verworfen und in legacy verschoben	Keine – nur zur internen Verwendung
Chevron	Verworfen und in legacy verschoben	Icon
CurrencyField	Verworfen und in legacy verschoben	CurrencyInput
DataTable	Verworfen und in legacy verschoben	UX-Muster
DataView	Verworfen und in legacy verschoben	UX-Muster
DropdownSelectField	Verworfen und in legacy verschoben	Select, MultipleSelect
FieldSkeleton	Eingestellt	TextArea
FileUploadField	Verworfen und in legacy verschoben	UX-Muster
Footer	Verworfen und in legacy verschoben	Verwendung durch Floorplan
FooterCopyRight	Verworfen und in legacy verschoben	Verwendung durch Floorplan
FooterNavBar	Verworfen und in legacy verschoben	Verwendung durch Floorplan
FooterNavLink	Verworfen und in legacy verschoben	Verwendung durch Floorplan
FooterText	Verworfen und in legacy verschoben	Verwendung durch Floorplan
FormSkeleton	Eingestellt	TextArea
Header	Verworfen und in legacy verschoben	UX-Muster	Andere header-Unterkomponenten ebenfalls verworfen: HeaderActions, LogoTitle, HelpHeading, HelpLink, HelpParagraph, HelpPopover, HelpElement
GlobalizationSettingsCard	Verworfen und in legacy verschoben	Keine
IconButton	Verworfen und in legacy verschoben	Button
ImageRadioButtonField	Verworfen und in legacy verschoben	RadioGroup, Radio	Kein direkter Ersatz
InlineNotification	Kleinere Änderung: Standardanfangstext der Meldung entfernt (Erfolg, Warnung…)
InputField	Verworfen und in legacy verschoben	TextInput
InputNumberField	Verworfen und in legacy verschoben	NumberInput
IntlPhoneNumberField	Verworfen und in legacy verschoben	PhoneNumberInput
JsonForm	Eingestellt	Keine	Verwendung von Metadaten wurde verworfen.
Layout	Verworfen und in legacy verschoben	Andere Layoutkomponenten
ListView	Verworfen und in legacy verschoben	UX-Muster
LinkSkeleton-Komponenten	Eingestellt	Keine
LiveRegion	Eingestellt	Keine – nur zur internen Verwendung
Location	Verworfen und in legacy verschoben	UX-Muster
Main	Verworfen und in legacy verschoben	Keine – nur zur internen Verwendung
MapArea	Verworfen und in legacy verschoben	Keine	Kartenrelevante Funktionen sind nicht im Umfang enthalten.
MapTooltipContent	Verworfen und in legacy verschoben	Keine
MenuSkeleton	Eingestellt	TextArea
PageHead	Eingestellt	Keine
PageLayout	Eingestellt	Andere Layoutkomponenten
PageLoader	Verworfen und in legacy verschoben	Loader
PanelLayout	Eingestellt	Andere Layoutkomponenten
PhoneNumberField	Verworfen und in legacy verschoben	PhoneNumberInput
PrivateRoute	Eingestellt	Keine – nur zur internen Verwendung
QuickView	Verworfen und in legacy verschoben	UX-Muster
RadioButtonCardField	Verworfen und in legacy verschoben	RadioGroup, Radio	Kein direkter Ersatz
RadioButtonField	Verworfen und in legacy verschoben	RadioGroup, Radio
RadioField	Verworfen und in legacy verschoben	RadioGroup, Radio
RadioGroup	Verworfen und in legacy verschoben	RadioGroup, Radio
ResponsiveElement	Eingestellt	Keine – nur zur internen Verwendung
RouteTracker	Eingestellt	Keine – nur zur internen Verwendung
ScrollToError	Verworfen und in legacy verschoben	Keine – nur zur internen Verwendung
SettingsCard	Verworfen und in legacy verschoben	Keine
SkipNav	Eingestellt	Keine – nur zur internen Verwendung
StickyFooter	Verworfen und in legacy verschoben	Verwendung durch Floorplan
TabbedContainer	Eingestellt	TabGroup
Table	Verworfen und in legacy verschoben	UX-Muster
TableAdapters	Verworfen und in legacy verschoben	UX-Muster	Enthält: ActionColumnAdapter, ActionItemAdapter, DisplayColumnAdapter, FieldColumnAdapter, RadioColumnAdapter
TableSkeleton	Eingestellt	TextArea
TableView	Verworfen und in legacy verschoben	UX-Muster
TextAreaField	Verworfen und in legacy verschoben	TextArea
TextHighlight	Eingestellt	Keine – nur zur internen Verwendung
ThemeSettingsCard	Verworfen und in legacy verschoben	Keine
ToastProvider / ToastField	Kleinere Änderung: Standardanfangstext der Meldung entfernt (Erfolg, Warnung…)
TreeView	Von lab preview in stable verschoben
TypeaheadMultiSelectField	Verworfen und in legacy verschoben	Combobox, MultipleCombobox

Note: Auch andere Unterkomponenten sind von den Änderungen betroffen, sind jedoch aus Gründen der Übersichtlichkeit hier nicht aufgeführt.

Note: Einige Komponenten werden ebenfalls überarbeitet und in kommenden Releases werden neue Versionen eingeführt: Datumskomponenten sowie die Komponenten InputMaskField, Slider Stepper und SwitchField.

Zudem werden weitere Komponenten überprüft und die entsprechenden APIs werden geändert, hauptsächlich durch Verwerfung einiger der vorhandenen Eigenschaften.

2. Änderungen des Typs

Werttyp

value oder gleichwertige Eigenschaften. Typ wurde so geändert, dass er dem Anwendungsfall der Komponente entspricht:

Komponente	Eigenschaft	Vorheriger Typ	Neuer Typ
Checkbox	checked	any	bool
Combobox	value	any	string
CurrencyInput	value	any - { amount: number, currency: string }	{ amount: number, currency: ISOCurrencyCodes }
NumberInput	value	any	number
PhoneNumberInput	value	any - { countryCode: {code: string }, phoneNumber: string }	{ phoneNumber: string, countryCode: ISOCountryCodes }
TextArea	value	any	string
TextInput	value	any	string
RadioGroup	value	any	string
Select	value	any	string

Dropdown-Optionen

Die Optionen für Dropdown-Komponenten wurden von availableValues in children mit dem Typ SelectOption oder ComboboxOption geändert.

Die Definition hat sich geändert von:

<DropdownSelectField
  availableValues={[
    {
      code: string,
      name: string,
    },
    {
      code: string,
      name: string,
    },
  ]}
/>

in

<Combobox>
  <ComboboxOption
    value={{
      id: string,
      label: string,
    }}
  />
  <ComboboxOption
    value={{
      id: string,
      label: string,
    }}
  />
</Combobox>

3. Zuordnung von Eigenschaften

Einige neue Eigenschaften wurden definiert, die vorherige Eigenschaften ganz oder teilweise ersetzen.

readOnly alt gegenüber displayOnly und readOnly neu

In legacy-Komponenten bewirkte die Eigenschaft readOnly, dass die jeweilige Komponente als Text angezeigt wurde, ohne das Erscheinungsbild einer Eingabe. Die neuen Komponenten weisen dagegen zwei unterschiedliche Status auf:

• readOnly: fokussierbare, aber nicht bearbeitbare Eingabe
• displayOnly: einfacher Text ohne das Erscheinungsbild einer Eingabe

Hier erfahren Sie mehr über diese Status.

Meldungen in Komponenten

Fehlermeldungen und Fehlerstatus in legacy-Komponenten wurden durch Übergeben der Eigenschaft validationMessages in Kombination mit der Eigenschaft showErrors definiert. Wenn diese Eigenschaft auf true festgelegt war, wurde der Fehler im Fehlerzustand angezeigt und auch die Meldungen wurden angezeigt.

Bei neuen Komponenten ist die Eigenschaft stateMessages enthalten und, wenn vorhanden, wird bereits die jeweilige Meldung angezeigt und der Fehlerstatus für das Feld festgelegt.

validationMessages: ['message 1', 'message 2'];
showErrors: true;

stateMessages: {
  error: ['message 1', 'message 2'];
}

min/max gegenüber minValue/maxValue

Benutzerdefinierte Eigenschaften zum Definieren des minimalen oder maximalen zulässigen Werts wurden durch die nativen Eigenschaften min und max ersetzt.

tooltip-Eigenschaft

Diese Eigenschaft ist weiterhin verfügbar, wurde jedoch vereinfacht: tooltip: { text: string | IntlShapeObject; trigger?: string }; ersetzt nun mehrere Eigenschaften und benutzerdefinierte Rendering-Optionen.

required nur visuell

Jegliche Validierungslogik für die Option required wurde entfernt. Wenn required nun auf true festgelegt ist, wird lediglich bestimmt, dass neben der Beschriftung ein „*“ angezeigt werden muss.

Eigenschaften defaultValue und initialValue

Die Eigenschaften defaultValue und initialValue sind nicht gleichwertig.

Die Eigenschaft defaultValue wurde entfernt. Jetzt enthalten Komponenten keinen spezifischen zuzuweisenden Wert mehr, wenn der Benutzer keinen Wert angibt.

Die Eigenschaft initialValue wird für unkontrollierte Komponenten verwendet. Daher wird der Eingabe ein Anfangswert zugewiesen.

Native HTML-Eigenschaften

Mit Eingabekomponenten, aber auch mit anderen Komponenten, können Entwickler nicht nur die in der API definierten Eigenschaften, sondern auch andere HTML-Eigenschaften übergeben, die sich auf diesen Komponententyp beziehen. Beispielsweise unterstützt TextInput sowie NumberInput die Eigenschaften, die ein input-HTML-Element unterstützt.

Diese Eigenschaften können basierend auf der API und dem Verhalten der Komponente eingeschränkt sein:

• Einige native Eigenschaften werden durch die API der Komponente überschrieben: min und max in NumberInput.
• Andere Eigenschaften sind vordefiniert und können nicht geändert werden: type hat keine Auswirkungen in NumberInput.

Weitere Einzelheiten dazu finden Sie hier.

Entfernte Eigenschaften

Mehrere allgemeine Eigenschaften wurden in den neuen Komponenten nicht mehr berücksichtigt. Darüber hinaus kommen sie in Betracht für eine Verwerfung in den übrigen Komponenten.

Je nach Eigenschaft kann der Grund für ihre Entfernung oder Verwerfung unterschiedlich sein:

• Nicht empfohlene Methode (id)
• Kopplung von Datenmodell und UX-Komponente (path)
• Adaptives Verhalten (Eigenschaft phone oder phoneWide)
• Nicht erforderliche Funktionen (autotrim)

Es folgt eine Liste der am häufigsten entfernten Eigenschaften. Einige davon wurden bereits in den vorherigen Abschnitten erwähnt, da sie durch andere Eigenschaften ersetzt wurden:

• autotrim
• dataType
• defaultValue
• id
• nullable
• onValueChange
• path
• phone
• phoneWide
• secondaryLabelId
• showOptional
• tablet
• Validierungsbezogene Eigenschaften: enableMultipleValidation, onValidationChange, showErrors, registerValidation, validationMessages, validator
• visible
• *******ClassName (alle className-Eigenschaften, die nicht className für das oberste Element sind)

4. Ereignis onChange

Die Signatur des Ereignisses onChange lautet:

onChange(event: React.ChangeEvent, value: valueType, options?: any)

• event: Dieser erste Parameter ist das Ereignisobjekt, das mit dem ausgelösten Ereignis verknüpft ist. In einigen Fällen handelt es sich um das native Ereignisobjekt, in anderen um ein benutzerdefiniertes Objekt, das es repliziert, jedoch an die Anforderungen oder die Implementierung der Komponente angepasst ist. Dieses Objekt bietet Zugriff auf einige Implementierungsdetails der zugrunde liegenden Komponente.

Note: Es ist mit Vorsicht zu verwenden. Da Implementierungsdetails verfügbar gemacht werden und nicht Teil der API der Komponente sind, können sich einige Änderungen auf den darauf basierenden Code auswirken.

Die meisten erforderlichen Funktionen werden über andere Mechanismen bereitgestellt: zusätzliche Parameter, ref-Eigenschaft usw. Dies dient jedoch dazu, alle eventuell fehlenden Grenzfälle zu unterstützen.

• value: Dies ist der aktuelle Wert der Komponente. Er hat den gleichen Typ wie die Eigenschaften value und initialValue der Komponente und kann für jede Validierung oder Statusverwaltung verwendet werden.

• options: Wird nicht bei allen Komponenten verwendet, bietet bei Verwendung aber Zugriff auf andere ergänzende Informationen. Wird anfangs zum Teilen von Validierungsergebnissen verwendet, die in die Komponente eingebettet werden können. Ein Beispiel dafür ist die Komponente PhoneNumberInput, bei der dieser Parameter den Zugriff auf ein {errorCode: number}-Objekt mit dem Code ermöglicht, der einem spezifischen Validierungsfehler entspricht.

5. Dateninkongruenz

Während die Datentypen der legacy-Komponenten an das Datenmodell angepasst wurden, ist dies bei den neuen Komponenten nicht der Fall: Sie unterstützen nur ein Eingabe- und Ausgabeformat. Aus diesem Grund müssen Sie bei der Interaktion mit dem SDK die ein- und ausgehenden Daten transformieren.

Einige Beispiele:

• CurrencyInput liest/schreibt { currency: ISOCurrencyCodes (string), amount: number }, aber das SDK erfordert { currency: string, amount: string }.

• Select liest/schreibt {id: string, label: string} des ausgewählten Elements, aber das SDK erfordert { code: string, name?: string}.

• NumberInput liest/schreibt number, aber das SDK erfordert string.

• PhoneNumberInput liest/schreibt { phoneNumber: string, countryCode: ISOCountryCodes (string) }, aber das SDK erfordert { number: string, countryCode: string }.

6. Validierung

Die Validierung erfolgt durch den Entwickler. In den neuen Komponenten wird keine Validierung mehr durchgeführt (siehe unten).

Sie wird in den Komponenten wie folgt unterstützt:

• Mit der Eigenschaft statusMessages, mit der Entwickler alle anzuzeigenden Fehlermeldungen übergeben können. Sobald die Meldungen verfügbar sind, werden sie angezeigt. In der Komponente wird dann das Erscheinungsbild des Fehlerzustands verwendet (z. B. rote Umrandung eines Eingabefelds).
• Bereitstellung einiger ergänzender Funktionen: Komponenten wie PhoneNumberField enthalten einen eingebetteten Validierungsmechanismus. Ihr Ergebnis wird als dritter Parameter des Ereignisses onChange angegeben.

Der Entwickler legt Folgendes fest:

• Welche Art von Validierung erforderlich ist und wie sie implementiert wird
• Wann und wo die Fehlermeldungen angezeigt werden müssen (z. B. anstelle Fehler auf Komponentenebene anzuzeigen, können Fehler auf Seitenebene verwendet werden)
• Ob die vorgegebene Logik der Komponente verwendet wird

Dies gilt auch für alle Meldungen oder Validierungen für Pflichtfelder.

7. Design-Token und MFE

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 MFEs verwendet werden kann.

Ein Fall muss beachtet werden: Shell-basiertes Theming mit den alten GW-Variablen und Micro Frontends mit Design-Token kann dazu führen, dass Komponenten keine neuen Werte erhalten oder nicht wie erwartet ausgeführt werden. Möglicherweise treten Probleme beim Styling auf. Bitte melden Sie jedes aufgetretene Problem. Wir werden in den folgenden Releases detailliertere Anleitungen zur Verwendung alter GW-Variablen und Design-Token in den Micro Frontends bereitstellen.

8. Neue .themesConfig-Datei

Bisher waren separate Konfigurationsdateien für jedes Theme vorhanden, die Benutzer unter src/config/... ablegen und dann themeConfig in der start-Funktion zuweisen mussten.

Derzeit ist alles in einer einzigen Datei, .themesConfig.json, zusammengefasst, in der mehrere Definitionen der verschiedenen Themes enthalten sein können.

{
  "sampleTheme": {
    "name": "sampleTheme",
    "baseTheme": "Consumer"
    "styleOverrides": "styles/sampleTheme/styleOverrides.css",
    "variableOverrides": "styles/sampleTheme/variableOverrides.css"
  },
  "nexusTheme": {
    "name": "nexusTheme",
    "tokens": {
      "input-path": "src/tokens/Nexus/*.json",
      "output-file-name": "nexusTheme.css"
    }
  },
}

Wenn Sie eine Aktualisierung von einer Version älter als 10.0.x durchführen, wird ein Codemod ausgeführt, wobei die Theme-Konfiguration im alten Format, die in src/config/.. enthalten war, in die Theme-Konfiguration im neuen Format migriert wird.

Warning: Wenn Sie mehrere Theme-Definitionen in separaten Dateien erstellt haben, wird nur diejenige, die aktuell in der Theme-Konfiguration der Anwendung verwendet wird, in der neuen Datei .themesConfig.json hinzugefügt.

9. Rangfolge der Theming-Optionen

Bei einigen Komponenten wurden bisher --GW--Variablen zur Theming-Anpassung verwendet. Mit dem Hinzufügen des Design-Token-Mechanismus wird ein neuer Satz von Variablen hinzugefügt (--JDS-) und einige zusätzliche Zuordnungen und Standardwerte werden zugewiesen. Die Abwärtskompatibilität der vorhandenen Komponenten bleibt jedoch erhalten.

Wie wirkt sich die Definition des Theming in diesen Fällen auf das Theming aus?

Szenario: Sie haben eine Überschreibung der Variablen --GW- auf Kundenseite für die Link-Komponente festgelegt: --GW-LINK-COLOR

• Fall 1: Sie verwenden keine Token. Es gibt keine Konfiguration für Token in der Datei .themesConfig.json.

Die Überschreibung der Variablen --GW- durch den Kunden wird in der Link-Komponente verwendet.

• Fall 2: Sie haben begonnen, Token zu verwenden. Eines davon entspricht der Farbe, die auf die Link-Komponente angewendet wurde (--JDS-LINK-COLOR): Die Informationen des Tokens werden in .themesConfig.json hinzugefügt. Die Ausgabe enthält eine Überschreibung für die Link-Farbe.

Der Wert aus dem Design-Token, der den --JDS-LINK-COLOR-CSS-Variablen während des Transformationsprozesses zugewiesen wird, wird in der Link-Komponente verwendet.

• Fall 3: Sie haben begonnen, Design-Token zu verwenden. Allerdings ist kein Token für die Farbe der Link-Komponente vorgesehen.

Die Überschreibung der Variablen --GW- durch den Kunden wird in der Link-Komponente verwendet.

Wenn Sie in den oben genannten Fällen die Eigenschaft className der Link-Komponente zum Definieren eines anderen Stils verwenden, hat dies Vorrang vor den CSS-Variablen.

10. Theming von alten und neuen Komponenten

Für JDP 10 wurden neue Versionen einiger Komponenten eingefügt, die die vorhandenen ersetzen: Accordion, Button und die meisten eingabebezogenen Komponenten. Gleichzeitig wurden einige eingabebezogene Komponenten noch nicht ersetzt: InputMaskField, ToggleField, SwitchField, StepperField, Slider und die Datumskomponenten.

Zu den Änderungen, die mit den neu implementierten Komponenten eingeführt wurden, gehört vor allem das Theming: Diese Komponenten sind vollständig für die Verwendung mit den Design-Token vorbereitet und verfügen über einen völlig neuen Satz von CSS-Variablen. Die Theming-Optionen stimmen jedoch nicht vollständig mit den Anpassungsoptionen der Vorgängerversionen überein.

Daher kann es vorkommen, dass beide Gruppen von Komponenten nebeneinander vorhanden sind, da sie Teil derselben Anwendung sind oder dies durch die MFE-Einbettung erfolgt.

Einige Beispiele:

1. Nicht aktualisierte Eingaben und neue Eingaben werden verwendet: z. B. eine Seite, bei der die Komponenten InputMaskField und TextInput verwendet werden.

2. Eine Legacy- und eine neue Version der gleichen Komponente werden in einer Anwendung verwendet: z. B. eine Anwendung, in der legacy/components/Accordion und components/Accordionverwendet werden.

3. Shell-Anwendung mit alten (Legacy- und nicht aktualisierten) Komponenten und einem eingebetteten Micro Frontend, in dem die neuen Komponenten verwendet werden.

Außerdem ist es möglich, dass zwei Theming-Mechanismen nebeneinander vorhanden sind: basierend auf CSS-Variablen und mit Verwendung von Design-Token.

Warning: CSS-Variablen sind nicht Teil der API der Komponente und gelten als internes Implementierungsdetail. Für Komponenten im legacy-Paket gelten CSS-Variablen weiterhin als gültiger Ansatz und unterliegen keinen Änderungen.

Ein Vergleich des Erscheinungsbilds der Komponenten und verschiedener Kombinationen wurde durchgeführt, damit sie „ähnlich“ aussehen.

Note: Eine alte Komponente lässt sich möglicherweise nicht genau wie eine neue konfigurieren und umgekehrt.

Alte und neue Eingaben mit CSS-Variablen ähnlich aussehen lassen

Wenn Sie nicht überarbeitete Komponenten wie ToggleField, SwitchField oder DateFields und neue Komponenten ohne Verwendung von Design-Token kombinieren möchten, müssen Sie ihre Zuordnung zu „variablesOverrides.css“ hinzufügen, um das Erscheinungsbild der Komponenten zu vereinheitlichen: https://stash.guidewire.com/projects/JUT/repos/jutro-main/browse/packages/jutro-theme-styles/src/gwToTokens/gwToTokens.js

(Hinweis: Diese Zuordnung kann in Zukunft erweitert werden.)

Neue Komponenten mithilfe von Design-Token wie alte aussehen lassen

Die Komponenten im JDP-Release 10 können unter Verwendung der verfügbaren Design-Token an das gleiche Design angepasst werden wie die legacy-Komponenten. Es kann einige Unterschiede geben, aber das allgemeine Erscheinungsbild ist ähnlich.

Im Folgenden werden einige Aspekte und Unterschiede beschrieben:

1. Schriftfamilien:

• Bei Verwendung von Token und der enthaltenen gwToTokens-Datei bestehen keine visuellen Unterschiede bei den Schriftfamilien (Standard ist „Source Sans 3“).
• Wenn keine Token verwendet werden, unterscheidet sich die Schriftfamilie (sie ist ähnlich, aber nicht identisch): In legacy wird "Source Sans Variable", "Helvetica", "Arial", sans-serif;" verwendet, der Standard ist dagegen "Source Sans 3", "Helvetica", "Arial", sans-serif.

2. Accordion: Die Hintergrundfarbe von Kartenkopfzeile und Inhalt war für die Accordion-Legacy-Komponente nicht festgelegt. Die aktuelle Accordion-Komponente enthält Token für beides:

background-color: var(--JDS-ACCORDION-CARD-CONTENT-COLOR-BACKGROUND); // #fff

background-color: var(--JDS-ACCORDION-CARD-HEADER-COLOR-BACKGROUND); // #fff

3. Button: Die Definition des Innenabstands unterscheidet sich:

• Legacy-Button: padding: 0 var(--GW-SPACING-6); // 0 20px
• Aktueller Innenabstand: var(--JDS-BUTTON-PRIMARY-PADDING); // 0 16px

4. Eingabebezogene Komponenten: Es gibt einige Unterschiede:

• Der Stil der Zeilenhöhe für Beschriftungen unterscheidet sich. Wenn sich bei labelPosition: left die vertikale Ausrichtung der Beschriftung unterscheidet, ist auch der Abstand zwischen Beschriftung und Steuerelement unterschiedlich.

  • Legacy: line-height: var(--GW-LINE-HEIGHT-LABEL); // calculates to 21px
  • Aktuell: line-height: var(--JDS-FONT-LABEL-MEDIUM-LINE-HEIGHT); // calculates to 18px

• Der Stil der Zeilenhöhe für sekundäre Beschriftungen unterscheidet sich:

  • Legacy: var(--GW-LINE-HEIGHT-SECONDARY-LABEL); // calculates to 18px
  • Aktuell: line-height: var(--JDS-FONT-LABEL-SMALL-LINE-HEIGHT); // calculates to 15px

• Tooltip: QuickInfos sind bei alten Komponenten größer. Außerdem werden bei labelPosition: left QuickInfos an einer anderen Stelle gerendert.

• Sternchen für „Erforderlich“: Sieht aufgrund des unterschiedlichen Werts für die Schriftstärke bei den aktuellen Komponenten kleiner aus.

• Disabled für Opazität: Dieser Wert für Beschriftung und sekundäre Beschriftung wird nur für die neuen Felder festgelegt.

• Fehlermeldungen: Das Format der Fehlerstatusmeldungen ist unterschiedlich, z. B. haben Legacy-Komponenten einen roten Text.