SolidJS 2.0 ஒரு இயல்பான (native) async-data மாதிரியுடன் வருகிறது. இது ஒரு component-ஐ ஒரு promise-ஐ மற்ற reactive மதிப்புகளைப் போலவே கையாள அனுமதிக்கிறது; மேலும் React டெவலப்பர்கள் Suspense மற்றும் hooks மூலம் சந்திக்கும் தொடர்ச்சியான re-renders சிக்கல் இன்றி இது செயல்படுகிறது. தரவுகள் புதுப்பிக்கப்படும்போது (refreshes) UI திரையில் இருப்பதை உறுதி செய்வதால், boilerplate குறியீடுகளைக் குறைப்பதன் மூலமும், React குழுக்கள் தங்கள் data-fetching குறியீடுகளை எளிதாக Solid-க்கு மாற்ற வழிவகை செய்வதன் மூலமும் இந்த மாற்றம் முக்கியத்துவம் பெறுகிறது.

ஏன் Solid-ன் async மாதிரி வித்தியாசமாகத் தோன்றுகிறது

React-இல், தரவு தேவைப்படும் ஒரு component பொதுவாக ஒரு hook-ஐ (பெரும்பாலும் ஒரு custom hook) அழைக்கும், அது ஒரு promise போன்ற பொருளைத் தரும்; பின்னர் அந்த promise தீரும் வரை ஒரு fallback-ஐக் காட்ட UI-ஐ <Suspense> மூலம் சுற்றியிருக்கும். ஒவ்வொரு முறை promise முடிவடையும் போதும், React ஒரு re-render-ஐத் திட்டமிடுகிறது; அதே component பின்னர் மீண்டும் தரவை எடுத்தால் (refetch), ஏற்கனவே திரையில் தெரியும் உள்ளடக்கத்தின் மேல் fallback மின்னக்கூடும் (flash).

Solid இந்த முறையை மாற்றுகிறது. ஒரு promise என்பது reactive graph கண்காணிக்கும் ஒரு மதிப்பு மட்டுமே. ஒரு கணக்கீடு (computation) அந்த மதிப்பை வாசிக்கும்போது, promise தீரும் வரை graph அந்த வாசிப்பை நிறுத்தி வைக்கும், ஆனால் மீதமுள்ள UI திரையில் அப்படியே இருக்கும். ஒரு component முதன்முதலில் mount ஆகும்போது, ஒரு <Loading> boundary ஒரு fallback-ஐக் காட்டலாம்; அதன் பிறகு, புதிய தரவு வரும் வரை ஒரு refetch ஏற்கனவே உள்ள DOM-ஐ மாற்றாமல் அப்படியே வைத்திருக்கும். Component-க்குள் வெளிப்படையான “await” தேவையில்லை, createResource தேவையில்லை, மற்றும் கைமுறையாக state-ஐ மாற்ற வேண்டிய அவசியமும் இல்லை.

முக்கிய primitives

  • <Loading> boundary – React-ன் <Suspense>-க்கு மாற்றாக இது செயல்படுகிறது. இது ஆரம்பக்கட்ட லோடிங்கின் போது (initial load) மட்டுமே fallback-ஐக் காட்டும். முதல் முறை திரையில் தோன்றும் (first paint) பிறகு, ஒரு pending read UI-ஐ மாற்றாது; புதிய மதிப்பு கிடைக்கும் வரை பழைய உள்ளடக்கமே இருக்கும். ஒரு குறிப்பிட்ட refetch-ன் போது spinner-ஐக் காட்ட on prop-ஐப் பயன்படுத்தலாம்.
  • <Reveal> component – பல <Loading> boundaries எவ்வாறு ஒன்றாகத் தோன்ற வேண்டும் என்பதைக் கட்டுப்படுத்துகிறது. இதில் கீழ்க்கண்டவற்றைத் தேர்ந்தெடுக்கலாம்:
    • Sequential: boundaries DOM வரிசைப்படி ஒன்றன்பின் ஒன்றாகத் தோன்றும்.
    • Together: அனைத்துத் தரவுகளும் தயாரானதும் அனைத்தும் ஒரே நேரத்தில் தோன்றும்.
    • Natural: ஒவ்வொரு தரவும் வந்தவுடன் அது தனித்தனியாகத் தோன்றும்.
  • isPending signal – ஒரு குறிப்பிட்ட தரவு வாசிக்கப்படும்போது (read in flight) true என்பதைத் தரும். முக்கிய உள்ளடக்கத்தை திரையில் வைத்திருக்கும்போதே, ஒரு மெல்லிய loading bar அல்லது சிறிய அனிமேஷனைத் திரையில் காட்ட இதைப் பயன்படுத்தலாம்; இது உங்களுக்கு "stale-while-revalidate" வசதியை இலவசமாக வழங்குகிறது.
  • action generator – React-ன் mutable-state updates-க்கு மாற்றாக இது வருகிறது. ஒரு action(function*…) UI-ஐ optimistically update செய்யவும், சர்வர் பதிலுக்காக yield மூலம் காத்திருக்கவும், பின்னர் promise தீரும்போது முடிவைச் சரிசெய்யவும் (reconcile) உதவும். UI உடனடியாகச் செயல்படுவது போன்ற உணவைத் தரும், மேலும் இந்த reconciliation படிநிலை இந்த primitive-லேயே இணைக்கப்பட்டுள்ளது.

இந்த அம்சங்கள் React கருத்துகளுடன் எவ்வாறு ஒத்துப் போகின்றன

அம்சம் React அணுகுமுறை Solid 2.0 அணுகுமுறை
Data fetching use() (experimental) அல்லது மூன்றாம் தரப்பு hooks; முடிவு <Suspense> மூலம் சுற்றப்பட்டிருக்கும் ஒரு promise-ஐத் தரும் createMemo (அல்லது அது போன்ற ஒன்று); JSX-இல் நேரடியாக வாசிக்கலாம்
Loading UI ஒவ்வொரு refetch-ன் போதும் <Suspense> மீண்டும் fallback-ஐத் தூண்டலாம் <Loading> முதல் லோடிங்கில் மட்டுமே; refetch பழைய UI-ஐ அப்படியே வைத்திருக்கும்
Refreshing UI புதுப்பிப்புகளைத் தள்ளிப்போட useTransition UI மாற்றமின்றி isPending நிலுவையில் உள்ள வாசிப்புகளைக் குறிக்கும்
Mutations useState/useReducer + async அழைப்புகள், பெரும்பாலும் custom actions மூலம் சுற்றப்பட்டிருக்கும் உள்ளமைக்கப்பட்ட optimistic handling வசதியுடன் கூடிய action(function*…)

இதன் நடைமுறைப் பயன் என்னவென்றால், React தனித்தனி hooks ஆகக் கருதும் அம்சங்களை Solid தனது மையமான reactivity engine-லேயே கட்டமைத்துள்ளது.

படிப் படியாக மாற்றும் வழிகாட்டி (A step-by-step migration guide)

  1. தரவு மூலத்தைக் கண்டறியவும் – React-இல் நீங்கள் பெரும்பாலும் const data = useMyFetch(url) என்பதைப் பயன்படுத்துவீர்கள். Solid-இல் அதை ஒரு memo மூலம் மாற்றவும்: const data = createMemo(() => fetch(url).then(r => r.json())).
  2. மேல்நிலைத் தொகுதியை (top-level component) சுற்றவும் – promise தீரத் தொடங்கும் முன் component render செய்யப்பட்டால், அதை <Loading fallback={<Spinner/>}>…</Loading> கொண்டு சுற்றவும். fallback முதல் முறை mount செய்யப்படும்போது மட்டுமே தோன்றும்.
  3. ஒவ்வொரு முறை தரவை மீண்டும் எடுக்கும்போதும் (refetch) தோன்றும் spinners-களை மாற்றவும் – முன்பு நீங்கள் ஒரு loading flag-ஐ மாற்றிய இடத்தில், இப்போது isPending(data) என்பதைப் படிக்கவும். தற்போதுள்ள UI திரையில் இருக்கும்போதே, ஒரு சிறிய குறிகாட்டியை (subtle indicator) காட்ட அந்த boolean-ஐப் பயன்படுத்தவும்.
  4. optimistic updates-களை மாற்றவும் – நீங்கள் setState(prev => ({...prev, optimisticValue})) மற்றும் அதைத் தொடர்ந்து ஒரு async call பயன்படுத்தியிருந்தால், அதை const update = action(function* (newValue) { state = newValue; const server = yield fetch(...); state = reconcile(server); }); என மாற்றியமைக்கவும். server பதிலளிக்கும் வரை generator கட்டுப்பாட்டைத் தந்துவிட்டு, பின்னர் தானாகவே reactive graph-ஐப் புதுப்பிக்கும்.
  5. பல async பகுதிகளைக் கையாளவும் – தேவைக்கேற்ப <Loading> boundaries-களை ஒன்றன் கீழ் ஒன்றாக (nest) அமைக்கவும், பின்னர் அவை ஒன்றாகத் தோன்ற வேண்டுமா அல்லது ஒவ்வொன்றாகத் தோன்ற வேண்டுமா என்பதைத் தீர்மானிக்க <Reveal> wrapper-ஐச் சேர்க்கவும். React டெவலப்பர்கள் சிக்கலான state சோதனைகளுடன் பல <Suspense> components-களை வரிசைப்படுத்திய முறையை இது மாற்றுகிறது.
  6. ஓட்டத்தைப் (flow) பரிசோதிக்கவும் – promise தீரும்போது Solid மீண்டும் render செய்யாததால், நீங்கள் எதிர்பார்க்கும் இடங்களில் UI புதுப்பிப்புகள் நடக்கின்றனவா என்பதைச் சரிபார்க்கவும். reactive graph தானாகவே மாற்றங்களைப் பரப்புகிறது; கூடுதல் useEffect அழைப்புகள் தேவையில்லை.

இன்னும் மாற்றமடைந்து கொண்டிருப்பவை

Solid 2.0-ன் async API தற்போது beta நிலையில் உள்ளது. நிலையான வெளியீடு (stable release) வரும் முன் <Loading> மற்றும் action போன்ற பெயர்கள் மாறக்கூடும், மேலும் ஆவணங்கள் (documentation) இன்னும் வளர்ச்சியடைந்து வருகின்றன. promises-களை reactive values-களாகக் கருதுவது என்ற அடிப்படை யோசனை மாறவில்லை, ஆனால் library நிலைபெறும் போது ஆரம்பகாலப் பயனர்கள் சிறிய breaking changes-களை எதிர்பார்க்கலாம்.

யாருக்குப் பயன் கிடைக்கும்

  • அதிகப்படியான data fetching கொண்ட React குழுக்கள் – வெளிப்புற state libraries-களுக்கான தேவை குறைவதாலும், உள்ளமைக்கப்பட்ட stale-while-revalidate pattern இருப்பதாலும், bundle size குறைக்கப்பட்டு codebase எளிமையாக்கப்படலாம்.
  • செயல்திறன் சார்ந்த செயலிகள் (Performance-focused apps) – ஒவ்வொரு fetch செய்யும் போதும் முழு component-ஐயும் மீண்டும் render செய்வதைத் தவிர்ப்பதன் மூலம், Solid மென்மையான காட்சிப் புதுப்பிப்புகளை (visual updates) வழங்குகிறது, குறிப்பாகக் குறைந்த திறன் கொண்ட சாதனங்களில்.
  • “flash of spinner” என்பதால் சலிப்படைந்த டெவலப்பர்கள்<Loading> boundary-ன் “first-load-only” பண்பு, ஏற்கனவே திரையில் தெரியும் உள்ளடக்கத்தின் மேல் spinner தோன்றும் பொதுவான எரிச்சலைத் தவிர்க்கிறது.

சாத்தியமான குறைபாடுகள்

  • Beta நிலை – API நிலைபெறும் வரை, நீண்ட காலத் திட்டங்களுக்குப் பின்னர் இடமாற்றப் பணிக்காக (migration effort)த் திட்டமிட வேண்டியிருக்கலாம்.

அடுத்து கவனிக்க வேண்டியவை

<Loading> அல்லது action ஆகியவற்றின் பெயர் மாற்றங்களைக் கண்காணிக்க அதிகாரப்பூர்வ changelog-ஐப் பார்க்கவும்.

சுருக்கமாகச் சொன்னால்: SolidJS 2.0, promises-களை முதன்மையான reactive values-களாகக் கையாள அனுமதிக்கிறது, இது தரவு புதுப்பிக்கப்படும்போது UI-ஐ நிலையாக வைத்திருக்க உதவுகிறது மற்றும் React-style hooks தொகுப்பின் தேவையை நீக்குகிறது. re-render-centric மாதிரியிலிருந்து வெளியேறத் தயாராக இருக்கும் குழுக்களுக்கு, இடமாற்றப் பாதை தெளிவாக உள்ளது, செயல்திறன் பலன் புலனாகக் கிடைக்கிறது, மேலும் உண்மையான ஆபத்து என்பது வழக்கமான beta-நிலை நிச்சயமற்ற தன்மை மட்டுமே.