SolidJS 2.0 ਇੱਕ native async-data ਮਾਡਲ ਦੇ ਨਾਲ ਆਉਂਦਾ ਹੈ ਜੋ ਇੱਕ component ਨੂੰ promise ਨੂੰ ਕਿਸੇ ਵੀ ਹੋਰ reactive value ਵਾਂਗ ਵਰਤਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਉਹਨਾਂ re-renders ਦੀ ਲੜੀ ਤੋਂ ਬਿਨਾਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ React developers Suspense ਅਤੇ hooks ਦੇ ਨਾਲ ਦੇਖਦੇ ਹਨ। ਇਹ ਤਬਦੀਲੀ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਹ data refresh ਹੋਣ ਵੇਲੇ UI ਨੂੰ ਸਕ੍ਰੀਨ 'ਤੇ ਰੱਖਦੀ ਹੈ, boilerplate ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ, ਅਤੇ React teams ਲਈ ਆਪਣੇ data-fetching code ਨੂੰ Solid ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਲਈ ਇੱਕ ਸਪੱਸ਼ਟ ਰਸਤਾ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ।

ਕਿਉਂ Solid ਦਾ async ਮਾਡਲ ਵੱਖਰਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ

React ਵਿੱਚ, ਇੱਕ component ਜਿਸਨੂੰ data ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ hook (ਅਕਸਰ ਇੱਕ custom hook) ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ ਜੋ ਇੱਕ promise-like object ਵਾਪਸ ਕਰਦਾ ਹੈ, ਫਿਰ promise resolve ਹੋਣ ਤੱਕ fallback ਦਿਖਾਉਣ ਲਈ UI ਨੂੰ <Suspense> ਵਿੱਚ ਲਪੇਟਦਾ ਹੈ। ਹਰ ਵਾਰ ਜਦੋਂ promise settle ਹੁੰਦਾ ਹੈ, React ਇੱਕ re-render schedule ਕਰਦਾ ਹੈ; ਜੇਕਰ ਉਹੀ component ਬਾਅਦ ਵਿੱਚ refetch ਕਰਦਾ ਹੈ, ਤਾਂ fallback ਉਸ content ਦੇ ਉੱਪਰ ਫਲੈਸ਼ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਦਿਖਾਈ ਦੇ ਰਿਹਾ ਹੈ।

Solid ਇਸ ਸਥਿਤੀ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਇੱਕ promise ਸਿਰਫ਼ ਇੱਕ value ਹੈ ਜਿਸ 'ਤੇ reactive graph ਨਜ਼ਰ ਰੱਖਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ computation ਉਸ value ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ, ਤਾਂ graph ਉਸ ਪੜ੍ਹਨ (read) ਨੂੰ ਉਦੋਂ ਤੱਕ ਰੋਕ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ promise resolve ਨਹੀਂ ਹੋ ਜਾਂਦਾ, ਪਰ ਬਾਕੀ UI rendered ਰਹਿੰਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ component ਪਹਿਲੀ ਵਾਰ mount ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇੱਕ <Loading> boundary fallback ਦਿਖਾ ਸਕਦੀ ਹੈ; ਉਸ ਤੋਂ ਬਾਅਦ, ਇੱਕ refetch ਨਵੇਂ data ਦੇ ਆਉਣ ਤੱਕ ਮੌਜੂਦਾ DOM ਨੂੰ ਅਣਛੂਹਿਆ ਰੱਖਦਾ ਹੈ। Component ਦੇ ਅੰਦਰ ਕੋਈ explicit “await” ਨਹੀਂ, ਕੋਈ createResource ਨਹੀਂ, ਅਤੇ ਕੋਈ manual state toggles ਨਹੀਂ।

ਮੁੱਖ primitives

  • <Loading> boundary – React ਦੇ <Suspense> ਦੀ ਜਗ੍ਹਾ ਲੈਂਦਾ ਹੈ। ਇਹ ਸਿਰਫ਼ ਸ਼ੁਰੂਆਤੀ load 'ਤੇ fallback ਦਿਖਾਉਂਦਾ ਹੈ। ਪਹਿਲੀ paint ਤੋਂ ਬਾਅਦ, ਇੱਕ pending read UI ਨੂੰ ਬਦਲਦਾ ਨਹੀਂ ਹੈ; ਨਵੀਂ value resolve ਹੋਣ ਤੱਕ ਪੁਰਾਣਾ content ਬਣਿਆ ਰਹਿੰਦਾ ਹੈ। ਕਿਸੇ ਖਾਸ refetch 'ਤੇ spinner ਦਿਖਾਉਣ ਲਈ on prop pass ਕਰੋ।
  • <Reveal> component – ਇਹ ਕੰਟਰੋਲ ਕਰਦਾ ਹੈ ਕਿ ਕਈ <Loading> boundaries ਇਕੱਠੀਆਂ ਕਿਵੇਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ। ਚੁਣੋ:
    • Sequential: boundaries DOM order ਵਿੱਚ ਇੱਕ ਤੋਂ ਬਾਅਦ ਇੱਕ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ।
    • Together: ਜਦੋਂ ਹਰ piece of data ਤਿਆਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਾਰੀਆਂ ਇਕੱਠੀਆਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ।
    • Natural: ਹਰ ਇੱਕ ਉਦੋਂ ਹੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ ਜਦੋਂ ਉਸਦਾ ਆਪਣਾ data ਆ ਜਾਂਦਾ ਹੈ।
  • isPending signal – ਜਦੋਂ ਕੋਈ ਖਾਸ read ਚੱਲ ਰਿਹਾ ਹੁੰਦਾ ਹੈ ਤਾਂ true ਵਾਪਸ ਕਰਦਾ ਹੈ। ਇਸਦੀ ਵਰਤੋਂ ਮੁੱਖ content ਦਿਖਾਈ ਦੇਣ ਵੇਲੇ ਇੱਕ ਪਤਲੀ loading bar ਜਾਂ ਸੂਖਮ (subtle) animation ਦਿਖਾਉਣ ਲਈ ਕਰੋ, ਜੋ ਤੁਹਾਨੂੰ ਮੁਫ਼ਤ ਵਿੱਚ “stale-while-revalidate” ਦੀ ਸਹੂਲਤ ਦਿੰਦਾ ਹੈ।
  • action generator – React ਦੇ mutable-state updates ਦੀ ਜਗ੍ਹਾ ਲੈਂਦਾ ਹੈ। ਇੱਕ action(function*…) UI ਨੂੰ optimistically update ਕਰ ਸਕਦਾ ਹੈ, server response ਦੀ ਉਡੀਕ ਕਰਨ ਲਈ yield ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਫਿਰ promise resolve ਹੋਣ 'ਤੇ result ਨੂੰ reconcile ਕਰ ਸਕਦਾ ਹੈ। UI ਤੁਰੰਤ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਅਤੇ reconciliation step ਇਸ primitive ਵਿੱਚ ਹੀ ਸ਼ਾਮਲ ਹੈ।

ਇਹ ਹਿੱਸੇ React concepts ਨਾਲ ਕਿਵੇਂ ਮੇਲ ਖਾਂਦੇ ਹਨ

Feature React approach Solid 2.0 approach
Data fetching use() (experimental) ਜਾਂ third-party hooks; result <Suspense> ਵਿੱਚ ਲਪੇਟਿਆ ਹੁੰਦਾ ਹੈ createMemo (ਜਾਂ ਸਮਾਨ) ਜੋ ਇੱਕ promise ਵਾਪਸ ਕਰਦਾ ਹੈ; JSX ਵਿੱਚ ਸਿੱਧਾ ਪੜ੍ਹੋ
Loading UI <Suspense> ਹਰ refetch 'ਤੇ fallback ਨੂੰ ਦੁਬਾਰਾ trigger ਕਰ ਸਕਦਾ ਹੈ <Loading> ਸਿਰਫ਼ ਪਹਿਲੇ load 'ਤੇ; refetch ਪੁਰਾਣਾ UI ਬਣਾਈ ਰੱਖਦਾ ਹੈ
Refreshing UI updates ਨੂੰ ਮੁਲਤਵੀ ਕਰਨ ਲਈ useTransition isPending UI ਬਦਲੇ ਬਿਨਾਂ pending reads ਦੇ ਸੰਕੇਤ ਦਿੰਦਾ ਹੈ
Mutations useState/useReducer + async calls, ਅਕਸਰ custom actions ਵਿੱਚ ਲਪੇਟੇ ਹੋਏ built-in optimistic handling ਦੇ ਨਾਲ action(function*…)

ਇਸਦਾ ਵਿਵਹਾਰਕ ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ Solid ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਨੂੰ core reactivity engine ਵਿੱਚ ਬਣਾਉਂਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ React ਵੱਖਰੇ hooks ਵਜੋਂ ਮੰਨਦਾ ਹੈ।

ਇੱਕ ਸਟੈਪ-ਬਾਈ-ਸਟੈਪ ਮਾਈਗ੍ਰੇਸ਼ਨ ਗਾਈਡ

  1. ਡਾਟਾ ਸਰੋਤ ਦੀ ਪਛਾਣ ਕਰੋ – React ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਲ ਸ਼ਾਇਦ const data = useMyFetch(url) ਹੋਵੇਗਾ। Solid ਵਿੱਚ ਇਸਨੂੰ ਇੱਕ memo ਨਾਲ ਬਦਲ ਦਿਓ ਜੋ promise ਨੂੰ ਰਿਟਰਨ ਕਰਦਾ ਹੈ: const data = createMemo(() => fetch(url).then(r => r.json()))।
  2. ਟੌਪ-ਲੈਵਲ ਕੰਪੋਨੈਂਟ ਨੂੰ ਵੈਪ (wrap) ਕਰੋ – ਜੇਕਰ ਕੰਪੋਨੈਂਟ promise ਰੈਜ਼ੋਲਵ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਰੈਂਡਰ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ <Loading fallback={<Spinner/>}>…</Loading> ਨਾਲ ਘੇਰ ਦਿਓ। Fallback ਸਿਰਫ਼ ਪਹਿਲੀ ਵਾਰ ਮਾਊਂਟ ਹੋਣ 'ਤੇ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।
  3. ਪ੍ਰਤੀ-ਰੀ-ਫੈਚ (per-refetch) ਸਪਿਨਰਾਂ ਨੂੰ ਬਦਲੋ – ਜਿੱਥੇ ਤੁਸੀਂ ਪਹਿਲਾਂ loading flag ਨੂੰ ਟੌਗਲ ਕਰਦੇ ਸੀ, ਹੁਣ isPending(data) ਪੜ੍ਹੋ। ਮੌਜੂਦਾ UI ਸਕ੍ਰੀਨ 'ਤੇ ਰਹਿਣ ਦੌਰਾਨ ਇੱਕ ਸੂਖਮ (subtle) ਇੰਡੀਕੇਟਰ ਦਿਖਾਉਣ ਲਈ ਉਸ ਬੂਲੀਅਨ (boolean) ਦੀ ਵਰਤੋਂ ਕਰੋ।
  4. Optimistic updates ਨੂੰ ਬਦਲੋ – ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ setState(prev => ({...prev, optimisticValue})) ਸੀ ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਇੱਕ async ਕਾਲ ਸੀ, ਤਾਂ ਇਸਨੂੰ const update = action(function* (newValue) { state = newValue; const server = yield fetch(...); state = reconcile(server); }); ਵਜੋਂ ਲਿਖੋ। ਜਨਰੇਟਰ (generator) ਉਦੋਂ ਤੱਕ ਕੰਟਰੋਲ ਰਿਲੀਜ਼ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਸਰਵਰ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ, ਫਿਰ ਆਪਣੇ ਆਪ ਰੀਐਕਟਿਵ ਗ੍ਰਾਫ (reactive graph) ਨੂੰ ਅਪਡੇਟ ਕਰ ਦਿੰਦਾ ਹੈ।
  5. ਕਈ async ਹਿੱਸਿਆਂ ਨੂੰ ਸੰਭਾਲੋ – ਲੋੜ ਅਨੁਸਾਰ <Loading> boundaries ਨੂੰ ਨੇਸਟ (nest) ਕਰੋ, ਫਿਰ ਇਹ ਫੈਸਲਾ ਕਰਨ ਲਈ ਕਿ ਉਹ ਇਕੱਠੇ ਦਿਖਣਗੇ ਜਾਂ ਇੱਕ ਤੋਂ ਬਾਅਦ ਇੱਕ, ਇੱਕ <Reveal> ਵੈਪਰ (wrapper) ਜੋੜੋ। ਇਹ ਉਹਨਾਂ ਪੈਟਰਨਾਂ ਦੀ ਜਗ੍ਹਾ ਲੈਂਦਾ ਹੈ ਜਿੱਥੇ React ਡਿਵੈਲਪਰ ਗੁੰਝਲਦਾਰ ਸਟੇਟ ਚੈੱਕਾਂ ਨਾਲ ਕਈ <Suspense> ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਕਤਾਰਵਾਰ ਵਰਤਦੇ ਸਨ।
  6. ਫਲੋ (flow) ਦੀ ਜਾਂਚ ਕਰੋ – ਕਿਉਂਕਿ Solid promise ਰੈਜ਼ੋਲਵ ਹੋਣ 'ਤੇ re-render ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਲਈ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ UI ਅਪਡੇਟ ਅਜੇ ਵੀ ਉੱਥੇ ਹੋ ਰਹੇ ਹਨ ਜਿੱਥੇ ਤੁਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹੋ। ਰੀਐਕਟਿਵ ਗ੍ਰਾਫ ਆਪਣੇ ਆਪ ਤਬਦੀਲੀਆਂ ਨੂੰ ਫੈਲਾਉਂਦਾ ਹੈ; ਵਾਧੂ useEffect ਕਾਲਾਂ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ।

ਕੀ ਅਜੇ ਵੀ ਬਦਲਾਅ ਦੇ ਅਧੀਨ ਹੈ

Solid 2.0 ਦੀ async API ਇਸ ਸਮੇਂ ਬੀਟਾ (beta) ਵਿੱਚ ਹੈ। ਸਥਿਰ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ <Loading> ਅਤੇ action ਵਰਗੇ ਨਾਮ ਬਦਲ ਸਕਦੇ ਹਨ, ਅਤੇ ਦਸਤਾਵੇਜ਼ (documentation) ਅਜੇ ਵੀ ਵਿਕਸਿਤ ਹੋ ਰਿਹਾ ਹੈ। ਮੁੱਖ ਵਿਚਾਰ—promises ਨੂੰ reactive values ਵਜੋਂ ਮੰਨਣਾ—ਬਦਲਿਆ ਨਹੀਂ ਹੈ, ਪਰ ਸ਼ੁਰੂਆਤੀ ਅਪਣਾਉਣ ਵਾਲਿਆਂ ਨੂੰ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਸਥਿਰ ਹੋਣ ਤੱਕ ਛੋਟੇ ਬ੍ਰੇਕਿੰਗ ਚੇਂਜਸ (breaking changes) ਦੀ ਉਮੀਦ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ।

ਕਿਸ ਨੂੰ ਫਾਇਦਾ ਹੋਵੇਗਾ

  • ਭਾਰੀ ਡਾਟਾ ਫੈਚਿੰਗ ਵਾਲੀਆਂ React ਟੀਮਾਂ – ਬਾਹਰੀ ਸਟੇਟ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਘਟਦੀ ਲੋੜ ਅਤੇ ਇਨ-ਬਿਲਟ stale-while-revalidate ਪੈਟਰਨ ਬੰਡਲ ਸਾਈਜ਼ ਨੂੰ ਘਟਾ ਸਕਦੇ ਹਨ ਅਤੇ ਕੋਡਬੇਸ ਨੂੰ ਸਰਲ ਬਣਾ ਸਕਦੇ ਹਨ।
  • ਪਰਫਾਰਮੈਂਸ-ਕੇਂਦਰਿਤ ਐਪਸ – ਹਰ ਫੈਚ 'ਤੇ ਪੂਰੇ ਕੰਪੋਨੈਂਟ re-renders ਤੋਂ ਬਚ ਕੇ, Solid ਵਧੇਰੇ ਸੁਚਾਰੂ ਵਿਜ਼ੂਅਲ ਅਪਡੇਟਸ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਘੱਟ-ਐਂਡ (low-end) ਡਿਵਾਈਸਾਂ 'ਤੇ।
  • "flash of spinner" ਤੋਂ ਥੱਕੇ ਹੋਏ ਡਿਵੈਲਪਰ – <Loading> boundary ਦਾ "first-load-only" ਵਿਵਹਾਰ ਉਸ ਆਮ ਪਰੇਸ਼ਾਨੀ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ ਜਿੱਥੇ ਕੰਟੈਂਟ ਦੇ ਉੱਪਰ ਸਪਿਨਰ ਚਮਕਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਦਿਖਾਈ ਦੇ ਰਿਹਾ ਹੈ।

ਸੰਭਾਵੀ ਨੁਕਸਾਨ

  • ਬੀਟਾ ਸਟੇਟਸ – ਜਦੋਂ ਤੱਕ API ਸਥਿਰ ਨਹੀਂ ਹੋ ਜਾਂਦੀ, ਲੰਬੇ ਸਮੇਂ ਦੇ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਮਾਈਗ੍ਰੇਸ਼ਨ (migration) ਦੀ ਕੋਸ਼ਿਸ਼ ਲਈ ਬਜਟ ਰੱਖਣ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।

ਅੱਗੇ ਕੀ ਦੇ