ಪ್ರತಿಯೊಬ್ಬ React ಡೆವಲಪರ್ ಅಂತಿಮವಾಗಿ ಒಂದೇ ಪ್ರಶ್ನೆಯನ್ನು ಎದುರಿಸುತ್ತಾರೆ: ನಾನು Context ಬಳಸಬೇಕೇ ಅಥವಾ ಇದು Redux ಸಮಸ್ಯೆಯೇ? ನೀವು ಕೇವಲ ಕೆಲವು ತಿಂಗಳುಗಳಿಂದ ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿದ್ದರೆ, ಆನ್ಲೈನ್ನಲ್ಲಿನ ಗೊಂದಲಗಳು ಇದು ಯಾವುದಾದರೂ ಒಂದನ್ನು ಮಾತ್ರ ಆರಿಸಿಕೊಳ್ಳಬೇಕಾದ ನಿರ್ಧಾರ ಎಂದು ತಿಳಿಸುತ್ತವೆ. ಕೆಲವು ಟ್ಯುಟೋರಿಯಲ್ಗಳು Redux ಅನ್ನು ಹಳೆಯ ಕಾಲದ ಹೊರೆಯೆಂದು ಪರಿಗಣಿಸುತ್ತವೆ. ಇನ್ನು ಕೆಲವು Context ಒಂದು to-do ಲಿಸ್ಟ್ಗಿಂತ ಹೆಚ್ಚು ವಿಸ್ತರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಎಚ್ಚರಿಸುತ್ತವೆ. ಈ ಎರಡೂ ತೀವ್ರವಾದ ಅಭಿಪ್ರಾಯಗಳು ಸಹಕಾರಿಯಲ್ಲ. ಸತ್ಯವೇನೆಂದರೆ, ಈ ಪರಿಕರಗಳು ವಿಭಿನ್ನ ರೀತಿಯ ತಲೆನೋವುಗಳನ್ನು ಪರಿಹರಿಸುತ್ತವೆ ಮತ್ತು ನೀವು ಬುದ್ಧಿವಂತಿಕೆಯಿಂದ ಆಯ್ಕೆ ಮಾಡುವುದು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ವಾಸ್ತವವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ.
The Prop Drilling Problem
ನೀವು state management ತಂತ್ರವನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು, ಈ ಎರಡೂ ಪರಿಕರಗಳು ಯಾವ ಸಮಸ್ಯೆಯನ್ನು ಗುಣಪಡಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಸಹಕಾರಿಯಾಗಿದೆ. ನೀವು ಒಂದು e-commerce ಸೈಟ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ನೀವು ಬಳಕೆದಾರರ ಪ್ರೊಫೈಲ್ ಅನ್ನು top-level App component ನಲ್ಲಿ ಪಡೆಯುತ್ತೀರಿ. ಕೆಳಗಿನ footer ನಲ್ಲಿರುವ ಒಂದು ಸಣ್ಣ AccountLink component ಗೆ ಆ ಪ್ರೊಫೈಲ್ ಚಿತ್ರದ ಅಗತ್ಯವಿದೆ. ಗ್ಲೋಬಲ್ ಸ್ಟೋರ್ ಇಲ್ಲದಿದ್ದರೆ, user object ಎಂಬುದು Home, ನಂತರ Header, ನಂತರ NavContainer, ನಂತರ UserDropdown ಮತ್ತು ಅಂತಿಮವಾಗಿ AccountLink ಮೂಲಕ ಪ್ರಯಾಣಿಸಬೇಕಾಗುತ್ತದೆ. ಮಧ್ಯದಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಪದರವು ತಾನು ಬಳಸದ ಡೇಟಾವನ್ನು ಸ್ಪರ್ಶಿಸುತ್ತದೆ. ಇದನ್ನೇ prop drilling ಎನ್ನಲಾಗುತ್ತದೆ.
Prop drilling ಮಾಡ್ಯೂಲ್ಗಳನ್ನು (components) ಅಸ್ಥಿರವಾಗಿಸುತ್ತದೆ. Refactoring ಮಾಡುವುದು ಅಪಾಯಕಾರಿಯಾಗುತ್ತದೆ ಏಕೆಂದರೆ ಮಧ್ಯದ ಒಂದು link ಅನ್ನು ತೆಗೆದರೆ ಇಡೀ ಸರಪಳಿ ತಪ್ಪಿಹೋಗುತ್ತದೆ. Reusability ಕುಂಠಿತವಾಗುತ್ತದೆ ಏಕೆಂದರೆ components ಕೇವಲ ಕೆಳಮಟ್ಟಕ್ಕೆ ವರ್ಗಾಯಿಸುವ props ಗಳನ್ನು ಕೇಳುತ್ತವೆ. Context ಮತ್ತು Redux ಎರಡೂ ದೂರದ components ಗಳು ನೇರವಾಗಿ ಹಂಚಿಕೆಯ ಡೇಟಾವನ್ನು ಪಡೆಯಲು (subscribe ಮಾಡಲು) ಅನುಮತಿಸುವ ಮೂಲಕ ಇದನ್ನು ನಿವಾರಿಸುತ್ತವೆ. ಆದರೆ ಅವು ಡೇಟಾವನ್ನು ತಲುಪಿಸುವ ವಿಧಾನ ಮತ್ತು ಅದಕ್ಕೆ ತಗಲುವ ವೆಚ್ಚವು ಬೇರೆಯಾಗಿರುತ್ತದೆ.
When React Context API Is the Right Fit
React Context ಅನ್ನು ಲೈಬ್ರರಿಯಲ್ಲೇ ಅಳವಡಿಸಲಾಗಿದೆ. ಯಾವುದೇ ಹೆಚ್ಚುವರಿ npm ಇನ್ಸ್ಟಾಲ್ಗಳು, build ಕಾನ್ಫಿಗರೇಶನ್ ಅಥವಾ boilerplate ಫೈಲ್ಗಳ ಅಗತ್ಯವಿಲ್ಲ. ನೀವು ಒಂದು context ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ರಚಿಸುತ್ತೀರಿ, ನಿಮ್ಮ tree ನ ಒಂದು ಭಾಗವನ್ನು Provider ನಲ್ಲಿ ಸುತ್ತುತ್ತೀರಿ ಮತ್ತು ಯಾವುದೇ nested component ನಲ್ಲಿ useContext ಮೂಲಕ ಮೌಲ್ಯವನ್ನು ಬಳಸುತ್ತೀರಿ. ಆ ಸರಳತೆಯ ಕಾರಣದಿಂದಾಗಿ, state ಬದಲಾವಣೆಗಳು ಅಪರೂಪವಾಗಿ ನಡೆಯುವ ಮತ್ತು state ನ ರಚನೆಯು ಸರಳವಾಗಿರುವ ಸಣ್ಣ ಅಥವಾ ಮಧ್ಯಮ ಗಾತ್ರದ ಪ್ರಾಜೆಕ್ಟ್ಗಳಲ್ಲಿ Context ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
UI themes ಬಗ್ಗೆ ಯೋಚಿಸಿ. ಬಳಕೆದಾರರು ಒಂದು ಸೆಷನ್ನಲ್ಲಿ ಬಹುಶಃ ಒಂದು ಬಾರಿ ಮಾತ್ರ light ಮತ್ತು dark mode ನಡುವೆ ಬದಲಾಯಿಸುತ್ತಾರೆ. ಈ ಮೌಲ್ಯವು ಪ್ರತಿಯೊಂದು styled component ಗೆ ಹರಡುತ್ತದೆ, ಆದರೆ ಅದು ಎಷ್ಟು ಅಪರೂಪವಾಗಿ ಬದಲಾಗುತ್ತದೆ ಎಂದರೆ ಕಾರ್ಯಕ್ಷಮತೆಯ (performance) ಕಾಳಜಿಗಳು ಕಂಡುಬರುವುದಿಲ್ಲ. Authentication status ಮತ್ತೊಂದು ಉತ್ತಮ ಉದಾಹರಣೆ. ಬಳಕೆದಾರರು ಒಮ್ಮೆ ಲಾಗ್ ಇನ್ ಆದ ನಂತರ, isAuthenticated ಫ್ಲಾಗ್ ಮತ್ತು user ಆಬ್ಜೆಕ್ಟ್ ಡಜನ್ಗಟ್ಟಲೆ ಪೇಜ್ ನ್ಯಾವಿಗೇಷನ್ಗಳಾದ್ಯಂತ ಸ್ಥಿರವಾಗಿರುತ್ತವೆ. ಭಾಷೆ ಅಥವಾ localization ಸೆಟ್ಟಿಂಗ್ಗಳು ಕೂಡ ಇದೇ ರೀತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಇವು ವಿಶಾಲವಾದ, ನಿಧಾನವಾಗಿ ಚಲಿಸುವ ಸಂಕೇತಗಳಾಗಿದ್ದು, ಅನೇಕ components ಗೆ ಇವುಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ, ಆದರೆ ಕೆಲವೇ ಕೆಲವು components ಇವುಗಳನ್ನು ಬದಲಾಯಿಸುತ್ತವೆ (mutate).
ಆದರೆ ಇಲ್ಲಿನ ಸಮಸ್ಯೆ ಎಂದರೆ Context ಅಪ್ಡೇಟ್ಗಳನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದು. ಒಂದು Context Provider ನ ಮೌಲ್ಯವು ಬದಲಾದಾಗ, ಆ context ಅನ್ನು ಬಳಸುವ ಪ್ರತಿಯೊಂದು component ಅನ್ನು React ಮತ್ತೆ ರಿಸೆಂಡರ್ (re-render) ಮಾಡುತ್ತದೆ. ಸಣ್ಣ ಅಪ್ಲಿಕೇಶನ್ನಲ್ಲಿ, ನೀವು ಇದನ್ನು ಗಮನಿಸುವುದಿಲ್ಲ. ದೊಡ್ಡ ಅಪ್ಲಿಕೇಶನ್ನಲ್ಲಿ, ನೀವು ವೇಗವಾಗಿ ಬದಲಾಗುವ ಡೇಟಾವನ್ನು ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲಾಗುವ Context ಒಳಗೆ ಇರಿಸಿದರೆ, ಅನಗತ್ಯ ರಿಸೆಂಡರ್ಗಳ ಸುರಿಮಳೆಯಾಗುತ್ತದೆ. ನೀವು ಅಸ್ಥಿರತೆಯನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು context ಗಳನ್ನು ವಿಂಗಡಿಸಬಹುದು, ಆದರೆ ಆ ಹಂತದಲ್ಲಿ ನೀವು ಬೇರೆ ಪರಿಕರವು ಈಗಾಗಲೇ ಪರಿಹರಿಸಿರುವ ಆಪ್ಟಿಮೈಸೇಶನ್ ಕೆಲಸಗಳನ್ನು ಮ್ಯಾನುಯಲ್ ಆಗಿ ಮಾಡುತ್ತಿರುತ್ತೀರಿ.
When Redux Toolkit Earns Its Place
Redux Toolkit ಅನ್ನು state ಸಂಕೀರ್ಣವಾಗಿದ್ದಾಗ, ಅಪ್ಡೇಟ್ಗಳು ಪದೇ ಪದೇ ನಡೆಯುತ್ತಿದ್ದಾಗ ಮತ್ತು ಒಂದೇ ಡೇಟಾವನ್ನು ಹಲವಾರು ದೂರದ ಫೀಚರ್ಗಳು ಘರ್ಷಣೆಯಿಲ್ಲದೆ ಓದಲು ಮತ್ತು ಬರೆಯಲು ಅಗತ್ಯವಿರುವ ಅಪ್ಲಿಕೇಶನ್ಗಳಿಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಒಂದು shopping cart ಅನ್ನು ಪರಿಗಣಿಸಿ. ಬಳಕೆದಾರರು ಒಂದು product card ನಿಂದ ಐಟಂ ಅನ್ನು ಸೇರಿಸುತ್ತಾರೆ. header ನಲ್ಲಿರುವ cart icon ತನ್ನ badge count ಅನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡಬೇಕು. line items ತೋರಿಸಲು ಒಂದು sidebar ಹೊರಬರುತ್ತದೆ. discount code ಇನ್ಪುಟ್ ವ್ಯಾಲಿಡೇಶನ್ ಮಾಡುತ್ತದೆ. ನಂತರ checkout ಪೇಜ್ ಕಾರ್ಟ್ನ ವಿಷಯಗಳನ್ನು ಓದುತ್ತದೆ. ಆ state ಅನ್ನು ಇಡೀ tree ನಲ್ಲಿರುವ ಸಂಬಂಧವಿಲ್ಲದ components ಬಳಸುತ್ತವೆ ಮತ್ತು ಅದು ಪದೇ ಪದೇ ಬದಲಾಗುತ್ತದೆ.
Redux Toolkit ಇದನ್ನು ಕೇಂದ್ರೀಕೃತ store ಮತ್ತು state ನ ಸ್ಪಷ್ಟ slices ಮೂಲಕ ಪರಿಹರಿಸುತ್ತದೆ. Components useSelector ಬಳಸಿ ತಮಗೆ ಬೇಕಾದ ಡೇಟಾದ ಸಣ್ಣ ಭಾಗಗಳಿಗೆ ಮಾತ್ರ ಸಬ್ಸ್ಕ್ರೈಬ್ ಆಗುತ್ತವೆ. ರಿಯಲ್-ಟೈಮ್ ಡ್ಯಾಶ್ಬೋರ್ಡ್ನಲ್ಲಿ ಸ್ಟಾಕ್ ಬೆಲೆ ಅಪ್ಡೇಟ್ ಆದರೆ, ಬಳಕೆದಾರರ ಪ್ರೊಫೈಲ್ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ತೋರಿಸುವ component ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. Redux ಒಳಗಿನಿಂದ reference equality ಚೆಕ್ಗಳನ್ನು ಬಳಸುತ್ತದೆ ಇದರಿಂದ ಸಬ್ಸ್ಕ್ರಿಪ್ಶನ್ಗಳು ಅತ್ಯಂತ ನಿಖರವಾಗಿರುತ್ತವೆ (granular). ನಿಮ್ಮ component ಸಂಖ್ಯೆಯು ನೂರಾರು ತಲುಪಿದಾಗ ಇದು ಬಹಳ ಮುಖ್ಯವಾಗುತ್ತದೆ.
Redux ನಿಮಗೆ ಊಹಿಸಬಹುದಾದ (predictable) ಡೇಟಾ ಫ್ಲೋ ಅನ್ನು ನೀಡುತ್ತದೆ. State ಬದಲಾವಣೆಗಳು reducers ಮೂಲಕ ನಿರ್ವಹಿಸಲ್ಪಡುವ dispatched actions ಮೂಲಕ ನಡೆಯುತ್ತವೆ. ಇದು ತಾಂತ್ರಿಕ ಪದಗಳಂತೆ (jargon) ಕೇಳಿಸಬಹುದು, ಆದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಇದರರ್ಥ ನೀವು ನಿಮ್ಮ codebase ನಲ್ಲಿ addToCart ಅನ್ನು ಹುಡುಕುವ ಮೂಲಕ ಕಾರ್ಟ್ ಅನ್ನು ಮಾರ್ಪಡಿಸುವ ಪ್ರತಿಯೊಂದು ಕೋಡ್ ಪಾತ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚಬಹುದು ಎಂದರ್ಥ. ದೊಡ್ಡ ತಂಡದಲ್ಲಿ, ಈ ನಿಯಮವು ಬಗ್ಗಳನ್ನು ತಡೆಯುತ್ತದೆ. ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, Context ಎಂಬುದು ಕೇವಲ ಒಂದು ಮೌಲ್ಯ ಮತ್ತು setter ಆಗಿದೆ. ಯಾವುದೇ ಕನ್ಸ್ಯೂಮರ್ setState ಅನ್ನು ಕರೆಯಬಹುದು, ಮತ್ತು ತಪ್ಪಾದ ಮೌಲ್ಯದ ಮೂಲವನ್ನು ಪತ್ತೆಹಚ್ಚುವುದು ಎಂದರೆ ಅನೇಕ components ನಲ್ಲಿ ಬ್ರೇಕ್ಪಾಯಿಂಟ್ಗಳನ್ನು (breakpoints) ಹಾಕಬೇಕಾಗುತ್ತದೆ ಎಂದರ್ಥ.
Where They Really Diverge
ಕಾರ್ಯಕ್ಷಮತೆಯ ಗುಣಲಕ್ಷಣಗಳು ಇವುಗಳನ್ನು ಎಲ್ಲಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಬೇರ್ಪಡಿಸುತ್ತವೆ. Context ಎಲ್ಲಾ ಬಳಕೆದಾರರಿಗೆ (consumers) ಯಾವುದೇ ಷರತ್ತುಗಳಿಲ್ಲದೆ ಹೊಸ ಮೌಲ್ಯವನ್ನು ಪ್ರಸಾರ ಮಾಡುತ್ತದೆ. Redux ತನ್ನ ಆಯ್ಕೆಯಾದ slice ಬದಲಾದಾಗ ಮಾತ್ರ ಸಂಬಂಧಿತ subscribers ಗೆ ಸೂಚನೆ ನೀಡುತ್ತದೆ. ನೀವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಕೋಟ್ಗಳು ರಿಫ್ರೆಶ್ ಆಗುವ ರಿಯಲ್-ಟೈಮ್ ಸ್ಟಾಕ್ ಡ್ಯಾಶ್ಬೋರ್ಡ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, Context ಇಡೀ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಮರು-ರೆಂಡರ್ (global re-render) ಮಾಡುವಂತೆ ಒತ್ತಾಯಿಸುತ್ತದೆ. Redux ಕೇವಲ ಟಿಕರ್ ಸೆಲ್ ಮತ್ತು ಸ್ಪಾರ್ಕ್ಲೈನ್ ಚಾರ್ಟ್ ಅನ್ನು ಮಾತ್ರ ಮರು-ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಬಿಡುತ್ತದೆ.
Debugging ಎಂಬುದು ಸಂಕೀರ್ಣ ಅಪ್ಲಿಕೇಶನ್ಗಳಲ್ಲಿ Redux ಮುನ್ನಡೆ ಸಾಧಿಸುವ ಮತ್ತೊಂದು ಕ್ಷೇತ್ರವಾಗಿದೆ. Redux DevTools ನಿಮಗೆ time-travel debugging ಅನ್ನು ನೀಡುತ್ತದೆ. ನೀವು ಪ್ರತಿಯೊಂದು dispatched action ಮೂಲಕ ಹಿಂದಕ್ಕೆ ಹೋಗಬಹುದು ಮತ್ತು state ಹೇಗೆ ಹಿಂದಕ್ಕೆ ಹೋಗುತ್ತದೆ ಎಂಬುದನ್ನು ವೀಕ್ಷಿಸಬಹುದು. ಶಿಪ್ಪಿಂಗ್ ಲೆಕ್ಕಾಚಾರಗಳು, ಪಾವತಿ ವ್ಯಾಲಿಡೇಶನ್ ಮತ್ತು ಎರರ್ ರಿಕವರಿ ಇರುವ ಮಲ್ಟಿ-ಸ್ಟೆಪ್ ಚೆಕ್ಔಟ್ ಫ್ಲೋನಲ್ಲಿ, ಬಗ್ಗೆ ಕಾರಣವಾದ ನಿಖರವಾದ ಸರಣಿಯನ್ನು ಮರುಕಳಿಸುವುದು (replay) ಅತ್ಯಂತ ಅಮೂಲ್ಯವಾಗಿದೆ. Context ಪ್ರಮಾಣಿತ React DevTools ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ನೀವು ಪ್ರಸ್ತುತ context ಮೌಲ್ಯಗಳನ್ನು ಪರೀಕ್ಷಿಸಬಹುದು, ಆದರೆ ಇದರಲ್ಲಿ ಬಿಲ್ಟ್-ಇನ್ action log ಅಥವಾ state diff viewer ಇಲ್ಲ. ಅಂತಿಮವಾಗಿ ನೀವು ಮತ್ತೆ console logs ಬಳಸಬೇಕಾಗುತ್ತದೆ.
Middleware ಮತ್ತು side effects ಎಂಬವು Redux ನ ಮೂಲಭೂತ ಅಂಶಗಳಾಗಿವೆ. Redux Toolkit createAsyncThunk ಅನ್ನು ಒಳಗೊಂಡಿದೆ ಮತ್ತು data-fetching ಲೈಬ್ರರಿಗಳೊಂದಿಗೆ ಸುಲಭವಾಗಿ ಸಂಯೋಜನೆಗೊಳ್ಳುತ್ತದೆ. ನೀವು API ಕಾಲ್ ಮಾಡುವುದು, ಲೋಡಿಂಗ್ ಸ್ಪಿನರ್ ತೋರಿಸುವುದು, ನೆಟ್ವರ್ಕ್ ವೈಫಲ್ಯವನ್ನು ನಿರ್ವಹಿಸುವುದು ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ಕ್ಯಾಶ್ ಮಾಡುವುದನ್ನು Redux ಡೇಟಾ ಫ್ಲೋವಿನಲ್ಲೇ ಮಾಡಬಹುದು. Context ಅಸಮಕಾಲಿಕ ತರ್ಕಕ್ಕೆ (asynchronous logic) ಯಾವುದೇ ಬಿಲ್ಟ್-ಇನ್ ಮಾದರಿಯನ್ನು ನೀಡುವುದಿಲ್ಲ. ನೀವು ಕಾಮಪೊನೆಂಟ್ಗಳ ಒಳಗೆ ಡೇಟಾವನ್ನು ಪಡೆದು ನಂತರ ಫಲಿತಾಂಶವನ್ನು Context ಗೆ ಕಳುಹಿಸಬಹುದು ಅಥವಾ ಸ್ವಂತ async ಯುಟಿಲಿಟಿಗಳ ಮೂಲಕ providers ಅನ್ನು ಸುತ್ತಬಹುದು. ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಇದು ಅಲ್ಪಕಾಲಿಕ ಅಥವಾ ಅಸ್ತವ್ಯಸ್ತವಾದ (ad hoc) ವಿಧಾನವಾಗಿದೆ.
Setup ವೆಚ್ಚದ ವಿಷಯದಲ್ಲಿ Context ಸ್ಪಷ್ಟವಾಗಿ ಗೆಲ್ಲುತ್ತದೆ. ಒಂದು theme provider ಅನ್ನು ನಿರ್ಮಿಸಲು ಸುಮಾರು ಐದು ನಿಮಿಷಗಳು ಬೇಕಾಗುತ್ತವೆ. Redux Toolkit ಗೆ ಒಂದು store ಫೈಲ್ ರಚಿಸುವುದು, slices ವ್ಯಾಖ್ಯಾನಿಸುವುದು ಮತ್ತು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು Provider ನಲ್ಲಿ ಸುತ್ತುವುದು ಅಗತ್ಯವಿದೆ. ಹಳೆಯ Redux ಮತ್ತು ಅದರ ಅತಿಯಾದ boilerplate ಕೋಡ್ನಿಂದಾಗಿ ಇದು ವಾರಗಟ್ಟಲೆ ತೆಗೆದುಕೊಳ್ಳುವ ಕೆಲಸವಾಗಿರಲಿಲ್ಲ, ಆದರೂ ಇದು Context ಗಿಂತ ಹೆಚ್ಚಿನ ಸೆಟಪ್ ಅನ್ನು ಬಯಸುತ್ತದೆ. ವೀಕೆಂಡ್ ಸೈಡ್ ಪ್ರಾಜೆಕ್ಟ್ ಅಥವಾ ಮೂರು ರೂಟ್ಗಳಿರುವ ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗೆ, ಈ ಹೆಚ್ಚಿನ ಕೆಲಸವು ಪ್ರಯೋಜನಕಾರಿಯಾಗದಿರಬಹುದು.
ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್ನಲ್ಲಿ ಎರಡನ್ನೂ ಬಳಸುವುದು
ನೀವು ಯಾವುದಾದರೊಂದು ಗುಂಪಿಗೆ ಮಾತ್ರ ಬದ್ಧರಾಗಿರಬೇಕೆಂದಿಲ್ಲ. ಅನೇಕ ಪ್ರೊಡಕ್ಷನ್ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಗ್ಲೋಬಲ್ UI ಶೆಲ್ ವಿಷಯಗಳಿಗಾಗಿ Context ಅನ್ನು ಮತ್ತು ಡೊಮೇನ್-ಭಾರಿತ ಬಿಸಿನೆಸ್ ಡೇಟಾಕ್ಕಾಗಿ Redux ಅನ್ನು ಬಳಸುತ್ತವೆ. ಥೀಮ್, ಲೋಕೇಲ್ ಮತ್ತು ಬಹುಶಃ ಲೈಟ್ವೇಯ್ಟ್ auth ಫ್ಲ್ಯಾಗ್ ಅನ್ನು Context ನಲ್ಲಿ ಇಡುವುದು ಒಂದು ಸಾಮಾನ್ಯ ಮಾದರಿಯಾಗಿದೆ, ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದು ರೂಟ್ಗೂ ಇವು ಬೇಕಾಗುತ್ತವೆ ಮತ್ತು ಇವು ಅಪರೂಪವಾಗಿ ಬದಲಾಗುತ್ತವೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಆರ್ಡರ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್ ಸಿಸ್ಟಮ್, ನೋಟಿಫಿಕೇಶನ್ ಸೆಂಟರ್ ಮತ್ತು ಡೇಟಾ ಟೇಬಲ್ಗಳು Redux ನಲ್ಲಿ ಇರುತ್ತವೆ, ಏಕೆಂದರೆ ಅಲ್ಲಿ ಪದೇ ಪದೇ ಅಪ್ಡೇಟ್ಗಳು ಮತ್ತು ಕ್ರಾಸ್-ಕಾಂಪೊನೆಂಟ್ ಲಾಜಿಕ್ ನಿಖರವಾದ ನಿಯಂತ್ರಣವನ್ನು ಬಯಸುತ್ತವೆ.
ಈ ಹೈಬ್ರಿಡ್ ವಿಧಾನವು ಸ್ಟ್ಯಾಟಿಕ್ ಥೀಮ್ ಆಬ್ಜೆಕ್ಟ್ ಸುತ್ತ ಪೂರ್ಣ Redux store ಅನ್ನು ಹೇರದೆ, ಸರಳ ವಿಷಯಗಳನ್ನು ಸರಳವಾಗಿಡುತ್ತದೆ. ಇದು ನಿಮ್ಮ Redux slices ಗಳಲ್ಲಿ ಅನಗತ್ಯ UI ಅಂಶಗಳು ತುಂಬದಂತೆ ತಡೆಯುತ್ತದೆ, ಏಕೆಂದರೆ ಅವುಗಳಿಗೆ ಮೊದಲೇ ಇಂಡಸ್ಟ್ರಿಯಲ್-ಗ್ರೇಡ್ ಸ್ಟೇಟ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ.
ನಿಜವಾದ ಸಾರಾಂಶ
ಹೆಚ್ಚು ಭಾರವಾದ ಪರಿಕರವನ್ನು (tool) ಆರಿಸಿಕೊಳ್ಳುವುದು ದೊಡ್ಡ ಸಾಧನೆಯಲ್ಲ. ನಿಮ್ಮ state ಎಷ್ಟು ಬಾರಿ ಬದಲಾಗುತ್ತದೆ, ಎಷ್ಟು ಕಾಮಪೊನೆಂಟ್ಗಳು ಅದನ್ನು ಬಳಸುತ್ತವೆ ಮತ್ತು ತಂಡದ ಮಿತಿಗಳ ಆಚೆಗೂ ಬದಲಾವಣೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವ (trace mutations) ಅಗತ್ಯವಿದೆಯೇ ಎಂಬುದನ್ನು ನೋಡುವುದರ ಮೂಲಕ ಪ್ರಾರಂಭಿಸಿ. ನೀವು ಮಧ್ಯಮ ಗಾತ್ರದ ಅಪ್ಲಿಕೇಶನ್ನಲ್ಲಿ ನಿಧಾನವಾಗಿ ಬದಲಾಗುವ, ವ್ಯಾಪಕವಾಗಿ ಹಂಚಿಕೆಯಾದ ಮೌಲ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ, Context ಬಹುಶಃ ಸಾಕಾಗುತ್ತದೆ. ನಿಮ್ಮ state ಪದೇ ಪದೇ ಬದಲಾಗುತ್ತಿದ್ದರೆ, ಸಂಬಂಧವಿಲ್ಲದ ಫೀಚರ್ಗಳಿಗೆ ವ್ಯಾಪಿಸಿರಬೇಕಾದರೆ ಮತ್ತು ಸ್ಪಷ್ಟವಾದ ಆಡಿಟ್ ಟ್ರೈಲ್ (audit trail) ಅಗತ್ಯವಿದ್ದರೆ, Redux Toolkit ನಿಮ್ಮ ಕೆಲಸವನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ.
ಕಾನ್ಫರೆನ್ಸ್ ಮಾತುಕತೆಗಳು ಅಥವಾ GitHub ಸ್ಟಾರ್ಗಳ ಆಧಾರದ ಮೇಲೆ ಅಲ್ಲದೆ, ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ನ ಅಗತ್ಯಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಆಯ್ಕೆ ಮಾಡಿ. ಐವತ್ತು ಐಟಂಗಳನ್ನು ಹೊಂದಿರುವ ಶಾಪಿಂಗ್ ಕಾರ್ಟ್ ಅಂದರೆ ತಕ್ಷಣವೇ Redux ಬೇಕೆಂದಿಲ್ಲ, ಮತ್ತು ಥೀಮ್ ಟೋಗಲ್ ಗೆ ಗ್ಲೋಬಲ್ ಸ್ಟೋರ್ ಅಗತ್ಯವಿಲ್ಲ. ಸಮಸ್ಯೆಗೆ ತಕ್ಕಂತೆ ಪರಿಕರವನ್ನು ಆರಿಸಿ, ಆಗ ನಿಮ್ಮ ಕೋಡ್ಬೇಸ್ ದೀರ್ಘಕಾಲದವರೆಗೆ ಸುಲಭವಾಗಿ ನಿರ್ವಹಣೆಗೆ ಲಭ್ಯವಿರುತ್ತದೆ.