Most frontend code treats asynchronous work like a single shape. You kick off a Promise, wait for it to resolve, dump th

ಹೆಚ್ಚಿನ ಫ್ರಂಟ್‌ಎಂಡ್ ಕೋಡ್ ಅಸಿಂಕ್ರೋನಸ್ ಕೆಲಸವನ್ನು ಒಂದೇ ರೀತಿಯ ರೂಪದಲ್ಲಿ ಪರಿಗಣಿಸುತ್ತದೆ. ನೀವು ಒಂದು Promise ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ, ಅದು resolve ಆಗುವವರೆಗೆ ಕಾಯುತ್ತೀರಿ, ಫಲಿತಾಂಶವನ್ನು ಲೋಕಲ್ ಸ್ಟೇಟ್‌ಗೆ ಹಾಕುತ್ತೀರಿ ಮತ್ತು ಫ್ರೇಮ್‌ವರ್ಕ್ ವ್ಯತ್ಯಾಸಗಳನ್ನು (diff) ಹೊಂದಾಣಿಕೆ ಮಾಡಲು ಬಿಡುತ್ತೀರಿ. ಈ ಮಾದರಿಯು ಎಲ್ಲೆಡೆ ಕೆಲಸ ಮಾಡುವುದರಿಂದ ಇದು ಆಕರ್ಷಕವಾಗಿ ಕಾಣುತ್ತದೆ: ಒಂದು REST ಕಾಲ್, ಫಾರ್ಮ್ ಸಬ್ಮಿಷನ್ ಅಥವಾ WebSocket ಸಂದೇಶ. ಇವೆಲ್ಲವೂ ಒಂದೇ useEffect ಅಥವಾ ಇವೆಂಟ್ ಹ್ಯಾಂಡ್ಲರ್‌ನಲ್ಲಿ ಬರುತ್ತವೆ, ಎಲ್ಲವೂ setState ಮೂಲಕ ಪೈಪ್‌ಲೈನ್ ಆಗುತ್ತವೆ ಮತ್ತು ನೋಡಲು ಒಂದೇ ರೀತಿಯ ಅಸಿಂಕ್ರೋನಸ್ ಪ್ಲಂಬಿಂಗ್‌ನಂತೆ ಕಾಣುತ್ತವೆ. ಈ ಏಕರೂಪತೆಯೇ ಒಂದು ಬಲೆ. ನೈಜ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ, ಎಲ್ಲಾ ಅಸಿಂಕ್ರೋನಸ್ ಕೆಲಸಗಳು ಒಂದೇ ರೀತಿ ಇರುವುದಿಲ್ಲ. ಹಾಗೆ ಇವೆಂದು ನಂಬುವುದು ನಿಮ್ಮ UI ಘಟಕಗಳನ್ನು (components) ಅಕಸ್ಮಾತ್ ಡೇಟಾ ಆರ್ಕಿಟೆಕ್ಟ್‌ಗಳನ್ನಾಗಿ ಮಾಡುತ್ತದೆ, ಇವುಗಳನ್ನು useEffect ಹುಕ್‌ಗಳು ಮತ್ತು ಅನಿಶ್ಚಿತತೆಯೊಂದಿಗೆ ಕೇವಲ ಅಂಟಿಸಿ ಜೋಡಿಸಲಾಗಿರುತ್ತದೆ.

ಅಸಿಂಕ್ರೋನಸ್ ಕಾರ್ಯಾಚರಣೆಗಳು ವಾಸ್ತವವಾಗಿ ಮೂರು ವಿಭಿನ್ನ ವಿಧಗಳಾಗಿವೆ. ಪ್ರತಿಯೊಂದಕ್ಕೂ ಸಮಯ, ಕ್ಯಾಶಿಂಗ್ ಮತ್ತು ಮಾಲೀಕತ್ವದೊಂದಿಗೆ (ownership) ವಿಭಿನ್ನ ಸಂಬಂಧವಿದೆ. ಇವುಗಳನ್ನು ಗುರುತಿಸುವುದನ್ನು ಕಲಿಯುವುದು ಫ್ರಂಟ್‌ಎಂಡ್ ಅನ್ನು ವೇಗವಾಗಿ, ನಿಖರವಾಗಿ ಮತ್ತು ಸುಸ್ಥಿತಿಯಲ್ಲಿಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

Queries: ವಿಳಾಸವಿರುವ ಸತ್ಯಗಳು

ಕ್ವೇರಿ ಎಂದರೆ ಕೇವಲ ಒಂದು ಫೆಚ್ (fetch) ಅಲ್ಲ. ಇದು ಗುರುತಿಸಬಹುದಾದ ಸತ್ಯಕ್ಕಾಗಿ ಮಾಡುವ ವಿನಂತಿ. ನೀವು "ಕೆಲವು ಬಳಕೆದಾರರ ಡೇಟಾ" ಎಂದು ಕೇಳುತ್ತಿಲ್ಲ, ಬದಲಾಗಿ /user/123 ಅನ್ನು ಕೇಳುತ್ತಿದ್ದೀರಿ. ಈ ವ್ಯತ್ಯಾಸವು ಮುಖ್ಯವಾಗಿದೆ ಏಕೆಂದರೆ ಗುರುತಿಸುವಿಕೆಯು (identity) ಕ್ಯಾಶಿಂಗ್ ಅನ್ನು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ. ಒಂದೇ ಪರದೆಯ ಮೇಲಿರುವ ಎರಡು ಘಟಕಗಳಿಗೆ ಒಂದೇ ಬಳಕೆದಾರರ ರೆಕಾರ್ಡ್ ಅಗತ್ಯವಿದ್ದರೆ, ಅವು ಒಂದೇ ಉತ್ತರವನ್ನು ಹಂಚಿಕೊಳ್ಳಬೇಕು. ಪ್ರತಿಯೊಂದು ಘಟಕವು useState ನಲ್ಲಿ ತನ್ನದೇ ಆದ ಲೋಕಲ್ ಕಾಪಿಯನ್ನು ಇಟ್ಟುಕೊಂಡಾಗ, ನೀವು ಸತ್ಯವನ್ನು ವಿಭಜಿಸುತ್ತೀರಿ. ಹೆಡರ್‌ನಲ್ಲಿರುವ ಅವತಾರ್ ಮತ್ತು ಸೈಡ್‌ಬಾರ್‌ನಲ್ಲಿರುವ ಹೆಸರುಗಳು ಬೇರೆ ಬೇರೆ ಸಮಯದಲ್ಲಿ ಫೆಚ್ ಮಾಡಲ್ಪಟ್ಟಿದ್ದರಿಂದ ಅಥವಾ ಒಂದು ಫೇಲ್ ಆಗಿ ಇನ್ನೊಂದು ಸಕ್ಸಸ್ ಆಗಿದ್ದರಿಂದ ಅವುಗಳ ನಡುವೆ ವ್ಯತ್ಯಾಸ ಉಂಟಾಗುತ್ತದೆ.

ಕ್ವೇರಿಯನ್ನು ಒಂದು ಕ್ರಿಯೆಯಾಗಿ (action) ನೋಡುವ ಬದಲು ಒಂದು ಸಂಪನ್ಮೂಲವಾಗಿ (resource) ಭಾವಿಸಿ. ಅದಕ್ಕೆ ಒಂದು ಕ್ಯಾಶ್ ಕೀ (cache key), ಫ್ರೆಶ್‌ನೆಸ್ ಪಾಲಿಸಿ (freshness policy) ಮತ್ತು ಯಾವುದೇ ಏಕೈಕ ಘಟಕಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಾಲ ಬಾಳಿಕೆ ಬರುವ ಜೀವನಚಕ್ರ (lifecycle) ಇರುತ್ತದೆ. ಉತ್ತಮವಾಗಿ ನಿರ್ಮಿಸಲಾದ ಕ್ವೇರಿ ಲೇಯರ್, /projects?page=2 ಅನ್ನು ಓದುವುದು /projects?page=3 ಅನ್ನು ಓದುವುದಕ್ಕಿಂತ ಭಿನ್ನವಾಗಿದೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ. ಪ್ರತಿಯೊಂದು URL ಮತ್ತು ಪ್ಯಾರಾಮೀಟರ್ ಸೆಟ್ ಒಂದು ವಿಳಾಸವನ್ನು ರೂಪಿಸುತ್ತದೆ, ಮತ್ತು ಆ ವಿಳಾಸದಲ್ಲಿರುವ ಡೇಟಾ ಹಳೆಯದಾಗಿರಬಹುದು (stale), ತಾಜಾ ಇರಬಹುದು (fresh) ಅಥವಾ ಇಲ್ಲದಿರಬಹುದು. ಈ ಲೆಕ್ಕಪತ್ರವನ್ನು (bookkeeping) UI ನಿರ್ವಹಿಸಬಾರದು. ಅದು ಡೇಟಾ ಲೇಯರ್‌ನಿಂದ user:123 ಅನ್ನು ಕೇಳಬೇಕು ಮತ್ತು ಅದರ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಅನ್ನು ಪಡೆಯಬೇಕು. ಆ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಎರಡು ಸೆಕೆಂಡುಗಳ ಹಿಂದೆ ಸರ್ವರ್‌ನಿಂದ ಬಂದಿದೆಯೇ ಅಥವಾ ಎರಡು ಮಿಲಿಸೆಕೆಂಡುಗಳ ಹಿಂದೆ ಕ್ಯಾಶ್‌ನಿಂದ ಬಂದಿದೆಯೇ ಎಂಬುದು ಘಟಕದ ವಿಷಯವಲ್ಲ.

ಇದರ ಪ್ರಾಯೋಗಿಕ ಪರಿಣಾಮ ತಕ್ಷಣವೇ ಗೋಚರಿಸುತ್ತದೆ. ನೀವು ಪ್ರತಿಯೊಂದು ರೀಡ್ ಅನ್ನು ಘಟಕದ ಒಳಗಿನ ಇಂಪೆರೇಟಿವ್ ಫೆಚ್ (imperative fetch) ಎಂದು ಪರಿಗಣಿಸಿದಾಗ, ನೀವು ಡಿಡೂಪ್ಲಿಕೇಶನ್ (deduplication) ಅನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ. ಬ್ಯಾಕ್‌ಗ್ರೌಂಡ್ ರಿಫ್ರೆಶ್ ಅನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ. ಬ್ಯಾಕ್‌ಗ್ರೌಂಡ್‌ನಲ್ಲಿ ಡೇಟಾವನ್ನು ವ್ಯಾಲಿಡೇಟ್ ಮಾಡುವಾಗ ಕ್ಯಾಶ್ ಮಾಡಿದ ಡೇಟಾವನ್ನು ತಕ್ಷಣವೇ ತೋರಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ. ಕ್ವೇರಿಯು ನಿಮ್ಮ UI ಟ್ರೀ ಹೊರಗಿನ ಒಂದು ಮನೆಯನ್ನು ಅರ್ಹವಾಗಿರಿಸಿಕೊಳ್ಳುತ್ತದೆ.

Mutations: ಜಗತ್ತನ್ನು ಬದಲಾಯಿಸುವುದು

ಕ್ವೇರಿಗಳು ಜಗತ್ತಿನ ಬಗ್ಗೆ ಕೇಳಿದರೆ, ಮ್ಯುಟೇಶನ್‌ಗಳು ಅದನ್ನು ಬದಲಾಯಿಸುತ್ತವೆ. ನೈಜ ನೆಟ್‌ವರ್ಕ್ ವಿನಂತಿ—POST, PUT, ಅಥವಾ DELETE—ಸಾಮಾನ್ಯವಾಗಿ ಸುಲಭವಾದ ಭಾಗವಾಗಿದೆ. ಸರ್ವರ್ "OK" ಎಂದು ಹೇಳಿದ ನಂತರ ನಡೆಯುವ ಎಲ್ಲವೂ ಕಷ್ಟದ ಭಾಗವಾಗಿದೆ.

ಬಳಕೆದಾರರು ತಮ್ಮ ಡಿಸ್‌ಪ್ಲೇ ಹೆಸರನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡುತ್ತಾರೆ ಎಂದು ಭಾವಿಸೋಣ. ಮ್ಯುಟೇಶನ್ ಸ್ವತಃ ಒಂದು ಸಿಂಗಲ್ ರಿಕ್ವೆಸ್ಟ್ ಆಗಿದೆ. ಆದರೆ ಅದರ ಪರಿಣಾಮವು (blast radius) ಎಲ್ಲೆಡೆ ಇರುತ್ತದೆ. ಪ್ರೊಫೈಲ್ ಪೇಜ್ ಹಳೆಯ ಹೆಸರನ್ನು ಹೊಂದಿರುತ್ತದೆ. ನ್ಯಾವಿಗೇಷನ್ ಬಾರ್ ಹಳೆಯ ಹೆಸರನ್ನು ತೋರಿಸುತ್ತದೆ. ಕಾಮೆಂಟ್ ಹಿಸ್ಟರಿಯು ಅದನ್ನು ಉಲ್ಲೇಖಿಸಿರಬಹುದು. ನಿಮ್ಮ ಮ್ಯುಟೇಶನ್ ಕೋಡ್ ಕೇವಲ ಒಂದು ಲೋಕಲ್ isLoading ಫ್ಲಾಗ್ ಅನ್ನು ಬದಲಾಯಿಸುವುದು ಮತ್ತು ನಂತರ ಒಂದು ಸ್ಟೇಟ್ ಅನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡುವುದ除此之外 ಬೇರೇನೂ ಮಾಡದಿದ್ದರೆ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಈಗ ತನಗೆ ತಾನೇ ಸುಳ್ಳು ಹೇಳುತ್ತಿದೆ ಎಂದರ್ಥ. UI ನ ಕೆಲವು ಭಾಗಗಳು ಬದಲಾವಣೆ ನಡೆದಿದೆ ಎಂದು ನಂಬುತ್ತವೆ. ಇತರ ಭಾಗಗಳಿಗೆ ಏನೂ ಬದಲಾಗಿಲ್ಲ ಎಂಬ ಅರಿವೇ ಇರುವುದಿಲ್ಲ.

ಮ್ಯುಟೇಶನ್ ತನ್ನ ಡೇಟಾ ಗ್ರಾಫ್ ಮೇಲಿನ ಪ್ರಭಾವವನ್ನು ಘೋಷಿಸಬೇಕು. ಯಾವ ಕ್ವೇರಿಗಳು ಈಗ ಅಮಾನ್ಯವಾಗಿವೆ (invalid), ಯಾವ ಕ್ಯಾಶ್ಡ್ ಕೀಗಳನ್ನು ಮರು-ಫೆಚ್ (refetch) ಮಾಡಬೇಕಾಗಿದೆ ಮತ್ತು ಯಾವ ಸಂಬಂಧಗಳು ಬದಲಾಗಿವೆ ಎಂಬುದನ್ನು ಅದು ಸಿಸ್ಟಮ್‌ಗೆ ತಿಳಿಸಬೇಕು. ಇದು ಮೂಲಭೂತವಾಗಿ ಕ್ವೇರಿಯಿಂದ ಭಿನ್ನವಾಗಿದೆ. ಕ್ವೇರಿಯು ಕೇವಲ ಓದಲು ಮಾತ್ರ (read-only) ಮತ್ತು ಹಂಚಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುವಂತದ್ದು. ಮ್ಯುಟೇಶನ್ ಬರವಣಿಗೆಗೆ ಕೇಂದ್ರೀಕೃತವಾಗಿದೆ (write-focused) ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕ್ಯಾಶ್‌ಗಳಿಗೆ ವಿನಾಶಕಾರಿಯಾಗಿದೆ. ಇವೆರಡನ್ನೂ ಒಂದೇ ಅಬ್‌ಸ್ಟ್ರಾಕ್ಷನ್ ಆಗಿ ನೋಡಿದಾಗ, ಡೆವಲಪರ್‌ಗಳು ಯಾದೃಚ್ಛಿಕ ಘಟಕಗಳ ಒಳಗೆ ಮ್ಯಾನುಯಲ್ ಆಗಿ refetch() ಅನ್ನು ಕರೆಯಬೇಕಾಗುತ್ತದೆ, ಅಥವಾ ಅದಕ್ಕಿಂತ ಕೆಟ್ಟದಾಗಿ, ಲೋಕಲ್ ಸ್ಟೇಟ್ ಅನ್ನು ಸರ್ವರ್‌ನೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆ ಮಾಡಲು (sync) ಇಡೀ ಟ್ರೀ ಉದ್ದಕ್ಕೂ useEffect ಹುಕ್‌ಗಳನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ.

ಮಾಲೀಕತ್ವದ ಮಾದರಿಯೂ (ownership model) ವಿಭಿನ್ನವಾಗಿದೆ. ಕ್ವೇರಿಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಕ್ಯಾಶ್ ನಿರ್ವಹಿಸುತ್ತದೆ. ಮ್ಯುಟೇಶನ್ ಅದನ್ನು ಪ್ರಚೋದಿಸಿದ ಬಳಕೆದಾರರ ಕ್ರಿಯೆಯ ಮೂಲಕ ನಿರ್ಧರಿಸಲ್ಪಡುತ್ತದೆ. ಅದಕ್ಕೆ ಪೆಂಡಿಂಗ್ ಸ್ಟೇಟ್, ಎರರ್ ಸ್ಟೇಟ್ ಮತ್ತು ಸಂಭಾವ್ಯವಾಗಿ ಒಂದು ಆಪ್ಟಿಮಿಸ್ಟಿಕ್ ವ್ಯಾಲ್ಯೂ ಇರುತ್ತದೆ, ಅದನ್ನು ರೋಲ್