ಕನ್ನಡ

ರಿಯಾಕ್ಟ್ 18ರ ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್ ಮೂಲಕ ವೇಗದ ವೆಬ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಅನ್ಲಾಕ್ ಮಾಡಿ. ಈ ಮಾರ್ಗದರ್ಶಿ ಆದ್ಯತೆ-ಆಧಾರಿತ ಲೋಡಿಂಗ್, ಸ್ಟ್ರೀಮಿಂಗ್ SSR, ಮತ್ತು ಜಾಗತಿಕ ಬಳಕೆದಾರರಿಗಾಗಿ ಪ್ರಾಯೋಗಿಕ ಅಳವಡಿಕೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ.

ರಿಯಾಕ್ಟ್ ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್: ಆದ್ಯತೆ-ಆಧಾರಿತ ಕಾಂಪೊನೆಂಟ್ ಲೋಡಿಂಗ್ ಕುರಿತು ಒಂದು ಆಳವಾದ ನೋಟ

ಶ್ರೇಷ್ಠ ವೆಬ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ನಿರಂತರ ಅನ್ವೇಷಣೆಯಲ್ಲಿ, ಫ್ರಂಟ್ಎಂಡ್ ಡೆವಲಪರ್‌ಗಳು ನಿರಂತರವಾಗಿ ಒಂದು ಸಂಕೀರ್ಣ ವಿನಿಮಯವನ್ನು ಎದುರಿಸುತ್ತಿದ್ದಾರೆ. ನಮಗೆ ಶ್ರೀಮಂತ, ಸಂವಾದಾತ್ಮಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಬೇಕು, ಆದರೆ ಬಳಕೆದಾರರ ಸಾಧನ ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ವೇಗವನ್ನು ಲೆಕ್ಕಿಸದೆ, ಅವು ತಕ್ಷಣವೇ ಲೋಡ್ ಆಗಬೇಕು ಮತ್ತು ವಿಳಂಬವಿಲ್ಲದೆ ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕು. ಹಲವು ವರ್ಷಗಳಿಂದ, ಸರ್ವರ್-ಸೈಡ್ ರೆಂಡರಿಂಗ್ (SSR) ಈ ಪ್ರಯತ್ನದ ಮೂಲಾಧಾರವಾಗಿದೆ, ಇದು ವೇಗದ ಆರಂಭಿಕ ಪುಟ ಲೋಡ್‌ಗಳು ಮತ್ತು ಬಲವಾದ ಎಸ್‌ಇಒ ಪ್ರಯೋಜನಗಳನ್ನು ನೀಡುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಸಾಂಪ್ರದಾಯಿಕ SSR ಒಂದು ಗಮನಾರ್ಹ ಅಡಚಣೆಯೊಂದಿಗೆ ಬಂದಿತ್ತು: ಭಯಾನಕ "ಎಲ್ಲವೂ-ಅಥವಾ-ಏನೂ-ಇಲ್ಲ" ಹೈಡ್ರೇಶನ್ ಸಮಸ್ಯೆ.

ಒಂದು SSR-ರಚಿತ ಪುಟವು ನಿಜವಾಗಿಯೂ ಸಂವಾದಾತ್ಮಕವಾಗುವ ಮೊದಲು, ಸಂಪೂರ್ಣ ಅಪ್ಲಿಕೇಶನ್‌ನ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಬಂಡಲ್ ಅನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ, ಪಾರ್ಸ್ ಮಾಡಿ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾಗಿತ್ತು. ಇದು ಸಾಮಾನ್ಯವಾಗಿ ನಿರಾಶಾದಾಯಕ ಬಳಕೆದಾರರ ಅನುಭವಕ್ಕೆ ಕಾರಣವಾಗುತ್ತಿತ್ತು, ಅಲ್ಲಿ ಪುಟವು ಪೂರ್ಣಗೊಂಡಂತೆ ಮತ್ತು ಸಿದ್ಧವಾಗಿ ಕಾಣಿಸುತ್ತಿತ್ತು ಆದರೆ ಕ್ಲಿಕ್‌ಗಳು ಅಥವಾ ಇನ್‌ಪುಟ್‌ಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಿರಲಿಲ್ಲ, ಈ ವಿದ್ಯಮಾನವು ಟೈಮ್ ಟು ಇಂಟರಾಕ್ಟಿವ್ (TTI) ಮತ್ತು ಹೊಸ ಇಂಟರಾಕ್ಷನ್ ಟು ನೆಕ್ಸ್ಟ್ ಪೇಂಟ್ (INP) ನಂತಹ ಪ್ರಮುಖ ಮೆಟ್ರಿಕ್‌ಗಳ ಮೇಲೆ ನಕಾರಾತ್ಮಕ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.

ರಿಯಾಕ್ಟ್ 18 ಅನ್ನು ಪರಿಚಯಿಸಲಾಯಿತು. ಅದರ ಕ್ರಾಂತಿಕಾರಿ ಕನ್ಕರೆಂಟ್ ರೆಂಡರಿಂಗ್ ಇಂಜಿನ್‌ನೊಂದಿಗೆ, ರಿಯಾಕ್ಟ್ ಒಂದು ಪರಿಹಾರವನ್ನು ಪರಿಚಯಿಸಿತು, ಅದು ಎಷ್ಟು ಶಕ್ತಿಯುತವೋ ಅಷ್ಟೇ ಸೊಗಸಾಗಿದೆ: ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್. ಇದು ಕೇವಲ ಒಂದು ಹೆಚ್ಚುವರಿ ಸುಧಾರಣೆಯಲ್ಲ; ಇದು ಬ್ರೌಸರ್‌ನಲ್ಲಿ ರಿಯಾಕ್ಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಹೇಗೆ ಜೀವಂತವಾಗುತ್ತವೆ ಎಂಬುದರಲ್ಲಿ ಒಂದು ಮೂಲಭೂತ ಮಾದರಿ ಬದಲಾವಣೆಯಾಗಿದೆ. ಇದು ಏಕಶಿಲೆಯ ಹೈಡ್ರೇಶನ್ ಮಾದರಿಯನ್ನು ಮೀರಿ, ಬಳಕೆದಾರರ ಸಂವಾದಕ್ಕೆ ಮೊದಲ ಆದ್ಯತೆ ನೀಡುವ ಒಂದು ಸೂಕ್ಷ್ಮ, ಆದ್ಯತೆ-ಆಧಾರಿತ ವ್ಯವಸ್ಥೆಗೆ ಚಲಿಸುತ್ತದೆ.

ಈ ಸಮಗ್ರ ಮಾರ್ಗದರ್ಶಿ ರಿಯಾಕ್ಟ್ ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್‌ನ ಯಂತ್ರಶಾಸ್ತ್ರ, ಪ್ರಯೋಜನಗಳು ಮತ್ತು ಪ್ರಾಯೋಗಿಕ ಅಳವಡಿಕೆಯನ್ನು ಅನ್ವೇಷಿಸುತ್ತದೆ. ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಜಾಗತಿಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಇದು ಏಕೆ ಒಂದು ಗೇಮ್-ಚೇಂಜರ್ ಆಗಿದೆ, ಮತ್ತು ವೇಗವಾದ, ಹೆಚ್ಚು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಬಳಕೆದಾರರ ಅನುಭವಗಳನ್ನು ನಿರ್ಮಿಸಲು ನೀವು ಅದನ್ನು ಹೇಗೆ ಬಳಸಿಕೊಳ್ಳಬಹುದು ಎಂಬುದನ್ನು ನಾವು ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ.

ಹಿಂದಿನದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು: ಸಾಂಪ್ರದಾಯಿಕ SSR ಹೈಡ್ರೇಶನ್‌ನ ಸವಾಲು

ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್‌ನ ನಾವೀನ್ಯತೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರಶಂಸಿಸಲು, ಅದು ನಿವಾರಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಮಿತಿಗಳನ್ನು ನಾವು ಮೊದಲು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ರಿಯಾಕ್ಟ್ 18-ಪೂರ್ವದ ಸರ್ವರ್-ಸೈಡ್ ರೆಂಡರಿಂಗ್ ಜಗತ್ತನ್ನು ಮತ್ತೊಮ್ಮೆ ನೋಡೋಣ.

ಸರ್ವರ್-ಸೈಡ್ ರೆಂಡರಿಂಗ್ (SSR) ಎಂದರೇನು?

ಒಂದು ಸಾಮಾನ್ಯ ಕ್ಲೈಂಟ್-ಸೈಡ್ ರೆಂಡರ್ಡ್ (CSR) ರಿಯಾಕ್ಟ್ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ, ಬ್ರೌಸರ್ ಒಂದು ಕನಿಷ್ಠ HTML ಫೈಲ್ ಮತ್ತು ಒಂದು ದೊಡ್ಡ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಬಂಡಲ್ ಅನ್ನು ಪಡೆಯುತ್ತದೆ. ನಂತರ ಬ್ರೌಸರ್ ಪುಟದ ವಿಷಯವನ್ನು ರೆಂಡರ್ ಮಾಡಲು ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ಈ ಪ್ರಕ್ರಿಯೆಯು ನಿಧಾನವಾಗಿರಬಹುದು, ಬಳಕೆದಾರರನ್ನು ಖಾಲಿ ಪರದೆಯನ್ನು ನೋಡುವಂತೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸರ್ಚ್ ಇಂಜಿನ್ ಕ್ರಾಲರ್‌ಗಳಿಗೆ ವಿಷಯವನ್ನು ಇಂಡೆಕ್ಸ್ ಮಾಡಲು ಕಷ್ಟವಾಗಿಸುತ್ತದೆ.

SSR ಈ ಮಾದರಿಯನ್ನು ತಿರುಗಿಸುತ್ತದೆ. ಸರ್ವರ್ ರಿಯಾಕ್ಟ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಚಲಾಯಿಸುತ್ತದೆ, ವಿನಂತಿಸಿದ ಪುಟಕ್ಕಾಗಿ ಪೂರ್ಣ HTML ಅನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಬ್ರೌಸರ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಪ್ರಯೋಜನಗಳು ತಕ್ಷಣವೇ ಗೋಚರಿಸುತ್ತವೆ:

"ಎಲ್ಲವೂ-ಅಥವಾ-ಏನೂ-ಇಲ್ಲ" ಹೈಡ್ರೇಶನ್ ಅಡಚಣೆ

SSR ನಿಂದ ಆರಂಭಿಕ HTML ವೇಗದ ಸಂವಾದಾತ್ಮಕವಲ್ಲದ ಪೂರ್ವವೀಕ್ಷಣೆಯನ್ನು ಒದಗಿಸಿದರೂ, ಪುಟವು ಇನ್ನೂ ನಿಜವಾಗಿಯೂ ಬಳಸಲು ಯೋಗ್ಯವಾಗಿಲ್ಲ. ನಿಮ್ಮ ರಿಯಾಕ್ಟ್ ಕಾಂಪೊನೆಂಟ್‌ಗಳಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಈವೆಂಟ್ ಹ್ಯಾಂಡ್ಲರ್‌ಗಳು (`onClick` ನಂತಹ) ಮತ್ತು ಸ್ಟೇಟ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಕಾಣೆಯಾಗಿರುತ್ತದೆ. ಈ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ತರ್ಕವನ್ನು ಸರ್ವರ್-ರಚಿತ HTML ಗೆ ಜೋಡಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೈಡ್ರೇಶನ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.

ಇಲ್ಲಿದೆ ಕ್ಲಾಸಿಕ್ ಸಮಸ್ಯೆ: ಸಾಂಪ್ರದಾಯಿಕ ಹೈಡ್ರೇಶನ್ ಒಂದು ಏಕಶಿಲೆಯ, ಸಿಂಕ್ರೊನಸ್ ಮತ್ತು ಬ್ಲಾಕಿಂಗ್ ಕಾರ್ಯಾಚರಣೆಯಾಗಿತ್ತು. ಇದು ಕಟ್ಟುನಿಟ್ಟಾದ, ಕ್ಷಮಿಸದ ಅನುಕ್ರಮವನ್ನು ಅನುಸರಿಸುತ್ತಿತ್ತು:

  1. ಸಂಪೂರ್ಣ ಪುಟಕ್ಕಾಗಿ ಇರುವ ಇಡೀ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಬಂಡಲ್ ಅನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಬೇಕು.
  2. ರಿಯಾಕ್ಟ್ ಇಡೀ ಬಂಡಲ್ ಅನ್ನು ಪಾರ್ಸ್ ಮಾಡಿ ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕು.
  3. ನಂತರ ರಿಯಾಕ್ಟ್ ರೂಟ್‌ನಿಂದ ಇಡೀ ಕಾಂಪೊನೆಂಟ್ ಟ್ರೀಯನ್ನು ಹಾದುಹೋಗುತ್ತದೆ, ಪ್ರತಿ ಕಾಂಪೊನೆಂಟ್‌ಗೆ ಈವೆಂಟ್ ಲಿಸನರ್‌ಗಳನ್ನು ಜೋಡಿಸುತ್ತದೆ ಮತ್ತು ಸ್ಟೇಟ್ ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ.
  4. ಈ ಸಂಪೂರ್ಣ ಪ್ರಕ್ರಿಯೆ ಪೂರ್ಣಗೊಂಡ ನಂತರವೇ ಪುಟವು ಸಂವಾದಾತ್ಮಕವಾಗುತ್ತದೆ.

ಒಂದು ಸಂಪೂರ್ಣವಾಗಿ ಜೋಡಿಸಲಾದ, ಸುಂದರವಾದ ಹೊಸ ಕಾರನ್ನು ನೀವು ಸ್ವೀಕರಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ, ಆದರೆ ಇಡೀ ವಾಹನದ ಎಲೆಕ್ಟ್ರಾನಿಕ್ಸ್‌ಗಾಗಿ ಒಂದೇ ಮಾಸ್ಟರ್ ಸ್ವಿಚ್ ಅನ್ನು ಫ್ಲಿಪ್ ಮಾಡುವವರೆಗೆ ನೀವು ಒಂದೇ ಒಂದು ಬಾಗಿಲನ್ನು ತೆರೆಯಲು, ಇಂಜಿನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಅಥವಾ ಹಾರ್ನ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ನಿಮಗೆ ಹೇಳಲಾಗುತ್ತದೆ. ನೀವು ಕೇವಲ ಪ್ರಯಾಣಿಕರ ಸೀಟಿನಿಂದ ನಿಮ್ಮ ಬ್ಯಾಗ್ ತೆಗೆದುಕೊಳ್ಳಲು ಬಯಸಿದರೂ, ನೀವು ಎಲ್ಲದಕ್ಕೂ ಕಾಯಬೇಕು. ಇದೇ ಸಾಂಪ್ರದಾಯಿಕ ಹೈಡ್ರೇಶನ್‌ನ ಬಳಕೆದಾರರ ಅನುಭವವಾಗಿತ್ತು. ಪುಟವು ಸಿದ್ಧವಾಗಿ ಕಾಣಿಸಬಹುದು, ಆದರೆ ಅದರೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಯಾವುದೇ ಪ್ರಯತ್ನ ಮಾಡಿದರೆ ಏನೂ ಆಗುತ್ತಿರಲಿಲ್ಲ, ಇದು ಬಳಕೆದಾರರ ಗೊಂದಲ ಮತ್ತು "ರೋಷದ ಕ್ಲಿಕ್‌ಗಳಿಗೆ" ಕಾರಣವಾಗುತ್ತಿತ್ತು.

ರಿಯಾಕ್ಟ್ 18 ರ ಆಗಮನ: ಕನ್ಕರೆಂಟ್ ರೆಂಡರಿಂಗ್‌ನೊಂದಿಗೆ ಒಂದು ಮಾದರಿ ಬದಲಾವಣೆ

ರಿಯಾಕ್ಟ್ 18ರ ಪ್ರಮುಖ ನಾವೀನ್ಯತೆ ಕನ್ಕರೆನ್ಸಿ. ಇದು ರಿಯಾಕ್ಟ್‌ಗೆ ಏಕಕಾಲದಲ್ಲಿ ಅನೇಕ ಸ್ಟೇಟ್ ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ತಯಾರಿಸಲು ಮತ್ತು ಮುಖ್ಯ ಥ್ರೆಡ್ ಅನ್ನು ಬ್ಲಾಕ್ ಮಾಡದೆ ರೆಂಡರಿಂಗ್ ಕೆಲಸವನ್ನು ವಿರಾಮಗೊಳಿಸಲು, ಪುನರಾರಂಭಿಸಲು ಅಥವಾ ಕೈಬಿಡಲು ಅನುಮತಿಸುತ್ತದೆ. ಇದು ಕ್ಲೈಂಟ್-ಸೈಡ್ ರೆಂಡರಿಂಗ್‌ಗೆ ಆಳವಾದ ಪರಿಣಾಮಗಳನ್ನು ಹೊಂದಿದ್ದರೂ, ಇದು ಹೆಚ್ಚು ಚುರುಕಾದ ಸರ್ವರ್ ರೆಂಡರಿಂಗ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಅನ್ಲಾಕ್ ಮಾಡುವ ಕೀಲಿಯಾಗಿದೆ.

ಕನ್ಕರೆನ್ಸಿ ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್ ಅನ್ನು ಸಾಧ್ಯವಾಗಿಸಲು ಒಟ್ಟಾಗಿ ಕೆಲಸ ಮಾಡುವ ಎರಡು ನಿರ್ಣಾಯಕ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ:

  1. ಸ್ಟ್ರೀಮಿಂಗ್ SSR: ಸರ್ವರ್ ಪುಟವು ಸಂಪೂರ್ಣವಾಗಿ ಸಿದ್ಧವಾಗುವವರೆಗೆ ಕಾಯುವ ಬದಲು, ರೆಂಡರ್ ಆಗುತ್ತಿದ್ದಂತೆ HTML ಅನ್ನು ತುಣುಕುಗಳಾಗಿ ಕಳುಹಿಸಬಹುದು.
  2. ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್: ಪೂರ್ಣ HTML ಸ್ಟ್ರೀಮ್ ಮತ್ತು ಎಲ್ಲಾ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಬರುವ ಮೊದಲೇ ರಿಯಾಕ್ಟ್ ಪುಟವನ್ನು ಹೈಡ್ರೇಟ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಬಹುದು, ಮತ್ತು ಅದನ್ನು ನಾನ್-ಬ್ಲಾಕಿಂಗ್, ಆದ್ಯತೆಯ ರೀತಿಯಲ್ಲಿ ಮಾಡಬಹುದು.

ಮೂಲ ಪರಿಕಲ್ಪನೆ: ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್ ಎಂದರೇನು?

ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್ "ಎಲ್ಲವೂ-ಅಥವಾ-ಏನೂ-ಇಲ್ಲ" ಮಾದರಿಯನ್ನು ಕಿತ್ತುಹಾಕುತ್ತದೆ. ಒಂದೇ, ಏಕಶಿಲೆಯ ಕಾರ್ಯದ ಬದಲು, ಹೈಡ್ರೇಶನ್ ಸಣ್ಣ, ನಿರ್ವಹಿಸಬಲ್ಲ ಮತ್ತು ಆದ್ಯತೆ ನೀಡಬಹುದಾದ ಕಾರ್ಯಗಳ ಸರಣಿಯಾಗುತ್ತದೆ. ಇದು ರಿಯಾಕ್ಟ್‌ಗೆ ಕಾಂಪೊನೆಂಟ್‌ಗಳು ಲಭ್ಯವಾದಂತೆ ಅವುಗಳನ್ನು ಹೈಡ್ರೇಟ್ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಮುಖ್ಯವಾಗಿ, ಬಳಕೆದಾರರು ಸಕ್ರಿಯವಾಗಿ ಸಂವಹನ ನಡೆಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಕಾಂಪೊನೆಂಟ್‌ಗಳಿಗೆ ಆದ್ಯತೆ ನೀಡುತ್ತದೆ.

ಪ್ರಮುಖ ಅಂಶಗಳು: ಸ್ಟ್ರೀಮಿಂಗ್ SSR ಮತ್ತು ``

ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ನೀವು ಮೊದಲು ಅದರ ಎರಡು ಮೂಲಭೂತ ಆಧಾರಸ್ತಂಭಗಳನ್ನು ಗ್ರಹಿಸಬೇಕು: ಸ್ಟ್ರೀಮಿಂಗ್ SSR ಮತ್ತು `` ಕಾಂಪೊನೆಂಟ್.

ಸ್ಟ್ರೀಮಿಂಗ್ SSR

ಸ್ಟ್ರೀಮಿಂಗ್ SSR ನೊಂದಿಗೆ, ಸರ್ವರ್ ನಿಧಾನವಾದ ಡೇಟಾ ಫೆಚ್‌ಗಳು (ಕಾಮೆಂಟ್ಸ್ ವಿಭಾಗಕ್ಕಾಗಿ API ಕರೆಯಂತಹ) ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ಕಾಯಬೇಕಾಗಿಲ್ಲ. ಬದಲಾಗಿ, ಅದು ಮುಖ್ಯ ಲೇಔಟ್ ಮತ್ತು ವಿಷಯದಂತಹ ಪುಟದ ಸಿದ್ಧವಾಗಿರುವ ಭಾಗಗಳಿಗಾಗಿ HTML ಅನ್ನು ತಕ್ಷಣವೇ ಕಳುಹಿಸಬಹುದು. ನಿಧಾನವಾದ ಭಾಗಗಳಿಗಾಗಿ, ಅದು ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ (ಒಂದು ಫಾಲ್‌ಬ್ಯಾಕ್ UI) ಅನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ನಿಧಾನವಾದ ಭಾಗಕ್ಕಾಗಿ ಡೇಟಾ ಸಿದ್ಧವಾದಾಗ, ಸರ್ವರ್ ಹೆಚ್ಚುವರಿ HTML ಮತ್ತು ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ ಅನ್ನು ನಿಜವಾದ ವಿಷಯದೊಂದಿಗೆ ಬದಲಾಯಿಸಲು ಒಂದು ಇನ್‌ಲೈನ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸ್ಟ್ರೀಮ್ ಮಾಡುತ್ತದೆ. ಇದರರ್ಥ ಬಳಕೆದಾರರು ಪುಟದ ರಚನೆ ಮತ್ತು ಪ್ರಾಥಮಿಕ ವಿಷಯವನ್ನು ಹೆಚ್ಚು ವೇಗವಾಗಿ ನೋಡುತ್ತಾರೆ.

`` ಗಡಿರೇಖೆ

`` ಕಾಂಪೊನೆಂಟ್ ಎಂದರೆ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಯಾವ ಭಾಗಗಳನ್ನು ಪುಟದ ಉಳಿದ ಭಾಗವನ್ನು ಬ್ಲಾಕ್ ಮಾಡದೆ ಅಸಿಂಕ್ರೊನಸ್ ಆಗಿ ಲೋಡ್ ಮಾಡಬಹುದು ಎಂದು ರಿಯಾಕ್ಟ್‌ಗೆ ಹೇಳಲು ನೀವು ಬಳಸುವ ಯಾಂತ್ರಿಕತೆಯಾಗಿದೆ. ನೀವು ನಿಧಾನವಾದ ಕಾಂಪೊನೆಂಟ್ ಅನ್ನು `` ನಲ್ಲಿ ಸುತ್ತಿ ಮತ್ತು `fallback` ಪ್ರಾಪ್ ಅನ್ನು ಒದಗಿಸುತ್ತೀರಿ, ಕಾಂಪೊನೆಂಟ್ ಲೋಡ್ ಆಗುತ್ತಿರುವಾಗ ರಿಯಾಕ್ಟ್ ಇದನ್ನು ರೆಂಡರ್ ಮಾಡುತ್ತದೆ.

ಸರ್ವರ್‌ನಲ್ಲಿ, `` ಸ್ಟ್ರೀಮಿಂಗ್‌ಗೆ ಸಂಕೇತವಾಗಿದೆ. ಸರ್ವರ್ `` ಗಡಿರೇಖೆಯನ್ನು ಎದುರಿಸಿದಾಗ, ಅದು ಮೊದಲು ಫಾಲ್‌ಬ್ಯಾಕ್ HTML ಅನ್ನು ಕಳುಹಿಸಬಹುದು ಮತ್ತು ನಂತರ ನಿಜವಾದ ಕಾಂಪೊನೆಂಟ್ ಸಿದ್ಧವಾದಾಗ ಅದರ HTML ಅನ್ನು ಸ್ಟ್ರೀಮ್ ಮಾಡಬಹುದು ಎಂದು ಅದಕ್ಕೆ ತಿಳಿದಿರುತ್ತದೆ. ಬ್ರೌಸರ್‌ನಲ್ಲಿ, `` ಗಡಿರೇಖೆಗಳು ಸ್ವತಂತ್ರವಾಗಿ ಹೈಡ್ರೇಟ್ ಮಾಡಬಹುದಾದ "ದ್ವೀಪಗಳನ್ನು" ವ್ಯಾಖ್ಯಾನಿಸುತ್ತವೆ.

ಇಲ್ಲಿ ಒಂದು ಪರಿಕಲ್ಪನಾತ್ಮಕ ಉದಾಹರಣೆ ಇದೆ:


function App() {
  return (
    <div>
      <Header />
      <main>
        <ArticleContent />
        <Suspense fallback={<CommentsSkeleton />}>
          <CommentsSection />  <!-- ಈ ಕಾಂಪೊನೆಂಟ್ ಡೇಟಾವನ್ನು ಪಡೆಯಬಹುದು -->
        </Suspense>
      </main>
      <Suspense fallback={<ChatWidgetLoader />}>
        <ChatWidget /> <!-- ಇದು ಒಂದು ಭಾರವಾದ ಥರ್ಡ್-ಪಾರ್ಟಿ ಸ್ಕ್ರಿಪ್ಟ್ ಆಗಿದೆ -->
      </Suspense>
      <Footer />
    </div>
  );
}

ಈ ಉದಾಹರಣೆಯಲ್ಲಿ, `Header`, `ArticleContent`, ಮತ್ತು `Footer` ತಕ್ಷಣವೇ ರೆಂಡರ್ ಆಗಿ ಸ್ಟ್ರೀಮ್ ಆಗುತ್ತವೆ. ಬ್ರೌಸರ್ `CommentsSkeleton` ಮತ್ತು `ChatWidgetLoader` ಗಾಗಿ HTML ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ನಂತರ, ಸರ್ವರ್‌ನಲ್ಲಿ `CommentsSection` ಮತ್ತು `ChatWidget` ಸಿದ್ಧವಾದಾಗ, ಅವುಗಳ HTML ಅನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ಸ್ಟ್ರೀಮ್ ಮಾಡಲಾಗುತ್ತದೆ. ಈ `` ಗಡಿರೇಖೆಗಳು ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್ ತನ್ನ ಮ್ಯಾಜಿಕ್ ಮಾಡಲು ಅನುಮತಿಸುವ ಸೀಮ್‌ಗಳನ್ನು ರಚಿಸುತ್ತವೆ.

ಅದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ: ಆದ್ಯತೆ-ಆಧಾರಿತ ಲೋಡಿಂಗ್ ಕ್ರಿಯೆಯಲ್ಲಿ

ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್‌ನ ನಿಜವಾದ ಪ್ರತಿಭೆಯು ಕಾರ್ಯಾಚರಣೆಗಳ ಕ್ರಮವನ್ನು ನಿರ್ದೇಶಿಸಲು ಅದು ಬಳಕೆದಾರರ ಸಂವಾದವನ್ನು ಹೇಗೆ ಬಳಸುತ್ತದೆ ಎಂಬುದರಲ್ಲಿದೆ. ರಿಯಾಕ್ಟ್ ಇನ್ನು ಮುಂದೆ ಕಟ್ಟುನಿಟ್ಟಾದ, ಮೇಲಿನಿಂದ ಕೆಳಗಿನ ಹೈಡ್ರೇಶನ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಅನುಸರಿಸುವುದಿಲ್ಲ; ಅದು ಬಳಕೆದಾರರಿಗೆ ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ.

ಬಳಕೆದಾರನೇ ಆದ್ಯತೆ

ಇಲ್ಲಿ ಮೂಲ ತತ್ವವಿದೆ: ಬಳಕೆದಾರ ಸಂವಹನ ನಡೆಸುವ ಕಾಂಪೊನೆಂಟ್‌ಗಳನ್ನು ಹೈಡ್ರೇಟ್ ಮಾಡಲು ರಿಯಾಕ್ಟ್ ಆದ್ಯತೆ ನೀಡುತ್ತದೆ.

ರಿಯಾಕ್ಟ್ ಪುಟವನ್ನು ಹೈಡ್ರೇಟ್ ಮಾಡುತ್ತಿರುವಾಗ, ಅದು ರೂಟ್ ಮಟ್ಟದಲ್ಲಿ ಈವೆಂಟ್ ಲಿಸನರ್‌ಗಳನ್ನು ಜೋಡಿಸುತ್ತದೆ. ಬಳಕೆದಾರರು ಇನ್ನೂ ಹೈಡ್ರೇಟ್ ಆಗದ ಕಾಂಪೊನೆಂಟ್‌ನೊಳಗಿನ ಬಟನ್ ಮೇಲೆ ಕ್ಲಿಕ್ ಮಾಡಿದರೆ, ರಿಯಾಕ್ಟ್ ಅತ್ಯಂತ ಚತುರತೆಯಿಂದ ಕೆಲಸ ಮಾಡುತ್ತದೆ:

  1. ಈವೆಂಟ್ ಕ್ಯಾಪ್ಚರ್: ರಿಯಾಕ್ಟ್ ರೂಟ್‌ನಲ್ಲಿ ಕ್ಲಿಕ್ ಈವೆಂಟ್ ಅನ್ನು ಸೆರೆಹಿಡಿಯುತ್ತದೆ.
  2. ಆದ್ಯತೆ ನೀಡುವುದು: ಬಳಕೆದಾರರು ಯಾವ ಕಾಂಪೊನೆಂಟ್ ಮೇಲೆ ಕ್ಲಿಕ್ ಮಾಡಿದ್ದಾರೆಂದು ಅದು ಗುರುತಿಸುತ್ತದೆ. ನಂತರ ಅದು ಆ ನಿರ್ದಿಷ್ಟ ಕಾಂಪೊನೆಂಟ್ ಮತ್ತು ಅದರ ಪೋಷಕ ಕಾಂಪೊನೆಂಟ್‌ಗಳನ್ನು ಹೈಡ್ರೇಟ್ ಮಾಡುವ ಆದ್ಯತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ನಡೆಯುತ್ತಿರುವ ಯಾವುದೇ ಕಡಿಮೆ-ಆದ್ಯತೆಯ ಹೈಡ್ರೇಶನ್ ಕೆಲಸವನ್ನು ವಿರಾಮಗೊಳಿಸಲಾಗುತ್ತದೆ.
  3. ಹೈಡ್ರೇಟ್ ಮತ್ತು ರಿಪ್ಲೇ: ರಿಯಾಕ್ಟ್ ತುರ್ತಾಗಿ ಟಾರ್ಗೆಟ್ ಕಾಂಪೊನೆಂಟ್ ಅನ್ನು ಹೈಡ್ರೇಟ್ ಮಾಡುತ್ತದೆ. ಹೈಡ್ರೇಶನ್ ಪೂರ್ಣಗೊಂಡು `onClick` ಹ್ಯಾಂಡ್ಲರ್ ಜೋಡಣೆಯಾದ ನಂತರ, ರಿಯಾಕ್ಟ್ ಸೆರೆಹಿಡಿದ ಕ್ಲಿಕ್ ಈವೆಂಟ್ ಅನ್ನು ಮರುಪ್ರಸಾರ ಮಾಡುತ್ತದೆ.

ಬಳಕೆದಾರರ ದೃಷ್ಟಿಕೋನದಿಂದ, ಸಂವಾದವು ಮೊದಲಿನಿಂದಲೂ ಸಂವಾದಾತ್ಮಕವಾಗಿದ್ದಂತೆ ಸರಾಗವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ತೆರೆಮರೆಯಲ್ಲಿ ಅದನ್ನು ತಕ್ಷಣವೇ ಸಾಧ್ಯವಾಗಿಸಲು ಒಂದು ಅತ್ಯಾಧುನಿಕ ಆದ್ಯತೆಯ ನೃತ್ಯ ನಡೆದಿದೆ ಎಂಬುದು ಅವರಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ತಿಳಿದಿರುವುದಿಲ್ಲ.

ಹಂತ-ಹಂತದ ಸನ್ನಿವೇಶ

ಇದನ್ನು ಕ್ರಿಯೆಯಲ್ಲಿ ನೋಡಲು ನಮ್ಮ ಇ-ಕಾಮರ್ಸ್ ಪುಟದ ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ. ಪುಟದಲ್ಲಿ ಮುಖ್ಯ ಉತ್ಪನ್ನ ಗ್ರಿಡ್, ಸಂಕೀರ್ಣ ಫಿಲ್ಟರ್‌ಗಳೊಂದಿಗೆ ಒಂದು ಸೈಡ್‌ಬಾರ್, ಮತ್ತು ಕೆಳಭಾಗದಲ್ಲಿ ಒಂದು ಭಾರವಾದ ಥರ್ಡ್-ಪಾರ್ಟಿ ಚಾಟ್ ವಿಜೆಟ್ ಇದೆ.

  1. ಸರ್ವರ್ ಸ್ಟ್ರೀಮಿಂಗ್: ಸರ್ವರ್ ಉತ್ಪನ್ನ ಗ್ರಿಡ್ ಸೇರಿದಂತೆ ಆರಂಭಿಕ HTML ಶೆಲ್ ಅನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಸೈಡ್‌ಬಾರ್ ಮತ್ತು ಚಾಟ್ ವಿಜೆಟ್ `` ನಲ್ಲಿ ಸುತ್ತಿರುತ್ತವೆ ಮತ್ತು ಅವುಗಳ ಫಾಲ್‌ಬ್ಯಾಕ್ UIಗಳನ್ನು (ಸ್ಕೆಲಿಟನ್‌ಗಳು/ಲೋಡರ್‌ಗಳು) ಕಳುಹಿಸಲಾಗುತ್ತದೆ.
  2. ಆರಂಭಿಕ ರೆಂಡರ್: ಬ್ರೌಸರ್ ಉತ್ಪನ್ನ ಗ್ರಿಡ್ ಅನ್ನು ರೆಂಡರ್ ಮಾಡುತ್ತದೆ. ಬಳಕೆದಾರರು ಉತ್ಪನ್ನಗಳನ್ನು ಬಹುತೇಕ ತಕ್ಷಣವೇ ನೋಡಬಹುದು. ಯಾವುದೇ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಜೋಡಣೆಯಾಗದ ಕಾರಣ TTI ಇನ್ನೂ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ.
  3. ಕೋಡ್ ಲೋಡಿಂಗ್: ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಬಂಡಲ್‌ಗಳು ಡೌನ್‌ಲೋಡ್ ಆಗಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ. ಸೈಡ್‌ಬಾರ್ ಮತ್ತು ಚಾಟ್ ವಿಜೆಟ್‌ನ ಕೋಡ್ ಪ್ರತ್ಯೇಕ, ಕೋಡ್-ಸ್ಪ್ಲಿಟ್ ಚಂಕ್‌ಗಳಲ್ಲಿದೆ ಎಂದು ಭಾವಿಸೋಣ.
  4. ಬಳಕೆದಾರರ ಸಂವಾದ: ಯಾವುದೂ ಹೈಡ್ರೇಟ್ ಆಗಿ ಮುಗಿಯುವ ಮೊದಲು, ಬಳಕೆದಾರರು ತಮಗೆ ಇಷ್ಟವಾದ ಉತ್ಪನ್ನವನ್ನು ನೋಡಿ ಉತ್ಪನ್ನ ಗ್ರಿಡ್‌ನೊಳಗಿನ "ಕಾರ್ಟ್‌ಗೆ ಸೇರಿಸಿ" ಬಟನ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡುತ್ತಾರೆ.
  5. ಆದ್ಯತೆಯ ಮ್ಯಾಜಿಕ್: ರಿಯಾಕ್ಟ್ ಕ್ಲಿಕ್ ಅನ್ನು ಸೆರೆಹಿಡಿಯುತ್ತದೆ. ಕ್ಲಿಕ್ `ProductGrid` ಕಾಂಪೊನೆಂಟ್‌ನೊಳಗೆ ನಡೆದಿದೆ ಎಂದು ಅದು ನೋಡುತ್ತದೆ. ಅದು ತಕ್ಷಣವೇ ಪುಟದ ಇತರ ಭಾಗಗಳ ಹೈಡ್ರೇಶನ್ ಅನ್ನು (ಅದು ಬಹುಶಃ ಆಗತಾನೆ ಪ್ರಾರಂಭಿಸಿರಬಹುದು) ನಿಲ್ಲಿಸುತ್ತದೆ ಅಥವಾ ವಿರಾಮಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಕೇವಲ `ProductGrid` ಅನ್ನು ಹೈಡ್ರೇಟ್ ಮಾಡುವುದರ ಮೇಲೆ ಗಮನಹರಿಸುತ್ತದೆ.
  6. ವೇಗದ ಸಂವಾದಾತ್ಮಕತೆ: `ProductGrid` ಕಾಂಪೊನೆಂಟ್‌ನ ಕೋಡ್ ಮುಖ್ಯ ಬಂಡಲ್‌ನಲ್ಲಿರುವ ಸಾಧ್ಯತೆಯಿರುವುದರಿಂದ ಅದು ಬೇಗನೆ ಹೈಡ್ರೇಟ್ ಆಗುತ್ತದೆ. `onClick` ಹ್ಯಾಂಡ್ಲರ್ ಜೋಡಣೆಯಾಗುತ್ತದೆ ಮತ್ತು ಸೆರೆಹಿಡಿದ ಕ್ಲಿಕ್ ಈವೆಂಟ್ ಅನ್ನು ಮರುಪ್ರಸಾರ ಮಾಡಲಾಗುತ್ತದೆ. ಐಟಂ ಕಾರ್ಟ್‌ಗೆ ಸೇರಿಸಲ್ಪಡುತ್ತದೆ. ಬಳಕೆದಾರರಿಗೆ ತಕ್ಷಣದ ಪ್ರತಿಕ್ರಿಯೆ ಸಿಗುತ್ತದೆ.
  7. ಹೈಡ್ರೇಶನ್ ಪುನರಾರಂಭ: ಈಗ ಉನ್ನತ-ಆದ್ಯತೆಯ ಸಂವಾದವನ್ನು ನಿರ್ವಹಿಸಲಾಗಿದೆ, ರಿಯಾಕ್ಟ್ ತನ್ನ ಕೆಲಸವನ್ನು ಪುನರಾರಂಭಿಸುತ್ತದೆ. ಅದು ಸೈಡ್‌ಬಾರ್ ಅನ್ನು ಹೈಡ್ರೇಟ್ ಮಾಡಲು ಮುಂದುವರಿಯುತ್ತದೆ. ಅಂತಿಮವಾಗಿ, ಚಾಟ್ ವಿಜೆಟ್‌ನ ಕೋಡ್ ಬಂದಾಗ, ಅದು ಆ ಕಾಂಪೊನೆಂಟ್ ಅನ್ನು ಕೊನೆಯದಾಗಿ ಹೈಡ್ರೇಟ್ ಮಾಡುತ್ತದೆ.

ಫಲಿತಾಂಶ? ಪುಟದ ಅತ್ಯಂತ ನಿರ್ಣಾಯಕ ಭಾಗಕ್ಕೆ TTI ಬಳಕೆದಾರರ ಸ್ವಂತ ಉದ್ದೇಶದಿಂದ ನಡೆಸಲ್ಪಟ್ಟು, ಬಹುತೇಕ ತತ್‌ಕ್ಷಣದ್ದಾಗಿತ್ತು. ಒಟ್ಟಾರೆ ಪುಟದ TTI ಇನ್ನು ಮುಂದೆ ಒಂದೇ, ಭಯಾನಕ ಸಂಖ್ಯೆಯಲ್ಲ, ಬದಲಿಗೆ ಪ್ರಗತಿಪರ ಮತ್ತು ಬಳಕೆದಾರ-ಕೇಂದ್ರಿತ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ.

ಜಾಗತಿಕ ಪ್ರೇಕ್ಷಕರಿಗೆ ಸ್ಪಷ್ಟವಾದ ಪ್ರಯೋಜನಗಳು

ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್‌ನ ಪ್ರಭಾವವು ಆಳವಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ವಿಭಿನ್ನ ನೆಟ್‌ವರ್ಕ್ ಪರಿಸ್ಥಿತಿಗಳು ಮತ್ತು ಸಾಧನ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿರುವ ವೈವಿಧ್ಯಮಯ, ಜಾಗತಿಕ ಪ್ರೇಕ್ಷಕರಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ.

ಗ್ರಹಿಸಿದ ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ನಾಟಕೀಯ ಸುಧಾರಣೆ

ಅತ್ಯಂತ ಮಹತ್ವದ ಪ್ರಯೋಜನವೆಂದರೆ ಬಳಕೆದಾರರು-ಗ್ರಹಿಸಿದ ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿನ ಭಾರಿ ಸುಧಾರಣೆಯಾಗಿದೆ. ಬಳಕೆದಾರರು ಸಂವಹನ ನಡೆಸುವ ಪುಟದ ಭಾಗಗಳನ್ನು ಮೊದಲು ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡುವುದರಿಂದ, ಅಪ್ಲಿಕೇಶನ್ *ವೇಗವಾಗಿ* ಭಾಸವಾಗುತ್ತದೆ. ಬಳಕೆದಾರರನ್ನು ಉಳಿಸಿಕೊಳ್ಳಲು ಇದು ನಿರ್ಣಾಯಕವಾಗಿದೆ. ಅಭಿವೃದ್ಧಿಶೀಲ ರಾಷ್ಟ್ರದಲ್ಲಿ ನಿಧಾನಗತಿಯ 3G ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿರುವ ಬಳಕೆದಾರರಿಗೆ, ಸಂಪೂರ್ಣ ಪುಟವು ಸಂವಾದಾತ್ಮಕವಾಗಲು 15 ಸೆಕೆಂಡುಗಳ ಕಾಲ ಕಾಯುವುದಕ್ಕೂ, 3 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಮುಖ್ಯ ವಿಷಯದೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಸಾಧ್ಯವಾಗುವುದಕ್ಕೂ ನಡುವಿನ ವ್ಯತ್ಯಾಸವು ಅಗಾಧವಾಗಿದೆ.

ಉತ್ತಮ ಕೋರ್ ವೆಬ್ ವೈಟಲ್ಸ್

ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್ ಗೂಗಲ್‌ನ ಕೋರ್ ವೆಬ್ ವೈಟಲ್ಸ್ ಮೇಲೆ ನೇರವಾಗಿ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ:

ಭಾರವಾದ ಕಾಂಪೊನೆಂಟ್‌ಗಳಿಂದ ವಿಷಯವನ್ನು ಬೇರ್ಪಡಿಸುವುದು

ಆಧುನಿಕ ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಅನಾಲಿಟಿಕ್ಸ್, A/B ಟೆಸ್ಟಿಂಗ್, ಗ್ರಾಹಕ ಬೆಂಬಲ ಚಾಟ್‌ಗಳು ಅಥವಾ ಜಾಹೀರಾತುಗಳಿಗಾಗಿ ಭಾರವಾದ ಥರ್ಡ್-ಪಾರ್ಟಿ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳೊಂದಿಗೆ ಲೋಡ್ ಆಗಿರುತ್ತವೆ. ಐತಿಹಾಸಿಕವಾಗಿ, ಈ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಇಡೀ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸಂವಾದಾತ್ಮಕವಾಗದಂತೆ ತಡೆಯುತ್ತಿದ್ದವು. ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್ ಮತ್ತು `` ನೊಂದಿಗೆ, ಈ ನಿರ್ಣಾಯಕವಲ್ಲದ ಕಾಂಪೊನೆಂಟ್‌ಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತ್ಯೇಕಿಸಬಹುದು. ಮುಖ್ಯ ಅಪ್ಲಿಕೇಶನ್ ವಿಷಯವು ಲೋಡ್ ಆಗಿ ಸಂವಾದಾತ್ಮಕವಾಗಬಹುದು, ಆದರೆ ಈ ಭಾರವಾದ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಲೋಡ್ ಆಗಿ ಹೈಡ್ರೇಟ್ ಆಗುತ್ತವೆ, ಮುಖ್ಯ ಬಳಕೆದಾರರ ಅನುಭವದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರದಂತೆ.

ಹೆಚ್ಚು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು

ಹೈಡ್ರೇಶನ್ ತುಣುಕುಗಳಲ್ಲಿ ನಡೆಯಬಹುದಾದ್ದರಿಂದ, ಒಂದು ಅಪ್ರಮುಖ ಕಾಂಪೊನೆಂಟ್‌ನಲ್ಲಿನ (ಸಾಮಾಜಿಕ ಮಾಧ್ಯಮ ವಿಜೆಟ್‌ನಂತಹ) ದೋಷವು ಇಡೀ ಪುಟವನ್ನು ಮುರಿಯುವ ಅಗತ್ಯವಿಲ್ಲ. ರಿಯಾಕ್ಟ್ ಸಂಭಾವ್ಯವಾಗಿ ಆ `` ಗಡಿರೇಖೆಯೊಳಗೆ ದೋಷವನ್ನು ಪ್ರತ್ಯೇಕಿಸಬಹುದು, ಆದರೆ ಉಳಿದ ಅಪ್ಲಿಕೇಶನ್ ಸಂವಾದಾತ್ಮಕವಾಗಿಯೇ ಉಳಿಯುತ್ತದೆ.

ಪ್ರಾಯೋಗಿಕ ಅಳವಡಿಕೆ ಮತ್ತು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು

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

`hydrateRoot` API ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವುದು

ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ, ಈ ಹೊಸ ವರ್ತನೆಯ ಪ್ರವೇಶ ಬಿಂದು `hydrateRoot` API ಆಗಿದೆ. ನೀವು ಹಳೆಯ `ReactDOM.hydrate` ನಿಂದ `ReactDOM.hydrateRoot` ಗೆ ಬದಲಾಯಿಸುತ್ತೀರಿ.


// ಮೊದಲು (ಹಳೆಯದು)
import { hydrate } from 'react-dom';
const container = document.getElementById('root');
hydrate(<App />, container);

// ನಂತರ (ರಿಯಾಕ್ಟ್ 18+)
import { hydrateRoot } from 'react-dom/client';
const container = document.getElementById('root');
const root = hydrateRoot(container, <App />);

ಈ ಸರಳ ಬದಲಾವಣೆಯು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್ ಸೇರಿದಂತೆ ಹೊಸ ಕನ್ಕರೆಂಟ್ ರೆಂಡರಿಂಗ್ ವೈಶಿಷ್ಟ್ಯಗಳಿಗೆ ಸೇರಿಸುತ್ತದೆ.

`` ನ ವ್ಯೂಹಾತ್ಮಕ ಬಳಕೆ

ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್‌ನ ಶಕ್ತಿಯು ನಿಮ್ಮ `` ಗಡಿರೇಖೆಗಳನ್ನು ನೀವು ಹೇಗೆ ಇರಿಸುತ್ತೀರಿ ಎಂಬುದರ ಮೂಲಕ ಅನ್‌ಲಾಕ್ ಆಗುತ್ತದೆ. ಪ್ರತಿ ಸಣ್ಣ ಕಾಂಪೊನೆಂಟ್ ಅನ್ನು ಸುತ್ತಬೇಡಿ; ಬಳಕೆದಾರರ ಹರಿವನ್ನು ಅಡ್ಡಿಪಡಿಸದೆ ಸ್ವತಂತ್ರವಾಗಿ ಲೋಡ್ ಮಾಡಬಹುದಾದ ತಾರ್ಕಿಕ UI ಘಟಕಗಳು ಅಥವಾ "ದ್ವೀಪಗಳ" ದೃಷ್ಟಿಯಿಂದ ಯೋಚಿಸಿ.

`` ಗಡಿರೇಖೆಗಳಿಗೆ ಉತ್ತಮ ಅಭ್ಯರ್ಥಿಗಳು:

ಕೋಡ್ ಸ್ಪ್ಲಿಟಿಂಗ್‌ಗಾಗಿ `React.lazy` ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಿ

`React.lazy` ಮೂಲಕ ಕೋಡ್ ಸ್ಪ್ಲಿಟಿಂಗ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಿದಾಗ ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್ ಇನ್ನಷ್ಟು ಶಕ್ತಿಯುತವಾಗಿರುತ್ತದೆ. ಇದು ನಿಮ್ಮ ಕಡಿಮೆ-ಆದ್ಯತೆಯ ಕಾಂಪೊನೆಂಟ್‌ಗಳ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಅಗತ್ಯವಿದ್ದಾಗ ಮಾತ್ರ ಡೌನ್‌ಲೋಡ್ ಮಾಡುವುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ, ಆರಂಭಿಕ ಬಂಡಲ್ ಗಾತ್ರವನ್ನು ಮತ್ತಷ್ಟು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.


import React, { Suspense, lazy } from 'react';

const CommentsSection = lazy(() => import('./CommentsSection'));
const ChatWidget = lazy(() => import('./ChatWidget'));

function App() {
  return (
    <div>
      <ArticleContent />
      <Suspense fallback={<CommentsSkeleton />}>
        <CommentsSection />
      </Suspense>
      <Suspense fallback={null}> <!-- ಮರೆಮಾಡಿದ ವಿಜೆಟ್‌ಗೆ ದೃಶ್ಯ ಲೋಡರ್ ಅಗತ್ಯವಿಲ್ಲ -->
        <ChatWidget />
      </Suspense>
    </div>
  );
}

ಈ ಸೆಟಪ್‌ನಲ್ಲಿ, `CommentsSection` ಮತ್ತು `ChatWidget` ಗಾಗಿ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಕೋಡ್ ಪ್ರತ್ಯೇಕ ಫೈಲ್‌ಗಳಲ್ಲಿರುತ್ತದೆ. ರಿಯಾಕ್ಟ್ ಅವುಗಳನ್ನು ರೆಂಡರ್ ಮಾಡಲು ನಿರ್ಧರಿಸಿದಾಗ ಮಾತ್ರ ಬ್ರೌಸರ್ ಅವುಗಳನ್ನು ಪಡೆಯುತ್ತದೆ, ಮತ್ತು ಅವು ಮುಖ್ಯ `ArticleContent` ಅನ್ನು ಬ್ಲಾಕ್ ಮಾಡದೆ ಸ್ವತಂತ್ರವಾಗಿ ಹೈಡ್ರೇಟ್ ಆಗುತ್ತವೆ.

`renderToPipeableStream` ನೊಂದಿಗೆ ಸರ್ವರ್-ಸೈಡ್ ಸೆಟಪ್

ಕಸ್ಟಮ್ SSR ಪರಿಹಾರವನ್ನು ನಿರ್ಮಿಸುತ್ತಿರುವವರಿಗೆ, ಬಳಸಬೇಕಾದ ಸರ್ವರ್-ಸೈಡ್ API `renderToPipeableStream` ಆಗಿದೆ. ಈ API ಅನ್ನು ವಿಶೇಷವಾಗಿ ಸ್ಟ್ರೀಮಿಂಗ್‌ಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು `` ನೊಂದಿಗೆ ಮನಬಂದಂತೆ ಸಂಯೋಜನೆಗೊಳ್ಳುತ್ತದೆ. HTML ಅನ್ನು ಯಾವಾಗ ಕಳುಹಿಸಬೇಕು ಮತ್ತು ದೋಷಗಳನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸಬೇಕು ಎಂಬುದರ ಮೇಲೆ ಇದು ನಿಮಗೆ ಸೂಕ್ಷ್ಮ-ನಿಯಂತ್ರಿತ ನಿಯಂತ್ರಣವನ್ನು ನೀಡುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಹೆಚ್ಚಿನ ಡೆವಲಪರ್‌ಗಳಿಗೆ, Next.js ನಂತಹ ಮೆಟಾ-ಫ್ರೇಮ್‌ವರ್ಕ್ ಶಿಫಾರಸು ಮಾಡಲಾದ ಮಾರ್ಗವಾಗಿದೆ, ಏಕೆಂದರೆ ಇದು ಈ ಸಂಕೀರ್ಣತೆಯನ್ನು ದೂರ ಮಾಡುತ್ತದೆ.

ಭವಿಷ್ಯ: ರಿಯಾಕ್ಟ್ ಸರ್ವರ್ ಕಾಂಪೊನೆಂಟ್ಸ್

ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್ ಒಂದು ಸ್ಮಾರಕ ಹೆಜ್ಜೆಯಾಗಿದೆ, ಆದರೆ ಇದು ಇನ್ನೂ ದೊಡ್ಡ ಕಥೆಯ ಒಂದು ಭಾಗವಾಗಿದೆ. ಮುಂದಿನ ವಿಕಸನವು ರಿಯಾಕ್ಟ್ ಸರ್ವರ್ ಕಾಂಪೊನೆಂಟ್ಸ್ (RSCs) ಆಗಿದೆ. RSCಗಳು ಸರ್ವರ್‌ನಲ್ಲಿ ಮಾತ್ರ ಚಲಿಸುವ ಮತ್ತು ತಮ್ಮ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ಎಂದಿಗೂ ಕಳುಹಿಸದ ಕಾಂಪೊನೆಂಟ್‌ಗಳಾಗಿವೆ. ಇದರರ್ಥ ಅವುಗಳನ್ನು ಹೈಡ್ರೇಟ್ ಮಾಡಬೇಕಾಗಿಲ್ಲ, ಇದು ಕ್ಲೈಂಟ್-ಸೈಡ್ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಬಂಡಲ್ ಅನ್ನು ಇನ್ನಷ್ಟು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್ ಮತ್ತು RSCಗಳು ಒಟ್ಟಿಗೆ ಪರಿಪೂರ್ಣವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಕೇವಲ ಡೇಟಾ ಪ್ರದರ್ಶಿಸುವ ಭಾಗಗಳು RSCಗಳಾಗಿರಬಹುದು (ಶೂನ್ಯ ಕ್ಲೈಂಟ್-ಸೈಡ್ JS), ಆದರೆ ಸಂವಾದಾತ್ಮಕ ಭಾಗಗಳು ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್‌ನಿಂದ ಪ್ರಯೋಜನ ಪಡೆಯುವ ಕ್ಲೈಂಟ್ ಕಾಂಪೊನೆಂಟ್‌ಗಳಾಗಿರಬಹುದು. ಈ ಸಂಯೋಜನೆಯು ರಿಯಾಕ್ಟ್‌ನೊಂದಿಗೆ ಹೆಚ್ಚು ಕಾರ್ಯಕ್ಷಮತೆಯ, ಸಂವಾದಾತ್ಮಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವ ಭವಿಷ್ಯವನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ.

ತೀರ್ಮಾನ: ಹೆಚ್ಚು ಚುರುಕಾಗಿ ಹೈಡ್ರೇಟ್ ಮಾಡಿ, ಕಷ್ಟಪಟ್ಟು ಅಲ್ಲ

ರಿಯಾಕ್ಟ್‌ನ ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್ ಕೇವಲ ಒಂದು ಕಾರ್ಯಕ್ಷಮತೆ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಿಂತ ಹೆಚ್ಚಾಗಿದೆ; ಇದು ಹೆಚ್ಚು ಬಳಕೆದಾರ-ಕೇಂದ್ರಿತ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನತ್ತ ಒಂದು ಮೂಲಭೂತ ಬದಲಾವಣೆಯಾಗಿದೆ. ಹಿಂದಿನ "ಎಲ್ಲವೂ-ಅಥವಾ-ಏನೂ-ಇಲ್ಲ" ನಿರ್ಬಂಧಗಳಿಂದ ಮುಕ್ತವಾಗಿ, ರಿಯಾಕ್ಟ್ 18 ಡೆವಲಪರ್‌ಗಳಿಗೆ ಕೇವಲ ಲೋಡ್ ಮಾಡಲು ವೇಗವಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಮಾತ್ರವಲ್ಲದೆ, ಸವಾಲಿನ ನೆಟ್‌ವರ್ಕ್ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿಯೂ ಸಂವಹನ ನಡೆಸಲು ವೇಗವಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಅಧಿಕಾರ ನೀಡುತ್ತದೆ.

ಪ್ರಮುಖ ಅಂಶಗಳು ಸ್ಪಷ್ಟವಾಗಿವೆ:

ಜಾಗತಿಕ ಪ್ರೇಕ್ಷಕರಿಗಾಗಿ ನಿರ್ಮಿಸುವ ಡೆವಲಪರ್‌ಗಳಾಗಿ, ನಮ್ಮ ಗುರಿ ಎಲ್ಲರಿಗೂ ಪ್ರವೇಶಿಸಬಹುದಾದ, ಸ್ಥಿತಿಸ್ಥಾಪಕ ಮತ್ತು ಸಂತೋಷಕರ ಅನುಭವಗಳನ್ನು ರಚಿಸುವುದಾಗಿದೆ. ಸೆಲೆಕ್ಟಿವ್ ಹೈಡ್ರೇಶನ್‌ನ ಶಕ್ತಿಯನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವ ಮೂಲಕ, ನಾವು ನಮ್ಮ ಬಳಕೆದಾರರನ್ನು ಕಾಯುವಂತೆ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಬಹುದು ಮತ್ತು ಆ ಭರವಸೆಯನ್ನು ಈಡೇರಿಸಲು ಪ್ರಾರಂಭಿಸಬಹುದು, ಒಂದು ಸಮಯದಲ್ಲಿ ಒಂದು ಆದ್ಯತೆಯ ಕಾಂಪೊನೆಂಟ್ ಮೂಲಕ.