ಹ್ಯಾಬ್ರ್ ಫ್ರಂಟ್-ಎಂಡ್ ಡೆವಲಪರ್ ಲಾಗ್‌ಗಳು: ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಮತ್ತು ರಿಫ್ಲೆಕ್ಟಿಂಗ್

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

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

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

ಇದು ನಿಖರವಾಗಿ ಈ "ಆಫ್-ಸೀಸನ್" ಸ್ಪ್ರಿಂಟ್ ಅನ್ನು ಕೆಳಗೆ ಚರ್ಚಿಸಲಾಗುವುದು. ಈ ಬಾರಿ ಅದು Habr ನ ಮೊಬೈಲ್ ಆವೃತ್ತಿಯ ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಅನ್ನು ಒಳಗೊಂಡಿತ್ತು. ಸಾಮಾನ್ಯವಾಗಿ, ಕಂಪನಿಯು ಅದರ ಬಗ್ಗೆ ಹೆಚ್ಚಿನ ಭರವಸೆಯನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ ಇದು ಹಬರ್ನ ಅವತಾರಗಳ ಸಂಪೂರ್ಣ ಮೃಗಾಲಯವನ್ನು ಬದಲಿಸಬೇಕು ಮತ್ತು ಸಾರ್ವತ್ರಿಕ ಅಡ್ಡ-ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಪರಿಹಾರವಾಗಬೇಕು. ಒಂದು ದಿನ ಅಡಾಪ್ಟಿವ್ ಲೇಔಟ್, PWA, ಆಫ್‌ಲೈನ್ ಮೋಡ್, ಬಳಕೆದಾರರ ಕಸ್ಟಮೈಸೇಶನ್ ಮತ್ತು ಇತರ ಅನೇಕ ಆಸಕ್ತಿದಾಯಕ ವಿಷಯಗಳು ಇರುತ್ತವೆ.

ಕಾರ್ಯವನ್ನು ಹೊಂದಿಸೋಣ

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

ನಾನು ಪ್ರಾಥಮಿಕವಾಗಿ ಸಂಪನ್ಮೂಲ ಬಳಕೆಯ ದಕ್ಷತೆ ಮತ್ತು ಮೃದುವಾದ ಇಂಟರ್ಫೇಸ್ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಬಗ್ಗೆ ಕಾಳಜಿ ವಹಿಸಿದೆ. ಪ್ರತಿದಿನ, ಮನೆ-ಕೆಲಸ-ಮನೆ ಮಾರ್ಗದಲ್ಲಿ, ನನ್ನ ಹಳೆಯ ಫೋನ್ ಫೀಡ್‌ನಲ್ಲಿ 20 ಮುಖ್ಯಾಂಶಗಳನ್ನು ಪ್ರದರ್ಶಿಸಲು ತೀವ್ರವಾಗಿ ಪ್ರಯತ್ನಿಸುತ್ತಿರುವುದನ್ನು ನಾನು ನೋಡಿದೆ. ಇದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಮಾಡುವ ಮೊದಲು ಮೊಬೈಲ್ ಹ್ಯಾಬ್ರ್ ಇಂಟರ್ಫೇಸ್

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

ಹಳೆಯ SSR-CSR ಯೋಜನೆ. ದೃಢೀಕರಣವು C3 ಮತ್ತು C4 ಹಂತಗಳಲ್ಲಿ ಮಾತ್ರ ಸಾಧ್ಯ, ನೋಡ್ JS HTML ಅನ್ನು ರಚಿಸುವಲ್ಲಿ ನಿರತವಾಗಿಲ್ಲದಿದ್ದಾಗ ಮತ್ತು API ಗೆ ವಿನಂತಿಗಳನ್ನು ಪ್ರಾಕ್ಸಿ ಮಾಡಬಹುದು.

ಆ ಕಾಲದ ನಮ್ಮ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಹಬ್ರ್ ಬಳಕೆದಾರರಲ್ಲಿ ಒಬ್ಬರು ನಿಖರವಾಗಿ ವಿವರಿಸಿದ್ದಾರೆ:

ಮೊಬೈಲ್ ಆವೃತ್ತಿಯು ಕ್ರ್ಯಾಪ್ ಆಗಿದೆ. ನಾನು ಇದ್ದ ಹಾಗೆ ಹೇಳುತ್ತಿದ್ದೇನೆ. SSR ಮತ್ತು CSR ನ ಭಯಾನಕ ಸಂಯೋಜನೆ.

ಎಷ್ಟೇ ದುಃಖವಿದ್ದರೂ ನಾವು ಒಪ್ಪಿಕೊಳ್ಳಲೇ ಬೇಕಿತ್ತು.

ನಾನು ಆಯ್ಕೆಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿದ್ದೇನೆ, ಜಿರಾದಲ್ಲಿ "ಇದು ಈಗ ಕೆಟ್ಟದಾಗಿದೆ, ಸರಿಯಾಗಿ ಮಾಡಿ" ಎಂಬ ಮಟ್ಟದಲ್ಲಿ ವಿವರಣೆಯೊಂದಿಗೆ ಟಿಕೆಟ್ ಅನ್ನು ರಚಿಸಿದೆ ಮತ್ತು ಕಾರ್ಯವನ್ನು ವಿಶಾಲವಾದ ಹೊಡೆತಗಳಲ್ಲಿ ಕೊಳೆತಗೊಳಿಸಿದೆ:

• ಡೇಟಾ ಮರುಬಳಕೆ,
• ಪುನಃ ಡ್ರಾಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಿ,
• ನಕಲಿ ವಿನಂತಿಗಳನ್ನು ನಿವಾರಿಸಿ,
• ಲೋಡಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೆಚ್ಚು ಸ್ಪಷ್ಟವಾಗಿ ಮಾಡಿ.

ಡೇಟಾವನ್ನು ಮರುಬಳಕೆ ಮಾಡೋಣ

ಸಿದ್ಧಾಂತದಲ್ಲಿ, ಸರ್ವರ್-ಸೈಡ್ ರೆಂಡರಿಂಗ್ ಅನ್ನು ಎರಡು ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ: ಪರಿಭಾಷೆಯಲ್ಲಿ ಹುಡುಕಾಟ ಎಂಜಿನ್ ಮಿತಿಗಳಿಂದ ಬಳಲುತ್ತಿಲ್ಲ SPA ಇಂಡೆಕ್ಸಿಂಗ್ ಮತ್ತು ಮೆಟ್ರಿಕ್ ಅನ್ನು ಸುಧಾರಿಸಿ FMP (ಅನಿವಾರ್ಯವಾಗಿ ಹದಗೆಡುತ್ತಿದೆ ಟಿಟಿಐ) ಕ್ಲಾಸಿಕ್ ಸನ್ನಿವೇಶದಲ್ಲಿ ಅದು ಅಂತಿಮವಾಗಿ 2013 ರಲ್ಲಿ Airbnb ನಲ್ಲಿ ರೂಪಿಸಲಾಗಿದೆ ವರ್ಷ (ಇನ್ನೂ Backbone.js ನಲ್ಲಿದೆ), SSR ನೋಡ್ ಪರಿಸರದಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಅದೇ ಐಸೊಮಾರ್ಫಿಕ್ JS ಅಪ್ಲಿಕೇಶನ್ ಆಗಿದೆ. ವಿನಂತಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ಸರ್ವರ್ ರಚಿಸಿದ ವಿನ್ಯಾಸವನ್ನು ಸರಳವಾಗಿ ಕಳುಹಿಸುತ್ತದೆ. ನಂತರ ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲಿ ಪುನರ್ಜಲೀಕರಣ ಸಂಭವಿಸುತ್ತದೆ, ಮತ್ತು ನಂತರ ಎಲ್ಲವೂ ಪುಟವನ್ನು ಮರುಲೋಡ್ ಮಾಡದೆಯೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಹಬ್ರ್‌ಗೆ, ಪಠ್ಯ ವಿಷಯದೊಂದಿಗೆ ಇತರ ಹಲವು ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಸರ್ಚ್ ಇಂಜಿನ್‌ಗಳೊಂದಿಗೆ ಸ್ನೇಹ ಸಂಬಂಧವನ್ನು ನಿರ್ಮಿಸುವಲ್ಲಿ ಸರ್ವರ್ ರೆಂಡರಿಂಗ್ ನಿರ್ಣಾಯಕ ಅಂಶವಾಗಿದೆ.

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

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

ಆವರ್ತಕ ರಚನೆಗಳನ್ನು JSON ಆಗಿ ಪರಿವರ್ತಿಸಲು ಅಸಮರ್ಥತೆ ಉದ್ಭವಿಸಿದ ಸಮಸ್ಯೆಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ (ವೃತ್ತಾಕಾರದ ಉಲ್ಲೇಖ); ಅಂತಹ ರಚನೆಗಳನ್ನು ಅವುಗಳ ಫ್ಲಾಟ್ ಕೌಂಟರ್ಪಾರ್ಟ್ಸ್ನೊಂದಿಗೆ ಸರಳವಾಗಿ ಬದಲಿಸುವ ಮೂಲಕ ಪರಿಹರಿಸಲಾಗಿದೆ.

ಹೆಚ್ಚುವರಿಯಾಗಿ, UGC ವಿಷಯದೊಂದಿಗೆ ವ್ಯವಹರಿಸುವಾಗ, HTML ಅನ್ನು ಮುರಿಯದಿರಲು ಡೇಟಾವನ್ನು HTML ಘಟಕಗಳಾಗಿ ಪರಿವರ್ತಿಸಬೇಕು ಎಂಬುದನ್ನು ನೀವು ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳಬೇಕು. ಈ ಉದ್ದೇಶಗಳಿಗಾಗಿ ನಾವು ಬಳಸುತ್ತೇವೆ he.

ರಿಡ್ರಾಗಳನ್ನು ಕಡಿಮೆಗೊಳಿಸುವುದು

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

ಸಮಸ್ಯೆಗೆ ಕೇವಲ ಎರಡು ಪರಿಹಾರಗಳಿವೆ:

• ಕ್ರಾಸ್-ಸರ್ವರ್ ವಿನಂತಿಗಳಿಗೆ ಅಧಿಕೃತ ಡೇಟಾವನ್ನು ಲಗತ್ತಿಸಿ;
• ನೋಡ್ JS ಲೇಯರ್‌ಗಳನ್ನು ಎರಡು ಪ್ರತ್ಯೇಕ ನಿದರ್ಶನಗಳಾಗಿ ವಿಭಜಿಸಿ.

ಮೊದಲ ಪರಿಹಾರಕ್ಕೆ ಸರ್ವರ್‌ನಲ್ಲಿ ಜಾಗತಿಕ ವೇರಿಯಬಲ್‌ಗಳ ಬಳಕೆಯ ಅಗತ್ಯವಿದೆ, ಮತ್ತು ಎರಡನೆಯದು ಕಾರ್ಯವನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಗಡುವನ್ನು ಕನಿಷ್ಠ ಒಂದು ತಿಂಗಳವರೆಗೆ ವಿಸ್ತರಿಸಿತು.

ಆಯ್ಕೆ ಮಾಡುವುದು ಹೇಗೆ? Habr ಸಾಮಾನ್ಯವಾಗಿ ಕನಿಷ್ಠ ಪ್ರತಿರೋಧದ ಹಾದಿಯಲ್ಲಿ ಚಲಿಸುತ್ತದೆ. ಅನೌಪಚಾರಿಕವಾಗಿ, ಕಲ್ಪನೆಯಿಂದ ಮೂಲಮಾದರಿಯವರೆಗಿನ ಚಕ್ರವನ್ನು ಕನಿಷ್ಠಕ್ಕೆ ತಗ್ಗಿಸುವ ಸಾಮಾನ್ಯ ಬಯಕೆ ಇದೆ. ಉತ್ಪನ್ನದ ಬಗೆಗಿನ ವರ್ತನೆಯ ಮಾದರಿಯು booking.com ನ ಪೋಸ್ಟುಲೇಟ್‌ಗಳನ್ನು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ನೆನಪಿಸುತ್ತದೆ, ಒಂದೇ ವ್ಯತ್ಯಾಸವೆಂದರೆ Habr ಬಳಕೆದಾರರ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಹೆಚ್ಚು ಗಂಭೀರವಾಗಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅಂತಹ ನಿರ್ಧಾರಗಳನ್ನು ಮಾಡಲು ಡೆವಲಪರ್ ಆಗಿ ನಿಮ್ಮನ್ನು ನಂಬುತ್ತದೆ.

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

ರಿಫ್ಯಾಕ್ಟರಿಂಗ್‌ನ ಮೊದಲ ಹಂತದ ನಂತರ ಮೊಬೈಲ್ ಹ್ಯಾಬ್ರ್ ಇಂಟರ್ಫೇಸ್

ಅಂತಿಮವಾಗಿ, ಮೊಬೈಲ್ ಆವೃತ್ತಿಯ SSR-CSR ಆರ್ಕಿಟೆಕ್ಚರ್ ಈ ಚಿತ್ರಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ:

"ಎರಡು-ನೋಡ್" SSR-CSR ಸರ್ಕ್ಯೂಟ್. Node JS API ಯಾವಾಗಲೂ ಅಸಮಕಾಲಿಕ I/O ಗೆ ಸಿದ್ಧವಾಗಿರುತ್ತದೆ ಮತ್ತು SSR ಕಾರ್ಯದಿಂದ ನಿರ್ಬಂಧಿಸಲ್ಪಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಎರಡನೆಯದು ಪ್ರತ್ಯೇಕ ನಿದರ್ಶನದಲ್ಲಿದೆ. ಪ್ರಶ್ನೆ ಸರಣಿ #3 ಅಗತ್ಯವಿಲ್ಲ.

ನಕಲಿ ವಿನಂತಿಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದು

ಕುಶಲತೆಯನ್ನು ನಿರ್ವಹಿಸಿದ ನಂತರ, ಪುಟದ ಆರಂಭಿಕ ರೆಂಡರಿಂಗ್ ಇನ್ನು ಮುಂದೆ ಅಪಸ್ಮಾರವನ್ನು ಪ್ರಚೋದಿಸಲಿಲ್ಲ. ಆದರೆ SPA ಮೋಡ್‌ನಲ್ಲಿ Habr ನ ಮತ್ತಷ್ಟು ಬಳಕೆಯು ಇನ್ನೂ ಗೊಂದಲಕ್ಕೆ ಕಾರಣವಾಯಿತು.

ಬಳಕೆದಾರರ ಹರಿವಿನ ಆಧಾರವು ರೂಪದ ಪರಿವರ್ತನೆಗಳಾಗಿರುವುದರಿಂದ ಲೇಖನಗಳ ಪಟ್ಟಿ → ಲೇಖನ → ಕಾಮೆಂಟ್‌ಗಳು ಮತ್ತು ಪ್ರತಿಯಾಗಿ, ಈ ಸರಪಳಿಯ ಸಂಪನ್ಮೂಲ ಬಳಕೆಯನ್ನು ಮೊದಲ ಸ್ಥಾನದಲ್ಲಿ ಅತ್ಯುತ್ತಮವಾಗಿಸಲು ಮುಖ್ಯವಾಗಿದೆ.

ಪೋಸ್ಟ್ ಫೀಡ್‌ಗೆ ಹಿಂತಿರುಗುವುದು ಹೊಸ ಡೇಟಾ ವಿನಂತಿಯನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ

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

ArticlesList: [
  { Article1 },
  ...
],
PageArticle: { ArticleFull1 },

ಒಟ್ಟಾರೆಯಾಗಿ, ನಾವು ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ಲೇಖನಗಳ ಪಟ್ಟಿ, ಇದು ಪ್ರಕಾರದ ವಸ್ತುಗಳನ್ನು ಒಳಗೊಂಡಿದೆ ಲೇಖನ ಮತ್ತು ಮಾಡ್ಯೂಲ್ ಪುಟ ಲೇಖನ, ಇದು ವಸ್ತುವಿನ ವಿಸ್ತೃತ ಆವೃತ್ತಿಯಾಗಿದೆ ಲೇಖನ, ರೀತಿಯ ಲೇಖನ ಪೂರ್ಣ. ದೊಡ್ಡದಾಗಿ, ಈ ಅನುಷ್ಠಾನವು ಸ್ವತಃ ಭಯಾನಕವಾದ ಯಾವುದನ್ನೂ ಒಯ್ಯುವುದಿಲ್ಲ - ಇದು ತುಂಬಾ ಸರಳವಾಗಿದೆ, ಒಬ್ಬರು ನಿಷ್ಕಪಟವೆಂದು ಹೇಳಬಹುದು, ಆದರೆ ಅತ್ಯಂತ ಅರ್ಥವಾಗುವಂತಹದ್ದಾಗಿದೆ. ನೀವು ಮಾರ್ಗವನ್ನು ಬದಲಾಯಿಸಿದಾಗಲೆಲ್ಲಾ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಮರುಹೊಂದಿಸಿದರೆ, ನೀವು ಅದರೊಂದಿಗೆ ಬದುಕಬಹುದು. ಆದಾಗ್ಯೂ, ಲೇಖನ ಫೀಡ್‌ಗಳ ನಡುವೆ ಚಲಿಸುವುದು, ಉದಾಹರಣೆಗೆ /ಫೀಡ್ → /ಎಲ್ಲಾ, ವೈಯಕ್ತಿಕ ಫೀಡ್‌ಗೆ ಸಂಬಂಧಿಸಿದ ಎಲ್ಲವನ್ನೂ ಎಸೆಯಲು ಖಾತ್ರಿಪಡಿಸಲಾಗಿದೆ, ಏಕೆಂದರೆ ನಾವು ಒಂದನ್ನು ಮಾತ್ರ ಹೊಂದಿದ್ದೇವೆ ಲೇಖನಗಳ ಪಟ್ಟಿ, ಇದರಲ್ಲಿ ನೀವು ಹೊಸ ಡೇಟಾವನ್ನು ಹಾಕಬೇಕಾಗುತ್ತದೆ. ಇದು ಮತ್ತೊಮ್ಮೆ ನಮ್ಮನ್ನು ವಿನಂತಿಗಳ ನಕಲು ಮಾಡಲು ಕಾರಣವಾಗುತ್ತದೆ.

ನಾನು ವಿಷಯದ ಬಗ್ಗೆ ಅಗೆಯಲು ಸಾಧ್ಯವಾದ ಎಲ್ಲವನ್ನೂ ಸಂಗ್ರಹಿಸಿದ ನಂತರ, ನಾನು ಹೊಸ ರಾಜ್ಯ ರಚನೆಯನ್ನು ರೂಪಿಸಿದೆ ಮತ್ತು ಅದನ್ನು ನನ್ನ ಸಹೋದ್ಯೋಗಿಗಳಿಗೆ ಪ್ರಸ್ತುತಪಡಿಸಿದೆ. ಚರ್ಚೆಗಳು ಸುದೀರ್ಘವಾಗಿದ್ದವು, ಆದರೆ ಕೊನೆಯಲ್ಲಿ ಪರವಾಗಿ ವಾದಗಳು ಅನುಮಾನಗಳನ್ನು ಮೀರಿಸಿದೆ, ಮತ್ತು ನಾನು ಅನುಷ್ಠಾನವನ್ನು ಪ್ರಾರಂಭಿಸಿದೆ.

ಪರಿಹಾರದ ತರ್ಕವನ್ನು ಎರಡು ಹಂತಗಳಲ್ಲಿ ಉತ್ತಮವಾಗಿ ಬಹಿರಂಗಪಡಿಸಲಾಗುತ್ತದೆ. ಮೊದಲಿಗೆ ನಾವು Vuex ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಪುಟಗಳಿಂದ ಬೇರ್ಪಡಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ ಮತ್ತು ನೇರವಾಗಿ ಮಾರ್ಗಗಳಿಗೆ ಬಂಧಿಸುತ್ತೇವೆ. ಹೌದು, ಅಂಗಡಿಯಲ್ಲಿ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಡೇಟಾ ಇರುತ್ತದೆ, ಪಡೆಯುವವರು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗುತ್ತಾರೆ, ಆದರೆ ನಾವು ಎರಡು ಬಾರಿ ಲೇಖನಗಳನ್ನು ಲೋಡ್ ಮಾಡುವುದಿಲ್ಲ. ಮೊಬೈಲ್ ಆವೃತ್ತಿಗೆ, ಇದು ಬಹುಶಃ ಪ್ರಬಲವಾದ ವಾದವಾಗಿದೆ. ಇದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

ArticlesList: {
  ROUTE_FEED: [ 
    { Article1 },
    ...
  ],
  ROUTE_ALL: [ 
    { Article2 },
    ...
  ],
}

ಆದರೆ ಲೇಖನ ಪಟ್ಟಿಗಳು ಬಹು ಮಾರ್ಗಗಳ ನಡುವೆ ಅತಿಕ್ರಮಿಸಬಹುದಾದರೆ ಮತ್ತು ನಾವು ಆಬ್ಜೆಕ್ಟ್ ಡೇಟಾವನ್ನು ಮರುಬಳಕೆ ಮಾಡಲು ಬಯಸಿದರೆ ಏನು ಲೇಖನ ಪೋಸ್ಟ್ ಪುಟವನ್ನು ನಿರೂಪಿಸಲು, ಅದನ್ನು ತಿರುಗಿಸಲು ಲೇಖನ ಪೂರ್ಣ? ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಅಂತಹ ರಚನೆಯನ್ನು ಬಳಸುವುದು ಹೆಚ್ಚು ತಾರ್ಕಿಕವಾಗಿದೆ:

ArticlesIds: {
  ROUTE_FEED: [ '1', ... ],
  ROUTE_ALL: [ '1', '2', ... ],
},
ArticlesList: {
  '1': { Article1 }, 
  '2': { Article2 },
  ...
}

ಲೇಖನಗಳ ಪಟ್ಟಿ ಇಲ್ಲಿ ಇದು ಕೇವಲ ಒಂದು ರೀತಿಯ ಲೇಖನಗಳ ಭಂಡಾರವಾಗಿದೆ. ಬಳಕೆದಾರರ ಅಧಿವೇಶನದಲ್ಲಿ ಡೌನ್‌ಲೋಡ್ ಮಾಡಲಾದ ಎಲ್ಲಾ ಲೇಖನಗಳು. ನಾವು ಅವರನ್ನು ಅತ್ಯಂತ ಎಚ್ಚರಿಕೆಯಿಂದ ಪರಿಗಣಿಸುತ್ತೇವೆ, ಏಕೆಂದರೆ ಇದು ನಿಲ್ದಾಣಗಳ ನಡುವೆ ಮೆಟ್ರೋದಲ್ಲಿ ಎಲ್ಲೋ ನೋವಿನಿಂದ ಡೌನ್‌ಲೋಡ್ ಆಗಿರುವ ಟ್ರಾಫಿಕ್ ಆಗಿರಬಹುದು ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಈಗಾಗಲೇ ಹೊಂದಿರುವ ಡೇಟಾವನ್ನು ಲೋಡ್ ಮಾಡಲು ಒತ್ತಾಯಿಸುವ ಮೂಲಕ ಮತ್ತೊಮ್ಮೆ ಈ ನೋವನ್ನು ಉಂಟುಮಾಡಲು ನಾವು ಖಂಡಿತವಾಗಿಯೂ ಬಯಸುವುದಿಲ್ಲ. ಡೌನ್‌ಲೋಡ್ ಮಾಡಲಾಗಿದೆ. ಒಂದು ವಸ್ತು ಲೇಖನಗಳುಐಡಿಗಳು ವಸ್ತುಗಳಿಗೆ ID ಗಳ ("ಲಿಂಕ್‌ಗಳಂತೆ") ಸರಳವಾಗಿ ಒಂದು ಶ್ರೇಣಿಯಾಗಿದೆ ಲೇಖನ. ಈ ರಚನೆಯು ಮಾರ್ಗಗಳಿಗೆ ಸಾಮಾನ್ಯ ಡೇಟಾವನ್ನು ನಕಲಿಸುವುದನ್ನು ತಪ್ಪಿಸಲು ಮತ್ತು ವಸ್ತುವನ್ನು ಮರುಬಳಕೆ ಮಾಡುವುದನ್ನು ತಪ್ಪಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ಲೇಖನ ವಿಸ್ತೃತ ಡೇಟಾವನ್ನು ವಿಲೀನಗೊಳಿಸುವ ಮೂಲಕ ಪೋಸ್ಟ್ ಪುಟವನ್ನು ರೆಂಡರ್ ಮಾಡುವಾಗ.

ಲೇಖನಗಳ ಪಟ್ಟಿಯ ಔಟ್‌ಪುಟ್ ಕೂಡ ಹೆಚ್ಚು ಪಾರದರ್ಶಕವಾಗಿದೆ: ಪುನರಾವರ್ತಕ ಘಟಕವು ಲೇಖನ ID ಗಳೊಂದಿಗೆ ಸರಣಿಯ ಮೂಲಕ ಪುನರಾವರ್ತನೆಯಾಗುತ್ತದೆ ಮತ್ತು ಲೇಖನದ ಟೀಸರ್ ಘಟಕವನ್ನು ಸೆಳೆಯುತ್ತದೆ, ಐಡಿಯನ್ನು ಪ್ರಾಪ್ ಆಗಿ ರವಾನಿಸುತ್ತದೆ ಮತ್ತು ಮಗುವಿನ ಘಟಕವು ಅಗತ್ಯ ಡೇಟಾವನ್ನು ಹಿಂಪಡೆಯುತ್ತದೆ ಲೇಖನಗಳ ಪಟ್ಟಿ. ನೀವು ಪ್ರಕಟಣೆಯ ಪುಟಕ್ಕೆ ಹೋದಾಗ, ನಾವು ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ದಿನಾಂಕವನ್ನು ಪಡೆಯುತ್ತೇವೆ ಲೇಖನಗಳ ಪಟ್ಟಿ, ಕಾಣೆಯಾದ ಡೇಟಾವನ್ನು ಪಡೆಯಲು ನಾವು ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ವಸ್ತುವಿಗೆ ಸೇರಿಸುತ್ತೇವೆ.

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

ಡೌನ್‌ಲೋಡ್ ಮಾಡುವುದನ್ನು ಹೆಚ್ಚು ಆನಂದದಾಯಕವಾಗಿಸುವುದು

ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಕೇಕ್ ಮೇಲಿನ ಐಸಿಂಗ್ ಅಸ್ಥಿಪಂಜರಗಳ ಪರಿಕಲ್ಪನೆಯಾಗಿದೆ, ಇದು ನಿಧಾನವಾದ ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ವಿಷಯವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವಲ್ಪ ಕಡಿಮೆ ಅಸಹ್ಯಕರವಾಗಿಸುತ್ತದೆ. ಈ ವಿಷಯದ ಬಗ್ಗೆ ಯಾವುದೇ ಚರ್ಚೆಗಳಿಲ್ಲ; ಕಲ್ಪನೆಯಿಂದ ಮೂಲಮಾದರಿಯ ಮಾರ್ಗವು ಅಕ್ಷರಶಃ ಎರಡು ಗಂಟೆಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು. ವಿನ್ಯಾಸವು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಸ್ವತಃ ಸೆಳೆಯಿತು, ಮತ್ತು ಡೇಟಾಕ್ಕಾಗಿ ಕಾಯುತ್ತಿರುವಾಗ ಸರಳವಾದ, ಕೇವಲ ಮಿನುಗುವ ಡಿವ್ ಬ್ಲಾಕ್‌ಗಳನ್ನು ನಿರೂಪಿಸಲು ನಾವು ನಮ್ಮ ಘಟಕಗಳಿಗೆ ಕಲಿಸಿದ್ದೇವೆ. ವ್ಯಕ್ತಿನಿಷ್ಠವಾಗಿ, ಲೋಡ್ ಮಾಡುವ ಈ ವಿಧಾನವು ಬಳಕೆದಾರರ ದೇಹದಲ್ಲಿ ಒತ್ತಡದ ಹಾರ್ಮೋನುಗಳ ಪ್ರಮಾಣವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಅಸ್ಥಿಪಂಜರವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

ಹಬ್ರಾಲೋಡಿಂಗ್

ಪ್ರತಿಬಿಂಬಿಸುತ್ತಿದೆ

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

ಈ ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳ ಬಿಡುಗಡೆಯ ನಂತರ, ನಾವು ಸಕಾರಾತ್ಮಕ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದು ತುಂಬಾ ಚೆನ್ನಾಗಿತ್ತು. ಇದು ಸ್ಪೂರ್ತಿದಾಯಕವಾಗಿದೆ. ಧನ್ಯವಾದ! ಇನ್ನಷ್ಟು ಬರೆಯಿರಿ.

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

ಮೂಲ: www.habr.com