SolidJS 2.0 ships with a native async-data model that lets a component treat a promise like any other reactive value, and it does so without the cascade of re-renders that React developers see with Suspense and hooks. The change matters because it keeps UI on screen while data refreshes, cuts boilerplate, and offers a concrete path for React teams to move their data-fetching code over to Solid.
Why Solid’s async model feels different
In React, a component that needs data usually calls a hook (often a custom one) that returns a promise-like object, then wraps the UI in <Suspense> to show a fallback while the promise resolves. Every time the promise settles, React schedules a re-render; if the same component later refetches, the fallback can flash over content that is already visible.
Solid flips the script. A promise is simply a value that the reactive graph watches. When a computation reads that value, the graph pauses that read until the promise resolves, but the rest of the UI stays rendered. The first time a component mounts, a <Loading> boundary can display a fallback; after that, a refetch leaves the existing DOM untouched until the new data arrives. No explicit “await” inside the component, no createResource, no manual state toggles.
The core primitives
<Loading>boundary – Replaces React’s<Suspense>. It shows a fallback only on the initial load. After the first paint, a pending read does not replace the UI; the old content remains until the fresh value resolves. Pass anonprop to force a spinner on a specific refetch.<Reveal>component – Controls how multiple<Loading>boundaries appear together. Choose:- Sequential: boundaries reveal one after another in DOM order.
- Together: all reveal at once when every piece of data is ready.
- Natural: each reveals as soon as its own data lands.
isPendingsignal – Returnstruewhile a particular read is in flight. Use it to overlay a thin loading bar or subtle animation while the main content stays visible, giving you “stale-while-revalidate” for free.actiongenerator – Replaces React’s mutable-state updates. Anaction(function*…)can optimistically update the UI,yieldto wait for a server response, then reconcile the result when the promise resolves. The UI feels instant, and the reconciliation step is baked into the primitive.
How the pieces map to React concepts
| Feature | React approach | Solid 2.0 approach |
|---|---|---|
| Data fetching | use() (experimental) or third-party hooks; result wrapped in <Suspense> |
createMemo (or similar) that returns a promise; read directly in JSX |
| Loading UI | <Suspense> may re-trigger fallback on every refetch |
<Loading> only on first load; refetch keeps old UI |
| Refreshing | useTransition to defer UI updates |
isPending signals pending reads without UI swap |
| Mutations | useState/useReducer + async calls, often wrapped in custom actions |
action(function*…) with built-in optimistic handling |
The practical upshot is that Solid builds what React treats as separate hooks into the core reactivity engine.
A step-by-step migration guide
- Veri kaynağını belirleyin – React'te muhtemelen
const data = useMyFetch(url)yapısına sahipsiniz. Solid'de bunu, promise döndüren bir memo ile değiştirin:const data = createMemo(() => fetch(url).then(r => r.json())). - En üst düzey bileşeni sarmalayın – Eğer bileşen promise çözümlenmeden önce render ediliyorsa, onu
<Loading fallback={<Spinner/>}>…</Loading>ile çevreleyin. Fallback yalnızca ilk mount sırasında görünür. - Yeniden veri çekme (refetch) spinner'larını değiştirin – Daha önce bir loading bayrağını (flag) değiştirdiğiniz yerde, artık
isPending(data)değerini okuyun. Mevcut UI ekranda kalırken, ince bir gösterge render etmek için bu boolean değerini kullanın. - Optimistik güncellemeleri dönüştürün – Eğer
setState(prev => ({...prev, optimisticValue}))ve ardından gelen bir async çağrınız varsa, bunu şu şekilde yeniden yazın:const update = action(function* (newValue) { state = newValue; const server = yield fetch(...); state = reconcile(server); });. Generator, sunucu yanıt verene kadar kontrolü devreder ve ardından reaktif grafiği otomatik olarak günceller. - Birden fazla asenkron parçayı yönetin – İhtiyaç duyulduğunda
<Loading>sınırlarını iç içe geçirin, ardından bunların birlikte mi yoksa birbiri ardına mı görüneceğine karar vermek için bir<Reveal>sarmalayıcısı ekleyin. Bu, React geliştiricilerinin karmaşık state kontrolleriyle birden fazla<Suspense>bileşenini kademeli olarak kullandığı kalıpların yerini alır. - Akışı test edin – Solid, promise çözümlendiğinde yeniden render etmediği için, UI güncellemelerinin beklediğiniz yerlerde gerçekleştiğini doğrulayın. Reaktif grafik değişiklikleri otomatik olarak yayar; ekstra
useEffectçağrılarına gerek yoktur.
Hâlâ değişim aşamasında olanlar
Solid 2.0'ın async API'si şu anda beta aşamasındadır. <Loading> ve action gibi isimler kararlı sürümden önce değişebilir ve dokümantasyon hâlâ gelişmeye devam etmektedir. Temel fikir —promise'leri reaktif değerler olarak ele almak— değişmeden kalıyor, ancak erken benimseyenler kütüphane oturdukça küçük köklü değişiklikler (breaking changes) beklemelidir.
Kimler fayda sağlar
- Yoğun veri çekme işlemi yapan React ekipleri – Dış state kütüphanelerine olan ihtiyacın azalması ve yerleşik stale-while-revalidate kalıbı, bundle boyutunu küçültebilir ve kod tabanlarını basitleştirebilir.
- Performans odaklı uygulamalar – Her fetch işleminde tam bileşen yeniden render edilmesinden kaçınarak Solid, özellikle düşük segment cihazlarda daha pürüzsüz görsel güncellemeler sunar.
- “Spinner parlamasından” (flash of spinner) yorulan geliştiriciler –
<Loading>sınırının “yalnızca ilk yüklemede” davranışı, zaten görünür olan bir içeriğin üzerinde bir spinner'ın anlık olarak parlaması şeklindeki yaygın rahatsızlığı ortadan kaldırır.
Olası dezavantajlar
- Beta durumu – API kararlı hale gelene kadar, uzun vadeli projelerin daha sonraki taşıma (migration) çabaları için bütçe ayırması gerekebilir.
Bundan sonra neyi takip etmeli
<Loading> veya action isimlendirmelerindeki herhangi bir değişiklik için resmi changelog'u takip edin.
Özetle: SolidJS 2.0, veriler yenilenirken UI'ı sabit tutarak ve bir dizi React tarzı hook ihtiyacını ortadan kaldırarak promise'leri birinci sınıf reaktif değerler olarak ele almanıza olanak tanır. Yeniden render odaklı modelin ötesine geçmeye hazır ekipler için geçiş yolu nettir, performans avantajı somuttur ve tek gerçek risk her zamanki beta aşaması belirsizliğidir.
