Solid 2 hat sein eigenes Meta-Framework abgelöst

Solid 2.0, jetzt als Release Candidate verfügbar, überarbeitet asynchrone Operationen grundlegend und integriert sie als Bürger erster Klasse in den reaktiven Graphen. Dies macht das createResource-Primitiv aus Solid 1 überflüssig und ermöglicht es Berechnungen wie createMemo, Promises direkt zurückzugeben. Das Framework versteht und verwaltet nun nativ asynchrone Werte, was die Integration von fetchUser oder ähnlichen Datenquellen in reaktive Abläufe vereinfacht.

Das Entfernen von createResource vereinfacht die Logik zum Datenabruf und bereinigt den Komponenten-Code. In Solid 1 mussten Entwickler createResource-Ausgaben verwalten, was verstreute Null- oder Undefined-Prüfungen beim Zugriff auf Ressourcenwerte erforderte. Die direkte Promise-Rückgabe in Solid 2 bedeutet, dass der reaktive Graph die Datenverfügbarkeit steuert, wodurch diese Prüfungen entfallen und Komponenten nur noch mit einfachen, definierten Werten arbeiten müssen.

Boundary-Primitive wurden ebenfalls neu architektoniert, um sie an das neue Async-Modell anzupassen, was sowohl die Entwickler- als auch die Benutzererfahrung verbessert. Suspense wird durch die Loading-Boundary ersetzt, die Fallbacks speziell für das anfängliche Fehlen von Daten rendert. ErrorBoundary wird zu Errored, was größtenteils eine Umbenennung mit zugrunde liegenden Überarbeitungen ist, und SuspenseList heißt jetzt Reveal.

Dieser verfeinerte Boundary-Ansatz verbessert die Benutzererfahrung erheblich. Im Gegensatz zu anderen Frameworks, die die UI bei der Promise-Verarbeitung blockieren, konsumiert das Framework in Solid 2 Promises bei der Erstellung in seinem Graphen und blockiert nur dort, wo der Wert gelesen wird. Dies ermöglicht es der UI, sofort zu aktualisieren, sobald einzelne Datenteile bereit sind, anstatt auf den Abschluss aller Anfragen zu warten. isPending verfolgt nachfolgende Datenabrufe, ohne die UI zu zerstören.

Solid 2.0 verfeinert die Entwicklererfahrung für Datenmutationen und Effekte erheblich. Ein neuer Mutations-Flow führt das action-Primitiv ein, das einen klaren Lebenszyklus für Updates definiert. Gepaart mit createOptimistic und createOptimisticStore ermöglicht dieses System ein automatisches UI-Rollback: Lokale optimistische Änderungen sind flüchtig, verschwinden bei einem API-Fehler und setzen die UI auf den autoritativen Serverstatus zurück.

Die Store-Verwaltung wird vereinfacht, da direkte Mutation zum Standardverhalten wird. Diese Änderung macht die produce-Funktion überflüssig und macht createMutable obsolet, sodass Entwickler Store-Entwürfe direkt bearbeiten können. Der storePath-Helfer bleibt für spezifische Legacy-Anwendungsfälle verfügbar.

createEffect erhält ein umfassendes Refactoring und wird in zwei separate Funktionen aufgeteilt. Die erste, eine getrackte 'Compute'-Phase, definiert Abhängigkeiten. Die zweite, eine untrackte 'Apply'-Phase, führt den Seiteneffekt aus und empfängt den berechneten Wert. Diese architektonische Verschiebung eliminiert den on-Helfer und ermöglicht es, die defer-Option direkt am Effekt zu setzen.

Auch die Effekt-Bereinigung entwickelt sich weiter. Die apply-Funktion gibt nun direkt ihre Bereinigungslogik zurück, was das Ressourcenmanagement rationalisiert. onMount wurde durch onSettled ersetzt, das erst feuert, nachdem alle asynchronen Operationen innerhalb seines Bereichs abgeschlossen sind, und gibt ebenfalls seine Bereinigungsfunktion zurück. Das createComputed-Primitiv wurde entfernt; seine Funktionalität wird nun durch createMemo oder den neuen geteilten Effekt abgedeckt.

Solid 2.0 vereinfacht die JSX-Syntax erheblich und reduziert Framework-spezifische Idiome. Die classList Prop wurde vollständig entfernt; die class Prop akzeptiert nun direkt Strings, Objekte oder Arrays. Dies ermöglicht intuitiveres und dynamischeres bedingtes Styling, ohne dass eine manuelle String-Verkettung oder Array-Manipulation erforderlich ist.

Die Attributbehandlung orientiert sich nun ebenfalls stärker an nativem HTML. Die Präfixe attr: und bool:, die zuvor für explizite Attribut- und Boolean-Property-Bindungen verwendet wurden, sind nicht mehr notwendig. Diese Änderung standardisiert die Attributdeklaration und entfernt eine Ebene Solid-spezifischer Syntax für gängige HTML-Attribute.

Event-Handling-Namespaces wie on: und onCapture: wurden entfernt. Events werden nun über Standard-camelCase-Props wie onClick oder onInput verwaltet, was gängigen Webentwicklungs-Mustern entspricht. Die use:-Direktive wurde zudem durch stapelbare ref Callbacks ersetzt, was eine flexiblere und kombinierbare Methode für benutzerdefiniertes Elementverhalten und Lifecycle-Hooks bietet.

Das Listen-Rendering wurde vereinfacht. Die dedizierte Index-Komponente ist nicht mehr verfügbar; deren Funktionalität für nicht-keyed Listen wurde in <For keyed={false}> integriert. Zusätzlich wurde eine neue Repeat-Komponente eingeführt, um zählerbasiertes Rendering zu optimieren und eine deklarative Möglichkeit zu bieten, einen JSX-Block eine festgelegte Anzahl von Malen zu rendern. Erfahren Sie mehr über diese und andere Änderungen im Blog-Beitrag Solid 2.0 RC: The Big <Reveal> - SolidJS.

Solid 2 enthält einen neuen Rust-basierten Compiler, der auf dem leistungsstarken Oxc-Projekt aufbaut. Diese neu entwickelte Toolchain steigert die Build-Performance des Frameworks erheblich. Interne Benchmarks zeigen Kompilierungsgeschwindigkeiten, die 20- bis über 350-mal schneller sind als beim JavaScript-basierten Compiler von Solid 1, was sich direkt in schnelleren Entwicklungszyklen und effizienteren Projekt-Builds niederschlägt.

Das aktualisierte Vite-Plugin führt einen leistungsstarken 'Start-Modus' ein, der Entwicklern sofort einen vollständigen Anwendungs-Build bietet. Dieser Modus unterstützt sowohl Client-only-Rendering als auch umfassende Server-Side Rendering (SSR)-Funktionen. Er integriert Kernfunktionen wie Server-Funktionen direkt in die Tooling-Umgebung des Frameworks, wodurch separate Pakete überflüssig werden und die Projekteinrichtung für verschiedene Deployment-Ziele vereinfacht wird.

Dieses integrierte und leistungsstarke Tooling macht das separate SolidStart Meta-Framework überflüssig. Die etablierten Konventionen von SolidStart, einschließlich seiner Server-Funktionen und der Serving-Layer, wurden direkt in den Solid-Kern oder dessen Compiler-Plugin aufgenommen. Dieser strategische Schritt konsolidiert das Entwicklungs-Ökosystem und bettet die bewährten Architekturmuster und Full-Stack-Fähigkeiten von SolidStart direkt in das primäre Framework ein, was die Entwicklererfahrung insgesamt vereinfacht.

Was ist die größte Änderung in Solid 2.0?

Die Kerninnovation besteht darin, asynchrone Operationen zu einem erstklassigen Feature des reaktiven Graphen zu machen. Dies ermöglicht es Berechnungen, Promises direkt zurückzugeben, wodurch spezielle Primitive wie createResource nicht mehr benötigt werden.

Wird SolidStart eingestellt?

Ja, SolidStart wird als separates Meta-Framework eingestellt. Seine Hauptfunktionen, wie Server-Side Rendering und Server-Funktionen, wurden über einen neuen 'Start-Modus' direkt in das Kern-Plugin von Solid 2.0 für Vite integriert.

Wie geht Solid 2 mit Datenabrufen ohne createResource um?

Berechnungen wie createMemo können nun direkt Promises zurückgeben. Das reaktive System versteht und verarbeitet den asynchronen Status automatisch, was die Logik für Datenabrufe und den Komponentencode vereinfacht.

Ist Solid 2 schneller zu bauen?

Ja, deutlich. Solid 2 führt eine neue, in Rust geschriebene Compiler-Toolchain ein, die laut Benchmarks über 20-mal schneller ist, wobei einige Tests eine Geschwindigkeitsverbesserung von bis zu 355-fach zeigen.

Was ersetzt Suspense in Solid 2?

Die Suspense-Grenze wurde durch Loading ersetzt. Loading rendert ein Fallback nur für den ersten Datenabruf, während nachfolgende Abrufe mit isPending verfolgt werden können, ohne die bestehende Benutzeroberfläche zu entfernen.