ರಿಯಾಕ್ಟ್ನ ಕಾರ್ಯಕ್ಷಮತೆಯ ಹಿಂದಿನ ಮ್ಯಾಜಿಕ್ ಅನ್ನು ಅನ್ಲಾಕ್ ಮಾಡಿ. ಈ ಸಮಗ್ರ ಮಾರ್ಗದರ್ಶಿ Reconciliation ಅಲ್ಗಾರಿದಮ್, ವರ್ಚುವಲ್ DOM ಡಿಫಿಂಗ್ ಮತ್ತು ಪ್ರಮುಖ ಆಪ್ಟಿಮೈಸೇಶನ್ ತಂತ್ರಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.
ರಿಯಾಕ್ಟ್ನ ರಹಸ್ಯ: Reconciliation ಅಲ್ಗಾರಿದಮ್ ಮತ್ತು ವರ್ಚುವಲ್ DOM ಡಿಫಿಂಗ್ನ ಆಳವಾದ ನೋಟ
ಆಧುನಿಕ ವೆಬ್ ಡೆವಲಪ್ಮೆಂಟ್ ಜಗತ್ತಿನಲ್ಲಿ, ರಿಯಾಕ್ಟ್ ಡೈನಾಮಿಕ್ ಮತ್ತು ಇಂಟರಾಕ್ಟಿವ್ ಯೂಸರ್ ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಒಂದು ಪ್ರಬಲ ಶಕ್ತಿಯಾಗಿ ತನ್ನನ್ನು ತಾನು ಸ್ಥಾಪಿಸಿಕೊಂಡಿದೆ. ಅದರ ಜನಪ್ರಿಯತೆಯು ಕೇವಲ ಅದರ ಕಾಂಪೊನೆಂಟ್-ಆಧಾರಿತ ಆರ್ಕಿಟೆಕ್ಚರ್ನಿಂದಲ್ಲ, ಬದಲಿಗೆ ಅದರ ಅದ್ಭುತ ಕಾರ್ಯಕ್ಷಮತೆಯಿಂದ ಬಂದಿದೆ. ಆದರೆ ರಿಯಾಕ್ಟ್ ಅನ್ನು ಅಷ್ಟು ವೇಗವಾಗಿಸುವುದು ಯಾವುದು? ಉತ್ತರ ಮ್ಯಾಜಿಕ್ ಅಲ್ಲ; ಇದು Reconciliation ಅಲ್ಗಾರಿದಮ್ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಒಂದು ಅದ್ಭುತ ಇಂಜಿನಿಯರಿಂಗ್ ಕೌಶಲ್ಯ.
ಅನೇಕ ಡೆವಲಪರ್ಗಳಿಗೆ, ರಿಯಾಕ್ಟ್ನ ಆಂತರಿಕ ಕಾರ್ಯಗಳು ಒಂದು ಕಪ್ಪು ಪೆಟ್ಟಿಗೆಯಿದ್ದಂತೆ. ನಾವು ಕಾಂಪೊನೆಂಟ್ಗಳನ್ನು ಬರೆಯುತ್ತೇವೆ, ಸ್ಟೇಟ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತೇವೆ ಮತ್ತು UI ದೋಷರಹಿತವಾಗಿ ಅಪ್ಡೇಟ್ ಆಗುವುದನ್ನು ನೋಡುತ್ತೇವೆ. ಆದಾಗ್ಯೂ, ಈ ಸುಗಮ ಪ್ರಕ್ರಿಯೆಯ ಹಿಂದಿನ ಯಾಂತ್ರಿಕತೆಗಳನ್ನು, ವಿಶೇಷವಾಗಿ ವರ್ಚುವಲ್ DOM ಮತ್ತು ಅದರ ಡಿಫಿಂಗ್ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು, ಒಬ್ಬ ಉತ್ತಮ ರಿಯಾಕ್ಟ್ ಡೆವಲಪರ್ ಅನ್ನು ಶ್ರೇಷ್ಠ ಡೆವಲಪರ್ನಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ. ಈ ಆಳವಾದ ಜ್ಞಾನವು ನಿಮಗೆ ಹೆಚ್ಚು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಬರೆಯಲು, ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಡಚಣೆಗಳನ್ನು ಡೀಬಗ್ ಮಾಡಲು ಮತ್ತು ಲೈಬ್ರರಿಯನ್ನು ನಿಜವಾಗಿಯೂ ಕರಗತ ಮಾಡಿಕೊಳ್ಳಲು ಅಧಿಕಾರ ನೀಡುತ್ತದೆ.
ಈ ಸಮಗ್ರ ಮಾರ್ಗದರ್ಶಿಯು ರಿಯಾಕ್ಟ್ನ ಪ್ರಮುಖ ರೆಂಡರಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ. ನೇರ DOM ಮ್ಯಾನಿಪ್ಯುಲೇಷನ್ ಏಕೆ ದುಬಾರಿಯಾಗಿದೆ, ವರ್ಚುವಲ್ DOM ಹೇಗೆ ಒಂದು ಸೊಗಸಾದ ಪರಿಹಾರವನ್ನು ಒದಗಿಸುತ್ತದೆ, ಮತ್ತು Reconciliation ಅಲ್ಗಾರಿದಮ್ ನಿಮ್ಮ UI ಅನ್ನು ಹೇಗೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಅಪ್ಡೇಟ್ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ಅನ್ವೇಷಿಸುತ್ತೇವೆ. ಮೂಲ ಸ್ಟಾಕ್ Reconciler ನಿಂದ ಆಧುನಿಕ ಫೈಬರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ವರೆಗಿನ ವಿಕಾಸವನ್ನು ಸಹ ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ ಮತ್ತು ನಿಮ್ಮ ಸ್ವಂತ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲು ನೀವು ಇಂದು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಕಾರ್ಯತಂತ್ರಗಳೊಂದಿಗೆ ಮುಕ್ತಾಯಗೊಳಿಸುತ್ತೇವೆ.
ಮೂಲ ಸಮಸ್ಯೆ: ನೇರ DOM ಮ್ಯಾನಿಪ್ಯುಲೇಷನ್ ಏಕೆ ಅಸಮರ್ಥವಾಗಿದೆ
ರಿಯಾಕ್ಟ್ನ ಪರಿಹಾರವನ್ನು ಶ್ಲಾಘಿಸಲು, ಅದು ಪರಿಹರಿಸುವ ಸಮಸ್ಯೆಯನ್ನು ನಾವು ಮೊದಲು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಡಾಕ್ಯುಮೆಂಟ್ ಆಬ್ಜೆಕ್ಟ್ ಮಾಡೆಲ್ (DOM) ಎನ್ನುವುದು HTML ಡಾಕ್ಯುಮೆಂಟ್ಗಳನ್ನು ಪ್ರತಿನಿಧಿಸಲು ಮತ್ತು ಅವುಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಬಳಸುವ ಬ್ರೌಸರ್ API ಆಗಿದೆ. ಇದು ಆಬ್ಜೆಕ್ಟ್ಗಳ ಟ್ರೀ (ಮರ) ರಚನೆಯಲ್ಲಿದ್ದು, ಇಲ್ಲಿ ಪ್ರತಿಯೊಂದು ನೋಡ್ ಡಾಕ್ಯುಮೆಂಟ್ನ ಒಂದು ಭಾಗವನ್ನು (ಉದಾಹರಣೆಗೆ ಎಲಿಮೆಂಟ್, ಟೆಕ್ಸ್ಟ್, ಅಥವಾ ಅಟ್ರಿಬ್ಯೂಟ್) ಪ್ರತಿನಿಧಿಸುತ್ತದೆ.
ನೀವು ಪರದೆಯ ಮೇಲೆ ಏನನ್ನಾದರೂ ಬದಲಾಯಿಸಲು ಬಯಸಿದಾಗ, ನೀವು ಈ DOM ಟ್ರೀಯನ್ನು ಮ್ಯಾನಿಪ್ಯುಲೇಟ್ ಮಾಡುತ್ತೀರಿ. ಉದಾಹರಣೆಗೆ, ಹೊಸ ಲಿಸ್ಟ್ ಐಟಂ ಅನ್ನು ಸೇರಿಸಲು, ನೀವು ಹೊಸ `
- ` ನೋಡ್ಗೆ ಸೇರಿಸುತ್ತೀರಿ. ಇದು ನೇರವಾಗಿ ಕಂಡರೂ, DOM ಕಾರ್ಯಾಚರಣೆಗಳು ಗಣನಾತ್ಮಕವಾಗಿ ದುಬಾರಿಯಾಗಿರುತ್ತವೆ. ಇದಕ್ಕೇ ಕಾರಣ:
- ಲೇಔಟ್ ಮತ್ತು ರಿಫ್ಲೋ: ನೀವು ಒಂದು ಎಲಿಮೆಂಟ್ನ ಜ್ಯಾಮಿತಿಯನ್ನು (ಅದರ ಅಗಲ, ಎತ್ತರ, ಅಥವಾ ಸ್ಥಾನದಂತಹ) ಬದಲಾಯಿಸಿದಾಗ, ಬ್ರೌಸರ್ ಎಲ್ಲಾ ಪೀಡಿತ ಎಲಿಮೆಂಟ್ಗಳ ಸ್ಥಾನಗಳು ಮತ್ತು ಆಯಾಮಗಳನ್ನು ಮರುಲೆಕ್ಕಾಚಾರ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು "ರಿಫ್ಲೋ" ಅಥವಾ "ಲೇಔಟ್" ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಇದು ಇಡೀ ಡಾಕ್ಯುಮೆಂಟ್ನಾದ್ಯಂತ ಹರಡಬಹುದು, ಇದರಿಂದಾಗಿ ಗಮನಾರ್ಹ ಸಂಸ್ಕರಣಾ ಶಕ್ತಿಯನ್ನು ಬಳಸಿಕೊಳ್ಳುತ್ತದೆ.
- ರಿಪೇಂಟಿಂಗ್: ರಿಫ್ಲೋ ಆದ ನಂತರ, ಬ್ರೌಸರ್ ಅಪ್ಡೇಟ್ ಆದ ಎಲಿಮೆಂಟ್ಗಳಿಗಾಗಿ ಪರದೆಯ ಮೇಲೆ ಪಿಕ್ಸೆಲ್ಗಳನ್ನು ಮರು-ಚಿತ್ರಿಸಬೇಕಾಗುತ್ತದೆ. ಇದನ್ನು "ರಿಪೇಂಟಿಂಗ್" ಅಥವಾ "ರಾಸ್ಟರೈಸಿಂಗ್" ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಹಿನ್ನೆಲೆ ಬಣ್ಣದಂತಹ ಸರಳವಾದದ್ದನ್ನು ಬದಲಾಯಿಸುವುದು ಕೇವಲ ರಿಪೇಂಟ್ ಅನ್ನು ಪ್ರಚೋದಿಸಬಹುದು, ಆದರೆ ಲೇಔಟ್ ಬದಲಾವಣೆಯು ಯಾವಾಗಲೂ ರಿಪೇಂಟ್ ಅನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ.
- ಸಿಂಕ್ರೊನಸ್ ಮತ್ತು ಬ್ಲಾಕಿಂಗ್: DOM ಕಾರ್ಯಾಚರಣೆಗಳು ಸಿಂಕ್ರೊನಸ್ ಆಗಿರುತ್ತವೆ. ನಿಮ್ಮ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಕೋಡ್ DOM ಅನ್ನು ಮಾರ್ಪಡಿಸಿದಾಗ, ಬ್ರೌಸರ್ ರಿಫ್ಲೋ ಮತ್ತು ರಿಪೇಂಟ್ ಮಾಡಲು ಬಳಕೆದಾರರ ಇನ್ಪುಟ್ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವುದು ಸೇರಿದಂತೆ ಇತರ ಕಾರ್ಯಗಳನ್ನು ಆಗಾಗ್ಗೆ ವಿರಾಮಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ, ಇದು ನಿಧಾನಗತಿಯ ಅಥವಾ ಸ್ಥಗಿತಗೊಂಡ ಯೂಸರ್ ಇಂಟರ್ಫೇಸ್ಗೆ ಕಾರಣವಾಗಬಹುದು.
- ಆರಂಭಿಕ ರೆಂಡರ್: ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಮೊದಲು ಲೋಡ್ ಆದಾಗ, ರಿಯಾಕ್ಟ್ ನಿಮ್ಮ UI ಗಾಗಿ ಸಂಪೂರ್ಣ ವರ್ಚುವಲ್ DOM ಟ್ರೀಯನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಬಳಸಿ ಆರಂಭಿಕ ನಿಜವಾದ DOM ಅನ್ನು ರಚಿಸುತ್ತದೆ.
- ಸ್ಟೇಟ್ ಅಪ್ಡೇಟ್: ಅಪ್ಲಿಕೇಶನ್ನ ಸ್ಟೇಟ್ ಬದಲಾದಾಗ (ಉದಾಹರಣೆಗೆ, ಬಳಕೆದಾರರು ಬಟನ್ ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ), ರಿಯಾಕ್ಟ್ ಹೊಸ ಸ್ಟೇಟ್ ಅನ್ನು ಪ್ರತಿಬಿಂಬಿಸುವ ಹೊಸ ವರ್ಚುವಲ್ DOM ಟ್ರೀಯನ್ನು ರಚಿಸುತ್ತದೆ.
- ಡಿಫಿಂಗ್: ರಿಯಾಕ್ಟ್ ಈಗ ಮೆಮೊರಿಯಲ್ಲಿ ಎರಡು ವರ್ಚುವಲ್ DOM ಟ್ರೀಗಳನ್ನು ಹೊಂದಿದೆ: ಹಳೆಯದು (ಸ್ಟೇಟ್ ಬದಲಾವಣೆಯ ಮೊದಲು) ಮತ್ತು ಹೊಸದು. ನಂತರ ಅದು ಈ ಎರಡು ಟ್ರೀಗಳನ್ನು ಹೋಲಿಸಲು ಮತ್ತು ನಿಖರವಾದ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಗುರುತಿಸಲು ತನ್ನ "ಡಿಫಿಂಗ್" ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಚಲಾಯಿಸುತ್ತದೆ.
- ಬ್ಯಾಚಿಂಗ್ ಮತ್ತು ಅಪ್ಡೇಟಿಂಗ್: ರಿಯಾಕ್ಟ್ ನಿಜವಾದ DOM ಅನ್ನು ಹೊಸ ವರ್ಚುವಲ್ DOM ಗೆ ಹೊಂದಿಸಲು ಬೇಕಾದ ಅತ್ಯಂತ ಸಮರ್ಥ ಮತ್ತು ಕನಿಷ್ಠ ಕಾರ್ಯಾಚರಣೆಗಳ ಗುಂಪನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ. ಈ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಒಟ್ಟಿಗೆ ಸೇರಿಸಿ (ಬ್ಯಾಚ್) ಮತ್ತು ಒಂದೇ, ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ ಅನುಕ್ರಮದಲ್ಲಿ ನಿಜವಾದ DOM ಗೆ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ.
- ಇದು ಸಂಪೂರ್ಣ ಹಳೆಯ ಟ್ರೀಯನ್ನು ಕೆಡವುತ್ತದೆ, ಎಲ್ಲಾ ಹಳೆಯ ಕಾಂಪೊನೆಂಟ್ಗಳನ್ನು ಅನ್ಮೌಂಟ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅವುಗಳ ಸ್ಟೇಟ್ ಅನ್ನು ನಾಶಪಡಿಸುತ್ತದೆ.
- ಇದು ಹೊಸ ಎಲಿಮೆಂಟ್ ಪ್ರಕಾರವನ್ನು ಆಧರಿಸಿ ಸಂಪೂರ್ಣವಾಗಿ ಹೊಸ ಟ್ರೀಯನ್ನು ಮೊದಲಿನಿಂದ ನಿರ್ಮಿಸುತ್ತದೆ.
- ಐಟಂ B
- ಐಟಂ C
- ಐಟಂ A
- ಐಟಂ B
- ಐಟಂ C
- ಇದು ಇಂಡೆಕ್ಸ್ 0 ರಲ್ಲಿನ ಹಳೆಯ ಐಟಂ ('ಐಟಂ B') ಅನ್ನು ಇಂಡೆಕ್ಸ್ 0 ರಲ್ಲಿನ ಹೊಸ ಐಟಂ ('ಐಟಂ A') ನೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ. ಅವು ವಿಭಿನ್ನವಾಗಿವೆ, ಆದ್ದರಿಂದ ಇದು ಮೊದಲ ಐಟಂ ಅನ್ನು ರೂಪಾಂತರಿಸುತ್ತದೆ.
- ಇದು ಇಂಡೆಕ್ಸ್ 1 ರಲ್ಲಿನ ಹಳೆಯ ಐಟಂ ('ಐಟಂ C') ಅನ್ನು ಇಂಡೆಕ್ಸ್ 1 ರಲ್ಲಿನ ಹೊಸ ಐಟಂ ('ಐಟಂ B') ನೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ. ಅವು ವಿಭಿನ್ನವಾಗಿವೆ, ಆದ್ದರಿಂದ ಇದು ಎರಡನೇ ಐಟಂ ಅನ್ನು ರೂಪಾಂತರಿಸುತ್ತದೆ.
- ಇದು ಇಂಡೆಕ್ಸ್ 2 ರಲ್ಲಿ ಹೊಸ ಐಟಂ ('ಐಟಂ C') ಇರುವುದನ್ನು ನೋಡುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಸೇರಿಸುತ್ತದೆ.
- ಐಟಂ B
- ಐಟಂ C
- ಐಟಂ A
- ಐಟಂ B
- ಐಟಂ C
- ರಿಯಾಕ್ಟ್ ಹೊಸ ಪಟ್ಟಿಯ ಮಕ್ಕಳನ್ನು ನೋಡುತ್ತದೆ ಮತ್ತು 'b' ಮತ್ತು 'c' ಕೀಗಳೊಂದಿಗೆ ಎಲಿಮೆಂಟ್ಗಳನ್ನು ಹುಡುಕುತ್ತದೆ.
- 'b' ಮತ್ತು 'c' ಕೀಗಳೊಂದಿಗಿನ ಎಲಿಮೆಂಟ್ಗಳು ಈಗಾಗಲೇ ಹಳೆಯ ಪಟ್ಟಿಯಲ್ಲಿವೆ ಎಂದು ಅದಕ್ಕೆ ತಿಳಿದಿದೆ, ಆದ್ದರಿಂದ ಅದು ಅವುಗಳನ್ನು ಸರಳವಾಗಿ ಚಲಿಸುತ್ತದೆ.
- ಹಿಂದೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರದ 'a' ಕೀ ಹೊಂದಿರುವ ಹೊಸ ಎಲಿಮೆಂಟ್ ಇರುವುದನ್ನು ಅದು ನೋಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದು ಅದನ್ನು ರಚಿಸಿ ಸೇರಿಸುತ್ತದೆ.
- ... )`) ಒಂದು ಆಂಟಿ-ಪ್ಯಾಟರ್ನ್ ಆಗಿದೆ, ಒಂದು ವೇಳೆ ಪಟ್ಟಿಯನ್ನು ಮರು-ಜೋಡಿಸಬಹುದಾದರೆ, ಫಿಲ್ಟರ್ ಮಾಡಬಹುದಾದರೆ, ಅಥವಾ ಮಧ್ಯದಿಂದ ಐಟಂಗಳನ್ನು ಸೇರಿಸಬಹುದು/ತೆಗೆದುಹಾಕಬಹುದಾದರೆ, ಏಕೆಂದರೆ ಇದು ಕೀ ಇಲ್ಲದಿರುವಂತೆಯೇ ಅದೇ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ನಿಮ್ಮ ಡೇಟಾದಿಂದ ಬರುವ ಅನನ್ಯ ಗುರುತಿಸುವಿಕೆಗಳು, ಉದಾಹರಣೆಗೆ ಡೇಟಾಬೇಸ್ ID, ಅತ್ಯುತ್ತಮ ಕೀಗಳಾಗಿವೆ.
- ಹೆಚ್ಚುತ್ತಿರುವ ರೆಂಡರಿಂಗ್: ಇದು ರೆಂಡರಿಂಗ್ ಕೆಲಸವನ್ನು ಸಣ್ಣ ತುಂಡುಗಳಾಗಿ ವಿಭಜಿಸಿ ಅದನ್ನು ಅನೇಕ ಫ್ರೇಮ್ಗಳ ಮೇಲೆ ಹರಡಬಹುದು.
- ಆದ್ಯತೆ: ಇದು ವಿವಿಧ ರೀತಿಯ ಅಪ್ಡೇಟ್ಗಳಿಗೆ ವಿಭಿನ್ನ ಆದ್ಯತೆಯ ಮಟ್ಟಗಳನ್ನು ನಿಯೋಜಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ಇನ್ಪುಟ್ ಫೀಲ್ಡ್ನಲ್ಲಿ ಬಳಕೆದಾರರು ಟೈಪ್ ಮಾಡುವುದು ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಡೇಟಾ ತರುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯನ್ನು ಹೊಂದಿರುತ್ತದೆ.
- ವಿರಾಮ ಮತ್ತು ರದ್ದತಿ ಸಾಮರ್ಥ್ಯ: ಇದು ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯ ಕೆಲಸವನ್ನು ನಿರ್ವಹಿಸಲು ಕಡಿಮೆ ಆದ್ಯತೆಯ ಅಪ್ಡೇಟ್ನ ಕೆಲಸವನ್ನು ವಿರಾಮಗೊಳಿಸಬಹುದು, ಮತ್ತು ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿಲ್ಲದ ಕೆಲಸವನ್ನು ರದ್ದುಗೊಳಿಸಬಹುದು ಅಥವಾ ಮರುಬಳಕೆ ಮಾಡಬಹುದು.
- ರೆಂಡರ್/Reconciliation ಹಂತ (ಅಸಿಂಕ್ರೊನಸ್): ಈ ಹಂತದಲ್ಲಿ, ರಿಯಾಕ್ಟ್ ಫೈಬರ್ ನೋಡ್ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿ "ವರ್ಕ್-ಇನ್-ಪ್ರೋಗ್ರೆಸ್" ಟ್ರೀಯನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ. ಇದು ಕಾಂಪೊನೆಂಟ್ `render` ವಿಧಾನಗಳನ್ನು ಕರೆಯುತ್ತದೆ ಮತ್ತು DOM ಗೆ ಯಾವ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಬೇಕೆಂದು ನಿರ್ಧರಿಸಲು ಡಿಫಿಂಗ್ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಚಲಾಯಿಸುತ್ತದೆ. ನಿರ್ಣಾಯಕವಾಗಿ, ಈ ಹಂತವು ಅಡ್ಡಿಪಡಿಸಬಹುದಾದದ್ದು. ರಿಯಾಕ್ಟ್ ಹೆಚ್ಚು ಮುಖ್ಯವಾದದ್ದನ್ನು ನಿರ್ವಹಿಸಲು ಈ ಕೆಲಸವನ್ನು ವಿರಾಮಗೊಳಿಸಬಹುದು ಮತ್ತು ನಂತರ ಅದನ್ನು ಪುನರಾರಂಭಿಸಬಹುದು. ಇದನ್ನು ಅಡ್ಡಿಪಡಿಸಬಹುದಾದ್ದರಿಂದ, ಅಸಮಂಜಸವಾದ UI ಸ್ಟೇಟ್ ಅನ್ನು ತಪ್ಪಿಸಲು ರಿಯಾಕ್ಟ್ ಈ ಹಂತದಲ್ಲಿ ಯಾವುದೇ ನಿಜವಾದ DOM ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸುವುದಿಲ್ಲ.
- ಕಮಿಟ್ ಹಂತ (ಸಿಂಕ್ರೊನಸ್): ವರ್ಕ್-ಇನ್-ಪ್ರೋಗ್ರೆಸ್ ಟ್ರೀ ಪೂರ್ಣಗೊಂಡ ನಂತರ, ರಿಯಾಕ್ಟ್ ಕಮಿಟ್ ಹಂತವನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆ. ಇದು ಲೆಕ್ಕಾಚಾರ ಮಾಡಿದ ಬದಲಾವಣೆಗಳನ್ನು ತೆಗೆದುಕೊಂಡು ಅವುಗಳನ್ನು ನಿಜವಾದ DOM ಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. ಈ ಹಂತವು ಸಿಂಕ್ರೊನಸ್ ಮತ್ತು ಅಡ್ಡಿಪಡಿಸಲಾಗದ್ದು. ಇದು ಬಳಕೆದಾರರು ಯಾವಾಗಲೂ ಸ್ಥಿರವಾದ UI ಅನ್ನು ನೋಡುವುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ. `componentDidMount` ಮತ್ತು `componentDidUpdate` ನಂತಹ ಲೈಫ್ಸೈಕಲ್ ವಿಧಾನಗಳು, ಹಾಗೆಯೇ `useLayoutEffect` ಮತ್ತು `useEffect` ಹುಕ್ಗಳು ಈ ಹಂತದಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳ್ಳುತ್ತವೆ.
- `React.memo()`: ಫಂಕ್ಷನ್ ಕಾಂಪೊನೆಂಟ್ಗಳಿಗಾಗಿ ಇರುವ ಹೈಯರ್-ಆರ್ಡರ್ ಕಾಂಪೊನೆಂಟ್. ಇದು ಕಾಂಪೊನೆಂಟ್ನ ಪ್ರಾಪ್ಸ್ಗಳ ಶಾಲ್ಲೋ ಹೋಲಿಕೆಯನ್ನು ಮಾಡುತ್ತದೆ. ಪ್ರಾಪ್ಸ್ಗಳು ಬದಲಾಗದಿದ್ದರೆ, ರಿಯಾಕ್ಟ್ ಕಾಂಪೊನೆಂಟ್ ಅನ್ನು ಮರು-ರೆಂಡರ್ ಮಾಡುವುದನ್ನು ಬಿಟ್ಟು ಕೊನೆಯ ರೆಂಡರ್ ಫಲಿತಾಂಶವನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತದೆ.
- `useCallback()`: ಕಾಂಪೊನೆಂಟ್ ಒಳಗೆ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಫಂಕ್ಷನ್ಗಳು ಪ್ರತಿ ರೆಂಡರ್ನಲ್ಲಿ ಮರು-ರಚಿಸಲ್ಪಡುತ್ತವೆ. ನೀವು ಈ ಫಂಕ್ಷನ್ಗಳನ್ನು `React.memo` ನಲ್ಲಿ ಸುತ್ತಿದ ಚೈಲ್ಡ್ ಕಾಂಪೊನೆಂಟ್ಗೆ ಪ್ರಾಪ್ಸ್ ಆಗಿ ರವಾನಿಸಿದರೆ, ಫಂಕ್ಷನ್ ಪ್ರಾಪ್ ತಾಂತ್ರಿಕವಾಗಿ ಪ್ರತಿ ಬಾರಿಯೂ ಹೊಸ ಫಂಕ್ಷನ್ ಆಗಿರುವುದರಿಂದ ಚೈಲ್ಡ್ ಮರು-ರೆಂಡರ್ ಆಗುತ್ತದೆ. `useCallback` ಫಂಕ್ಷನ್ ಅನ್ನೇ ಮೆಮೊಯೈಸ್ ಮಾಡುತ್ತದೆ, ಅದರ ಡಿಪೆಂಡೆನ್ಸಿಗಳು ಬದಲಾದಾಗ ಮಾತ್ರ ಅದು ಮರು-ರಚಿಸಲ್ಪಡುವುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ.
- `useMemo()`: `useCallback` ನಂತೆಯೇ, ಆದರೆ ಮೌಲ್ಯಗಳಿಗೆ. ಇದು ದುಬಾರಿ ಲೆಕ್ಕಾಚಾರದ ಫಲಿತಾಂಶವನ್ನು ಮೆಮೊಯೈಸ್ ಮಾಡುತ್ತದೆ. ಅದರ ಡಿಪೆಂಡೆನ್ಸಿಗಳಲ್ಲಿ ಒಂದು ಬದಲಾದಾಗ ಮಾತ್ರ ಲೆಕ್ಕಾಚಾರವನ್ನು ಮರು-ಚಲಾಯಿಸಲಾಗುತ್ತದೆ. ಇದು ಪ್ರತಿ ರೆಂಡರ್ನಲ್ಲಿ ದುಬಾರಿ ಗಣನೆಗಳನ್ನು ತಡೆಯಲು ಮತ್ತು ಪ್ರಾಪ್ಸ್ ಆಗಿ ರವಾನಿಸಲಾದ ಸ್ಥಿರ ಆಬ್ಜೆಕ್ಟ್/ಅರೇ ರೆಫರೆನ್ಸ್ಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಉಪಯುಕ್ತವಾಗಿದೆ.
ಸಾವಿರಾರು ನೋಡ್ಗಳಿರುವ ಒಂದು ಸಂಕೀರ್ಣ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ನೀವು ಸ್ಟೇಟ್ ಅನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡಿ, ನೇರವಾಗಿ DOM ಅನ್ನು ಮ್ಯಾನಿಪ್ಯುಲೇಟ್ ಮಾಡುವ ಮೂಲಕ ಸಂಪೂರ್ಣ UI ಅನ್ನು ಮುಗ್ಧವಾಗಿ ಮರು-ರೆಂಡರ್ ಮಾಡಿದರೆ, ನೀವು ಬ್ರೌಸರ್ ಅನ್ನು ದುಬಾರಿ ರಿಫ್ಲೋ ಮತ್ತು ರಿಪೇಂಟ್ಗಳ ಸರಣಿಗೆ ಒತ್ತಾಯಿಸುತ್ತೀರಿ, ಇದು ಭಯಾನಕ ಬಳಕೆದಾರ ಅನುಭವಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಪರಿಹಾರ: ವರ್ಚುವಲ್ DOM (VDOM)
ರಿಯಾಕ್ಟ್ನ ರಚನೆಕಾರರು ನೇರ DOM ಮ್ಯಾನಿಪ್ಯುಲೇಷನ್ನ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಡಚಣೆಯನ್ನು ಗುರುತಿಸಿದರು. ಅವರ ಪರಿಹಾರವೆಂದರೆ ಒಂದು ಅಬ್ಸ್ಟ್ರಾಕ್ಷನ್ ಲೇಯರ್ ಅನ್ನು ಪರಿಚಯಿಸುವುದು: ವರ್ಚುವಲ್ DOM.
ವರ್ಚುವಲ್ DOM ಎಂದರೇನು?
ವರ್ಚುವಲ್ DOM ನಿಜವಾದ DOM ನ ಒಂದು ಹಗುರವಾದ, ಇನ್-ಮೆಮೊರಿ ಪ್ರಾತಿನಿಧ್ಯವಾಗಿದೆ. ಇದು ಮೂಲಭೂತವಾಗಿ UI ಅನ್ನು ವಿವರಿಸುವ ಒಂದು ಸರಳ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಆಬ್ಜೆಕ್ಟ್. ಒಂದು VDOM ಆಬ್ಜೆಕ್ಟ್ ನಿಜವಾದ DOM ಎಲಿಮೆಂಟ್ನ ಅಟ್ರಿಬ್ಯೂಟ್ಗಳನ್ನು ಹೋಲುವ ಪ್ರಾಪರ್ಟಿಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಒಂದು ಸರಳ `
{ type: 'div', props: { className: 'container', children: 'Hello World' } }
ಇವು ಕೇವಲ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಆಬ್ಜೆಕ್ಟ್ಗಳಾಗಿರುವುದರಿಂದ, ಅವುಗಳನ್ನು ರಚಿಸುವುದು ಮತ್ತು ಮ್ಯಾನಿಪ್ಯುಲೇಟ್ ಮಾಡುವುದು ಅತ್ಯಂತ ವೇಗವಾಗಿರುತ್ತದೆ. ಇದು ಬ್ರೌಸರ್ API ಗಳೊಂದಿಗೆ ಯಾವುದೇ ಸಂವಹನವನ್ನು ಒಳಗೊಂಡಿರುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಯಾವುದೇ ರಿಫ್ಲೋ ಅಥವಾ ರಿಪೇಂಟ್ಗಳು ಇರುವುದಿಲ್ಲ.
ವರ್ಚುವಲ್ DOM ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ?
VDOM UI ಡೆವಲಪ್ಮೆಂಟ್ಗೆ ಡಿಕ್ಲರೇಟಿವ್ ವಿಧಾನವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ. DOM ಅನ್ನು ಹಂತ-ಹಂತವಾಗಿ ಹೇಗೆ ಬದಲಾಯಿಸಬೇಕೆಂದು ಬ್ರೌಸರ್ಗೆ ಹೇಳುವ ಬದಲು (ಇಂಪರೇಟಿವ್), ನೀವು ನಿರ್ದಿಷ್ಟ ಸ್ಟೇಟ್ಗೆ UI ಹೇಗೆ ಕಾಣಬೇಕು ಎಂದು ಸರಳವಾಗಿ ಘೋಷಿಸುತ್ತೀರಿ (ಡಿಕ್ಲರೇಟಿವ್). ಉಳಿದದ್ದನ್ನು ರಿಯಾಕ್ಟ್ ನಿಭಾಯಿಸುತ್ತದೆ.
ಈ ಪ್ರಕ್ರಿಯೆ ಹೀಗಿರುತ್ತದೆ:
ಅಪ್ಡೇಟ್ಗಳನ್ನು ಬ್ಯಾಚ್ ಮಾಡುವ ಮೂಲಕ, ರಿಯಾಕ್ಟ್ ನಿಧಾನಗತಿಯ DOM ನೊಂದಿಗಿನ ನೇರ ಸಂವಹನವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಇದರಿಂದ ಕಾರ್ಯಕ್ಷಮತೆ ಗಮನಾರ್ಹವಾಗಿ ಸುಧಾರಿಸುತ್ತದೆ. ಈ ದಕ್ಷತೆಯ ತಿರುಳು "ಡಿಫಿಂಗ್" ಹಂತದಲ್ಲಿದೆ, ಇದನ್ನು ಔಪಚಾರಿಕವಾಗಿ Reconciliation ಅಲ್ಗಾರಿದಮ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.
ರಿಯಾಕ್ಟ್ನ ಹೃದಯ: Reconciliation ಅಲ್ಗಾರಿದಮ್
Reconciliation ಎನ್ನುವುದು ರಿಯಾಕ್ಟ್ ಇತ್ತೀಚಿನ ಕಾಂಪೊನೆಂಟ್ ಟ್ರೀಗೆ ಹೊಂದಿಸಲು DOM ಅನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡುವ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ. ಈ ಹೋಲಿಕೆಯನ್ನು ನಿರ್ವಹಿಸುವ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ನಾವು "ಡಿಫಿಂಗ್ ಅಲ್ಗಾರಿದಮ್" ಎಂದು ಕರೆಯುತ್ತೇವೆ.
ಸೈದ್ಧಾಂತಿಕವಾಗಿ, ಒಂದು ಟ್ರೀಯನ್ನು ಇನ್ನೊಂದಕ್ಕೆ ಪರಿವರ್ತಿಸಲು ಕನಿಷ್ಠ ಸಂಖ್ಯೆಯ ರೂಪಾಂತರಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಅತ್ಯಂತ ಸಂಕೀರ್ಣವಾದ ಸಮಸ್ಯೆಯಾಗಿದೆ, ಇದರ ಅಲ್ಗಾರಿದಮ್ ಸಂಕೀರ್ಣತೆಯು O(n³) ಕ್ರಮದಲ್ಲಿರುತ್ತದೆ, ಇಲ್ಲಿ n ಎಂಬುದು ಟ್ರೀಯಲ್ಲಿನ ನೋಡ್ಗಳ ಸಂಖ್ಯೆ. ಇದು ನೈಜ-ಪ್ರಪಂಚದ ಅಪ್ಲಿಕೇಶನ್ಗಳಿಗೆ ತುಂಬಾ ನಿಧಾನವಾಗಿರುತ್ತದೆ. ಇದನ್ನು ಪರಿಹರಿಸಲು, ರಿಯಾಕ್ಟ್ನ ತಂಡವು ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಹೇಗೆ ವರ್ತಿಸುತ್ತವೆ ಎಂಬುದರ ಕುರಿತು ಕೆಲವು ಅದ್ಭುತ ಅವಲೋಕನಗಳನ್ನು ಮಾಡಿತು ಮತ್ತು O(n) ಸಮಯದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಹೆಚ್ಚು ವೇಗವಾದ ಹ್ಯೂರಿಸ್ಟಿಕ್ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಅಳವಡಿಸಿತು.
ಹ್ಯೂರಿಸ್ಟಿಕ್ಸ್: ಡಿಫಿಂಗ್ ಅನ್ನು ವೇಗ ಮತ್ತು ನಿರೀಕ್ಷಿತವಾಗಿಸುವುದು
ರಿಯಾಕ್ಟ್ನ ಡಿಫಿಂಗ್ ಅಲ್ಗಾರಿದಮ್ ಎರಡು ಪ್ರಾಥಮಿಕ ಊಹೆಗಳು ಅಥವಾ ಹ್ಯೂರಿಸ್ಟಿಕ್ಗಳ ಮೇಲೆ ನಿರ್ಮಿತವಾಗಿದೆ:
ಹ್ಯೂರಿಸ್ಟಿಕ್ 1: ವಿಭಿನ್ನ ಎಲಿಮೆಂಟ್ ಪ್ರಕಾರಗಳು ವಿಭಿನ್ನ ಟ್ರೀಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತವೆ
ಇದು ಮೊದಲ ಮತ್ತು ಅತ್ಯಂತ ನೇರವಾದ ನಿಯಮ. ಎರಡು VDOM ನೋಡ್ಗಳನ್ನು ಹೋಲಿಸುವಾಗ, ರಿಯಾಕ್ಟ್ ಮೊದಲು ಅವುಗಳ ಪ್ರಕಾರವನ್ನು ನೋಡುತ್ತದೆ. ರೂಟ್ ಎಲಿಮೆಂಟ್ಗಳ ಪ್ರಕಾರವು ವಿಭಿನ್ನವಾಗಿದ್ದರೆ, ಡೆವಲಪರ್ ಒಂದನ್ನು ಇನ್ನೊಂದಕ್ಕೆ ಪರಿವರ್ತಿಸಲು ಪ್ರಯತ್ನಿಸಲು ಬಯಸುವುದಿಲ್ಲ ಎಂದು ರಿಯಾಕ್ಟ್ ಊಹಿಸುತ್ತದೆ. ಬದಲಾಗಿ, ಇದು ಹೆಚ್ಚು ಕಠಿಣ ಆದರೆ ನಿರೀಕ್ಷಿತ ವಿಧಾನವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ:
ಉದಾಹರಣೆಗೆ, ಈ ಬದಲಾವಣೆಯನ್ನು ಪರಿಗಣಿಸಿ:
ಮೊದಲು: <div><Counter /></div>
ನಂತರ: <span><Counter /></span>
ಚೈಲ್ಡ್ `Counter` ಕಾಂಪೊನೆಂಟ್ ಒಂದೇ ಆಗಿದ್ದರೂ, ರೂಟ್ `div` ನಿಂದ `span` ಗೆ ಬದಲಾಗಿದೆ ಎಂದು ರಿಯಾಕ್ಟ್ ನೋಡುತ್ತದೆ. ಇದು ಹಳೆಯ `div` ಮತ್ತು ಅದರೊಳಗಿನ `Counter` ಇನ್ಸ್ಟಾನ್ಸ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅನ್ಮೌಂಟ್ ಮಾಡುತ್ತದೆ (ಅದರ ಸ್ಟೇಟ್ ಅನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ) ಮತ್ತು ನಂತರ ಹೊಸ `span` ಮತ್ತು `Counter` ನ ಹೊಚ್ಚ ಹೊಸ ಇನ್ಸ್ಟಾನ್ಸ್ ಅನ್ನು ಮೌಂಟ್ ಮಾಡುತ್ತದೆ.
ಪ್ರಮುಖ ಅಂಶ: ನೀವು ಕಾಂಪೊನೆಂಟ್ ಸಬ್ಟ್ರೀಯ ಸ್ಟೇಟ್ ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳಲು ಅಥವಾ ಅದರ ಪೂರ್ಣ ಮರು-ರೆಂಡರ್ ಅನ್ನು ತಪ್ಪಿಸಲು ಬಯಸಿದರೆ, ಅದರ ರೂಟ್ ಎಲಿಮೆಂಟ್ ಪ್ರಕಾರವನ್ನು ಬದಲಾಯಿಸುವುದನ್ನು ತಪ್ಪಿಸಿ.
ಹ್ಯೂರಿಸ್ಟಿಕ್ 2: ಡೆವಲಪರ್ಗಳು `key` ಪ್ರಾಪ್ ಮೂಲಕ ಸ್ಥಿರ ಎಲಿಮೆಂಟ್ಗಳನ್ನು ಸೂಚಿಸಬಹುದು
ಇದು ಡೆವಲಪರ್ಗಳು ಸರಿಯಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ಅನ್ವಯಿಸಲು ಅತ್ಯಂತ ನಿರ್ಣಾಯಕ ಹ್ಯೂರಿಸ್ಟಿಕ್ ಆಗಿದೆ. ರಿಯಾಕ್ಟ್ ಚೈಲ್ಡ್ ಎಲಿಮೆಂಟ್ಗಳ ಪಟ್ಟಿಯನ್ನು ಹೋಲಿಸುವಾಗ, ಅದರ ಡೀಫಾಲ್ಟ್ ನಡವಳಿಕೆಯು ಎರಡೂ ಮಕ್ಕಳ ಪಟ್ಟಿಗಳ ಮೇಲೆ ಏಕಕಾಲದಲ್ಲಿ ಪುನರಾವರ್ತಿಸುವುದು ಮತ್ತು ವ್ಯತ್ಯಾಸವಿದ್ದಲ್ಲೆಲ್ಲಾ ರೂಪಾಂತರವನ್ನು (mutation) ಮಾಡುವುದು.
ಇಂಡೆಕ್ಸ್-ಆಧಾರಿತ ಡಿಫಿಂಗ್ನ ಸಮಸ್ಯೆ
ನಾವು ಐಟಂಗಳ ಪಟ್ಟಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಕೀಗಳನ್ನು ಬಳಸದೆ ಪಟ್ಟಿಯ ಆರಂಭಕ್ಕೆ ಹೊಸ ಐಟಂ ಅನ್ನು ಸೇರಿಸುತ್ತೇವೆ ಎಂದು ಊಹಿಸೋಣ.
ಆರಂಭಿಕ ಪಟ್ಟಿ:
ಅಪ್ಡೇಟ್ ಮಾಡಿದ ಪಟ್ಟಿ ('ಐಟಂ A' ಅನ್ನು ಆರಂಭದಲ್ಲಿ ಸೇರಿಸಿದಾಗ):
ಕೀಗಳಿಲ್ಲದೆ, ರಿಯಾಕ್ಟ್ ಸರಳ, ಇಂಡೆಕ್ಸ್-ಆಧಾರಿತ ಹೋಲಿಕೆಯನ್ನು ಮಾಡುತ್ತದೆ:
ಇದು ಅತ್ಯಂತ ಅಸಮರ್ಥವಾಗಿದೆ. ರಿಯಾಕ್ಟ್ ಎರಡು ಅನಗತ್ಯ ರೂಪಾಂತರಗಳನ್ನು ಮತ್ತು ಒಂದು ಸೇರ್ಪಡೆಯನ್ನು ಮಾಡಿದೆ, ಆದರೆ ಅಗತ್ಯವಿದ್ದುದು ಕೇವಲ ಆರಂಭದಲ್ಲಿ ಒಂದು ಸೇರ್ಪಡೆ ಮಾತ್ರ. ಈ ಲಿಸ್ಟ್ ಐಟಂಗಳು ತಮ್ಮದೇ ಆದ ಸ್ಟೇಟ್ ಹೊಂದಿರುವ ಸಂಕೀರ್ಣ ಕಾಂಪೊನೆಂಟ್ಗಳಾಗಿದ್ದರೆ, ಇದು ಗಂಭೀರ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳಿಗೆ ಮತ್ತು ದೋಷಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು, ಏಕೆಂದರೆ ಸ್ಟೇಟ್ ಕಾಂಪೊನೆಂಟ್ಗಳ ನಡುವೆ ಬೆರೆತುಹೋಗಬಹುದು.
`key` ಪ್ರಾಪ್ನ ಶಕ್ತಿ
ಇದಕ್ಕೆ `key` ಪ್ರಾಪ್ ಪರಿಹಾರವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಇದು ಎಲಿಮೆಂಟ್ಗಳ ಪಟ್ಟಿಗಳನ್ನು ರಚಿಸುವಾಗ ನೀವು ಸೇರಿಸಬೇಕಾದ ವಿಶೇಷ ಸ್ಟ್ರಿಂಗ್ ಅಟ್ರಿಬ್ಯೂಟ್ ಆಗಿದೆ. ಕೀಗಳು ರಿಯಾಕ್ಟ್ಗೆ ಪ್ರತಿಯೊಂದು ಎಲಿಮೆಂಟ್ಗೂ ಸ್ಥಿರವಾದ ಗುರುತನ್ನು ನೀಡುತ್ತವೆ.
ಅದೇ ಉದಾಹರಣೆಯನ್ನು ಮತ್ತೆ ನೋಡೋಣ, ಆದರೆ ಈ ಬಾರಿ ಸ್ಥಿರ, ಅನನ್ಯ ಕೀಗಳೊಂದಿಗೆ:
ಆರಂಭಿಕ ಪಟ್ಟಿ:
ಅಪ್ಡೇಟ್ ಮಾಡಿದ ಪಟ್ಟಿ:
ಈಗ, ರಿಯಾಕ್ಟ್ನ ಡಿಫಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯು ಹೆಚ್ಚು ಚುರುಕಾಗಿದೆ:
ಇದು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ. ರಿಯಾಕ್ಟ್ ಕೇವಲ ಒಂದು ಸೇರ್ಪಡೆಯನ್ನು ಮಾಡಬೇಕಾಗಿದೆ ಎಂದು ಸರಿಯಾಗಿ ಗುರುತಿಸುತ್ತದೆ. 'b' ಮತ್ತು 'c' ಕೀಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಕಾಂಪೊನೆಂಟ್ಗಳು ಸಂರಕ್ಷಿಸಲ್ಪಡುತ್ತವೆ, ಅವುಗಳ ಆಂತರಿಕ ಸ್ಟೇಟ್ ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತವೆ.
ಕೀಗಳಿಗಾಗಿ ನಿರ್ಣಾಯಕ ನಿಯಮ: ಕೀಗಳು ತಮ್ಮ ಒಡಹುಟ್ಟಿದವುಗಳಲ್ಲಿ ಸ್ಥಿರ, ನಿರೀಕ್ಷಿತ, ಮತ್ತು ಅನನ್ಯವಾಗಿರಬೇಕು. ಅರೇ ಇಂಡೆಕ್ಸ್ ಅನ್ನು ಕೀ ಆಗಿ ಬಳಸುವುದು (`items.map((item, index) =>
ವಿಕಾಸ: ಸ್ಟಾಕ್ನಿಂದ ಫೈಬರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ಗೆ
ಮೇಲೆ ವಿವರಿಸಿದ Reconciliation ಅಲ್ಗಾರಿದಮ್ ಹಲವು ವರ್ಷಗಳ ಕಾಲ ರಿಯಾಕ್ಟ್ನ ಅಡಿಪಾಯವಾಗಿತ್ತು. ಆದಾಗ್ಯೂ, ಅದಕ್ಕೆ ಒಂದು ಪ್ರಮುಖ ಮಿತಿಯಿತ್ತು: ಅದು ಸಿಂಕ್ರೊನಸ್ ಮತ್ತು ಬ್ಲಾಕಿಂಗ್ ಆಗಿತ್ತು. ಈ ಮೂಲ ಅನುಷ್ಠಾನವನ್ನು ಈಗ ಸ್ಟಾಕ್ Reconciler ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.
ಹಳೆಯ ವಿಧಾನ: ಸ್ಟಾಕ್ Reconciler
ಸ್ಟಾಕ್ Reconcilerನಲ್ಲಿ, ಸ್ಟೇಟ್ ಅಪ್ಡೇಟ್ ಮರು-ರೆಂಡರ್ ಅನ್ನು ಪ್ರಚೋದಿಸಿದಾಗ, ರಿಯಾಕ್ಟ್ ಸಂಪೂರ್ಣ ಕಾಂಪೊನೆಂಟ್ ಟ್ರೀಯನ್ನು ಪುನರಾವರ್ತಿತವಾಗಿ ಪರಿಶೀಲಿಸುತ್ತಿತ್ತು, ಬದಲಾವಣೆಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತಿತ್ತು ಮತ್ತು ಅವುಗಳನ್ನು DOM ಗೆ ಅನ್ವಯಿಸುತ್ತಿತ್ತು - ಎಲ್ಲವೂ ಒಂದೇ, ಅಡೆತಡೆಯಿಲ್ಲದ ಅನುಕ್ರಮದಲ್ಲಿ. ಸಣ್ಣ ಅಪ್ಡೇಟ್ಗಳಿಗೆ, ಇದು ಸರಿಯಾಗಿತ್ತು. ಆದರೆ ದೊಡ್ಡ ಕಾಂಪೊನೆಂಟ್ ಟ್ರೀಗಳಿಗೆ, ಈ ಪ್ರಕ್ರಿಯೆಯು ಗಮನಾರ್ಹ ಸಮಯವನ್ನು (ಉದಾಹರಣೆಗೆ, 16ms ಗಿಂತ ಹೆಚ್ಚು) ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ಇದು ಬ್ರೌಸರ್ನ ಮುಖ್ಯ ಥ್ರೆಡ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆ. ಇದು UI ಪ್ರತಿಕ್ರಿಯಿಸದಿರಲು, ಫ್ರೇಮ್ಗಳು ಡ್ರಾಪ್ ಆಗಲು, ಅನಿಮೇಷನ್ಗಳು ಸ್ಥಗಿತಗೊಳ್ಳಲು ಮತ್ತು ಕಳಪೆ ಬಳಕೆದಾರ ಅನುಭವಕ್ಕೆ ಕಾರಣವಾಗುತ್ತಿತ್ತು.
ರಿಯಾಕ್ಟ್ ಫೈಬರ್ ಪರಿಚಯ (ರಿಯಾಕ್ಟ್ 16+)
ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ರಿಯಾಕ್ಟ್ ತಂಡವು ಪ್ರಮುಖ Reconciliation ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪುನಃ ಬರೆಯಲು ಬಹು-ವರ್ಷಗಳ ಯೋಜನೆಯನ್ನು ಕೈಗೊಂಡಿತು. ಇದರ ಫಲಿತಾಂಶ, ರಿಯಾಕ್ಟ್ 16 ರಲ್ಲಿ ಬಿಡುಗಡೆಯಾಯಿತು, ಇದನ್ನು ರಿಯಾಕ್ಟ್ ಫೈಬರ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.
ಫೈಬರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಮೊದಲಿನಿಂದಲೂ ಕಾನ್ಕರೆನ್ಸಿಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ - ರಿಯಾಕ್ಟ್ಗೆ ಏಕಕಾಲದಲ್ಲಿ ಅನೇಕ ಕಾರ್ಯಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಮತ್ತು ಆದ್ಯತೆಯ ಆಧಾರದ ಮೇಲೆ ಅವುಗಳ ನಡುವೆ ಬದಲಾಯಿಸುವ ಸಾಮರ್ಥ್ಯ.
"ಫೈಬರ್" ಎನ್ನುವುದು ಕೆಲಸದ ಒಂದು ಘಟಕವನ್ನು ಪ್ರತಿನಿಧಿಸುವ ಸರಳ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಆಬ್ಜೆಕ್ಟ್ ಆಗಿದೆ. ಇದು ಒಂದು ಕಾಂಪೊನೆಂಟ್, ಅದರ ಇನ್ಪುಟ್ (props), ಮತ್ತು ಅದರ ಔಟ್ಪುಟ್ (children) ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಅಡ್ಡಿಪಡಿಸಲಾಗದ ಪುನರಾವರ್ತಿತ ಪರಿಶೀಲನೆಯ ಬದಲು, ರಿಯಾಕ್ಟ್ ಈಗ ಫೈಬರ್ ನೋಡ್ಗಳ ಲಿಂಕ್ಡ್ ಲಿಸ್ಟ್ ಅನ್ನು ಒಂದೊಂದಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ.
ಈ ಹೊಸ ಆರ್ಕಿಟೆಕ್ಚರ್ ಹಲವಾರು ಪ್ರಮುಖ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಅನ್ಲಾಕ್ ಮಾಡಿದೆ:
ಫೈಬರ್ನ ಎರಡು ಹಂತಗಳು
ಫೈಬರ್ ಅಡಿಯಲ್ಲಿ, ರೆಂಡರಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯು ಎರಡು ವಿಭಿನ್ನ ಹಂತಗಳಾಗಿ ವಿಭಜಿಸಲ್ಪಟ್ಟಿದೆ:
ಫೈಬರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ರಿಯಾಕ್ಟ್ನ ಅನೇಕ ಆಧುನಿಕ ವೈಶಿಷ್ಟ್ಯಗಳಾದ `Suspense`, ಕಾನ್ಕರೆಂಟ್ ರೆಂಡರಿಂಗ್, `useTransition`, ಮತ್ತು `useDeferredValue` ಗೆ ಅಡಿಪಾಯವಾಗಿದೆ, ಇವೆಲ್ಲವೂ ಡೆವಲಪರ್ಗಳಿಗೆ ಹೆಚ್ಚು ಸ್ಪಂದಿಸುವ ಮತ್ತು ಸುಗಮ ಯೂಸರ್ ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತವೆ.
ಡೆವಲಪರ್ಗಳಿಗಾಗಿ ಪ್ರಾಯೋಗಿಕ ಆಪ್ಟಿಮೈಸೇಶನ್ ತಂತ್ರಗಳು
ರಿಯಾಕ್ಟ್ನ Reconciliation ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ನಿಮಗೆ ಹೆಚ್ಚು ಕಾರ್ಯಕ್ಷಮತೆಯ ಕೋಡ್ ಬರೆಯುವ ಶಕ್ತಿಯನ್ನು ನೀಡುತ್ತದೆ. ಇಲ್ಲಿ ಕೆಲವು ಕಾರ್ಯಸಾಧ್ಯವಾದ ತಂತ್ರಗಳು:
1. ಪಟ್ಟಿಗಳಿಗಾಗಿ ಯಾವಾಗಲೂ ಸ್ಥಿರ ಮತ್ತು ಅನನ್ಯ ಕೀಗಳನ್ನು ಬಳಸಿ
ಇದನ್ನು ಸಾಕಷ್ಟು ಒತ್ತಿ ಹೇಳಲಾಗುವುದಿಲ್ಲ. ಪಟ್ಟಿಗಳಿಗಾಗಿ ಇದು ಅತ್ಯಂತ ಪ್ರಮುಖವಾದ ಆಪ್ಟಿಮೈಸೇಶನ್ ಆಗಿದೆ. ನಿಮ್ಮ ಡೇಟಾದಿಂದ ಅನನ್ಯ ID ಬಳಸಿ (ಉದಾ., `product.id`). ಪಟ್ಟಿ ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಥಿರವಾಗಿದ್ದು ಮತ್ತು ಎಂದಿಗೂ ಬದಲಾಗದ ಹೊರತು ಅರೇ ಇಂಡೆಕ್ಸ್ಗಳನ್ನು ಬಳಸುವುದನ್ನು ತಪ್ಪಿಸಿ.
2. ಅನಗತ್ಯ ಮರು-ರೆಂಡರ್ಗಳನ್ನು ತಪ್ಪಿಸಿ
ಒಂದು ಕಾಂಪೊನೆಂಟ್ನ ಸ್ಟೇಟ್ ಬದಲಾದರೆ ಅಥವಾ ಅದರ ಪೇರೆಂಟ್ ಮರು-ರೆಂಡರ್ ಆದರೆ ಅದು ಮರು-ರೆಂಡರ್ ಆಗುತ್ತದೆ. ಕೆಲವೊಮ್ಮೆ, ಅದರ ಔಟ್ಪುಟ್ ಒಂದೇ ಆಗಿದ್ದರೂ ಕಾಂಪೊನೆಂಟ್ ಮರು-ರೆಂಡರ್ ಆಗುತ್ತದೆ. ಇದನ್ನು ತಡೆಯಲು ನೀವು ಬಳಸಬಹುದು:
3. ಸ್ಮಾರ್ಟ್ ಕಾಂಪೊನೆಂಟ್ ಕಂಪೋಸಿಷನ್
ನೀವು ನಿಮ್ಮ ಕಾಂಪೊನೆಂಟ್ಗಳನ್ನು ರಚಿಸುವ ರೀತಿ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಗಮನಾರ್ಹ ಪರಿಣಾಮ ಬೀರಬಹುದು. ನಿಮ್ಮ ಕಾಂಪೊನೆಂಟ್ನ ಒಂದು ಭಾಗದ ಸ್ಟೇಟ್ ಆಗಾಗ್ಗೆ ಅಪ್ಡೇಟ್ ಆಗುತ್ತಿದ್ದರೆ, ಅದನ್ನು ಆಗದ ಭಾಗಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸಲು ಪ್ರಯತ್ನಿಸಿ.
ಉದಾಹರಣೆಗೆ, ಆಗಾಗ್ಗೆ ಬದಲಾಗುವ ಇನ್ಪುಟ್ ಫೀಲ್ಡ್ ಇಡೀ ಕಾಂಪೊನೆಂಟ್ ಮರು-ರೆಂಡರ್ ಆಗಲು ಕಾರಣವಾಗುವ ಒಂದೇ ದೊಡ್ಡ ಕಾಂಪೊನೆಂಟ್ ಹೊಂದುವ ಬದಲು, ಆ ಸ್ಟೇಟ್ ಅನ್ನು ಅದರದೇ ಆದ ಚಿಕ್ಕ ಕಾಂಪೊನೆಂಟ್ಗೆ ಎತ್ತಿ. ಈ ರೀತಿಯಾಗಿ, ಬಳಕೆದಾರರು ಟೈಪ್ ಮಾಡಿದಾಗ ಕೇವಲ ಆ ಚಿಕ್ಕ ಕಾಂಪೊನೆಂಟ್ ಮಾತ್ರ ಮರು-ರೆಂಡರ್ ಆಗುತ್ತದೆ.
4. ದೀರ್ಘ ಪಟ್ಟಿಗಳನ್ನು ವರ್ಚುವಲೈಸ್ ಮಾಡಿ
ನೀವು ನೂರಾರು ಅಥವಾ ಸಾವಿರಾರು ಐಟಂಗಳೊಂದಿಗೆ ಪಟ್ಟಿಗಳನ್ನು ರೆಂಡರ್ ಮಾಡಬೇಕಾದರೆ, ಸರಿಯಾದ ಕೀಗಳನ್ನು ಬಳಸಿದರೂ, ಅವೆಲ್ಲವನ್ನೂ ಒಂದೇ ಬಾರಿಗೆ ರೆಂಡರ್ ಮಾಡುವುದು ನಿಧಾನವಾಗಬಹುದು ಮತ್ತು ಬಹಳಷ್ಟು ಮೆಮೊರಿಯನ್ನು ಬಳಸಿಕೊಳ್ಳಬಹುದು. ಇದಕ್ಕೆ ಪರಿಹಾರವೆಂದರೆ ವರ್ಚುವಲೈಸೇಶನ್ ಅಥವಾ ವಿಂಡೋಯಿಂಗ್. ಈ ತಂತ್ರವು ಪ್ರಸ್ತುತ ವೀಕ್ಷಣೆ ಪೋರ್ಟ್ನಲ್ಲಿ ಗೋಚರಿಸುವ ಸಣ್ಣ ಉಪವಿಭಾಗದ ಐಟಂಗಳನ್ನು ಮಾತ್ರ ರೆಂಡರ್ ಮಾಡುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಬಳಕೆದಾರರು ಸ್ಕ್ರಾಲ್ ಮಾಡಿದಂತೆ, ಹಳೆಯ ಐಟಂಗಳು ಅನ್ಮೌಂಟ್ ಆಗುತ್ತವೆ ಮತ್ತು ಹೊಸ ಐಟಂಗಳು ಮೌಂಟ್ ಆಗುತ್ತವೆ. `react-window` ಮತ್ತು `react-virtualized` ನಂತಹ ಲೈಬ್ರರಿಗಳು ಈ ಮಾದರಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಶಕ್ತಿಯುತ ಮತ್ತು ಬಳಸಲು ಸುಲಭವಾದ ಕಾಂಪೊನೆಂಟ್ಗಳನ್ನು ಒದಗಿಸುತ್ತವೆ.
ತೀರ್ಮಾನ
ರಿಯಾಕ್ಟ್ನ ಕಾರ್ಯಕ್ಷಮತೆ ಆಕಸ್ಮಿಕವಲ್ಲ; ಇದು ವರ್ಚುವಲ್ DOM ಮತ್ತು ಸಮರ್ಥ Reconciliation ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಕೇಂದ್ರವಾಗಿಟ್ಟುಕೊಂಡು ಉದ್ದೇಶಪೂರ್ವಕ ಮತ್ತು ಅತ್ಯಾಧುನಿಕ ಆರ್ಕಿಟೆಕ್ಚರ್ನ ಫಲಿತಾಂಶವಾಗಿದೆ. ನೇರ DOM ಮ್ಯಾನಿಪ್ಯುಲೇಷನ್ ಅನ್ನು ಅಮೂರ್ತಗೊಳಿಸುವ ಮೂಲಕ, ರಿಯಾಕ್ಟ್ ಅಪ್ಡೇಟ್ಗಳನ್ನು ಕೈಯಾರೆ ನಿರ್ವಹಿಸಲು ನಂಬಲಾಗದಷ್ಟು ಸಂಕೀರ್ಣವಾದ ರೀತಿಯಲ್ಲಿ ಬ್ಯಾಚ್ ಮತ್ತು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಬಹುದು.
ಡೆವಲಪರ್ಗಳಾಗಿ, ನಾವು ಈ ಪ್ರಕ್ರಿಯೆಯ ನಿರ್ಣಾಯಕ ಭಾಗವಾಗಿದ್ದೇವೆ. ಡಿಫಿಂಗ್ ಅಲ್ಗಾರಿದಮ್ನ ಹ್ಯೂರಿಸ್ಟಿಕ್ಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಮೂಲಕ - ಕೀಗಳನ್ನು ಸರಿಯಾಗಿ ಬಳಸುವುದು, ಕಾಂಪೊನೆಂಟ್ಗಳು ಮತ್ತು ಮೌಲ್ಯಗಳನ್ನು ಮೆಮೊಯೈಸ್ ಮಾಡುವುದು, ಮತ್ತು ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಚಿಂತನಶೀಲವಾಗಿ ರಚಿಸುವುದು - ನಾವು ರಿಯಾಕ್ಟ್ನ Reconciler ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದು, ಅದರ ವಿರುದ್ಧವಲ್ಲ. ಫೈಬರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ಗೆ ವಿಕಾಸವು ಸಾಧ್ಯವಿರುವುದರ ಗಡಿಗಳನ್ನು ಮತ್ತಷ್ಟು ವಿಸ್ತರಿಸಿದೆ, ಸುಗಮ ಮತ್ತು ಸ್ಪಂದಿಸುವ UI ಗಳ ಹೊಸ ಪೀಳಿಗೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದೆ.
ಮುಂದಿನ ಬಾರಿ ನಿಮ್ಮ UI ಸ್ಟೇಟ್ ಬದಲಾವಣೆಯ ನಂತರ ತಕ್ಷಣವೇ ಅಪ್ಡೇಟ್ ಆಗುವುದನ್ನು ನೋಡಿದಾಗ, ತೆರೆಮರೆಯಲ್ಲಿ ನಡೆಯುತ್ತಿರುವ ವರ್ಚುವಲ್ DOM, ಡಿಫಿಂಗ್ ಅಲ್ಗಾರಿದಮ್, ಮತ್ತು ಕಮಿಟ್ ಹಂತದ ಸೊಗಸಾದ ನೃತ್ಯವನ್ನು ಶ್ಲಾಘಿಸಲು ಒಂದು ಕ್ಷಣ ತೆಗೆದುಕೊಳ್ಳಿ. ಈ ತಿಳುವಳಿಕೆ ಜಾಗತಿಕ ಪ್ರೇಕ್ಷಕರಿಗಾಗಿ ವೇಗವಾದ, ಹೆಚ್ಚು ಸಮರ್ಥ, ಮತ್ತು ಹೆಚ್ಚು ದೃಢವಾದ ರಿಯಾಕ್ಟ್ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ನಿರ್ಮಿಸಲು ನಿಮ್ಮ ಕೀಲಿಯಾಗಿದೆ.