ਹਰ React ਡਿਵੈਲਪਰ ਅੰਤ ਵਿੱਚ ਇੱਕੋ ਸਵਾਲ ਦਾ ਸਾਹਮਣਾ ਕਰਦਾ ਹੈ: ਕੀ ਮੈਨੂੰ Context ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਜਾਂ ਕੀ ਇਹ Redux ਦੀ ਸਮੱਸਿਆ ਹੈ? ਜੇਕਰ ਤੁਸੀਂ ਸਿਰਫ਼ ਕੁਝ ਮਹੀਨਿਆਂ ਤੋਂ ਬਿਲਡਿੰਗ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਆਨਲਾਈਨ ਸ਼ੋਰ (noise) ਇਸ ਨੂੰ ਅਜਿਹਾ ਬਣਾ ਦਿੰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਇਹ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਇੱਕ ਨੂੰ ਚੁਣਨ ਦਾ ਫੈਸਲਾ ਹੋਵੇ। ਕੁਝ ਟਿਊਟੋਰਿਅਲ Redux ਨੂੰ ਪੁਰਾਣੇ (legacy) ਬੋਝ ਵਜੋਂ ਮੰਨਦੇ ਹਨ। ਹੋਰ ਚੇਤਾਵਨੀ ਦਿੰਦੇ ਹਨ ਕਿ Context ਇੱਕ to-do list ਤੋਂ ਅੱਗੇ ਨਹੀਂ ਵਧ ਸਕਦਾ। ਕੋਈ ਵੀ ਅਤਿਮੁਖਤਾ (extreme) ਮਦਦਗਾਰ ਨਹੀਂ ਹੈ। ਸੱਚਾਈ ਇਹ ਹੈ ਕਿ ਇਹ ਟੂਲ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੀਆਂ ਮੁਸ਼ਕਲਾਂ ਨੂੰ ਹੱਲ ਕਰਦੇ ਹਨ, ਅਤੇ ਸਹੀ ਚੋਣ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦੀ ਹੈ।
Prop Drilling ਦੀ ਸਮੱਸਿਆ
ਕੋਈ ਵੀ state management stratgy ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਸਮਝਣਾ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਕਿ ਦੋਵੇਂ ਟੂਲ ਕਿਸ ਬਿਮਾਰੀ ਦਾ ਇਲਾਜ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਨ। ਕਲਪਨਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਇੱਕ e-commerce ਸਾਈਟ ਬਣਾ ਰਹੇ ਹੋ। ਤੁਸੀਂ top-level App component 'ਤੇ ਯੂਜ਼ਰ ਦਾ ਪ੍ਰੋਫਾਈਲ ਫੈਚ (fetch) ਕਰਦੇ ਹੋ। ਫੁੱਟਰ (footer) ਵਿੱਚ, ਇੱਕ ਛੋਟਾ ਜਿਹਾ AccountLink component ਉਸ ਪ੍ਰੋਫਾਈਲ ਫੋਟੋ ਦੀ ਲੋੜ ਰੱਖਦਾ ਹੈ। ਇੱਕ ਗਲੋਬਲ store ਤੋਂ ਬਿਨਾਂ, user object ਨੂੰ Home, ਫਿਰ Header, ਫਿਰ NavContainer, ਫਿਰ UserDropdown, ਅਤੇ ਅੰਤ ਵਿੱਚ AccountLink ਰਾਹੀਂ ਲੰਘਣਾ ਪੈਂਦਾ ਹੈ। ਵਿਚਕਾਰ ਹਰ ਲੇਅਰ ਉਸ ਡੇਟਾ ਨੂੰ ਛੂਹਦੀ ਹੈ ਜਿਸਦੀ ਉਸਨੂੰ ਵਰਤੋਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਸੇ ਨੂੰ prop drilling ਕਿਹਾ ਜਾਂਦਾ ਹੈ।
Prop drilling ਕੰਪੋਨੈਂਟਸ ਨੂੰ ਕਮਜ਼ੋਰ (brittle) ਬਣਾ ਦਿੰਦੀ ਹੈ। Refactoring ਜੋਖਮ ਭਰਪੂਰ ਹੋ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਇੱਕ ਵਿਚਕਾਰਲੇ ਮੀਡੀਆਮੈਨ (middleman) ਨੂੰ ਹਟਾਉਣ ਨਾਲ ਪੂਰੀ ਲੜੀ ਟੁੱਟ ਜਾਂਦੀ ਹੈ। Reusability 'ਤੇ ਅਸਰ ਪੈਂਦਾ ਹੈ ਕਿਉਂਕਿ ਕੰਪੋਨੈਂਟਸ ਉਹ props ਮੰਗਦੇ ਹਨ ਜੋ ਉਹ ਸਿਰਫ਼ ਹੇਠਾਂ ਭੇਜ ਰਹੇ ਹੁੰਦੇ ਹਨ। Context ਅਤੇ Redux ਦੋਵੇਂ ਹੀ ਦੂਰ ਦੇ ਕੰਪੋਨੈਂਟਸ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸਾਂਝੇ ਡੇਟਾ ਨੂੰ ਸਬਸਕ੍ਰਾਈਬ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇ ਕੇ ਇਸ ਨੂੰ ਖਤਮ ਕਰਦੇ ਹਨ। ਪਰ ਉਹ ਉਸ ਡੇਟਾ ਨੂੰ ਜਿਸ ਤਰ੍ਹਾਂ ਪਹੁੰਚਾਉਂਦੇ ਹਨ, ਅਤੇ ਅਜਿਹਾ ਕਰਨ ਦੀ ਕੀਮਤ, ਉਹ ਜਲਦੀ ਹੀ ਵੱਖਰੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
ਜਦੋਂ React Context API ਸਹੀ ਚੋਣ ਹੁੰਦੀ ਹੈ
React Context ਖੁਦ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਅੰਦਰ ਹੀ ਬਣਿਆ ਹੋਇਆ ਹੈ। ਕੋਈ ਵਾਧੂ npm installs ਨਹੀਂ, ਕੋਈ build configuration ਨਹੀਂ, ਕੋਈ boilerplate files ਨਹੀਂ। ਤੁਸੀਂ ਇੱਕ context object ਬਣਾਉਂਦੇ ਹੋ, ਆਪਣੇ tree ਦੇ ਇੱਕ ਹਿੱਸੇ ਨੂੰ Provider ਵਿੱਚ ਲਪੇਟਦੇ ਹੋ, ਅਤੇ ਕਿਸੇ ਵੀ nested component ਵਿੱਚ useContext ਨਾਲ ਮੁੱਲ (value) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ। ਇਸ ਸਾਦਗੀ ਦੇ ਕਾਰਨ, Context ਉਹਨਾਂ ਛੋਟੇ ਤੋਂ ਦਰਮਿਆਨੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਿੱਥੇ state ਬਦਲਾਅ ਘੱਟ ਹੁੰਦੇ ਹਨ ਅਤੇ ਉਸ state ਦਾ ਰੂਪ ਕਾਫ਼ੀ ਸਧਾਰਨ ਹੁੰਦਾ ਹੈ।
UI themes ਬਾਰੇ ਸੋਚੋ। ਇੱਕ ਯੂਜ਼ਰ ਸ਼ਾਇਦ ਇੱਕ ਸੈਸ਼ਨ ਵਿੱਚ ਇੱਕ ਵਾਰ light ਅਤੇ dark mode ਦੇ ਵਿਚਕਾਰ ਬਦਲਦਾ ਹੈ। ਇਹ ਮੁੱਲ ਹਰ styled component ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਪਰ ਇਹ ਇੰਨੀ ਘੱਟ ਵਾਰ ਬਦਲਦਾ ਹੈ ਕਿ performance ਦੀਆਂ ਚਿੰਤਾਵਾਂ ਬਹੁਤ ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ। Authentication status ਇੱਕ ਹੋਰ ਕਲਾਸਿਕ ਉਦਾਹਰਣ ਹੈ। ਇੱਕ ਵਾਰ ਯੂਜ਼ਰ ਲੌਗਇਨ ਕਰ ਲੈਂਦਾ ਹੈ, ਤਾਂ isAuthenticated ਫਲੈਗ ਅਤੇ user object ਦਰਜਨਾਂ ਪੇਜ ਨੈਵੀਗੇਸ਼ਨਾਂ ਦੌਰਾਨ ਸਥਿਰ ਰਹਿੰਦੇ ਹਨ। ਭਾਸ਼ਾ ਜਾਂ localization ਸੈਟਿੰਗਾਂ ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। ਇਹ ਵਿਆਪਕ, ਹੌਲੀ-ਹੌਲੀ ਚੱਲਣ ਵਾਲੇ ਸਿਗਨਲ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਬਹੁਤ ਸਾਰੇ ਕੰਪੋਨੈਂਟਸ ਨੂੰ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਪਰ ਬਹੁਤ ਘੱਟ ਕੰਪੋਨੈਂਟਸ ਇਨ੍ਹਾਂ ਨੂੰ ਬਦਲਦੇ ਹਨ।
ਮੁੱਖ ਚੁਣੌਤੀ ਇਹ ਹੈ ਕਿ Context ਅਪਡੇਟਸ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦਾ ਹੈ। ਜਦੋਂ ਕਿਸੇ Context Provider ਦੀ value ਬਦਲਦੀ ਹੈ, ਤਾਂ React ਹਰ ਉਸ ਕੰਪੋਨੈਂਟ ਨੂੰ re-render ਕਰਦਾ ਹੈ ਜੋ ਉਸ context ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇੱਕ ਛੋਟੀ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਇਸਦਾ ਅਹਿਸਾਸ ਨਹੀਂ ਹੋਵੇਗਾ। ਇੱਕ ਵੱਡੀ ਐਪ ਵਿੱਚ, ਜੇਕਰ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਣ ਵਾਲੇ ਡੇਟਾ ਨੂੰ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤੇ ਜਾਣ ਵਾਲੇ Context ਦੇ ਅੰਦਰ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਬੇਲੋੜੇ re-renders ਦੀ ਇੱਕ ਲੜੀ ਸ਼ੁਰੂ ਕਰ ਦਿਓਗੇ। ਤੁਸੀਂ ਅਸਥਿਰਤਾ (volatility) ਨੂੰ ਅਲੱਗ ਕਰਨ ਲਈ contexts ਨੂੰ ਵੰਡ ਸਕਦੇ ਹੋ, ਪਰ ਉਸ ਸਮੇਂ ਤੁਸੀਂ ਮੈਨੂਅਲ ਤੌਰ 'ਤੇ ਅਜਿਹੀਆਂ optimization ਕੋਸ਼ਿਸ਼ਾਂ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹੋ ਜੋ ਕੋਈ ਹੋਰ ਟੂਲ ਪਹਿਲਾਂ ਹੀ ਹੱਲ ਕਰਦਾ ਹੈ।
ਜਦੋਂ Redux Toolkit ਆਪਣੀ ਜਗ੍ਹਾ ਬਣਾਉਂਦਾ ਹੈ
Redux Toolkit ਉਹਨਾਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ ਜਿੱਥੇ state ਗੁੰਝਲਦਾਰ ਹੁੰਦੀ ਹੈ, ਅਪਡੇਟਸ ਵਾਰ-ਵਾਰ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਕਈ ਦੂਰ-ਦੂਰ ਦੇ ਫੀਚਰਸ ਨੂੰ ਇੱਕੋ ਡੇਟਾ ਨੂੰ ਟਕਰਾਏ ਬਿਨਾਂ ਪੜ੍ਹਨ ਅਤੇ ਲਿਖਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਕ shopping cart ਬਾਰੇ ਵਿਚਾਰ ਕਰੋ। ਯੂਜ਼ਰ ਇੱਕ product card ਤੋਂ ਇੱਕ ਆਈਟਮ ਜੋੜਦਾ ਹੈ। header ਵਿੱਚ cart icon ਨੂੰ ਆਪਣਾ badge count ਅਪਡੇਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਲਾਈਨ ਆਈਟਮਾਂ ਦਿਖਾਉਣ ਲਈ ਇੱਕ sidebar ਬਾਹਰ ਆਉਂਦਾ ਹੈ। ਇੱਕ discount code input validation ਚਲਾਉਂਦਾ ਹੈ। ਬਾਅਦ ਵਿੱਚ checkout ਪੇਜ cart ਦੀ ਸਮੱਗਰੀ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ। ਉਹ state ਪੂਰੇ tree ਵਿੱਚ ਅਸੰਬੰਧਿਤ ਕੰਪੋਨੈਂਟਸ ਦੁਆਰਾ ਵਰਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਇਹ ਅਕਸਰ ਬਦਲਦੀ ਰਹਿੰਦੀ ਹੈ।
Redux Toolkit ਇਸ ਨੂੰ ਇੱਕ ਕੇਂਦਰੀਕ੍ਰਿਤ (centralized) store ਅਤੇ state ਦੇ ਸਪੱਸ਼ਟ slices ਰਾਹੀਂ ਹੱਲ ਕਰਦਾ ਹੈ। ਕੰਪੋਨੈਂਟਸ useSelector ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਿਰਫ਼ ਉਸ ਡੇਟਾ ਦੇ ਹਿੱਸੇ ਨੂੰ ਸਬਸਕ੍ਰਾਈਬ ਕਰਦੇ ਹਨ ਜਿਸਦੀ ਉਹਨਾਂ ਨੂੰ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਰੀਅਲ-ਟਾਈਮ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਸਟਾਕ ਦੀ ਕੀਮਤ ਅਪਡੇਟ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਯੂਜ਼ਰ ਪ੍ਰੋਫਾਈਲ ਸੈਟਿੰਗਾਂ ਦਿਖਾਉਣ ਵਾਲਾ ਕੰਪੋਨੈਂਟ ਨਹੀਂ ਜਾਗਦਾ। Redux ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ reference equality checks ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ subscriptions ਬਹੁਤ ਸਟੀਕ (granular) ਹੋਣ। ਇਹ ਉਦੋਂ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਕੰਪੋਨੈਂਟਸ ਦੀ ਗਿਣਤੀ ਸੈਂਕੜਿਆਂ ਵਿੱਚ ਪਹੁੰਚ
Performance characteristics (ਪ੍ਰਦਰਸ਼ਨ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ) ਇਹਨਾਂ ਟੂਲਜ਼ ਨੂੰ ਕਿਸੇ ਵੀ ਹੋਰ ਚੀਜ਼ ਨਾਲੋਂ ਵੱਖ ਕਰਦੀਆਂ ਹਨ। Context ਬਿਨਾਂ ਕਿਸੇ ਸ਼ਰਤ ਦੇ ਸਾਰੇ consumers ਨੂੰ ਨਵੀਂ value ਬ੍ਰੌਡਕਾਸਟ ਕਰਦਾ ਹੈ। Redux ਸਿਰਫ਼ ਉਹਨਾਂ subscribers ਨੂੰ ਸੂਚਿਤ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਚੁਣੀ ਹੋਈ slice ਬਦਲੀ ਹੋਵੇ। ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ real-time stock dashboard ਬਣਾ ਰਹੇ ਹੋ ਜਿੱਥੇ ਹਰ ਸੈਕਿੰਡ quotes ਰਿਫ੍ਰੈਸ਼ ਹੁੰਦੇ ਹਨ, ਤਾਂ Context ਇੱਕ global re-render ਦਾ ਤੂਫ਼ਾਨ ਖੜ੍ਹਾ ਕਰ ਦੇਵੇਗਾ। Redux ਸਿਰਫ਼ ticker cell ਅਤੇ sparkline chart ਨੂੰ ਹੀ recompute ਕਰਨ ਦੇਵੇਗਾ।
Debugging ਇੱਕ ਹੋਰ ਖੇਤਰ ਹੈ ਜਿੱਥੇ ਗੁੰਝਲਦਾਰ ਐਪਸ ਵਿੱਚ Redux ਅੱਗੇ ਨਿਕਲ ਜਾਂਦਾ ਹੈ। Redux DevTools ਤੁਹਾਨੂੰ time-travel debugging ਦੀ ਸਹੂਲਤ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਹਰੇਕ dispatched action ਰਾਹੀਂ ਪਿੱਛੇ ਜਾ ਸਕਦੇ ਹੋ ਅਤੇ state ਨੂੰ rewind ਹੁੰਦੇ ਦੇਖ ਸਕਦੇ ਹੋ। ਸ਼ਿਪਿੰਗ ਕੈਲਕੂਲੇਸ਼ਨ, ਪੇਮੈਂਟ ਵੈਲੀਡੇਸ਼ਨ, ਅਤੇ error recovery ਵਾਲੇ ਇੱਕ multi-step checkout flow ਵਿੱਚ, ਉਸ ਸਹੀ ਲੜੀ (sequence) ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਣ ਦੀ ਸਮਰੱਥਾ ਜੋ ਕਿਸੇ bug ਦਾ ਕਾਰਨ ਬਣੀ ਹੋਵੇ, ਬਹੁਤ ਕੀਮਤੀ ਹੈ। Context ਸਟੈਂਡਰਡ React DevTools 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਮੌਜੂਦਾ context values ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਕੋਈ built-in action log ਜਾਂ state diff viewer ਨਹੀਂ ਹੈ। ਤੁਹਾਨੂੰ ਫਿਰ ਤੋਂ console logs ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਪਵੇਗੀ।
Middleware and side effects Redux ਦੇ DNA ਦਾ ਹਿੱਸਾ ਹਨ। Redux Toolkit ਵਿੱਚ createAsyncThunk ਸ਼ਾਮਲ ਹੈ ਅਤੇ ਇਹ data-fetching libraries ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜੁੜ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ Redux data flow ਦੇ ਅੰਦਰ ਹੀ ਇੱਕ API call ਨੂੰ ਸੰਭਾਲ ਸਕਦੇ ਹੋ, loading spinner ਦਿਖਾ ਸਕਦੇ ਹੋ, network failure ਨੂੰ ਸੰਭਾਲ ਸਕਦੇ ਹੋ, ਅਤੇ result ਨੂੰ cache ਕਰ ਸਕਦੇ ਹੋ। Context asynchronous logic ਲਈ ਕੋਈ built-in pattern ਨਹੀਂ ਦਿੰਦਾ। ਜਾਂ ਤਾਂ ਤੁਸੀਂ components ਦੇ ਅੰਦਰ fetch ਕਰਦੇ ਹੋ ਅਤੇ ਫਿਰ result ਨੂੰ Context ਵਿੱਚ ਪੁਸ਼ ਕਰਦੇ ਹੋ, ਜਾਂ ਤੁਸੀਂ providers ਨੂੰ ਆਪਣੇ ਬਣਾਏ ਹੋਏ async utilities ਵਿੱਚ ਲਪੇਟਦੇ ਹੋ। ਇਹ ਕੰਮ ਤਾਂ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ad hoc ਹੈ।
Setup cost ਦੇ ਮਾਮਲੇ ਵਿੱਚ Context ਸਾਫ਼ ਤੌਰ 'ਤੇ ਜਿੱਤ ਜਾਂਦਾ ਹੈ। ਇੱਕ theme provider ਬਣਾਉਣ ਵਿੱਚ ਲਗਭਗ ਪੰਜ ਮਿੰਟ ਲੱਗਦੇ ਹਨ। Redux Toolkit ਲਈ ਇੱਕ store file ਬਣਾਉਣ, slices ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਅਤੇ ਆਪਣੀ application ਨੂੰ Provider ਵਿੱਚ ਲਪੇਟਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹ ਪੁਰਾਣੇ Redux ਅਤੇ ਉਸਦੇ ਬਹੁਤ ਸਾਰੇ boilerplate ਵਰਗਾ ਹਫ਼ਤੇ ਭਰ ਚੱਲਣ ਵਾਲਾ ਕੰਮ ਨਹੀਂ ਹੈ, ਪਰ ਫਿਰ ਵੀ ਇਹ Context ਨਾਲੋਂ ਜ਼ਿਆਦਾ setup ਮੰਗਦਾ ਹੈ। ਇੱਕ weekend side project ਜਾਂ ਤਿੰਨ routes ਵਾਲੇ dashboard ਲਈ, ਇਹ overhead ਸ਼ਾਇਦ ਫਾਇਦੇਮੰਦ ਨਾ ਹੋਵੇ।
ਇੱਕੋ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਦੋਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ
ਤੁਹਾਨੂੰ ਕਿਸੇ ਇੱਕ ਪੱਖ ਨਾਲ ਵਫ਼ਾਦਾਰੀ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਬਹੁਤ ਸਾਰੀਆਂ production applications global UI shell ਦੇ ਕੰਮਾਂ ਲਈ Context ਅਤੇ domain-heavy business data ਲਈ Redux ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ। ਇੱਕ ਆਮ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ theme, locale, ਅਤੇ ਸ਼ਾਇਦ ਇੱਕ lightweight auth flag ਨੂੰ Context ਵਿੱਚ ਰੱਖਿਆ ਜਾਵੇ ਕਿਉਂਕਿ ਹਰ route ਨੂੰ ਉਹਨਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਤੇ ਉਹ ਬਹੁਤ ਘੱਟ ਬਦਲਦੇ ਹਨ। ਇਸ ਦੇ ਉਲਟ, order management system, notification center, ਅਤੇ data tables Redux ਵਿੱਚ ਹੁੰਦੇ ਹਨ ਜਿੱਥੇ ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲੇ updates ਅਤੇ cross-component logic ਲਈ ਸਹੀ ਕੰਟਰੋਲ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਇਹ hybrid approach ਸੌਖੇ ਕੰਮਾਂ ਨੂੰ ਸੌਖਾ ਰੱਖਦਾ ਹੈ ਅਤੇ ਇੱਕ static theme object ਦੇ ਆਲੇ-ਦੁਆਲੇ ਪੂਰਾ Redux store ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ। ਇਹ ਤੁਹਾਡੇ Redux slices ਨੂੰ ਉਸ UI elements ਨਾਲ ਭਰਨ ਤੋਂ ਵੀ ਰੋਕਦਾ ਹੈ ਜਿਸ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਹੀ industrial-grade state management ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ।
ਅਸਲ ਸਿੱਖਿਆ (The Real Takeaway)
ਭਾਰੀ tool ਚੁਣਨ ਲਈ ਕੋਈ ਸਨਮਾਨ ਨਹੀਂ ਮਿਲਦਾ। ਇਹ ਦੇਖ ਕੇ ਸ਼ੁਰੂ ਕਰੋ ਕਿ ਤੁਹਾਡੀ state ਕਿੰਨੀ ਵਾਰ ਬਦਲਦੀ ਹੈ, ਕਿੰਨੇ components ਇਸ ਨੂੰ ਛੂਹਦੇ ਹਨ, ਅਤੇ ਕੀ ਤੁਹਾਨੂੰ team boundaries ਦੇ ਪਾਰ mutations ਨੂੰ ਟ੍ਰੇਸ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਦਰਮਿਆਨੇ ਆਕਾਰ ਦੀ ਐਪ ਵਿੱਚ ਹੌਲੀ-ਹੌਲੀ ਬਦਲਣ ਵਾਲੀਆਂ ਅਤੇ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਸਾਂਝੀਆਂ ਕੀਤੀਆਂ ਗਈਆਂ values ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ Context ਸ਼ਾਇਦ ਕਾਫ਼ੀ ਹੈ। ਜੇਕਰ ਤੁਹਾਡੀ state ਅਕਸਰ ਬਦਲਦੀ ਹੈ, ਵੱਖ-ਵੱਖ features ਤੱਕ ਫੈਲੀ ਹੋਈ ਹੈ, ਅਤੇ ਇੱਕ ਸਪੱਸ਼ਟ audit trail ਦੀ ਲੋੜ ਹੈ, ਤਾਂ Redux Toolkit ਤੁਹਾਡੀ ਮੁਸ਼ਕਲ ਘੱਟ ਕਰੇਗਾ।
ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਲੋੜ ਅਨੁਸਾਰ ਚੁਣੋ, ਨਾ ਕਿ ਕਾਨਫਰੰਸ ਟਾਕਸ ਜਾਂ GitHub stars ਦੇ ਆਧਾਰ 'ਤੇ। ਇੱਕ shopping cart ਜਿਸ ਵਿੱਚ ਪੰਜਾਹ ਆਈਟਮਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਉਸ ਲਈ ਆਪਣੇ ਆਪ Redux ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ, ਅਤੇ ਇੱਕ theme toggle ਲਈ global store ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਸਮੱਸਿਆ ਦੇ ਅਨੁਸਾਰ tool ਦੀ ਚੋਣ ਕਰੋ, ਅਤੇ ਤੁਹਾਡਾ codebase ਹਾਈਪ ਸਾਈਕਲ ਖਤਮ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵੀ ਲੰਬੇ ਸਮੇਂ ਤੱਕ maintainable ਰਹੇਗਾ।