SolidJS 2.0 एक नेटिव async-data मॉडल के साथ आता है जो एक कंपोनेंट को promise को किसी भी अन्य reactive value की तरह ट्रीट करने की अनुमति देता है, और यह बिना उन re-renders की झड़ी के ऐसा करता है जो React डेवलपर्स Suspense और hooks के साथ देखते हैं। यह बदलाव महत्वपूर्ण है क्योंकि यह डेटा रिफ्रेश होते समय UI को स्क्रीन पर बनाए रखता है, boilerplate को कम करता है, और React टीमों के लिए अपने data-fetching कोड को Solid पर ले जाने का एक ठोस रास्ता प्रदान करता है।

Solid का async मॉडल अलग क्यों महसूस होता है

React में, जिस कंपोनेंट को डेटा की आवश्यकता होती है, वह आमतौर पर एक hook (अक्सर एक custom hook) को कॉल करता है जो promise-like ऑब्जेक्ट लौटाता है, और फिर promise के resolve होने तक fallback दिखाने के लिए UI को <Suspense> में लपेट (wrap) देता है। हर बार जब promise settle होता है, React एक re-render शेड्यूल करता है; यदि वही कंपोनेंट बाद में refetch करता है, तो fallback उस कंटेंट के ऊपर फ्लैश हो सकता है जो पहले से ही दिखाई दे रहा है।

Solid इस पूरी प्रक्रिया को उलट देता है। एक promise बस एक ऐसी value है जिस पर reactive graph नज़र रखता है। जब कोई computation उस value को पढ़ता है, तो graph उस read को तब तक रोक देता है जब तक promise resolve न हो जाए, लेकिन बाकी का UI rendered रहता है। पहली बार जब कोई कंपोनेंट mount होता है, तो एक <Loading> boundary fallback दिखा सकती है; उसके बाद, नया डेटा आने तक refetch मौजूदा DOM को बिना छेड़े (untouched) छोड़ देता है। कंपोनेंट के अंदर कोई explicit “await” नहीं, कोई createResource नहीं, और कोई manual state toggles नहीं।

मुख्य primitives

  • <Loading> boundary – React के <Suspense> की जगह लेता है। यह केवल शुरुआती लोड पर ही fallback दिखाता है। पहले paint के बाद, एक pending read UI को रिप्लेस नहीं करता है; जब तक नई value resolve नहीं हो जाती, पुराना कंटेंट बना रहता है। किसी विशिष्ट refetch पर spinner दिखाने के लिए on prop पास करें।
  • <Reveal> component – यह नियंत्रित करता है कि कई <Loading> boundaries एक साथ कैसे दिखाई देती हैं। चुनें:
    • Sequential: boundaries DOM ऑर्डर में एक के बाद एक दिखाई देती हैं।
    • Together: जब डेटा का हर हिस्सा तैयार हो जाता है, तो सभी एक साथ दिखाई देते हैं।
    • Natural: जैसे ही अपना डेटा आता है, प्रत्येक boundary दिखाई देने लगती है।
  • isPending signal – जब कोई विशेष read चल रहा हो, तो यह true लौटाता है। इसका उपयोग मुख्य कंटेंट को दिखाई देने देते हुए एक पतली loading bar या सूक्ष्म (subtle) animation दिखाने के लिए करें, जिससे आपको मुफ्त में “stale-while-revalidate” की सुविधा मिलती है।
  • action generator – React के mutable-state updates की जगह लेता है। एक action(function*…) UI को optimistically अपडेट कर सकता है, सर्वर रिस्पॉन्स का इंतज़ार करने के लिए yield कर सकता है, और फिर promise resolve होने पर परिणाम को reconcile कर सकता है। UI तुरंत (instant) महसूस होता है, और reconciliation स्टेप इस primitive में ही शामिल है।

ये हिस्से React concepts से कैसे मेल खाते हैं

विशेषता React approach Solid 2.0 approach
Data fetching use() (experimental) या third-party hooks; परिणाम <Suspense> में लिपटा हुआ createMemo (या समान) जो एक promise लौटाता है; JSX में सीधे पढ़ें
Loading UI <Suspense> हर refetch पर fallback को फिर से ट्रिगर कर सकता है <Loading> केवल पहले लोड पर; refetch पुराने UI को बनाए रखता है
Refreshing UI अपडेट को टालने के लिए useTransition isPending बिना UI बदले pending reads का संकेत देता है
Mutations useState/useReducer + async calls, अक्सर custom actions में लिपटे हुए built-in optimistic handling के साथ action(function*…)

इसका व्यावहारिक परिणाम यह है कि Solid उन चीज़ों को अपने कोर reactivity engine में ही बना देता है जिन्हें React अलग-अलग hooks के रूप में मानता है।

स्टेप-बाय-स्टेप माइग्रेशन गाइड

  1. डेटा स्रोत की पहचान करें – React में आपके पास संभवतः const data = useMyFetch(url) होगा। Solid में इसे एक memo से बदल दें जो promise लौटाता है: const data = createMemo(() => fetch(url).then(r => r.json()))।
  2. टॉप-लेवल कंपोनेंट को रैप करें – यदि कंपोनेंट promise रिज़ॉल्व होने से पहले रेंडर होता है, तो इसे <Loading fallback={<Spinner/>}>…</Loading> के साथ घेरें। fallback केवल पहली बार माउंट होने पर दिखाई देता है।
  3. प्रति-रीफ़ेच (per-refetch) स्पिनर्स को बदलें – जहाँ आप पहले लोडिंग फ्लैग को टॉगल करते थे, अब isPending(data) पढ़ें। मौजूदा UI को स्क्रीन पर रखते हुए एक सूक्ष्म संकेतक रेंडर करने के लिए उस boolean का उपयोग करें।
  4. ऑप्टिमिस्टिक अपडेट्स को बदलें – यदि आपके पास setState(prev => ({...prev, optimisticValue})) के बाद एक async कॉल था, तो इसे const update = action(function* (newValue) { state = newValue; const server = yield fetch(...); state = reconcile(server); }); के रूप में फिर से लिखें। जनरेटर तब तक कंट्रोल यील्ड (yield) करता है जब तक सर्वर जवाब नहीं देता, फिर स्वचालित रूप से रिएक्टिव ग्राफ को अपडेट करता है।
  5. कई async हिस्सों को संभालें – आवश्यकतानुसार <Loading> बाउंड्रीज़ को नेस्ट करें, फिर यह तय करने के लिए कि वे एक साथ दिखाई दें या एक के बाद एक, एक <Reveal> रैपर जोड़ें। यह उन पैटर्न्स की जगह लेता है जहाँ React डेवलपर्स जटिल स्टेट चेक के साथ कई <Suspense> कंपोनेंट्स को क्रमबद्ध (staggered) करते थे।
  6. फ्लो का परीक्षण करें – क्योंकि Solid promise रिज़ॉल्यूशन पर री-रेंडर नहीं होता है, इसलिए सत्यापित करें कि UI अपडेट अभी भी वहीं हो रहे हैं जहाँ आप उनकी अपेक्षा करते हैं। रिएक्टिव ग्राफ परिवर्तनों को स्वचालित रूप से प्रसारित करता है; अतिरिक्त useEffect कॉल्स की आवश्यकता नहीं है।

अभी क्या परिवर्तनशील है

Solid 2.0 का async API वर्तमान में बीटा में है। स्थिर रिलीज़ से पहले <Loading> और action जैसे नाम बदल सकते हैं, और दस्तावेज़ अभी भी विकसित हो रहे हैं। मूल विचार—promises को reactive values के रूप में मानना—अपरिवर्तित रहता है, लेकिन शुरुआती अपनाने वालों को लाइब्रेरी के स्थिर होने तक मामूली ब्रेकिंग बदलावों की उम्मीद करनी चाहिए।

किसे लाभ होगा

  • भारी डेटा फ़ेचिंग वाली React टीमें – बाहरी स्टेट लाइब्रेरीज़ की कम आवश्यकता और बिल्ट-इन stale-while-revalidate पैटर्न बंडल साइज़ को कम कर सकते हैं और कोडबेस को सरल बना सकते हैं।
  • प्रदर्शन-केंद्रित ऐप्स – हर फ़ेच पर पूर्ण कंपोनेंट री-रेंडर से बचकर, Solid स्मूथ विज़ुअल अपडेट प्रदान करता है, विशेष रूप से लो-एंड डिवाइस पर।
  • "फ्लैश ऑफ स्पिनर" (flash of spinner) से थक चुके डेवलपर्स – <Loading> बाउंड्री का "केवल-पहली-बार-लोड" व्यवहार उस सामान्य परेशानी को खत्म करता है जहाँ पहले से दिखाई दे रहे कंटेंट के ऊपर स्पिनर फ्लैश होता है।

संभावित कमियां

  • बीटा स्थिति – जब तक API स्थिर नहीं हो जाता, दीर्घकालिक परियोजनाओं को बाद में माइग्रेशन प्रयास के लिए बजट रखना पड़ सकता है।

आगे क्या देखें

<Loading> या action के किसी भी रीनेमिंग के लिए आधिकारिक चेंजलॉग पर नज़र रखें।

निष्कर्ष: SolidJS 2.0 आपको promises को फर्स्ट-क्लास रिएक्टिव वैल्यूज़ के रूप में उपयोग करने की अनुमति देता है, जिससे डेटा रिफ्रेश होते समय UI स्थिर रहता है और React-शैली के हुक्स के सेट की आवश्यकता समाप्त हो जाती है। उन टीमों के लिए जो री-रेंडर-केंद्रित मॉडल से आगे बढ़ने के लिए तैयार हैं, माइग्रेशन का रास्ता स्पष्ट है, प्रदर्शन का लाभ प्रत्यक्ष है, और एकमात्र वास्तविक जोखिम सामान्य बीटा-चरण की अनिश्चितता है।