SolidJS 2.0 એક નેટિવ async-data મોડેલ સાથે આવે છે જે એક કમ્પોનન્ટને પ્રોમિસને અન્ય કોઈપણ રિએક્ટિવ વેલ્યુની જેમ ગણવાની મંજૂરી આપે છે, અને તે React ડેવલપર્સ દ્વારા Suspense અને hooks સાથે જોવામાં આવતા re-renders ના કેસ્કેડ વગર આ કાર્ય કરે છે. આ ફેરફાર મહત્વનો છે કારણ કે તે ડેટા રિફ્રેશ થતી વખતે UI ને સ્ક્રીન પર જાળવી રાખે છે, બોઈલરપ્લેટ ઘટાડે છે, અને React ટીમો માટે તેમના ડેટા-ફેચિંગ કોડને Solid પર સ્થાનાંતરિત કરવા માટે એક નક્કર માર્ગ પ્રદાન કરે છે.
Solid નું async મોડેલ અલગ કેમ લાગે છે
React માં, ડેટાની જરૂર હોય તેવા કમ્પોનન્ટ સામાન્ય રીતે એક hook (મોટે ભાગે કસ્ટમ) ને કોલ કરે છે જે promise જેવી ઓબ્જેક્ટ રિટર્ન કરે છે, અને પછી પ્રોમિસ રિઝોલ્વ થાય ત્યાં સુધી fallback બતાવવા માટે UI ને <Suspense> માં લપેટી દે છે. જ્યારે પણ પ્રોમિસ સેટલ થાય છે, ત્યારે React re-render શેડ્યૂલ કરે છે; જો તે જ કમ્પોનન્ટ પછીથી રિફેચ કરે છે, તો જે કન્ટેન્ટ પહેલેથી જ દેખાઈ રહ્યું છે તેની ઉપર fallback ફ્લેશ થઈ શકે છે.
Solid આ પદ્ધતિને બદલી નાખે છે. પ્રોમિસ એ માત્ર એક વેલ્યુ છે જેના પર રિએક્ટિવ ગ્રાફ (reactive graph) નજર રાખે છે. જ્યારે કોઈ કમ્પ્યુટેશન તે વેલ્યુ વાંચે છે, ત્યારે ગ્રાફ પ્રોમિસ રિઝોલ્વ ન થાય ત્યાં સુધી તે રીડ (read) ને અટકાવી દે છે, પરંતુ બાકીનું UI રેન્ડર થયેલું રહે છે. જ્યારે કમ્પોનન્ટ પહેલીવાર માઉન્ટ થાય છે, ત્યારે <Loading> બાઉન્ડ્રી એક fallback બતાવી શકે છે; તે પછી, નવો ડેટા આવે ત્યાં સુધી રિફેચ કરવાથી હાલનું DOM અસ્પૃશ્ય રહે છે. કમ્પોનન્ટની અંદર કોઈ સ્પષ્ટ “await” નથી, createResource નથી, અને કોઈ મેન્યુઅલ સ્ટેટ ટોગલ્સ નથી.
મુખ્ય પ્રિમીટિવ્સ
<Loading>boundary – React ના<Suspense>ને રિપ્લેસ કરે છે. તે ફક્ત શરૂઆતના લોડ પર જ fallback બતાવે છે. પ્રથમ પેઇન્ટ પછી, પેન્ડિંગ રીડ UI ને બદલતું નથી; જ્યાં સુધી નવી વેલ્યુ રિઝોલ્વ ન થાય ત્યાં સુધી જૂનું કન્ટેન્ટ રહે છે. ચોક્કસ રિફેચ પર સ્પિનર બતાવવા માટેonપ્રોપ પસાર કરો.<Reveal>component – એકસાથે અનેક<Loading>બાઉન્ડ્રીઝ કેવી રીતે દેખાય છે તેનું નિયંત્રણ કરે છે. પસંદ કરો:- Sequential: બાઉન્ડ્રીઝ DOM ક્રમમાં એક પછી એક દેખાય છે.
- Together: જ્યારે ડેટાનો દરેક ભાગ તૈયાર હોય ત્યારે બધું એકસાથે દેખાય છે.
- Natural: જેવી પોતાની ડેટા મળે કે તરત જ દરેક દેખાય છે.
isPendingsignal – જ્યારે કોઈ ચોક્કસ રીડ ચાલુ હોય ત્યારેtrueરિટર્ન કરે છે. મુખ્ય કન્ટેન્ટ દેખાતું રહે તે દરમિયાન પાતળી લોડિંગ બાર અથવા સૂક્ષ્મ એનિમેશન ઓવરલે કરવા માટે તેનો ઉપયોગ કરો, જે તમને મફતમાં “stale-while-revalidate” સુવિધા આપે છે.actiongenerator – React ના મ્યુટેબલ-સ્ટેટ અપડેટ્સને રિપ્લેસ કરે છે. એકaction(function*…)UI ને ઓપ્ટિમિસ્ટિકલી અપડેટ કરી શકે છે, સર્વરના પ્રતિસાદની રાહ જોવા માટેyieldકરી શકે છે, અને પ્રોમિસ રિઝોલ્વ થાય ત્યારે પરિણામનું રિસિલિયેશન (reconciliation) કરી શકે છે. UI ત્વરિત લાગે છે, અને રિસિલિયેશન સ્ટેપ પ્રિમીટિવમાં જ સામેલ હોય છે.
આ ભાગો React કન્સેપ્ટ્સ સાથે કેવી રીતે મેપ થાય છે
| ફીચર | React અભિગમ | Solid 2.0 અભિગમ |
|---|---|---|
| ડેટા ફેચિંગ | use() (experimental) અથવા થર્ડ-પાર્ટી hooks; પરિણામ <Suspense> માં લપેટીને આવે છે |
createMemo (અથવા સમાન) જે પ્રોમિસ રિટર્ન કરે છે; JSX માં સીધું જ વાંચો |
| લોડિંગ UI | <Suspense> દરેક રિફેચ પર fallback ફરીથી ટ્રિગર કરી શકે છે |
<Loading> ફક્ત પ્રથમ લોડ પર; રિફેચ જૂનું UI જાળવી રાખે છે |
| રિફ્રેશિંગ | UI અપડેટ્સ મોકૂફ રાખવા માટે useTransition |
isPending UI બદલ્યા વગર પેન્ડિંગ રીડ્સના સંકેત આપે છે |
| મ્યુટેશન | useState/useReducer + async કોલ્સ, જે ઘણીવાર કસ્ટમ એક્શનમાં લપેટીને આવે છે |
બિલ્ટ-ઇન ઓપ્ટિમિસ્ટિક હેન્ડલિંગ સાથે action(function*…) |
વ્યવહારિક પરિણામ એ છે કે Solid એ વસ્તુઓને જે React અલગ hooks તરીકે ગણે છે, તેને તેના મુખ્ય રિએક્ટિવિટી એન્જિનમાં જ સામેલ કરે છે.
સ્ટેપ-બાય-સ્ટેપ માઈગ્રેશન ગાઈડ
- ડેટા સ્ત્રોત ઓળખો – React માં તમારી પાસે કદાચ
const data = useMyFetch(url)હશે. Solid માં તેને એવા memo થી બદલો જે promise રિટર્ન કરે:const data = createMemo(() => fetch(url).then(r => r.json())). - ટોપ-લેવલ કોમ્પોનન્ટને રેપ (wrap) કરો – જો promise રિઝોલ્વ થાય તે પહેલાં કોમ્પોનન્ટ રેન્ડર થાય છે, તો તેને
<Loading fallback={<Spinner/>}>…</Loading>થી ઘેરી લો. fallback ફક્ત પ્રથમ માઉન્ટ વખતે જ દેખાય છે. - દરેક રિ-ફેચ સ્પિનર્સને બદલો – જ્યાં તમે અગાઉ loading flag ને ટોગલ કરતા હતા, ત્યાં હવે
isPending(data)વાંચો. હાલનું UI સ્ક્રીન પર રહે તે દરમિયાન સૂક્ષ્મ ઇન્ડિકેટર રેન્ડર કરવા માટે તે બુલિયનનો ઉપયોગ કરો. - ઓપ્ટિમીસ્ટિક અપડેટ્સમાં રૂપાંતરિત કરો – જો તમારી પાસે
setState(prev => ({...prev, optimisticValue}))અને ત્યારબાદ async કોલ હોય, તો તેનેconst update = action(function* (newValue) { state = newValue; const server = yield fetch(...); state = reconcile(server); });તરીકે ફરીથી લખો. જનરેટર સર્વર પ્રતિસાદ આપે ત્યાં સુધી કંટ્રોલ yield કરે છે, અને પછી આપમેળે રિએક્ટિવ ગ્રાફને અપડેટ કરે છે. - મલ્ટિપલ એસિંક (async) ભાગોને હેન્ડલ કરો – જરૂરિયાત મુજબ
<Loading>બોર્ડરને નેસ્ટ કરો, અને પછી તેઓ સાથે દેખાય છે કે એક પછી એક, તે નક્કી કરવા માટે<Reveal>રેપર ઉમેરો. આ એવા પેટર્નને બદલે છે જ્યાં React ડેવલપર્સ જટિલ સ્ટેટ ચેક્સ સાથે મલ્ટિપલ<Suspense>કોમ્પોનન્ટ્સનો ઉપયોગ કરતા હતા. - ફ્લો ટેસ્ટ કરો – કારણ કે Solid promise રિઝોલ્યુશન પર re-render થતું નથી, તેથી ખાતરી કરો કે UI અપડેટ્સ તમે જ્યાં અપેક્ષા રાખો છો ત્યાં થાય છે. રિએક્ટિવ ગ્રાફ આપમેળે ફેરફારો ફેલાવે છે; વધારાના
useEffectકોલ્સની જરૂર નથી.
હજુ પણ ફેરફાર હેઠળ છે
Solid 2.0 ની async API હાલમાં બીટા (beta) માં છે. <Loading> અને action જેવા નામો સ્ટેબલ રિલીઝ પહેલા બદલાઈ શકે છે, અને ડોક્યુમેન્ટેશન હજુ પણ વિકસી રહ્યું છે. મુખ્ય વિચાર—promises ને રિએક્ટિવ વેલ્યુ તરીકે ગણવો—તે બદલાયો નથી, પરંતુ લાઇબ્રેરી સ્થિર થતી જેમ શરૂઆતના વપરાશકર્તાઓએ નાના બ્રેકિંગ ફેરફારોની અપેક્ષા રાખવી જોઈએ.
કોને ફાયદો થશે
- ભારે ડેટા ફેચિંગ ધરાવતી React ટીમો – એક્સટર્નલ સ્ટેટ લાઇબ્રેરીઓની ઘટતી જરૂરિયાત અને ઇન-બિલ્ટ stale-while-revalidate પેટર્ન બંડલ સાઈઝ ઘટાડી શકે છે અને કોડબેઝને સરળ બનાવી શકે છે.
- પર્ફોર્મન્સ-કેન્દ્રિત એપ્સ – દરેક ફેચ પર સંપૂર્ણ કોમ્પોનન્ટ re-renders ટાળીને, Solid વધુ સ્મૂધ વિઝ્યુઅલ અપડેટ્સ આપે છે, ખાસ કરીને લો-એન્ડ ઉપકરણો પર.
- "flash of spinner" થી કંટાળેલા ડેવલપર્સ –
<Loading>બોર્ડરનું "first-load-only" વર્તણૂક પહેલેથી જ દેખાતા કન્ટેન્ટ પર સ્પિનર ઝબકવાની સામાન્ય સમસ્યાને દૂર કરે છે.
સંભવિત ગેરફાયદા
- બીટા સ્ટેટસ – જ્યાં સુધી API સ્થિર ન થાય ત્યાં સુધી, લાંબા ગાળાના પ્રોજેક્ટ્સ માટે પછીથી માઈગ્રેશન પ્રયાસ માટે બજેટ રાખવું પડી શકે છે.
આગળ શું જોવું
<Loading> અથવા action ના કોઈપણ નામ બદલાવવા માટે સત્તાવાર ચેન્જલોગ (changelog) પર નજર રાખો.
નિષ્કર્ષ: SolidJS 2.0 તમને promises ને ફર્સ્ટ-ક્લાસ રિએક્ટિવ વેલ્યુ તરીકે ગણવાની મંજૂરી આપે છે, જે ડેટા રિફ્રેશ થાય ત્યારે UI ને સ્થિર રાખે છે અને React-સ્ટાઇલના હૂક્સના સેટની જરૂરિયાત દૂર કરે છે. જે ટીમો re-render-કેન્દ્રિત મોડેલથી આગળ વધવા તૈયાર છે, તેમના માટે માઈગ્રેશન પાથ સ્પષ્ટ છે, પર્ફોર્મન્સનો ફાયદો સ્પષ્ટ છે, અને એકમાત્ર વાસ્તવિક જોખમ સામાન્ય બીટા-સ્ટેજ અનિશ્ચિતતા છે.