તમારી સ્ટેટ સ્ટેક (State Stack) નક્કી કરતો પ્રશ્ન
Redux ની React Query સાથે સરખામણી કરવાનું બંધ કરો.
તમે શું બનાવી રહ્યા છો તે જાણતા પહેલા, તમારે હથોડી જોઈએ છે કે સ્ક્રુડ્રાઈવર તે પૂછવા જેવું છે. Redux, React Query, અને Zustand ત્રણેય અલગ-અલગ સમસ્યાઓનો ઉકેલ લાવે છે.
સાચો નિર્ણય એક પ્રશ્ન પરથી આવે છે: દરેક સ્ટેટ (state) માટે 'સોર્સ ઓફ ટ્રુથ' (source of truth) કોણ ધરાવે છે?
તમારી પાસે બે પ્રકારના સત્ય (truth) છે.
- Owned Truth ક્લાયન્ટ એ સ્ત્રોત છે. આમાં નીચેની બાબતોનો સમાવેશ થાય છે:
- શું સાઇડબાર ખુલ્લો છે?
- વર્તમાન થીમ કઈ છે?
- ફોર્મનું કયું સ્ટેપ એક્ટિવ છે? આ સ્ટેટ તમારા સ્થાનિક નિર્ણયો પર આધારિત છે. તેને સર્વર સાથે ફરીથી ચકાસણી કરવાની જરૂર નથી.
- Borrowed Truth સ્ત્રોત સર્વર પર હોય છે. ક્લાયન્ટ પાસે માત્ર તે ડેટાનું પ્રતિબિંબ હોય છે. આ ડેટા તમારી જાણ બહાર બદલાતો રહે છે. તમારું કામ આનું સંચાલન કરવાનું છે:
- Staleness (ડેટા જૂનો થવો)
- Invalidation (અમાન્યતા)
- Refetching (ફરીથી મેળવવું)
- Caching (કેશિંગ)
મોટાભાગના ડેવલપર્સ સંઘર્ષ કરે છે કારણ કે તેઓ બંને માટે એક જ સાધનનો ઉપયોગ કરે છે. જ્યારે તમે ક્લાયન્ટ-સાઇડ રિડ્યુસર (client-side reducer) માં borrowed truth નું સંચાલન કરવાનો પ્રયાસ કરો છો, ત્યારે તમે ખરાબ રીતે React Query ને ફરીથી લખી રહ્યા હોવ તેવું બને છે. તમે મેન્યુઅલી લોડિંગ સ્ટેટ્સ, એરર હેન્ડલિંગ અને કેશિંગ લખો છો. આનાથી બિનજરૂરી કોડનું પ્રમાણ વધી જાય છે.
તેમને અલગ કરો અને સફળતા મેળવો.
Borrowed truth માટે React Query નો ઉપયોગ કરો. તે સિંક્રનાઇઝેશનનું અઘરું કામ સંભાળે છે. Owned truth માટે Zustand નો ઉપયોગ કરો. તે કોઈપણ જટિલતા વગર સાદા મૂલ્ય સંગ્રહ (value storage) નું કામ કરે છે.
સર્વર ડેટાને Zustand માં ન નાખો. તે સીમા સ્પષ્ટ રાખો.
Redux અને Sagas વિશે શું? Sagas ડેટા ફેચિંગ (data fetching) માટે નથી. તેઓ સમય જતાં જટિલ પ્રક્રિયાઓને સંચાલિત કરવા માટે છે. જો તમારું એપ નીચેની બાબતો સંભાળતું હોય તો તેનો ઉપયોગ કરો:
- Concurrent, રદ કરી શકાય તેવા (cancellable) ફ્લો.
- Real-time websocket સ્ટ્રીમ્સ.
- જટિલ સ્ટેટ મશીન્સ.
જો તમે React Query નો ઉપયોગ કરો છો અને તમારા Sagas કંઈ