ಟೈಪ್ಸ್ಕ್ರಿಪ್ಟ್ ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ಗಳ ಕುರಿತು ಒಂದು ವಿಸ್ತೃತ ಮಾರ್ಗದರ್ಶಿ. ಕಂಪೈಲ್-ಟೈಮ್ ಮತ್ತು ರನ್ಟೈಮ್ ನಡುವಿನ ಅಂತರವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು, ಡೇಟಾವನ್ನು ಮೌಲ್ಯೀಕರಿಸುವುದು, ಮತ್ತು ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆಗಳೊಂದಿಗೆ ಸುರಕ್ಷಿತ, ಹೆಚ್ಚು ದೃಢವಾದ ಕೋಡ್ ಬರೆಯುವುದು ಹೇಗೆಂದು ತಿಳಿಯಿರಿ.
ಟೈಪ್ಸ್ಕ್ರಿಪ್ಟ್ ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ಗಳು: ರನ್ಟೈಮ್ ಟೈಪ್ ಸುರಕ್ಷತೆಗೆ ಅಂತಿಮ ಮಾರ್ಗದರ್ಶಿ
ವೆಬ್ ಡೆವಲಪ್ಮೆಂಟ್ ಜಗತ್ತಿನಲ್ಲಿ, ನಿಮ್ಮ ಕೋಡ್ನ ನಿರೀಕ್ಷೆಗಳು ಮತ್ತು ಅದಕ್ಕೆ ಸಿಗುವ ಡೇಟಾದ ವಾಸ್ತವತೆಯ ನಡುವಿನ ಒಪ್ಪಂದವು ದುರ್ಬಲವಾಗಿರುತ್ತದೆ. ಟೈಪ್ಸ್ಕ್ರಿಪ್ಟ್, ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಬರೆಯುವ ನಮ್ಮ ವಿಧಾನವನ್ನು ಒಂದು ಶಕ್ತಿಯುತ ಸ್ಟ್ಯಾಟಿಕ್ ಟೈಪ್ ಸಿಸ್ಟಮ್ ಒದಗಿಸುವ ಮೂಲಕ ಕ್ರಾಂತಿಗೊಳಿಸಿದೆ, ಇದರಿಂದ ಅಸಂಖ್ಯಾತ ಬಗ್ಗಳು ಉತ್ಪಾದನೆಗೆ ತಲುಪುವ ಮೊದಲೇ ಪತ್ತೆಯಾಗುತ್ತವೆ. ಆದಾಗ್ಯೂ, ಈ ಸುರಕ್ಷತಾ ಜಾಲವು ಮುಖ್ಯವಾಗಿ ಕಂಪೈಲ್-ಟೈಮ್ನಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುತ್ತದೆ. ನಿಮ್ಮ ಸುಂದರವಾಗಿ ಟೈಪ್ ಮಾಡಲಾದ ಅಪ್ಲಿಕೇಶನ್ಗೆ ರನ್ಟೈಮ್ನಲ್ಲಿ ಹೊರಗಿನ ಪ್ರಪಂಚದಿಂದ ಗೊಂದಲಮಯ, ಅನಿರೀಕ್ಷಿತ ಡೇಟಾ ಬಂದಾಗ ಏನಾಗುತ್ತದೆ? ಇಲ್ಲಿಯೇ ಟೈಪ್ಸ್ಕ್ರಿಪ್ಟ್ನ ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ಗಳು ನಿಜವಾಗಿಯೂ ದೃಢವಾದ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಅನಿವಾರ್ಯ ಸಾಧನವಾಗುತ್ತವೆ.
ಈ ವಿಸ್ತೃತ ಮಾರ್ಗದರ್ಶಿಯು ನಿಮ್ಮನ್ನು ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ಗಳ ಆಳವಾದ ಜಗತ್ತಿಗೆ ಕರೆದೊಯ್ಯುತ್ತದೆ. ಅವು ಏಕೆ ಅವಶ್ಯಕ, ಅವುಗಳನ್ನು ಮೊದಲಿನಿಂದ ಹೇಗೆ ನಿರ್ಮಿಸುವುದು, ಮತ್ತು ಸಾಮಾನ್ಯ ನೈಜ-ಪ್ರಪಂಚದ ಸನ್ನಿವೇಶಗಳಿಗೆ ಅವುಗಳನ್ನು ಹೇಗೆ ಅನ್ವಯಿಸುವುದು ಎಂಬುದನ್ನು ನಾವು ಅನ್ವೇಷಿಸುತ್ತೇವೆ. ಕೊನೆಯಲ್ಲಿ, ನೀವು ಕೇವಲ ಕಂಪೈಲ್-ಟೈಮ್ನಲ್ಲಿ ಟೈಪ್-ಸುರಕ್ಷಿತವಾದ ಕೋಡ್ ಬರೆಯುವುದಲ್ಲದೆ, ರನ್ಟೈಮ್ನಲ್ಲಿಯೂ ಸ್ಥಿತಿಸ್ಥಾಪಕ ಮತ್ತು ಊಹಿಸಬಹುದಾದ ಕೋಡ್ ಬರೆಯಲು ಸಜ್ಜಾಗುತ್ತೀರಿ.
ದೊಡ್ಡ ವಿಭಜನೆ: ಕಂಪೈಲ್-ಟೈಮ್ ಮತ್ತು ರನ್ಟೈಮ್
ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ಗಳನ್ನು ನಿಜವಾಗಿಯೂ ಪ್ರಶಂಸಿಸಲು, ಅವುಗಳು ಪರಿಹರಿಸುವ ಮೂಲಭೂತ ಸವಾಲನ್ನು ನಾವು ಮೊದಲು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು: ಟೈಪ್ಸ್ಕ್ರಿಪ್ಟ್ನ ಕಂಪೈಲ್-ಟೈಮ್ ಪ್ರಪಂಚ ಮತ್ತು ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ನ ರನ್ಟೈಮ್ ಪ್ರಪಂಚದ ನಡುವಿನ ಅಂತರ.
ಟೈಪ್ಸ್ಕ್ರಿಪ್ಟ್ನ ಕಂಪೈಲ್-ಟೈಮ್ ಸ್ವರ್ಗ
ನೀವು ಟೈಪ್ಸ್ಕ್ರಿಪ್ಟ್ ಕೋಡ್ ಬರೆಯುವಾಗ, ನೀವು ಡೆವಲಪರ್ನ ಸ್ವರ್ಗದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿರುತ್ತೀರಿ. ಟೈಪ್ಸ್ಕ್ರಿಪ್ಟ್ ಕಂಪೈಲರ್ (tsc
) ಒಬ್ಬ ಜಾಗರೂಕ ಸಹಾಯಕರಂತೆ ವರ್ತಿಸುತ್ತದೆ, ನೀವು ವ್ಯಾಖ್ಯಾನಿಸಿದ ಟೈಪ್ಗಳ ವಿರುದ್ಧ ನಿಮ್ಮ ಕೋಡನ್ನು ವಿಶ್ಲೇಷಿಸುತ್ತದೆ. ಇದು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ:
- ಫಂಕ್ಷನ್ಗಳಿಗೆ ತಪ್ಪಾದ ಟೈಪ್ಗಳನ್ನು ರವಾನಿಸುವುದು.
- ಒಂದು ಆಬ್ಜೆಕ್ಟ್ನಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಪ್ರಾಪರ್ಟಿಗಳನ್ನು ಪ್ರವೇಶಿಸುವುದು.
null
ಅಥವಾundefined
ಆಗಿರಬಹುದಾದ ವೇರಿಯೇಬಲ್ ಅನ್ನು ಕಾಲ್ ಮಾಡುವುದು.
ಈ ಪ್ರಕ್ರಿಯೆಯು ನಿಮ್ಮ ಕೋಡ್ ಕಾರ್ಯಗತಗೊಳ್ಳುವ ಮೊದಲು ನಡೆಯುತ್ತದೆ. ಅಂತಿಮ ಉತ್ಪನ್ನವು ಎಲ್ಲಾ ಟೈಪ್ ಟಿಪ್ಪಣಿಗಳನ್ನು ತೆಗೆದುಹಾಕಿದ ಸರಳ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಆಗಿರುತ್ತದೆ. ಟೈಪ್ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಒಂದು ಕಟ್ಟಡದ ವಿವರವಾದ ವಾಸ್ತುಶಿಲ್ಪದ ನೀಲನಕ್ಷೆ ಎಂದು ಭಾವಿಸಿ. ಇದು ಎಲ್ಲಾ ಯೋಜನೆಗಳು ಸರಿಯಾಗಿವೆ, ಅಳತೆಗಳು ನಿಖರವಾಗಿವೆ, ಮತ್ತು ರಚನಾತ್ಮಕ ಸಮಗ್ರತೆಯನ್ನು ಕಾಗದದ ಮೇಲೆ ಖಾತರಿಪಡಿಸುತ್ತದೆ.
ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ನ ರನ್ಟೈಮ್ ವಾಸ್ತವ
ಒಮ್ಮೆ ನಿಮ್ಮ ಟೈಪ್ಸ್ಕ್ರಿಪ್ಟ್ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ಗೆ ಕಂಪೈಲ್ ಆಗಿ ಬ್ರೌಸರ್ ಅಥವಾ Node.js ಪರಿಸರದಲ್ಲಿ ರನ್ ಆದಾಗ, ಸ್ಟ್ಯಾಟಿಕ್ ಟೈಪ್ಗಳು ಮಾಯವಾಗುತ್ತವೆ. ನಿಮ್ಮ ಕೋಡ್ ಈಗ ರನ್ಟೈಮ್ನ ಡೈನಾಮಿಕ್, ಅನಿರೀಕ್ಷಿತ ಜಗತ್ತಿನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ. ಇದು ನಿಯಂತ್ರಿಸಲಾಗದ ಮೂಲಗಳಿಂದ ಬರುವ ಡೇಟಾದೊಂದಿಗೆ ವ್ಯವಹರಿಸಬೇಕಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ:
- API ಪ್ರತಿಕ್ರಿಯೆಗಳು: ಬ್ಯಾಕೆಂಡ್ ಸೇವೆಯು ತನ್ನ ಡೇಟಾ ರಚನೆಯನ್ನು ಅನಿರೀಕ್ಷಿತವಾಗಿ ಬದಲಾಯಿಸಬಹುದು.
- ಬಳಕೆದಾರರ ಇನ್ಪುಟ್: HTML ಫಾರ್ಮ್ಗಳಿಂದ ಬರುವ ಡೇಟಾವು ಇನ್ಪುಟ್ ಪ್ರಕಾರವನ್ನು ಲೆಕ್ಕಿಸದೆ ಯಾವಾಗಲೂ ಸ್ಟ್ರಿಂಗ್ ಆಗಿ ಪರಿಗಣಿಸಲ್ಪಡುತ್ತದೆ.
- ಲೋಕಲ್ ಸ್ಟೋರೇಜ್:
localStorage
ಇಂದ ಪಡೆದ ಡೇಟಾ ಯಾವಾಗಲೂ ಸ್ಟ್ರಿಂಗ್ ಆಗಿರುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಪಾರ್ಸ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. - ಪರಿಸರ ವೇರಿಯೇಬಲ್ಗಳು: ಇವುಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಸ್ಟ್ರಿಂಗ್ಗಳಾಗಿರುತ್ತವೆ ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ಇಲ್ಲದಿರಬಹುದು.
ನಮ್ಮ ಸಾದೃಶ್ಯವನ್ನು ಬಳಸುವುದಾದರೆ, ರನ್ಟೈಮ್ ಒಂದು ನಿರ್ಮಾಣ ಸ್ಥಳ. ನೀಲನಕ್ಷೆ ಪರಿಪೂರ್ಣವಾಗಿತ್ತು, ಆದರೆ ತಲುಪಿಸಲಾದ ಸಾಮಗ್ರಿಗಳು (ಡೇಟಾ) ತಪ್ಪು ಗಾತ್ರ, ತಪ್ಪು ಪ್ರಕಾರ, ಅಥವಾ ಸರಳವಾಗಿ ಕಾಣೆಯಾಗಿರಬಹುದು. ಈ ದೋಷಪೂರಿತ ಸಾಮಗ್ರಿಗಳನ್ನು ಬಳಸಿ ನಿರ್ಮಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ನಿಮ್ಮ ರಚನೆಯು ಕುಸಿಯುತ್ತದೆ. ಇಲ್ಲಿಯೇ ರನ್ಟೈಮ್ ದೋಷಗಳು ಸಂಭವಿಸುತ್ತವೆ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ "Cannot read properties of undefined" ನಂತಹ ಕ್ರ್ಯಾಶ್ಗಳು ಮತ್ತು ಬಗ್ಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ಗಳ ಪ್ರವೇಶ: ಅಂತರವನ್ನು ನಿವಾರಿಸುವುದು
ಹಾಗಾದರೆ, ರನ್ಟೈಮ್ನ ಅನಿರೀಕ್ಷಿತ ಸಾಮಗ್ರಿಗಳ ಮೇಲೆ ನಮ್ಮ ಟೈಪ್ಸ್ಕ್ರಿಪ್ಟ್ ನೀಲನಕ್ಷೆಯನ್ನು ಹೇಗೆ ಜಾರಿಗೊಳಿಸುವುದು? ನಮಗೆ ಡೇಟಾ ಬಂದ ತಕ್ಷಣ ಅದನ್ನು ಪರಿಶೀಲಿಸಿ, ನಮ್ಮ ನಿರೀಕ್ಷೆಗಳಿಗೆ ಸರಿಹೊಂದುತ್ತದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸುವ ಒಂದು ವ್ಯವಸ್ಥೆ ಬೇಕು. ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ಗಳು ನಿಖರವಾಗಿ ಇದನ್ನೇ ಮಾಡುತ್ತವೆ.
ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ ಎಂದರೇನು?
ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ ಟೈಪ್ಸ್ಕ್ರಿಪ್ಟ್ನಲ್ಲಿ ಒಂದು ವಿಶೇಷ ರೀತಿಯ ಫಂಕ್ಷನ್ ಆಗಿದ್ದು ಅದು ಎರಡು ನಿರ್ಣಾಯಕ ಉದ್ದೇಶಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ:
- ರನ್ಟೈಮ್ ಪರಿಶೀಲನೆ: ಇದು ಒಂದು ಮೌಲ್ಯ ಅಥವಾ ಸ್ಥಿತಿಯ ಮೇಲೆ ಮೌಲ್ಯೀಕರಣವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಮೌಲ್ಯೀಕರಣ ವಿಫಲವಾದರೆ, ಅದು ದೋಷವನ್ನು (error) ಎಸೆಯುತ್ತದೆ, ಆ ಕೋಡ್ ಮಾರ್ಗದ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ತಕ್ಷಣವೇ ನಿಲ್ಲಿಸುತ್ತದೆ. ಇದು ಅಮಾನ್ಯ ಡೇಟಾವು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ನಲ್ಲಿ ಮತ್ತಷ್ಟು ಹರಡುವುದನ್ನು ತಡೆಯುತ್ತದೆ.
- ಕಂಪೈಲ್-ಟೈಮ್ ಟೈಪ್ ಸಂಕುಚಿತಗೊಳಿಸುವಿಕೆ: ಮೌಲ್ಯೀಕರಣ ಯಶಸ್ವಿಯಾದರೆ (ಅಂದರೆ, ಯಾವುದೇ ದೋಷ ಎಸೆಯದಿದ್ದರೆ), ಇದು ಟೈಪ್ಸ್ಕ್ರಿಪ್ಟ್ ಕಂಪೈಲರ್ಗೆ ಆ ಮೌಲ್ಯದ ಟೈಪ್ ಈಗ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾಗಿದೆ ಎಂದು ಸಂಕೇತಿಸುತ್ತದೆ. ಕಂಪೈಲರ್ ಈ ಅಸರ್ಶನ್ ಅನ್ನು ನಂಬುತ್ತದೆ ಮತ್ತು ಆ ಮೌಲ್ಯವನ್ನು ಅದರ ಸ್ಕೋಪ್ನ ಉಳಿದ ಭಾಗಕ್ಕೆ ಅಸರ್ಟ್ ಮಾಡಿದ ಟೈಪ್ ಆಗಿ ಬಳಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ಇದರ ಮಾಂತ್ರಿಕತೆಯು ಫಂಕ್ಷನ್ನ ಸಿಗ್ನೇಚರ್ನಲ್ಲಿದೆ, ಅದು asserts
ಕೀವರ್ಡ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ಇದರಲ್ಲಿ ಎರಡು ಪ್ರಮುಖ ರೂಪಗಳಿವೆ:
asserts condition [is type]
: ಈ ರೂಪವು ಒಂದು ನಿರ್ದಿಷ್ಟcondition
ಸತ್ಯವಾಗಿದೆ ಎಂದು ಪ್ರತಿಪಾದಿಸುತ್ತದೆ. ನೀವು ಐಚ್ಛಿಕವಾಗಿis type
(ಟೈಪ್ ಪ್ರೆಡಿಕೇಟ್) ಅನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ವೇರಿಯೇಬಲ್ನ ಟೈಪ್ ಅನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಬಹುದು.asserts this is type
: ಇದನ್ನು ಕ್ಲಾಸ್ ಮೆಥಡ್ಗಳಲ್ಲಿthis
ಕಾಂಟೆಕ್ಸ್ಟ್ನ ಟೈಪ್ ಅನ್ನು ಅಸರ್ಟ್ ಮಾಡಲು ಬಳಸಲಾಗುತ್ತದೆ.
ಇಲ್ಲಿನ ಪ್ರಮುಖ ಅಂಶವೆಂದರೆ "ವಿಫಲವಾದರೆ ಎಸೆಯಿರಿ" (throw on failure) ವರ್ತನೆ. ಒಂದು ಸರಳ if
ಪರಿಶೀಲನೆಯಂತಲ್ಲದೆ, ಒಂದು ಅಸರ್ಶನ್ ಹೀಗೆ ಘೋಷಿಸುತ್ತದೆ: "ಪ್ರೋಗ್ರಾಂ ಮುಂದುವರೆಯಲು ಈ ಸ್ಥಿತಿಯು ಸತ್ಯವಾಗಿರಲೇಬೇಕು. ಅದು ಹಾಗಲ್ಲದಿದ್ದರೆ, ಅದು ಒಂದು ಅಸಾಧಾರಣ ಸ್ಥಿತಿ, ಮತ್ತು ನಾವು ತಕ್ಷಣವೇ ನಿಲ್ಲಿಸಬೇಕು."
ನಿಮ್ಮ ಮೊದಲ ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ ನಿರ್ಮಿಸುವುದು: ಒಂದು ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆ
ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಮತ್ತು ಟೈಪ್ಸ್ಕ್ರಿಪ್ಟ್ನಲ್ಲಿ ಅತ್ಯಂತ ಸಾಮಾನ್ಯವಾದ ಸಮಸ್ಯೆಗಳಲ್ಲಿ ಒಂದಾದ ಸಂಭಾವ್ಯ null
ಅಥವಾ undefined
ಮೌಲ್ಯಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸುವುದರಿಂದ ಪ್ರಾರಂಭಿಸೋಣ.
ಸಮಸ್ಯೆ: ಅನಗತ್ಯ ನಲ್ಗಳು (Nulls)
ಐಚ್ಛಿಕ ಬಳಕೆದಾರ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಮತ್ತು ಬಳಕೆದಾರರ ಹೆಸರನ್ನು ಲಾಗ್ ಮಾಡಲು ಬಯಸುವ ಒಂದು ಫಂಕ್ಷನ್ ಅನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಟೈಪ್ಸ್ಕ್ರಿಪ್ಟ್ನ ಕಟ್ಟುನಿಟ್ಟಾದ ನಲ್ ಪರಿಶೀಲನೆಗಳು ಸಂಭಾವ್ಯ ದೋಷದ ಬಗ್ಗೆ ನಮಗೆ ಸರಿಯಾಗಿ ಎಚ್ಚರಿಸುತ್ತವೆ.
interface User {
name: string;
email: string;
}
function logUserName(user: User | undefined) {
// 🚨 TypeScript Error: 'user' is possibly 'undefined'.
console.log(user.name.toUpperCase());
}
ಇದನ್ನು ಸರಿಪಡಿಸಲು ಪ್ರಮಾಣಿತ ಮಾರ್ಗವೆಂದರೆ if
ಪರಿಶೀಲನೆ:
function logUserName(user: User | undefined) {
if (user) {
// Inside this block, TypeScript knows 'user' is of type 'User'.
console.log(user.name.toUpperCase());
} else {
console.error('User is not provided.');
}
}
ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಈ ಸಂದರ್ಭದಲ್ಲಿ `user` `undefined` ಆಗಿರುವುದು ಸರಿಪಡಿಸಲಾಗದ ದೋಷವಾಗಿದ್ದರೆ ಏನು ಮಾಡುವುದು? ನಾವು ಫಂಕ್ಷನ್ ಮೌನವಾಗಿ ಮುಂದುವರೆಯುವುದನ್ನು ಬಯಸುವುದಿಲ್ಲ. ಅದು ಗಟ್ಟಿಯಾಗಿ ವಿಫಲವಾಗಬೇಕೆಂದು ನಾವು ಬಯಸುತ್ತೇವೆ. ಇದು ಪುನರಾವರ್ತಿತ ಗಾರ್ಡ್ ಕ್ಲಾಸ್ಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಪರಿಹಾರ: ಒಂದು `assertIsDefined` ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್
ಈ ಮಾದರಿಯನ್ನು ಸೊಗಸಾಗಿ ನಿರ್ವಹಿಸಲು ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ ಅನ್ನು ರಚಿಸೋಣ.
// Our reusable assertion function
function assertIsDefined<T>(value: T, message: string = "Value is not defined"): asserts value is NonNullable<T> {
if (value === undefined || value === null) {
throw new Error(message);
}
}
// Let's use it!
interface User {
name: string;
email: string;
}
function logUserName(user: User | undefined) {
assertIsDefined(user, "User object must be provided to log name.");
// No error! TypeScript now knows 'user' is of type 'User'.
// The type has been narrowed from 'User | undefined' to 'User'.
console.log(user.name.toUpperCase());
}
// Example usage:
const validUser = { name: 'Alice', email: 'alice@example.com' };
logUserName(validUser); // Logs "ALICE"
const invalidUser = undefined;
try {
logUserName(invalidUser); // Throws an Error: "User object must be provided to log name."
} catch (error) {
console.error(error.message);
}
ಅಸರ್ಶನ್ ಸಿಗ್ನೇಚರ್ ಅನ್ನು ವಿಭಜಿಸುವುದು
asserts value is NonNullable<T>
ಸಿಗ್ನೇಚರ್ ಅನ್ನು ವಿಭಜಿಸೋಣ.
asserts
: ಇದು ವಿಶೇಷ ಟೈಪ್ಸ್ಕ್ರಿಪ್ಟ್ ಕೀವರ್ಡ್ ಆಗಿದ್ದು, ಈ ಫಂಕ್ಷನ್ ಅನ್ನು ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.value
: ಇದು ಫಂಕ್ಷನ್ನ ಮೊದಲ ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ (ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, `value` ಹೆಸರಿನ ವೇರಿಯೇಬಲ್). ಇದು ಯಾವ ವೇರಿಯೇಬಲ್ನ ಟೈಪ್ ಅನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಬೇಕು ಎಂದು ಟೈಪ್ಸ್ಕ್ರಿಪ್ಟ್ಗೆ ಹೇಳುತ್ತದೆ.is NonNullable<T>
: ಇದು ಒಂದು ಟೈಪ್ ಪ್ರೆಡಿಕೇಟ್. ಫಂಕ್ಷನ್ ದೋಷವನ್ನು ಎಸೆಯದಿದ್ದರೆ, `value` ನ ಟೈಪ್ ಈಗNonNullable<T>
ಆಗಿದೆ ಎಂದು ಕಂಪೈಲರ್ಗೆ ಹೇಳುತ್ತದೆ. ಟೈಪ್ಸ್ಕ್ರಿಪ್ಟ್ನಲ್ಲಿನNonNullable
ಯುಟಿಲಿಟಿ ಟೈಪ್, ಒಂದು ಟೈಪ್ನಿಂದnull
ಮತ್ತುundefined
ಅನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.
ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ಗಳಿಗಾಗಿ ಪ್ರಾಯೋಗಿಕ ಬಳಕೆಯ ಪ್ರಕರಣಗಳು
ಈಗ ನಾವು ಮೂಲಭೂತ ಅಂಶಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ, ಸಾಮಾನ್ಯ, ನೈಜ-ಪ್ರಪಂಚದ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ಗಳನ್ನು ಹೇಗೆ ಅನ್ವಯಿಸುವುದು ಎಂದು ಅನ್ವೇಷಿಸೋಣ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ನ ಗಡಿಗಳಲ್ಲಿ, ಅಂದರೆ ಬಾಹ್ಯ, ಟೈಪ್ ಮಾಡದ ಡೇಟಾ ನಿಮ್ಮ ಸಿಸ್ಟಮ್ಗೆ ಪ್ರವೇಶಿಸುವ ಸ್ಥಳಗಳಲ್ಲಿ ಅವು ಅತ್ಯಂತ ಶಕ್ತಿಯುತವಾಗಿರುತ್ತವೆ.
ಬಳಕೆಯ ಪ್ರಕರಣ 1: API ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಮೌಲ್ಯೀಕರಿಸುವುದು
ಇದು ಬಹುಶಃ ಅತ್ಯಂತ ಪ್ರಮುಖ ಬಳಕೆಯ ಪ್ರಕರಣವಾಗಿದೆ. fetch
ವಿನಂತಿಯಿಂದ ಬರುವ ಡೇಟಾವು ಅಂತರ್ಗತವಾಗಿ ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲ. ಟೈಪ್ಸ್ಕ್ರಿಪ್ಟ್ `response.json()` ನ ಫಲಿತಾಂಶವನ್ನು Promise
ಅಥವಾ Promise
ಎಂದು ಸರಿಯಾಗಿ ಟೈಪ್ ಮಾಡುತ್ತದೆ, ಅದನ್ನು ಮೌಲ್ಯೀಕರಿಸಲು ನಿಮ್ಮನ್ನು ಒತ್ತಾಯಿಸುತ್ತದೆ.
ಸನ್ನಿವೇಶ
ನಾವು API ನಿಂದ ಬಳಕೆದಾರರ ಡೇಟಾವನ್ನು ಪಡೆಯುತ್ತಿದ್ದೇವೆ. ಅದು ನಮ್ಮ User
ಇಂಟರ್ಫೇಸ್ಗೆ ಸರಿಹೊಂದುತ್ತದೆ ಎಂದು ನಾವು ನಿರೀಕ್ಷಿಸುತ್ತೇವೆ, ಆದರೆ ನಮಗೆ ಖಚಿತವಾಗಿ ಹೇಳಲು ಸಾಧ್ಯವಿಲ್ಲ.
interface User {
id: number;
name: string;
email: string;
}
// A regular type guard (returns a boolean)
function isUser(data: unknown): data is User {
return (
typeof data === 'object' &&
data !== null &&
'id' in data && typeof (data as any).id === 'number' &&
'name' in data && typeof (data as any).name === 'string' &&
'email' in data && typeof (data as any).email === 'string'
);
}
// Our new assertion function
function assertIsUser(data: unknown): asserts data is User {
if (!isUser(data)) {
throw new TypeError('Invalid User data received from API.');
}
}
async function fetchAndProcessUser(userId: number) {
const response = await fetch(`https://api.example.com/users/${userId}`);
const data: unknown = await response.json();
// Assert the data shape at the boundary
assertIsUser(data);
// From this point on, 'data' is safely typed as 'User'.
// No more 'if' checks or type casting needed!
console.log(`Processing user: ${data.name.toUpperCase()} (${data.email})`);
}
fetchAndProcessUser(1);
ಇದು ಏಕೆ ಶಕ್ತಿಯುತವಾಗಿದೆ: ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸಿದ ತಕ್ಷಣ `assertIsUser(data)` ಎಂದು ಕರೆಯುವ ಮೂಲಕ, ನಾವು ಒಂದು "ಸುರಕ್ಷತಾ ಗೇಟ್" ಅನ್ನು ರಚಿಸುತ್ತೇವೆ. ಇದರ ನಂತರ ಬರುವ ಯಾವುದೇ ಕೋಡ್ `data` ಅನ್ನು `User` ಎಂದು ವಿಶ್ವಾಸದಿಂದ ಪರಿಗಣಿಸಬಹುದು. ಇದು ಮೌಲ್ಯೀಕರಣ ತರ್ಕವನ್ನು ವ್ಯವಹಾರ ತರ್ಕದಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ, ಇದು ಹೆಚ್ಚು ಸ್ವಚ್ಛ ಮತ್ತು ಓದಬಲ್ಲ ಕೋಡ್ಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಬಳಕೆಯ ಪ್ರಕರಣ 2: ಪರಿಸರ ವೇರಿಯೇಬಲ್ಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು
ಸರ್ವರ್-ಸೈಡ್ ಅಪ್ಲಿಕೇಶನ್ಗಳು (ಉದಾ., Node.js ನಲ್ಲಿ) ಕಾನ್ಫಿಗರೇಶನ್ಗಾಗಿ ಪರಿಸರ ವೇರಿಯೇಬಲ್ಗಳ ಮೇಲೆ ಹೆಚ್ಚು ಅವಲಂಬಿತವಾಗಿವೆ. `process.env.MY_VAR` ಅನ್ನು ಪ್ರವೇಶಿಸುವುದು `string | undefined` ಎಂಬ ಟೈಪ್ ಅನ್ನು ನೀಡುತ್ತದೆ. ಇದು ನೀವು ಅದನ್ನು ಬಳಸುವ ಪ್ರತಿಯೊಂದು ಸ್ಥಳದಲ್ಲಿ ಅದರ ಅಸ್ತಿತ್ವವನ್ನು ಪರಿಶೀಲಿಸಲು ನಿಮ್ಮನ್ನು ಒತ್ತಾಯಿಸುತ್ತದೆ, ಇದು ಬೇಸರದ ಮತ್ತು ದೋಷ-ಪೀಡಿತ ಕೆಲಸವಾಗಿದೆ.
ಸನ್ನಿವೇಶ
ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಪ್ರಾರಂಭವಾಗಲು API ಕೀ ಮತ್ತು ಡೇಟಾಬೇಸ್ URL ಪರಿಸರ ವೇರಿಯೇಬಲ್ಗಳಿಂದ ಬೇಕು. ಅವು ಕಾಣೆಯಾಗಿದ್ದರೆ, ಅಪ್ಲಿಕೇಶನ್ ರನ್ ಆಗಲು ಸಾಧ್ಯವಿಲ್ಲ ಮತ್ತು ಸ್ಪಷ್ಟವಾದ ದೋಷ ಸಂದೇಶದೊಂದಿಗೆ ತಕ್ಷಣವೇ ಕ್ರ್ಯಾಶ್ ಆಗಬೇಕು.
// In a utility file, e.g., 'config.ts'
export function getEnvVar(key: string): string {
const value = process.env[key];
if (value === undefined) {
throw new Error(`FATAL: Environment variable ${key} is not set.`);
}
return value;
}
// A more powerful version using assertions
function assertEnvVar(key: string): asserts key is keyof NodeJS.ProcessEnv {
if (process.env[key] === undefined) {
throw new Error(`FATAL: Environment variable ${key} is not set.`);
}
}
// In your application's entry point, e.g., 'index.ts'
function startServer() {
// Perform all checks at startup
assertEnvVar('API_KEY');
assertEnvVar('DATABASE_URL');
const apiKey = process.env.API_KEY;
const dbUrl = process.env.DATABASE_URL;
// TypeScript now knows apiKey and dbUrl are strings, not 'string | undefined'.
// Your application is guaranteed to have the required config.
console.log('API Key length:', apiKey.length);
console.log('Connecting to DB:', dbUrl.toLowerCase());
// ... rest of the server startup logic
}
startServer();
ಇದು ಏಕೆ ಶಕ್ತಿಯುತವಾಗಿದೆ: ಈ ಮಾದರಿಯನ್ನು "ಫೇಲ್-ಫಾಸ್ಟ್" (fail-fast) ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ನ ಜೀವನಚಕ್ರದ ಪ್ರಾರಂಭದಲ್ಲಿಯೇ ನೀವು ಎಲ್ಲಾ ನಿರ್ಣಾಯಕ ಕಾನ್ಫಿಗರೇಶನ್ಗಳನ್ನು ಒಮ್ಮೆ ಮೌಲ್ಯೀಕರಿಸುತ್ತೀರಿ. ಸಮಸ್ಯೆಯಿದ್ದರೆ, ಅದು ವಿವರಣಾತ್ಮಕ ದೋಷದೊಂದಿಗೆ ತಕ್ಷಣವೇ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ, ಇದು ಕಾಣೆಯಾದ ವೇರಿಯೇಬಲ್ ಅನ್ನು ಅಂತಿಮವಾಗಿ ಬಳಸಿದಾಗ ನಂತರ ಸಂಭವಿಸುವ ನಿಗೂಢ ಕ್ರ್ಯಾಶ್ಗಿಂತ ಡೀಬಗ್ ಮಾಡಲು ತುಂಬಾ ಸುಲಭ.
ಬಳಕೆಯ ಪ್ರಕರಣ 3: DOM ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು
ನೀವು DOM ಅನ್ನು ಪ್ರಶ್ನಿಸಿದಾಗ, ಉದಾಹರಣೆಗೆ `document.querySelector` ನೊಂದಿಗೆ, ಫಲಿತಾಂಶವು `Element | null` ಆಗಿರುತ್ತದೆ. ಒಂದು ಎಲಿಮೆಂಟ್ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂದು ನಿಮಗೆ ಖಚಿತವಾಗಿದ್ದರೆ (ಉದಾ., ಮುಖ್ಯ ಅಪ್ಲಿಕೇಶನ್ ರೂಟ್ `div`), ನಿರಂತರವಾಗಿ `null` ಗಾಗಿ ಪರಿಶೀಲಿಸುವುದು ತೊಡಕಿನದ್ದಾಗಿರಬಹುದು.
ಸನ್ನಿವೇಶ
ನಮ್ಮ ಬಳಿ `
` ಇರುವ HTML ಫೈಲ್ ಇದೆ, ಮತ್ತು ನಮ್ಮ ಸ್ಕ್ರಿಪ್ಟ್ ಅದಕ್ಕೆ ವಿಷಯವನ್ನು ಸೇರಿಸಬೇಕಾಗಿದೆ. ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂದು ನಮಗೆ ತಿಳಿದಿದೆ.
// Reusing our generic assertion from earlier
function assertIsDefined<T>(value: T, message: string = "Value is not defined"): asserts value is NonNullable<T> {
if (value === undefined || value === null) {
throw new Error(message);
}
}
// A more specific assertion for DOM elements
function assertQuerySelector<T extends Element>(selector: string, constructor?: new () => T): T {
const element = document.querySelector(selector);
assertIsDefined(element, `FATAL: Element with selector '${selector}' not found in the DOM.`);
// Optional: check if it's the right kind of element
if (constructor && !(element instanceof constructor)) {
throw new TypeError(`Element '${selector}' is not an instance of ${constructor.name}`);
}
return element as T;
}
// Usage
const appRoot = document.querySelector('#app-root');
assertIsDefined(appRoot, 'Could not find the main application root element.');
// After the assertion, appRoot is of type 'Element', not 'Element | null'.
appRoot.innerHTML = 'Hello, World!
';
// Using the more specific helper
const submitButton = assertQuerySelector<HTMLButtonElement>('#submit-btn', HTMLButtonElement);
// 'submitButton' is now correctly typed as HTMLButtonElement
submitButton.disabled = true;
ಇದು ಏಕೆ ಶಕ್ತಿಯುತವಾಗಿದೆ: ಇದು ನಿಮ್ಮ ಪರಿಸರದ ಬಗ್ಗೆ ನಿಮಗೆ ತಿಳಿದಿರುವ ಒಂದು ಸ್ಥಿರ ಸ್ಥಿತಿಯನ್ನು (invariant) ವ್ಯಕ್ತಪಡಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಇದು ಗದ್ದಲದ ನಲ್-ಚೆಕ್ಕಿಂಗ್ ಕೋಡ್ ಅನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ ಮತ್ತು ಸ್ಕ್ರಿಪ್ಟ್ನ ನಿರ್ದಿಷ್ಟ DOM ರಚನೆಯ ಮೇಲಿನ ಅವಲಂಬನೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ದಾಖಲಿಸುತ್ತದೆ. ರಚನೆ ಬದಲಾದರೆ, ನಿಮಗೆ ತಕ್ಷಣದ, ಸ್ಪಷ್ಟವಾದ ದೋಷ ಸಿಗುತ್ತದೆ.
ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ಗಳು ಮತ್ತು ಪರ್ಯಾಯಗಳು
ಟೈಪ್ ಗಾರ್ಡ್ಗಳು ಅಥವಾ ಟೈಪ್ ಕಾಸ್ಟಿಂಗ್ನಂತಹ ಇತರ ಟೈಪ್-ಸಂಕುಚಿತಗೊಳಿಸುವ ತಂತ್ರಗಳ ವಿರುದ್ಧ ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ ಅನ್ನು ಯಾವಾಗ ಬಳಸಬೇಕೆಂದು ತಿಳಿಯುವುದು ನಿರ್ಣಾಯಕವಾಗಿದೆ.
ತಂತ್ರ | ಸಿಂಟ್ಯಾಕ್ಸ್ | ವಿಫಲವಾದಾಗ ವರ್ತನೆ | ಇದಕ್ಕೆ ಉತ್ತಮ |
---|---|---|---|
ಟೈಪ್ ಗಾರ್ಡ್ಸ್ | value is Type |
false ಹಿಂತಿರುಗಿಸುತ್ತದೆ |
ನಿಯಂತ್ರಣ ಹರಿವು (if/else ). "ಅಹಿತಕರ" ಪ್ರಕರಣಕ್ಕೆ ಮಾನ್ಯ, ಪರ್ಯಾಯ ಕೋಡ್ ಮಾರ್ಗವಿದ್ದಾಗ. ಉದಾ., "ಇದು ಸ್ಟ್ರಿಂಗ್ ಆಗಿದ್ದರೆ, ಅದನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿ; ಇಲ್ಲದಿದ್ದರೆ, ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯವನ್ನು ಬಳಸಿ." |
ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ಗಳು | asserts value is Type |
Error ಎಸೆಯುತ್ತದೆ |
ಸ್ಥಿರ ಸ್ಥಿತಿಗಳನ್ನು ಜಾರಿಗೊಳಿಸುವುದು. ಪ್ರೋಗ್ರಾಂ ಸರಿಯಾಗಿ ಮುಂದುವರೆಯಲು ಒಂದು ಸ್ಥಿತಿಯು ಸತ್ಯವಾಗಿರಲೇಬೇಕಾದಾಗ. "ಅಹಿತಕರ" ಮಾರ್ಗವು ಸರಿಪಡಿಸಲಾಗದ ದೋಷವಾಗಿದೆ. ಉದಾ., "API ಪ್ರತಿಕ್ರಿಯೆಯು ಖಂಡಿತವಾಗಿಯೂ ಬಳಕೆದಾರ ಆಬ್ಜೆಕ್ಟ್ ಆಗಿರಬೇಕು." |
ಟೈಪ್ ಕಾಸ್ಟಿಂಗ್ | value as Type |
ರನ್ಟೈಮ್ ಪರಿಣಾಮವಿಲ್ಲ | ಡೆವಲಪರ್ ಆಗಿ ನಿಮಗೆ ಕಂಪೈಲರ್ಗಿಂತ ಹೆಚ್ಚು ತಿಳಿದಿರುವ ಮತ್ತು ಈಗಾಗಲೇ ಅಗತ್ಯ ಪರಿಶೀಲನೆಗಳನ್ನು ನಿರ್ವಹಿಸಿರುವ ಅಪರೂಪದ ಪ್ರಕರಣಗಳು. ಇದು ಶೂನ್ಯ ರನ್ಟೈಮ್ ಸುರಕ್ಷತೆಯನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಮಿತವಾಗಿ ಬಳಸಬೇಕು. ಅತಿಯಾದ ಬಳಕೆಯು ಒಂದು "ಕೋಡ್ ಸ್ಮೆಲ್". |
ಪ್ರಮುಖ ಮಾರ್ಗಸೂಚಿ
ನಿಮ್ಮನ್ನು ಕೇಳಿಕೊಳ್ಳಿ: "ಈ ಪರಿಶೀಲನೆ ವಿಫಲವಾದರೆ ಏನಾಗಬೇಕು?"
- ಒಂದು ನ್ಯಾಯಸಮ್ಮತ ಪರ್ಯಾಯ ಮಾರ್ಗವಿದ್ದರೆ (ಉದಾ., ಬಳಕೆದಾರರು ದೃಢೀಕರಿಸದಿದ್ದರೆ ಲಾಗಿನ್ ಬಟನ್ ತೋರಿಸಿ),
if/else
ಬ್ಲಾಕ್ನೊಂದಿಗೆ ಟೈಪ್ ಗಾರ್ಡ್ ಬಳಸಿ. - ವಿಫಲವಾದ ಪರಿಶೀಲನೆಯು ನಿಮ್ಮ ಪ್ರೋಗ್ರಾಂ ಅಮಾನ್ಯ ಸ್ಥಿತಿಯಲ್ಲಿದೆ ಮತ್ತು ಸುರಕ್ಷಿತವಾಗಿ ಮುಂದುವರೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದಾದರೆ, ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ ಬಳಸಿ.
- ನೀವು ರನ್ಟೈಮ್ ಪರಿಶೀಲನೆಯಿಲ್ಲದೆ ಕಂಪೈಲರ್ ಅನ್ನು ಅತಿಕ್ರಮಿಸುತ್ತಿದ್ದರೆ, ನೀವು ಟೈಪ್ ಕಾಸ್ಟ್ ಬಳಸುತ್ತಿದ್ದೀರಿ. ಬಹಳ ಜಾಗರೂಕರಾಗಿರಿ.
ಸುಧಾರಿತ ಮಾದರಿಗಳು ಮತ್ತು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು
1. ಕೇಂದ್ರೀಯ ಅಸರ್ಶನ್ ಲೈಬ್ರರಿಯನ್ನು ರಚಿಸಿ
ನಿಮ್ಮ ಕೋಡ್ಬೇಸ್ನಾದ್ಯಂತ ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ಗಳನ್ನು ಹರಡಬೇಡಿ. ಅವುಗಳನ್ನು src/utils/assertions.ts
ನಂತಹ ಮೀಸಲಾದ ಯುಟಿಲಿಟಿ ಫೈಲ್ನಲ್ಲಿ ಕೇಂದ್ರೀಕರಿಸಿ. ಇದು ಮರುಬಳಕೆ, ಸ್ಥಿರತೆಯನ್ನು ಉತ್ತೇಜಿಸುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಮೌಲ್ಯೀಕರಣ ತರ್ಕವನ್ನು ಹುಡುಕಲು ಮತ್ತು ಪರೀಕ್ಷಿಸಲು ಸುಲಭಗೊಳಿಸುತ್ತದೆ.
// src/utils/assertions.ts
export function assert(condition: unknown, message: string): asserts condition {
if (!condition) {
throw new Error(message);
}
}
export function assertIsDefined<T>(value: T): asserts value is NonNullable<T> {
assert(value !== null && value !== undefined, 'This value must be defined.');
}
export function assertIsString(value: unknown): asserts value is string {
assert(typeof value === 'string', 'This value must be a string.');
}
// ... and so on.
2. ಅರ್ಥಪೂರ್ಣ ದೋಷಗಳನ್ನು ಎಸೆಯಿರಿ
ವಿಫಲವಾದ ಅಸರ್ಶನ್ನಿಂದ ಬರುವ ದೋಷ ಸಂದೇಶವು ಡೀಬಗ್ ಮಾಡುವಾಗ ನಿಮ್ಮ ಮೊದಲ ಸುಳಿವು. ಅದನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಮಾಡಿ! "ಅಸರ್ಶನ್ ವಿಫಲವಾಗಿದೆ" ಎಂಬಂತಹ ಸಾಮಾನ್ಯ ಸಂದೇಶವು ಸಹಾಯಕವಲ್ಲ. ಬದಲಾಗಿ, ಸಂದರ್ಭವನ್ನು ಒದಗಿಸಿ:
- ಏನನ್ನು ಪರಿಶೀಲಿಸಲಾಗುತ್ತಿತ್ತು?
- ನಿರೀಕ್ಷಿತ ಮೌಲ್ಯ/ಟೈಪ್ ಏನಿತ್ತು?
- ಸ್ವೀಕರಿಸಿದ ನಿಜವಾದ ಮೌಲ್ಯ/ಟೈಪ್ ಏನಿತ್ತು? (ಸೂಕ್ಷ್ಮ ಡೇಟಾವನ್ನು ಲಾಗ್ ಮಾಡದಂತೆ ಜಾಗರೂಕರಾಗಿರಿ).
function assertIsUser(data: unknown): asserts data is User {
if (!isUser(data)) {
// Bad: throw new Error('Invalid data');
// Good:
throw new TypeError(`Expected data to be a User object, but received ${JSON.stringify(data)}`);
}
}
3. ಕಾರ್ಯಕ್ಷಮತೆಯ ಬಗ್ಗೆ ಗಮನವಿರಲಿ
ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ಗಳು ರನ್ಟೈಮ್ ಪರಿಶೀಲನೆಗಳಾಗಿವೆ, ಅಂದರೆ ಅವು ಸಿಪಿಯು ಸೈಕಲ್ಗಳನ್ನು ಬಳಸಿಕೊಳ್ಳುತ್ತವೆ. ಇದು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ನ ಗಡಿಗಳಲ್ಲಿ (API ಇಂಗ್ರೆಸ್, ಕಾನ್ಫಿಗರೇಶನ್ ಲೋಡಿಂಗ್) ಸಂಪೂರ್ಣವಾಗಿ ಸ್ವೀಕಾರಾರ್ಹ ಮತ್ತು ಅಪೇಕ್ಷಣೀಯವಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸಾವಿರಾರು ಬಾರಿ ರನ್ ಆಗುವ ಬಿಗಿಯಾದ ಲೂಪ್ನಂತಹ ಕಾರ್ಯಕ್ಷಮತೆ-ನಿರ್ಣಾಯಕ ಕೋಡ್ ಪಥಗಳಲ್ಲಿ ಸಂಕೀರ್ಣ ಅಸರ್ಶನ್ಗಳನ್ನು ಇಡುವುದನ್ನು ತಪ್ಪಿಸಿ. ಪರಿಶೀಲನೆಯ ವೆಚ್ಚವು ನಿರ್ವಹಿಸುತ್ತಿರುವ ಕಾರ್ಯಾಚರಣೆಗೆ (ನೆಟ್ವರ್ಕ್ ವಿನಂತಿಯಂತೆ) ಹೋಲಿಸಿದರೆ ನಗಣ್ಯವಾಗಿರುವಲ್ಲಿ ಅವುಗಳನ್ನು ಬಳಸಿ.
ತೀರ್ಮಾನ: ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಕೋಡ್ ಬರೆಯುವುದು
ಟೈಪ್ಸ್ಕ್ರಿಪ್ಟ್ ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ಗಳು ಕೇವಲ ಒಂದು ಸಣ್ಣ ವೈಶಿಷ್ಟ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿವೆ; ಅವು ದೃಢವಾದ, ಉತ್ಪಾದನಾ-ದರ್ಜೆಯ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಬರೆಯಲು ಒಂದು ಮೂಲಭೂತ ಸಾಧನವಾಗಿದೆ. ಕಂಪೈಲ್-ಟೈಮ್ ಸಿದ್ಧಾಂತ ಮತ್ತು ರನ್ಟೈಮ್ ವಾಸ್ತವತೆಯ ನಡುವಿನ ನಿರ್ಣಾಯಕ ಅಂತರವನ್ನು ನಿವಾರಿಸಲು ಅವು ನಿಮಗೆ ಅಧಿಕಾರ ನೀಡುತ್ತವೆ.
ಅಸರ್ಶನ್ ಫಂಕ್ಷನ್ಗಳನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವ ಮೂಲಕ, ನೀವು:
- ಸ್ಥಿರ ಸ್ಥಿತಿಗಳನ್ನು ಜಾರಿಗೊಳಿಸಬಹುದು: ಸತ್ಯವಾಗಿರಬೇಕಾದ ಸ್ಥಿತಿಗಳನ್ನು ಔಪಚಾರಿಕವಾಗಿ ಘೋಷಿಸಿ, ನಿಮ್ಮ ಕೋಡ್ನ ಊಹೆಗಳನ್ನು ಸ್ಪಷ್ಟಪಡಿಸಬಹುದು.
- ವೇಗವಾಗಿ ಮತ್ತು ಗಟ್ಟಿಯಾಗಿ ವಿಫಲಗೊಳ್ಳಬಹುದು: ಡೇಟಾ ಸಮಗ್ರತೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಮೂಲದಲ್ಲಿಯೇ ಹಿಡಿಯಬಹುದು, ಅವುಗಳು ನಂತರ ಸೂಕ್ಷ್ಮ ಮತ್ತು ಡೀಬಗ್ ಮಾಡಲು ಕಷ್ಟಕರವಾದ ಬಗ್ಗಳನ್ನು ಉಂಟುಮಾಡುವುದನ್ನು ತಡೆಯಬಹುದು.
- ಕೋಡ್ ಸ್ಪಷ್ಟತೆಯನ್ನು ಸುಧಾರಿಸಬಹುದು: ನೆಸ್ಟೆಡ್
if
ಪರಿಶೀಲನೆಗಳು ಮತ್ತು ಟೈಪ್ ಕಾಸ್ಟ್ಗಳನ್ನು ತೆಗೆದುಹಾಕಿ, ಇದರಿಂದಾಗಿ ಸ್ವಚ್ಛ, ಹೆಚ್ಚು ರೇಖೀಯ, ಮತ್ತು ಸ್ವಯಂ-ದಾಖಲಿಸುವ ವ್ಯವಹಾರ ತರ್ಕ ಉಂಟಾಗುತ್ತದೆ. - ಆತ್ಮವಿಶ್ವಾಸವನ್ನು ಹೆಚ್ಚಿಸಬಹುದು: ನಿಮ್ಮ ಟೈಪ್ಗಳು ಕೇವಲ ಕಂಪೈಲರ್ಗೆ ಸಲಹೆಗಳಲ್ಲ, ಆದರೆ ಕೋಡ್ ಕಾರ್ಯಗತಗೊಂಡಾಗ ಸಕ್ರಿಯವಾಗಿ ಜಾರಿಗೊಳ್ಳುತ್ತವೆ ಎಂಬ ಭರವಸೆಯೊಂದಿಗೆ ಕೋಡ್ ಬರೆಯಬಹುದು.
ಮುಂದಿನ ಬಾರಿ ನೀವು API ನಿಂದ ಡೇಟಾವನ್ನು ಪಡೆದಾಗ, ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು ಓದಿದಾಗ, ಅಥವಾ ಬಳಕೆದಾರರ ಇನ್ಪುಟ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದಾಗ, ಕೇವಲ ಟೈಪ್ ಅನ್ನು ಕಾಸ್ಟ್ ಮಾಡಿ ಮತ್ತು ಉತ್ತಮದ್ದಕ್ಕಾಗಿ ಆಶಿಸಬೇಡಿ. ಅದನ್ನು ಅಸರ್ಟ್ ಮಾಡಿ. ನಿಮ್ಮ ಸಿಸ್ಟಮ್ನ ಅಂಚಿನಲ್ಲಿ ಒಂದು ಸುರಕ್ಷತಾ ಗೇಟ್ ಅನ್ನು ನಿರ್ಮಿಸಿ. ನಿಮ್ಮ ಭವಿಷ್ಯದ ನೀವು—ಮತ್ತು ನಿಮ್ಮ ತಂಡ—ನೀವು ಬರೆದ ದೃಢವಾದ, ಊಹಿಸಬಹುದಾದ, ಮತ್ತು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಕೋಡ್ಗಾಗಿ ನಿಮಗೆ ಧನ್ಯವಾದ ಹೇಳುತ್ತಾರೆ.