ਹਰ React developer ਅੰਤ ਵਿੱਚ ਇੱਕੋ ਹੀ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਆਪਣੇ top-level App component ਦੇ ਅੰਦਰ ਇੱਕ user object fetch ਕਰਦੇ ਹੋ। ਫਿਰ ਤੁਸੀਂ ਇਸਨੂੰ ਹੇਠਾਂ pass ਕਰਦੇ ਹੋ। ਅਤੇ ਫਿਰ ਤੋਂ ਹੇਠਾਂ। ਇੱਕ route wrapper, ਇੱਕ layout shell, ਅਤੇ ਇੱਕ sidebar container ਰਾਹੀਂ, ਤਾਂ ਜੋ ਤਿੰਨ ਲੇਅਰ ਡੂੰਘਾਈ ਵਿੱਚ ਇੱਕ ਛੋਟਾ ਜਿਹਾ avatar component ਪ੍ਰੋਫਾਈਲ ਪਿਕਚਰ ਦਿਖਾ ਸਕੇ। ਵਿਚਕਾਰਲੇ components ਨੂੰ ਉਸ user object ਦੀ ਕੋਈ ਪਰਵਾਹ ਨਹੀਂ ਹੁੰਦੀ। ਉਹ ਸਿਰਫ਼ ਇੱਕ ਪੈਕੇਜ ਨੂੰ ਅੱਗੇ ਭੇਜ ਰਹੇ ਹੁੰਦੇ ਹਨ। ਇਸਨੂੰ prop drilling ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਇੱਕ ਸਾਫ਼ component tree ਨੂੰ ਇੱਕ ਨਿਰਾਸ਼ਾਜਨਕ 'game of telephone' ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।

ਅਸਲੀ ਮੁਸ਼ਕਲ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਉਸ ਡੇਟਾ ਦਾ ਰੂਪ (shape) ਬਦਲ ਜਾਂਦਾ ਹੈ। ਸ਼ਾਇਦ backend user.avatar ਦੀ ਬਜਾਏ user.profile.avatar ਨੂੰ nest ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦੇਵੇ। ਅਚਾਨਕ ਤੁਸੀਂ ਪੰਜ ਅਜਿਹੀਆਂ ਫਾਈਲਾਂ ਵਿੱਚ TypeScript interfaces ਜਾਂ PropTypes ਨੂੰ edit ਕਰ ਰਹੇ ਹੁੰਦੇ ਹੋ ਜੋ ਖੁਦ ਉਸ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੀਆਂ। ਇੱਥੇ ਹੀ React Context API ਕੰਮ ਆਉਂਦੀ ਹੈ।

Context ਡੇਟਾ ਫਲੋ (Data Flow) ਨੂੰ ਕਿਵੇਂ ਬਦਲਦਾ ਹੈ

Context ਨੂੰ ਆਪਣੇ ਘਰ ਦੇ ਕੇਂਦਰ ਵਿੱਚ ਰੱਖੇ ਇੱਕ WiFi router ਵਾਂਗ ਸਮਝੋ। ਇਸ ਤੋਂ ਬਿਨਾਂ, ਤੁਹਾਨੂੰ ਆਪਣੇ ਲੈਪਟਾਪ ਤੱਕ ਸਿਗਨਲ ਪਹੁੰਚਾਉਣ ਲਈ ਹਰ ਕਮਰੇ ਵਿੱਚੋਂ Ethernet cables ਲੰਘਾਉਣੀਆਂ ਪੈਣਗੀਆਂ। ਇਸ ਦੇ ਨਾਲ, router ਹਵਾ ਰਾਹੀਂ ਬ੍ਰੌਡਕਾਸਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਹੀ ਪਾਸਵਰਡ ਵਾਲਾ ਕੋਈ ਵੀ ਡਿਵਾਈਸ ਸਿੱਧਾ ਕਨੈਕਟ ਹੋ ਸਕਦਾ ਹੈ। ਕੰਧਾਂ ਨਾਲ ਕੋਈ ਫਰਕ ਨਹੀਂ ਪੈਂਦਾ।

React ਦੇ ਹਿਸਾਬ ਨਾਲ, ਤੁਹਾਡੀ app ਦਾ root ਹਰ ਲੇਅਰ ਨੂੰ ਕੂਰੀਅਰ ਵਜੋਂ ਕੰਮ ਕਰਨ ਲਈ ਕਹੇ ਬਿਨਾਂ component tree ਰਾਹੀਂ ਡੇਟਾ ਬ੍ਰੌਡਕਾਸਟ ਕਰ ਸਕਦਾ ਹੈ। ਕੋਈ ਵੀ nested component ਉਸ ਬ੍ਰੌਡਕਾਸਟ ਨੂੰ subscribe ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਬਿਲਕੁਲ ਉਹੀ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ ਜਿਸਦੀ ਉਸਨੂੰ ਲੋੜ ਹੈ।

ਤਿੰਨ ਮੁੱਖ ਹਿੱਸੇ

Context API ਤਿੰਨ ਮੁੱਖ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡੀ ਹੋਈ ਹੈ।

React.createContext() ਬ੍ਰੌਡਕਾਸਟ ਚੈਨਲ ਸੈੱਟਅੱਪ ਕਰਦਾ ਹੈ। ਇਹ ਇੱਕ object ਰਿਟਰਨ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ Provider ਅਤੇ (ਪੁਰਾਣੇ ਕੋਡ ਵਿੱਚ) ਇੱਕ Consumer ਹੁੰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਕਿਸੇ ਖਾਸ ਫੀਚਰ ਲਈ ਇਸਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ ਹੀ ਕਾਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

The Provider ਇੱਕ component ਹੈ ਜੋ ਤੁਹਾਡੇ tree ਦੇ ਇੱਕ ਹਿੱਸੇ ਨੂੰ wrap ਕਰਦਾ ਹੈ। ਇਹ value ਨਾਮ ਦਾ ਇੱਕ prop ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਉਸ prop ਵਿੱਚ ਜੋ ਵੀ ਰੱਖਦੇ ਹੋ, ਉਹ ਹਰ ਇੱਕ descendant ਲਈ ਉਪਲਬਧ ਹੋ ਜਾਂਦਾ ਹੈ, ਚਾਹੇ ਉਹ ਕਿੰਨਾ ਵੀ ਡੂੰਘਾ ਕਿਉਂ ਨਾ ਹੋਵੇ।

useContext ਉਹ Hook ਹੈ ਜੋ ਇੱਕ function component ਨੂੰ ਉਸ ਬ੍ਰੌਡਕਾਸਟ ਨਾਲ ਜੁੜਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਆਪਣੇ component ਦੇ ਅੰਦਰ, ਤੁਸੀਂ ਆਪਣੇ ਦੁਆਰਾ ਬਣਾਏ ਗਏ context object ਨੂੰ useContext ਵਿੱਚ pass ਕਰਦੇ ਹੋ, ਅਤੇ ਇਹ ਮੌਜੂਦਾ value ਰਿਟਰਨ ਕਰਦਾ ਹੈ। ਬੱਸ ਇੰਨਾ ਹੀ। ਕੋਈ wrappers ਨਹੀਂ, ਕੋਈ ਵਾਧੂ props ਨਹੀਂ।

Hooks ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ render props ਦੇ ਨਾਲ Consumer pattern ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਪੈਂਦੀ ਸੀ। ਇਹ ਕੰਮ ਕਰਦਾ ਸੀ, ਪਰ ਇਸ ਨਾਲ ਬਹੁਤ ਜ਼ਿਆਦਾ indentation ਅਤੇ wrapper ਦਾ ਭਾਰ (clutter) ਪੈਦਾ ਹੁੰਦਾ ਸੀ। useContext ਨੇ ਇਸ ਸਭ ਨੂੰ ਤੁਹਾਡੇ function body ਦੇ ਅੰਦਰ ਇੱਕ ਸਿੰਗਲ ਲਾਈਨ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ।

Context ਅਸਲ ਵਿੱਚ ਕਦੋਂ ਸਹੀ ਰਹਿੰਦਾ ਹੈ

ਸਿਰਫ਼ ਆਦਤ ਕਰਕੇ Context ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ। ਇਹ ਉਸ ਡੇਟਾ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ ਜੋ ਤੁਹਾਡੇ tree ਦੀਆਂ ਵੱਖ-ਵੱਖ branches ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਅਣਸੰਬੰਧਿਤ components ਸਾਂਝੇ ਕਰਦੇ ਹਨ। ਚੰਗੇ ਉਦਾਹਰਨਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:

  • Theme settings. ਸਿਰਫ਼ light ਜਾਂ dark mode ਹੀ ਨਹੀਂ, ਸਗੋਂ spacing tokens, color palettes, ਅਤੇ font scales ਵੀ। ਹਰ styled button ਅਤੇ modal ਰਾਹੀਂ ਇਹਨਾਂ ਨੂੰ ਮੈਨੂਅਲੀ pass ਕਰਨਾ ਜਲਦੀ ਹੀ ਬੋਰਿੰਗ ਹੋ ਜਾਂਦਾ ਹੈ।
  • User authentication. Login status, ਇੱਕ permissions array, ਜਾਂ ਮੌਜੂਦਾ user object। ਤੁਹਾਡਾ header bar, ਇੱਕ dashboard widget, ਅਤੇ ਇੱਕ private route guard, ਸਾਰੇ tree ਦੇ ਵੱਖ-ਵੱਖ ਕੋਨਿਆਂ ਵਿੱਚ ਹੋ ਸਕਦੇ ਹਨ।
  • Language preferences. Locale strings, date formats, ਅਤੇ currency symbols। Form labels ਵਰਗੇ ਡੂੰਘੇ leaf components ਨੂੰ ਇਹਨਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਬਿਨਾਂ ਇਸ ਦੇ ਕਿ ਰਸਤੇ ਵਿੱਚ ਆਉਣ ਵਾਲੇ ਹਰ parent ਨੂੰ ਇਸ ਬਾਰੇ ਪਤਾ ਹੋਵੇ।
  • Shopping cart data. Item count, total value, ਅਤੇ add-to-cart functions। Header badge ਅਤੇ checkout page ਨੂੰ ਇੱਕੋ ਜਿਹੀ state ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਪਰ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਬਿਲਕੁਲ ਵੱਖਰੇ layout branches ਦੇ ਹੇਠਾਂ ਹੁੰਦੇ ਹਨ।

ਇੱਕ ਪ੍ਰੈਕਟੀਕਲ Theme Switcher

Context ਨੂੰ ਕੰਮ ਕਰਦੇ ਹੋਏ ਦੇਖਣ ਦਾ ਸਭ ਤੋਂ ਸਪਸ਼ਟ ਤਰੀਕਾ ਇੱਕ theme toggle ਹੈ। ਇੱਥੇ ਦੱਸਿਆ ਗਿਆ ਹੈ ਕਿ ਤੁਸੀਂ ਮਹੱਤਵਪੂਰਨ ਵੇਰਵਿਆਂ ਨੂੰ ਛੱਡੇ ਬਿਨਾਂ ਇਸਨੂੰ ਕਿਵੇਂ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹੋ।

ਪਹਿਲਾਂ, ਇੱਕ ThemeContext.js ਫਾਈਲ ਬਣਾਓ। React.createContext() ਨੂੰ ਕਾਲ ਕਰੋ ਅਤੇ ਨਤੀਜੇ ਨੂੰ ਸਟੋਰ ਕਰੋ। ਫਿਰ ਇੱਕ ThemeProvider component ਬਣਾਓ ਜੋ useState ਜਾਂ useReducer ਨਾਲ ਮੌਜੂਦਾ theme ਨੂੰ ਮੈਨੇਜ ਕਰਦਾ ਹੈ। ਬੱਚਿਆਂ (children) ਨੂੰ ਆਪਣੇ context ਦੇ Provider ਵਿੱਚ wrap ਕਰੋ, ਇੱਕ ਅਜਿਹਾ object pass ਕਰਦੇ ਹੋ ਜਿਸ ਵਿੱਚ ਮੌਜੂਦਾ theme ਅਤੇ ਇਸਨੂੰ toggle ਕਰਨ ਲਈ ਇੱਕ function ਦੋਵੇਂ ਹੋਣ। ThemeProvider ਅਤੇ context object ਦੋਵਾਂ ਨੂੰ export ਕਰੋ।

ਦੂਜਾ, ਆਪਣੇ app entry point 'ਤੇ ਜਾਓ। ThemeProvider ਨੂੰ import ਕਰੋ ਅਤੇ ਆਪਣੀ ਪੂਰੀ application ਨੂੰ ਇਸਦੇ ਨਾਲ wrap ਕਰੋ। ਜੇਕਰ ਤੁਸੀਂ ਇਹ ਕਦਮ ਛੱਡ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਬਾਅਦ ਵਿੱਚ context ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਵਾਲੀ ਕੋਈ ਵੀ ਚੀਜ਼ ਸਿਰਫ਼ default value ਹੀ ਦੇਖੇਗੀ।

ਤੀਜਾ, ਇੱਕ Header ਜਾਂ Content component ਦੇ ਅੰਦਰ, context object ਅਤੇ useContext ਨੂੰ import ਕਰੋ। Hook ਨੂੰ ਕਾਲ ਕਰੋ, theme ਅਤੇ toggle function ਨੂੰ destructure ਕਰੋ, ਅਤੇ ਆਪਣੀਆਂ CSS classes ਨੂੰ ਕੰਡੀਸ਼ਨਲ ਤੌਰ 'ਤੇ ਲਾਗੂ ਕਰੋ। ਇੱਕ ਬਟਨ ਜੋ toggle ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਉਹ ਜੋੜੋ। Component ਨੂੰ ਕਦੇ ਵੀ ਆਪਣੇ parent ਤੋਂ theme prop ਨਹੀਂ ਮਿਲਦਾ। ਇਹ ਸਿੱਧਾ ਹਵਾ ਵਿੱਚੋਂ ਸਿਗਨਲ ਖਿੱਚ ਲੈਂਦਾ ਹੈ।

Prop Drilling, Context, ਜਾਂ Redux?

ਇਹਨਾਂ ਟੂਲਜ਼ ਵਿੱਚੋਂ ਚੋਣ ਕਰਨਾ ਵਫ਼ਾਦਾਰੀ ਬਾਰੇ ਘੱਟ ਅਤੇ ਤੁਹਾਡੇ ਸਟੇਟ (state) ਦੇ ਰੂਪ ਬਾਰੇ ਜ਼ਿਆਦਾ ਹੈ।

Prop drilling ਦੋ ਜਾਂ ਤਿੰਨ ਪੱਧਰਾਂ ਦੀ ਡੂੰਘਾਈ ਲਈ ਬਿਲਕੁਲ ਠੀਕ ਹੈ। ਇਹ ਸਪੱਸ਼ਟ ਹੈ, ਤੁਹਾਡੇ IDE ਵਿੱਚ ਲੱਭਣਾ ਆਸਾਨ ਹੈ, ਅਤੇ ਡਿਪੈਂਡੈਂਸੀਆਂ (dependencies) ਨੂੰ ਸਾਫ਼ ਰੱਖਦਾ ਹੈ। ਸਮੱਸਿਆਵਾਂ ਉਦੋਂ ਹੀ ਆਉਂਦੀਆਂ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕੋ ਪ੍ਰੌਪ (prop) ਨੂੰ ਛੇ ਜਾਂ ਸੱਤ ਪਰਤਾਂ ਰਾਹੀਂ ਲੰਘਾਉਣਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ।

Context API ਖ਼ੁਦ React ਦੇ ਨਾਲ ਆਉਂਦੀ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕੋਈ ਵਾਧੂ ਬੰਡਲ ਸਾਈਜ਼ ਨਹੀਂ ਅਤੇ ਕੋਈ ਬਾਹਰੀ ਸੈੱਟਅੱਪ ਨਹੀਂ। ਇਹ ਛੋਟੇ ਤੋਂ ਦਰਮਿਆਨੇ ਗਲੋਬਲ ਸਟੇਟ ਨੂੰ ਬਹੁਤ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਦੀ ਹੈ, ਖ਼ਾਸ ਕਰਕੇ ਉਹ ਡੇਟਾ ਜੋ ਬਹੁਤ ਘੱਟ ਬਦਲਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਥੀਮਾਂ (themes) ਜਾਂ ਯੂਜ਼ਰ ਪ੍ਰੋਫਾਈਲਾਂ।

Redux ਲਈ ਵਾਧੂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਇੰਸਟਾਲ ਕਰਨ ਅਤੇ ਬੁਆਇਲਰਪਲੇਟ (boilerplate) ਲਿਖਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹ ਉਦੋਂ ਫਾਇਦੇਮੰਦ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਹਾਡਾ ਸਟੇਟ ਲੌਜਿਕ (state logic) ਗੁੰਝਲਦਾਰ ਹੋਵੇ, ਜਦੋਂ ਸਟੇਟ ਦੇ ਕਈ ਹਿੱਸੇ (slices) ਡੂੰਘੇ ਤਰੀਕੇ ਨਾਲ ਆਪਸ ਵਿੱਚ ਜੁੜੇ ਹੋਣ, ਜਾਂ ਜਦੋਂ ਤੁਹਾਨੂੰ time-travel debugging ਅਤੇ middleware ਦੀ ਲੋੜ ਹੋਵੇ। ਸਾਧਾਰਨ ਗਲੋਬਲ ਡੇਟਾ ਲਈ, Redux ਦੀ ਲੋੜ ਤੋਂ ਵੱਧ ਹੈ।

ਉਹ ਪਰਫਾਰਮੈਂਸ ਹਕੀਕਤ ਜਿਸ ਬਾਰੇ ਕੋਈ ਗੱਲ ਨਹੀਂ ਕਰਦਾ

ਇੱਥੇ ਉਹ ਪੁਆੜਾ ਹੈ ਜੋ ਜੂਨੀਅਰ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨਾਂ ਨੂੰ ਸੀਨੀਅਰਾਂ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ Context Provider ਵੈਲਯੂ ਬਦਲਦੀ ਹੈ, ਤਾਂ ਉਹ ਕੰਟੈਕਸਟ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲਾ ਹਰ ਕੰਪੋਨੈਂਟ ਰੀ-ਰੈਂਡਰ (re-render) ਹੁੰਦਾ ਹੈ। ਇਸ ਨਾਲ ਕੋਈ ਫਰਕ ਨਹੀਂ ਪੈਂਦਾ ਕਿ ਉਹ ਖ਼ਾਸ ਹਿੱਸਾ (slice) ਜਿਸਦੀ ਉਸ ਕੰਪੋਨੈਂਟ ਨੂੰ ਲੋੜ ਹੈ, ਉਹ ਉਹੀ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ। React ਨਵੀਂ ਰੈਫਰੈਂਸ (reference) ਨੂੰ ਦੇਖਦਾ ਹੈ ਅਤੇ ਅਪਡੇਟ ਸ਼ਡਿਊਲ ਕਰਦਾ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ ਆਪਣੀ ਪੂਰੀ ਐਪਲੀਕੇਸ਼ਨ ਸਟੇਟ ਨੂੰ ਇੱਕ ਵਿਸ਼ਾਲ StoreContext ਵਿੱਚ ਪਾ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਆਪਣੇ ਪੂਰੇ UI ਨੂੰ ਆਪਸ ਵਿੱਚ ਚਿਪਕਾ ਦਿੱਤਾ ਹੈ। ਥੀਮ ਸੈਟਿੰਗ ਬਦਲਣ ਨਾਲ ਤੁਹਾਡਾ ਸ਼ਾਪਿੰਗ ਕਾਰਟ, ਤੁਹਾਡੇ ਡੈਸ਼ਬੋਰਡ ਚਾਰਟ, ਅਤੇ ਤੁਹਾਡੀ ਨੋਟੀਫਿਕੇਸ਼ਨ ਲਿਸਟ ਰੀ-ਰੈਂਡਰ ਹੋ ਜਾਵੇਗੀ। ਇਹ ਬੇਲੋੜਾ ਕੰਮ ਹੈ।

ਆਪਣੇ ਕੰਟੈਕਸਟਾਂ ਨੂੰ ਡੋਮੇਨ (domain) ਦੇ ਅਨੁਸਾਰ ਵੰਡੋ। ਵਿਜ਼ੂਅਲ ਸੈਟਿੰਗਾਂ ਲਈ ThemeContext, ਪ੍ਰੋਫਾਈਲ ਡੇਟਾ ਲਈ UserContext, ਅਤੇ ਕਾਮਰਸ ਸਟੇਟ ਲਈ CartContext ਰੱਖੋ। ਜੇਕਰ ਕੋਈ ਯੂਜ਼ਰ ਆਪਣਾ ਡਿਸਪਲੇਅ ਨਾਮ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ ਹੈਡਰ ਪ੍ਰੋਡਕਟ ਗਰਿੱਡ ਨੂੰ ਛੇੜੇ ਬਿਨਾਂ ਅਪਡੇਟ ਹੋ ਜਾਵੇਗਾ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਸ ਗੱਲ ਦਾ ਧਿਆਨ ਰੱਖੋ ਕਿ ਤੁਸੀਂ Provider value ਪ੍ਰੌਪ ਵਿੱਚ ਕੀ ਪਾਸ ਕਰ ਰਹੇ ਹੋ। ਜੇਕਰ ਤੁਸੀਂ ਰੈਂਡਰ ਦੌਰਾਨ ਇਨਲਾਈਨ { theme, toggleTheme } ਵਰਗਾ ਆਬਜੈਕਟ ਲਿਟਰਲ ਪਾਸ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਹਰ ਰੈਂਡਰ 'ਤੇ ਇੱਕ ਨਵੀਂ ਰੈਫਰੈਂਸ ਬਣਾਉਂਦੇ ਹੋ ਅਤੇ ਬੇਲੋੜੇ ਅਪਡੇਟ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹੋ। ਜੇਕਰ ਵੈਲਯੂ ਵਿੱਚ ਫੰਕਸ਼ਨ ਜਾਂ non-primitive ਡੇਟਾ ਹੈ, ਤਾਂ useMemo ਨਾਲ ਉਸ ਰੂਪ ਨੂੰ ਸਥਿਰ (stabilize) ਕਰੋ।

ਉਹ ਗਲਤੀਆਂ ਜੋ ਘੰਟਿਆਂ ਬਰਬਾਦ ਕਰਦੀਆਂ ਹਨ

ਦੋ ਗਲਤੀਆਂ ਟੀਮਾਂ ਨੂੰ ਵਾਰ-ਵਾਰ ਫਸਾਉਂਦੀਆਂ ਹਨ।

ਕੰਟੈਕਸਟ ਆਬਜੈਕਟ ਨੂੰ ਐਕਸਪੋਰਟ ਕਰਨਾ ਭੁੱਲ ਜਾਣਾ। ThemeProvider ਕੰਪੋਨੈਂਟ ਨੂੰ ਐਕਸਪੋਰਟ ਕਰਨਾ ਅਤੇ ਫਿਰ useContext(ThemeProvider) ਨੂੰ ਕਾਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਆਸਾਨ ਹੈ। ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਨਹੀਂ ਕਰਦਾ। Hook ਨੂੰ createContext ਦੁਆਰਾ ਰਿਟਰਨ ਕੀਤੇ ਗਏ ਕੰਟੈਕਸਟ ਆਬਜੈਕਟ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਨਾ ਕਿ ਵੈਪਰ (wrapper) ਕੰਪੋਨੈਂਟ ਦੀ। ਜੇਕਰ ਤੁਸੀਂ ਸਿਰਫ਼ Provider ਨੂੰ ਐਕਸਪੋਰਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੇ ਕੰਜ਼ਿਊਮਰਾਂ ਕੋਲ ਇੰਪੋਰਟ ਕਰਨ ਲਈ ਕੁਝ ਨਹੀਂ ਹੋਵੇਗਾ।

useContext ਨੂੰ ਇਸਦੇ Provider ਤੋਂ ਬਾਹਰ ਕਾਲ ਕਰਨਾ। Hook ਉਹ ਡਿਫੌਲਟ ਵੈਲਯੂ ਰਿਟਰਨ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ createContext ਨੂੰ ਦਿੱਤੀ ਸੀ। ਜੇਕਰ ਤੁਸੀਂ ਡਿਫੌਲਟ ਵੈਲਯੂ ਨਹੀਂ ਦਿੱਤੀ, ਤਾਂ ਤੁਹਾਨੂੰ undefined ਮਿਲੇਗਾ। ਜੇਕਰ ਤੁਹਾਡਾ ਕੰਪੋਨੈਂਟ ਟ੍ਰੀ ਕੰਜ਼ਿਊਮਰ ਨੂੰ Provider ਨਾਲੋਂ ਉੱਚੇ DOM ਪੱਧਰ 'ਤੇ ਰੈਂਡਰ ਕਰਦਾ ਹੈ, ਜਾਂ ਜੇਕਰ Provider ਪੂਰੀ ਤਰ੍ਹਾਂ ਗਾਇਬ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ ਡੇਟਾ ਸਿਰਫ਼ ਨਹੀਂ ਪਹੁੰਚੇਗਾ। ਦੋ ਵਾਰ ਚੈੱਕ ਕਰੋ ਕਿ ਤੁਹਾਡੀ index ਜਾਂ root ਫਾਈਲ ਅਸਲ ਵਿੱਚ ਐਪ ਨੂੰ ਵੈਰਪ (wrap) ਕਰਦੀ ਹੈ।

ਅਸਲ ਸਿੱਖਿਆ

React Context ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ ਵਿੱਚ ਕੋਈ ਕ੍ਰਾਂਤੀ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਖਾਸ ਸਪੇਸ਼ੀਅਲ ਸਮੱਸਿਆ ਲਈ ਇੱਕ ਨਿਸ਼ਾਨਾ ਟੂਲ ਹੈ: ਹਰ ਪਰਤ ਨੂੰ ਡਾਕਘਰ ਬਣਾਏ ਬਿਨਾਂ ਦੂਰ ਦੇ ਕੰਪੋਨੈਂਟਾਂ ਤੱਕ ਡੇਟਾ ਪਹੁੰਚਾਉਣਾ। ਇਸਦੀ ਵਰਤੋਂ ਸੱਚਮੁੱਚ ਗਲੋਬਲ ਡੇਟਾ ਲਈ ਕਰੋ, ਰੈਂਡਰਿੰਗ ਪਰਫਾਰਮੈਂਸ ਨੂੰ ਬਚਾਉਣ ਲਈ ਆਪਣੇ ਕੰਟੈਕਸਟਾਂ ਨੂੰ ਡੋਮੇਨ ਅਨੁਸਾਰ ਵੰਡ ਕੇ ਰੱਖੋ, ਅਤੇ ਸਿਗਨਲ ਪੜ੍ਹਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹਮੇਸ਼ਾ ਆਪਣੇ ਟ੍ਰੀ ਨੂੰ ਸਹੀ Provider ਨਾਲ ਵੈਰਪ ਕਰੋ। ਇਹਨਾਂ ਆਦਤਾਂ ਨੂੰ ਅਪਣਾਓ, ਅਤੇ ਤੁਹਾਡੇ ਕੰਪੋਨੈਂਟ ਟ੍ਰੀ ਸਾਫ਼, ਤੇਜ਼ ਅਤੇ ਸਮਝਣ ਵਿੱਚ ਆਸਾਨ ਰਹਿਣਗੇ।