Sie aktivieren Alert.alert() in React Native, testen Sie auf iPhone und Android, und es fühlt sich fertig an. Dann öffnet jemand die Webanwendung und nichts erscheint. Oder Android ignoriert die Prompt-Fluss, den Sie auf iOS verwendet haben. Oder zwei Teile der App lösen Benachrichtigungen aus und der Benutzer wird in einem chaotischen Stapel von Dialogen gefangen.
Das ist die Form der React Native Benachrichtigung API. Sie ist großartig für schnelle, native Bestätigungsflüsse. Sie ist auch eng, plattformgebunden und leicht zu missbrauchen in der Produktion. Die gute Nachricht ist, dass der glückliche Weg einfach ist und die rauhen Kanten vorhersehbar sind, sobald Sie wissen, wo sie sind.
Inhaltsverzeichnis
- Einfache Nachrichten mit Alert.alert anzeigen
- Eingaben des Benutzers mit Bestätigungsbuttons bearbeiten
- Plattformsspezifische Eigenheiten und Eingabefelder navigieren
- Wenn Sie ein benutzerdefiniertes Modalfenster anstelle eines Benachrichtigungsfensters verwenden möchten
- Produktionsmuster für zuverlässige React Native-Benachrichtigungen
Einfache Nachrichten anzuzeigen mit Alert.alert
Für grundlegende Benachrichtigungsoberflächen, React Native Alert ist immer noch das schnellste Werkzeug im Schrank. Sie importieren Alert, call Alert.alert(), rufen
The simplest version only needs a title and a message:
import React from 'react';
import { View, Button, Alert } from 'react-native';
export default function ProfileScreen() {
const showSavedMessage = () => {
Alert.alert('Profile updated', 'Your changes were saved successfully.');
};
return (
<View style={{ padding: 24 }}>
<Button title="Save profile" onPress={showSavedMessage} />
</View>
);
}
Die einfachste Version benötigt nur einen Titel und eine Nachricht:
Ein Detailfoto einer Person, die ein Smartphone benutzt, mit einer einfachen Warnmeldung auf dem Bildschirm.
Dieses Muster funktioniert gut, wenn der Benutzer keine bedeutende Entscheidung treffen muss. Denken Sie an 'Einstellungen gespeichert', 'Sitzung abgelaufen' oder 'Funktion nicht verfügbar zurzeit'. Das Dialogfenster unterbricht den Fluss, es sollte daher Informationen bereitstellen, die der Benutzer sofort benötigt, nicht jedoch geringfügige Statusmeldungen. Alert.alert(title, message) Was die grundlegende Anfrage gibt
Ein einfacher
- ist nützlich, weil er natürlich bleibt. Das Betriebssystem übernimmt die visuelle Darstellung, die Schaltfunktionen der Schaltflächen und das Standardinteraktionsmuster. Für viele Teams ist das genau der richtige Kompromiss.. 'Upload fehlgeschlagen' ist klarer als 'Hinweis'.
- . Die Nachricht soll kurz bleiben. Benachrichtigungen sind für den sofortigen Kontext und nicht für eine umfassende Erklärung bestimmt.
- . Für wichtige Informationen soll man sich die Benachrichtigung reservieren. Wenn der Benutzer ohne Unterbrechung fortfahren kann, ist ein Toast oft eine bessere Wahl.
. Benachrichtigungen sollen klein und entscheidend sein. Wenn der Benutzer eine ganze Passage lesen muss, ist das Dialogfenster wahrscheinlich die falsche UI.
Wo Teams es missbrauchen
Die häufigste Fehlhandlung ist die Verwendung von Benachrichtigungen als allgemeines Nachrichtensystem. Wenn jede erfolgreiche Aktion ein blockierendes Dialogfenster zeigt, fühlt sich die App schnell schwer an. Native Benachrichtigungen sind am stärksten, wenn sie den Benutzer für einen Grund stoppen.
Eine weitere Fehlhandlung ist die zu starke Verbindung von Benachrichtigungen zu internen Komponenten. Ein kleiner Button-Handler ist anfangs in Ordnung, aber sobald Flüsse mehrere Bildschirme und asynchrone Aktionen umfassen, werden Benachrichtigungsaufrufe überall, die man sich schwer überlegen kann. Das ist einer der Gründe, warum Teams oft die umgebenden UX-Patternen früh standardisieren, genauso wie sie die Splash-Screen-Behavior in React Native-Anwendungen standardisieren Gute Verwendungsfälle für eine einfache Benachrichtigung.
Szenario
| . 'Upload fehlgeschlagen' ist klarer als 'Hinweis'. | Warum Alert funktioniert |
|---|---|
| Speichern Sie die Bestätigung nach einer kritischen Einstellungsänderung | Der Benutzer benötigt eine explizite Bestätigung |
| Warnung vor Ablauf der Sitzung | Die Nachricht ist dringend und handlungsorientiert |
| Hinweis auf eine nicht unterstützte Funktion | Die App muss stoppen und erklären |
Wenn Sie den Benutzer auffordern, zwischen verschiedenen Pfaden zu wählen, ist der buttons Nächste Schritt der Array. Das ist, wo Alert.alert() sich zu einem einfachen Nachrichtenfenster entwickelt.
Benutzerinput mit Bestätigungs-Buttons verwalten
Die meisten echten Alert-Anwendungen sind nicht informativ. Es geht um eine Entscheidung. Den Entwurf löschen, Änderungen rückgängig machen, abmelden, einen fehlgeschlagenen Antrag erneut versuchen. Das ist, wo die buttons array matters.
Hier ist ein häufiges Bestätigungsdialogfeld:
import React from 'react';
import { View, Button, Alert } from 'react-native';
export default function DangerZone() {
const confirmDelete = () => {
Alert.alert(
'Delete item',
'This action cannot be undone.',
[
{
text: 'Cancel',
style: 'cancel',
},
{
text: 'Delete',
style: 'destructive',
onPress: () => {
console.log('Deleting item...');
},
},
]
);
};
return (
<View style={{ padding: 24 }}>
<Button title="Delete item" onPress={confirmDelete} />
</View>
);
}
Jeder Knopf ist ein Objekt. In der Praxis wirst du drei Eigenschaften am häufigsten verwenden:
textist die dem Benutzer angezeigte Beschriftung.onPressläuft aus, wenn der Knopf betätigt wird.stylekommuniziert Bedeutung, insbesondere auf iOS.
Die Wahl von Knopfbeschriftungen, die Fehler minimieren
Das API lässt dich schreiben „OK“ und weitermachen. Das ist normalerweise nicht ausreichend. Die Beschriftung sollte die Auswirkung beschreiben, insbesondere bei destruktiven Aktionen.
Vergleichen Sie diese beiden Mengen:
- Schwache Beschriftungen : OK / Abbrechen
- Bessere Beschriftungen: Löschobjekt / Objekt behalten
Die zweite Version entfernt die Ambiguität. Das ist in destruktiven Flüssen wichtig, und es ist noch wichtiger, wenn die Warnung nach einem Fehler oder einer asynchronen Operation erscheint. Der Text des Buttons sollte die Frage beantworten, "Was passiert, wenn ich auf diesen Button tippe?"
Wenn Ihr Fluss Text vom Benutzer sammelt, ist ein sauberes Begleitmustern das Paaren von Warnungen mit expliziten Formulareingaben wie einer dedizierten React Native TextInput Implementation anstatt versuchen, den Dialog zu überstrecken.
Was Button-Styles tatsächlich bedeuten
Der style Feld ist semantisch, nicht dekorativ. Verwenden Sie es, um Absichten zu kommunizieren.
| Stil | Wenn Sie es verwenden sollten | Hinweise |
|---|---|---|
default |
Normale Aktionen | Gut für neutrale Auswahlmöglichkeiten |
cancel |
Aus oder zurückgehen | Wichtig für sichere Abmeldung |
destructive |
Unumkehrbarer Vorgang | Visuell hervorgehoben auf iOS |
Technische Benchmarking von Gluestack weist darauf hin, dass Plattformkonventionen hier wichtig sind. iOS platziert die abbrechen Schaltfläche links und die bestätigen rechts, während Android das umkehrt. Verstöße gegen diese Konventionen führen zu einem Anstieg der Benutzerverwirrungsmetriken um 25% in globalen Märkten und 45% Produktionsanwendungen, die kritische Pfadwarnungen haben, fehlen oft eine verpflichtende Abbruch- oder Beendigungsmöglichkeit, was irreparable Aktionen und ein höheres Supportvolumen zur Folge hat. Eine ähnliche Analyse weist auch darauf hin, dass benutzerdefinierte Warnimplementierungen häufig bei der Lesereihenfolge für assistive Technologien scheitern. Siehe die Gluestack Warnleitfaden.
Praktische Regel: Jeder destruktive Warnhinweis sollte eine explizite Ausstiegsmöglichkeit enthalten.
Für eine visuellere Durchführung von Schaltflächenkonfiguration und Interaktionsablauf ist diese kurze Demo einen Blick wert.
Ein sichererer Bestätigungsmodell
Wenn die Aktion empfindlich ist, sollte der Callback dünn gehalten werden:
Alert.alert(
'Sign out',
'You will need to log in again to continue.',
[
{ text: 'Stay signed in', style: 'cancel' },
{
text: 'Sign out',
style: 'destructive',
onPress: async () => {
try {
await signOut();
} catch (error) {
Alert.alert('Sign out failed', 'Please try again.');
}
},
},
]
);Dieses Muster ist langweilig, und das ist gut so. Warnhinweise sollten vorhersehbar bleiben.
Navigation von Plattform-Sonderheiten und Eingabeprompten
Ein häufiger Produktionsfehler sieht so aus. Das gleiche Alert.alert() aufrufen funktioniert auf iOS, funktioniert auf Android, dann funktioniert es jedoch nicht, sobald das Team eine Webversion bereitstellt. Der API sieht gleichmäßig in code aus, aber die Plattformen sind nicht gleich.
IOS und Android passen sich nicht perfekt an
Die Reihenfolge der Schaltflächen ist der erste Ort, an dem Teams stolpern. React Native delegiert Benachrichtigungen an das Betriebssystem, sodass Benutzer native Konventionen sehen, nicht eine React Native-Abstraktion. Das ist in der Regel die richtige Abwägung, aber es bedeutet, dass die Schaltflächenbeschriftungen unverwirrend bleiben müssen, um Plattformen übergreifend.
Unterstützung für Anfragen ist der größere Mangelabstand. iOS unterstützt Alert.prompt für leichte Texteingabe. Android unterstützt dies nicht. Wenn ein Fluss von der Eingabe eines Passworts, der Umbenennung eines Elements oder der Erfassung eines kurzen Notizen innerhalb der Benachrichtigung selbst abhängt, ist dieser Fluss iOS-only, es sei denn, Sie bauen einen separaten Weg.
Verwenden Sie eine Plattformprüfung frühzeitig anstatt zu glauben, dass die APIs übereinstimmen.
import { Alert, Platform } from 'react-native';
export function requestPassword() {
if (Platform.OS === 'ios') {
Alert.prompt(
'Enter password',
'Please confirm your password.',
[
{ text: 'Cancel', style: 'cancel' },
{
text: 'Continue',
onPress: (value) => {
console.log('Password entered:', value);
},
},
],
'secure-text'
);
return;
}
Alert.alert(
'Confirmation required',
'Please continue to the next screen to confirm this action.',
[{ text: 'OK' }]
);
}Die Android-Fallback-Option ist weniger bequem. Sie ist jedoch die sichere Wahl. In der Produktion ist eine Umleitung zu einer dedizierten Seite oder einem kontrollierten Modalfenster einfacher zu testen, einfacher zu lokalisieren und einfacher zugänglich als eine fiktive Anfrage, die um nicht unterstütztes Verhalten herumgebaut wird.
Die Unterstützung für Web benötigt seinen eigenen Plan
Die offizielle React Native-Anleitung für API listet die Unterstützung für iOS und Android in der React Native Alert-ReferenzAn. Wenn Ihr App auch auf React Native Web oder Expo Web läuft, bleibt die ungewickelte Benachrichtigung bei Web-Builds eine vollständige Fehlfunktion für diesen Interaktionsweg (Diskussion über die Unterstützung von Benachrichtigungen in React Native Web).
Das ist kein Randfall. Teams finden es oft spät, weil die mobile QA zuerst durchläuft, während die Browser-Abdeckung später kommt.
Behandeln Sie native Benachrichtigungen als mobilen- nur- Anzeige, es sei denn, Sie fügen einen Wrapper hinzu.
Der Wrapper hilft auch, wenn Ihr Team die Hybrid- Laufzeit- Vorteile zwischen Plattformen vergleicht, insbesondere in einer React Native vs. Capacitor Architektur-Vergleich.
Ein einfaches Web-Polyfill-Muster
Für viele Apps ist der erste funktionierende Fix eine kleine Abstraktion um die Plattform-Spaltung:
import { Alert, Platform } from 'react-native';
type ConfirmOptions = {
title: string;
message?: string;
onConfirm?: () => void;
onCancel?: () => void;
};
export function confirmDialog({
title,
message,
onConfirm,
onCancel,
}: ConfirmOptions) {
if (Platform.OS === 'web') {
const result = window.confirm(message ? `${title}\n\n${message}` : title);
if (result) onConfirm?.();
else onCancel?.();
return;
}
Alert.alert(title, message, [
{ text: 'Cancel', style: 'cancel', onPress: onCancel },
{ text: 'OK', onPress: onConfirm },
]);
}Dieses Muster löst den sofortigen Unterstützungs- Abgrund, hat aber Grenzen. window.confirm gibt Ihnen fast keinen Kontrolle über die Gestaltung, das Fokusverhalten oder die Analytics- Hooks. Es ist ein vernünftiger Sicherheitsnetz für einfache Bestätigungen, kein endgültiger Antwort für Flows, die eine Barrierefreiheitsprüfung, eine Benachrichtigungs- Warteschlange oder eine konsistente Verhaltensweise zwischen mobilen und Web benötigen.
Wann Sie ein benutzerdefiniertes Modalfenster anstelle einer Benachrichtigung verwenden sollten
Native Benachrichtigungsdialoge sind stark, weil sie begrenzt sind. Diese gleiche Einschränkung ist der Grund, warum sie schnell nicht mehr die richtige Werkzeug sind.
Wenn Sie Markenpräsenz, Layout-Kontrolle, Icons, Formularelemente, benutzerdefinierte Abstände, Animationstimer oder konsistente visuelle Konsistenz zwischen Plattformen, stoppen Sie, sich gegen den API zu wehren. Verwenden Sie ein benutzerdefiniertes Modalfenster.
Native Benachrichtigungen, die Sie nicht code umgehen können.
Sie können nicht Alert.alert() wie Ihr Design-System aussehen. Das ist bewusst so.
React Native überträgt die Renderung an das Betriebssystem, sodass Sie eine native Oberfläche und native Einschränkungen erben.
- Das ist gut, wenn Sie eine schnelle Bestätigung wollen. Es ist schlecht, wenn das Produkt eine dieser Anfragen stellt: Eine benutzerdefinierte Bestätigungsanzeige
- mit Logo, Hilfetext und benutzerdefinierter Hierarchie Eine mehrfeldige Form
- innerhalb des Modals Eine reichere destruktive Fluss
- mit Checkbox-Bestätigung mit Sternen, Illustration und benutzerdefinierten Schaltflächen
Wenn diese Anforderungen auftauchen, wird das native Alert ein toter Weg.
Ein einfacher Entscheidungsfilter
Benutze React Native Alert wenn das Dialogfeld ist:
| Benutze native Alert | Benutze benutzerdefinierten Modal |
|---|---|
| Kurze Nachricht | Reicher oder strukturierter Inhalt |
| Eins bis drei grundlegende Aktionen | Formularelemente oder eingebettete Komponenten |
| Eine nativ anmutende Oberfläche ist akzeptabel | Die visuelle Konsistenz ist auf allen Plattformen wichtig |
| Sie wollen die schnellste Implementierung | Sie benötigen Kontrolle über Layout und Animation |
Ein benutzerdefinierter Modaldialog hilft auch, wenn Ihre mobilen und Web-Anwendungen denselben Verhalten benötigen. Anstatt jede Plattform für immer speziell zu behandeln, können Sie einen zentralen Dialogkomponenten erstellen und Ihr Interaktionsmodell konsistent halten.
Der Moment, in dem Sie sich wünschen, dass Alert nur noch ein weiteres Prop hätte, bedeutet wahrscheinlich, dass Sie einen Modaldialog benötigen.
Die guten Kandidaten für benutzerdefinierte Modaldialogbibliotheken
Der integrierte Modal Komponente funktioniert, aber viele Teams wählen einen Wrapper wie react-native-modal weil er praktische Kontrolle über Sichtbarkeit, Hintergrundverhalten und Animation bietet.
Das ist besonders nützlich für Flows, die sich an Aktionsscheiben, unteren Schubladen oder zusammengesetzte Bestätigungsfelder anlehnen. Wenn Ihr Design sich näher an einem Menü als an einem strengen nativen Warnhinweis befindet, sind verwandte UI-Muster wie ein Ionics Aktionsscheibe oftentimes bieten eine bessere mentale Vorstellung als das Versuchen, Alert in die richtige Form zu bringen.
Ein Warnhinweis ist hier wichtig. Ersetzen Sie nicht jede Benachrichtigung durch eine benutzerdefinierte Modale nur weil sie besser aussieht. Native Alerts gewinnen immer noch in Bezug auf Geschwindigkeit, Vertrautheit und geringen Implementierungsrisiko. Verwenden Sie eine Modale, weil die Interaktion es erfordert, und nicht weil das Design-Team die Systemchrome ablehnt.
Produktionsmuster für zuverlässige React Native-Benachrichtigungen
Ein Löschungsvorgang schlägt fehl, der Retry-Handler wird ausgelöst und die Sitzung-Abgelaufens-Überprüfung läuft gleichzeitig. Ohne eine klare Benachrichtigungsstrategie können Benutzer mit überlappenden Dialogen, verlorenem Fokus oder einem no-op auf der Webseite konfrontiert werden. Das liegt daran, dass Alert.alert nicht implementiert ist. Diese Fehler kommen normalerweise aus der Architektur und nicht aus der API-Aufruf selbst.
Benachrichtigungen centralisieren anstatt sie überall aufzurufen
Direkt Alert.alert(...) Aufrufe, die über verschiedene Bildschirme verteilt sind, halten sich in einem größeren Codebase nicht. Ein Komponente handhabt einen API-Fehler, eine andere fragt nach Navigationsbestätigung und eine dritte warnt vor Auth-Abgelaufenheit. Wenn diese Ereignisse in der Nähe voneinander auftreten, benötigt man eine Reihenfolge, eine Duplikationsvermeidung und eine Plattform-Abfanglogik an einem Ort.
Eine globale Benachrichtigungsdienstlösung löst das Problem. Verwenden Sie Redux, Zustand oder React Context. Die Wahl des Stores ist weniger wichtig als der Vertrag. Benachrichtigungsanfragen werden in eine Warteschlange eingefügt, es ist nur eine Dialogbox aktiv und die Webversion kann auf eine modalbasierte Abfangfunktion hinter der gleichen Schnittstelle umschalten.
Entwickler, die sich mit Mustern der Benachrichtigungsabstraktion auseinandersetzen, haben wiederholt darauf hingewiesen, dass schlecht strukturierte Apps oft mit gestapelten Dialogen enden, die Benutzer fangen oder die erforderliche Aktion verbergen, was manchmal etwa 30-40% von den in der Praxis diskutierten Implementierungen beeinträchtigen kann (Die praktische Lösung ist einfach. Wrap die __CAPGO_KEEP_0__ einmal, priorisieren die Anforderungen global und machen den Renderer für genau einen sichtbaren Benachrichtigungsdialog verantwortlich. was noted earlier in the article, so do not repeat that link here). The practical fix is simple. Wrap the API once, queue requests globally, and make the renderer responsible for exactly one visible alert.
Die Benutzeroberfläche abonniert das erste Queue-Element und rendernt genau einen Dialog. Wenn der Benutzer ihn abblendet, entfernt das Service das Element und enthüllt das nächste.
type AlertRequest = {
title: string;
message?: string;
buttons?: { text: string; onPress?: () => void; style?: 'default' | 'cancel' | 'destructive' }[];
};
type AlertStore = {
queue: AlertRequest[];
push: (alert: AlertRequest) => void;
shift: () => void;
};Barrierefreiheit ist Teil der Implementierung
Native-Benachrichtigungen bieten auf iOS und Android gute Standards. Sobald Sie jedoch eine benutzerdefinierte Ersatzlösung für das Web, reichere Inhalte oder die Ersetzung von Android-Prompten einführen, übernehmen Sie die Verantwortung für das Verhalten, das der Systemdialog kostenlos abgedeckt hat.
Gluestacks Vergleich von React Native-Benachrichtigungsoptionen weist darauf hin, dass benutzerdefinierte Modaleinführungen häufig die erwartete Lesereihenfolge von
→ Nachricht → Schaltflächen unterbrechen, wobei Versagen in diesem Bereich in ihrer Benchmark für die Barrierefreiheitshandhabung (Gluestacks Vergleich von React Native-Benachrichtigungen vs. Modale Barrierefreiheit) gemeldet wurden. Diese spezifische Problematik ist wichtig, weil sich Benutzer mit Bildschirmlesern auf eine vorhersehbare Struktur verlassen, um den Dialog zu verstehen, bevor sie darauf handeln.Implementierungsdiskussion zu Benachrichtigungsabstraktion und Dialogstapelung 60% war bereits in diesem Artikel erwähnt, daher sollten Sie diese Link hier nicht wiederholen. Die praktische Lösung ist einfach. Wrap die __CAPGO_KEEP_0__ einmal, priorisieren die Anforderungen global und machen den Renderer für genau einen sichtbaren Benachrichtigungsdialog verantwortlich.
Für eine benutzerdefinierte Benachrichtigungs-UI, halten Sie diese Checkliste kurz und durchsetzen:
- Fokus in das Dialogfeld setzen wenn es geöffnet wird.
- Fokus auf den Auslöser zurücksetzen nach der Abmeldung.
- Halten Sie die Lesereihenfolge unverändert: Titel, Nachricht, dann Aktionen.
- Bieten Sie einen klaren Abbruchpfad an, insbesondere für zerstörerische Flüsse.
- Beschriften Sie Aktionen genau. 'Löschen' ist besser als 'OK' wenn die Folgen zählen.
Barrierefreiheitsfehler in Benachrichtigungsflüssen sind leicht zu übersehen bei normaler QA. Tastaturnutzer und Screenreader-Nutzer finden sie zuerst.
Testen Sie den Trigger, nicht die Plattform-Dialg
Einheiten-Tests sollten überprüfen, dass Ihr code die Warnung angefordert hat, die Sie erwartet haben. Sie sollten sich nicht auf die native Dialog- Runtime verlassen.
Ein häufiges Muster für Jest sieht so aus:
import { Alert } from 'react-native';
jest.spyOn(Alert, 'alert').mockImplementation(() => {});
it('asks for confirmation before deleting', () => {
triggerDeleteFlow();
expect(Alert.alert).toHaveBeenCalledWith(
'Delete item',
'This action cannot be undone.',
expect.any(Array)
);
});Das hält die Tests auf die Geschäftslogik fokussiert und verhindert Hänge, die durch Dialogverhalten außerhalb der Testumgebung verursacht werden. Es drängt die Teams auch zu einem Wrapper API , der nützlich ist, wenn Web- und Android-Prompt-Beschränkungen eine benutzerdefinierte Fallback-Anforderung erzwingen.
Client-seitige Überwachung hilft hier auch. Teams, die bereits Interaktionsfehler mit Sentry in React Native-Anwendungen verfolgen fangen normalerweise mehr Warnungsbeziehungen auf, wenn die code -Pfade, die Warnungen auslösen, in explizitem Fehlerbehandlungs- und mit ausreichendem Kontext zum Wiederaufbau der Fluss geloggt werden.
Ein Produktionsniveau, das hält
Für Apps, die über das Prototypenstadium hinausgehen, verwenden Sie einen kleinen Satz von Regeln:
- Wrap
Alert.alertin einem Hilfsprogramm so dass die Web-Fallback-Logik in einem Ort lebt. - Globale Anfragen für Dialoge verarbeiten so ist nur ein Warnhinweis gleichzeitig sichtbar.
- Behandle Android-Fensterunterstützung als fehlend und plane stattdessen eine Modalfallback-Implementierung anstatt zu spät zu branchen.
- Erforderliche Abbruchaktionen für zerstörerische oder unwiderrufliche Operationen.
- Mock-Warnhinweise in Tests und überprüfe Labels, Callbacks und Anordnungen.
- Verwende einen benutzerdefinierten Modalfenster nur wenn nötig, wie z.B. Web-Parität, Eingabefelder oder reichhaltigeres Inhalt.
Dies hält native Warnhinweise schnell, wo sie gut funktionieren, und vermeidet es, den Codebase in eine Ecke zu malen, wenn sich Plattformunterschiede später zeigen.
