13 ਮਈ 2025·8 ਮਿੰਟ
TypeScript ਨੇ ਵੱਡੇ JavaScript ਫਰੰਟਐਂਡਸ ਨੂੰ ਰੱਖ-ਰਖਾਵਯੋਗ ਕਿਵੇਂ ਬਣਾਇਆ
TypeScript ਨੇ ਟਾਈਪਸ, ਵਧੀਆ ਟੂਲਿੰਗ ਅਤੇ ਸੁਰੱਖਿਅਤ ਰੀਫੈਕਟਰ ਜੋੜੇ—ਜਿਸ ਨਾਲ ਟੀਮਾਂ ਘੱਟ ਬੱਗਾਂ ਅਤੇ ਵੱਧ ਸਪష్టం ਵਾਲੇ ਕੋਡ ਨਾਲ JavaScript ਫਰੰਟਐਂਡਸ ਨੂੰ ਸਕੇਲ ਕਰ ਸਕਦੀਆਂ ਹਨ।
TypeScript ਨੇ ਟਾਈਪਸ, ਵਧੀਆ ਟੂਲਿੰਗ ਅਤੇ ਸੁਰੱਖਿਅਤ ਰੀਫੈਕਟਰ ਜੋੜੇ—ਜਿਸ ਨਾਲ ਟੀਮਾਂ ਘੱਟ ਬੱਗਾਂ ਅਤੇ ਵੱਧ ਸਪష్టం ਵਾਲੇ ਕੋਡ ਨਾਲ JavaScript ਫਰੰਟਐਂਡਸ ਨੂੰ ਸਕੇਲ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਇੱਕ ਫਰੰਟਐਂਡ ਜੋ "ਸਿਰਫ਼ ਕੁਝ ਪੰਨੇ" ਵਜੋਂ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀ, ਚੁੱਪਚਾਪ ਹਜ਼ਾਰਾਂ ਫਾਇਲਾਂ, ਦਰਜਨਾਂ ਫੀਚਰ ਖੇਤਰ, ਅਤੇ ਰੋਜ਼ਾਨਾ ਬਦਲਾਅ ਕਰਨ ਵਾਲੀਆਂ ਕਈ ਟੀਮਾਂ ਵੱਲ ਵਧ ਸਕਦਾ ਹੈ। ਇਸ ਪੱਧਰ ਤੇ, JavaScript ਦੀ ਲਚੀਲਤਾ ਆਜ਼ਾਦੀ ਲੱਗਣ ਦੀ ਥਾਂ ਅਣਿਸ਼ਚਿਤਤਾ ਬਣ ਜਾਂਦੀ ਹੈ।
ਵੱਡੇ JavaScript ਐਪ ਵਿੱਚ, ਬਹੁਤ ਸਾਰੀਆਂ ਬੱਗਜ਼ ਉਸ جگہ ਪ੍ਰਗਟ ਨਹੀਂ ਹੁੰਦੀਆਂ ਜਿਥੇ ਉਹ ਦਰਜ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ। ਇੱਕ ਛੋਟੀ ਬਦਲਾਅ ਕਿਸੇ ਦੂਜੇ ਸਕਰੀਨ ਨੂੰ ਟੁੱਟਾ ਸਕਦੀ ਹੈ ਕਿਉਂਕਿ ਉਹਨਾਂ ਦੇ ਵਿਚਕਾਰ ਰਿਸ਼ਤਾ ਅਣੌਪਚਾਰਿਕ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਫੰਕਸ਼ਨ ਕਿਸੇ ਡੇਟਾ ਆਕਾਰ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਇੱਕ ਕੰਪੋਨੇਟ ਇਹ ਮੰਨ ਲੈਂਦਾ ਹੈ ਕਿ ਇੱਕ prop ਹਮੇਸ਼ਾ ਮੌਜੂਦ ਹੈ, ਜਾਂ ਇੱਕ ਹੈਲਪਰਾਨੂੰ ਵੱਖ-ਵੱਖ ਇਨਪੁੱਟ ਦੇ ਆਧਾਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਟਾਈਪ ਵਾਪਸ ਕਰ ਦਿੰਦਾ ਹੈ।
ਸਾਂਝੇ ਦਰਦ-ਬਿੰਦੂਆਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਰੱਖ-ਰਖਾਵਯੋਗਤਾ ਇਕ ਢੁੱਬੀ "ਕੋਡ ਕੁਆਲਟੀ" ਸਕੋਰ ਨਹੀਂ ਹੈ। ਟੀਮਾਂ ਲਈ, ਇਹ ਆਮ ਤੌਰ ਤੇ ਮਤਲਬ ਹੈ:
TypeScript JavaScript + ਟਾਈਪਸ ਹੈ। ਇਹ ਵੈੱਬ ਪਲੈਟਫਾਰਮ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ ਅਤੇ ਨਵੀਂ ਰਨਟਾਈਮ ਦੀ ਲੋੜ ਨਹੀਂ ਦਿੰਦੈ; ਇਹ ਇੱਕ ਕੰਪਾਇਲ-ਟਾਈਮ ਪਰਤ ਜੋੜਦਾ ਹੈ ਜੋ ਡੇਟਾ ਆਕਾਰ ਅਤੇ API ਕੰਟ੍ਰੈਕਟ ਨੂੰ ਵਰਣਨ ਕਰਦੀ ਹੈ।
ਫਿਰ ਵੀ, TypeScript ਜਾਦੂ ਨਹੀਂ ਹੈ। ਇਸ ਵਿੱਚ ਕੁਝ ਪਹਿਲਾਂ ਦੀ ਕੋਸ਼ਿਸ਼ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (ਟਾਈਪਸ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨੇ, ਦਿਨਾਮਿਕ ਪੈਟਰਨਾਂ ਨਾਲ ਕਈ ਵਾਰੀ friction)। ਪਰ ਇਹ ਜ਼ਿਆਦਾਤਰ ਥਾਵਾਂ 'ਤੇ ਮਦਦ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਵੱਡੇ ਫਰੰਟਐਂਡ ਦੁੱਖੀ ਹੁੰਦੇ ਹਨ: ਮੋਡੀਊਲ ਬਾਊਂਡਰੀਆਂ ਤੇ, ਸ਼ੇਅਰਡ ਯੂਟਿਲਿਟੀਜ਼ ਵਿੱਚ, ਡੇਟਾ-ਹੈਵੀ UI ਵਿੱਚ ਅਤੇ ਰੀਫੈਕਟਰਸ ਦੌਰਾਨ ਜਦੋਂ "ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਇਹ ਸੇਫ਼ ਹੈ" ਤੋਂ "ਮੈਂ ਜਾਣਦਾ ਹਾਂ ਇਹ ਸੇਫ਼ ਹੈ" ਬਣਾਉਣਾ ਲਾਜ਼ਮੀ ਹੁੰਦਾ ਹੈ।
TypeScript ਨੇ JavaScript ਦੀ ਥਾਂ ਨਹੀਂ ਲੀ, ਬਲਕਿ ਇਸ ਨੂੰ ਉਸ ਚੀਜ਼ ਨਾਲ ਵਧਾਇਆ ਜੋ ਟੀਮਾਂ ਕਾਫੀ ਸਮੇਂ ਤੋਂ ਚਾਹੁੰਦੀਆਂ ਸਨ: ਇਹ ਦਰਸਾਉਣ ਦਾ ਤਰੀਕਾ ਕਿ ਕੋਡ ਨੂੰ ਕੀ ਸਵੀਕਾਰ/ਵਾਪਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਬਿਨਾਂ ਭਾਸ਼ਾ ਅਤੇ ਪਾਰਸਪਰਿਕ ਪਰਿਵਾਰ ਤੋਂ ਵੱਛੜੇ।
ਜਿਵੇਂ ਜਿਆਦਾ ਫਰੰਟਐਂਡ ਪੂਰੇ ਐਪ ਬਣ ਗਏ, ਉਹਨਾਂ ਨੇ ਹੋਰ ਹਿਲਣ-ਡੁਲਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਜੋੜ ਲੀਆਂ: ਵੱਡੇ single-page apps, ਸ਼ੇਅਰਡ ਕੰਪੋਨੈਂਟ ਲਾਇਬਰੇਰੀਆਂ, ਕਈ API ਇੰਟੇਗ੍ਰੇਸ਼ਨ, ਕੁਠੇ ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ, ਅਤੇ ਬਿਲਡ ਪਾਈਪਲਾਈਨ। ਇੱਕ ਛੋਟੇ ਕੋਡਬੇਸ ਵਿੱਚ ਤੁਸੀਂ ਸਭ ਕੁਝ ਆਪਣੇ ਦਿਮਾਗ ਵਿੱਚ ਰੱਖ ਸਕਦੇ ਹੋ। ਇਕ ਵੱਡੇ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਤੇਜ਼ ਤਰੀਕੇ ਚਾਹੀਦੇ ਹਨ ਇਹ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਲਈ: ਇਹ ਡੇਟਾ ਕਿਹੜੇ ਆਕਾਰ ਦਾ ਹੈ? ਇਹ ਫੰਕਸ਼ਨ ਕਿੰਨੇ ਵਾਰ ਕਿੱਥੇ ਕਾਲ ਹੁੰਦਾ ਹੈ? ਜੇ ਮੈਂ ਇਹ prop ਬਦਲਾਂ ਤਾਂ ਕੀ ਟੁੱਟੇਗਾ?
ਟੀਮਾਂ ਨੇ TypeScript ਨੂੰ ਇਸਲਈ ਅਪਣਾਇਆ ਕਿਉਂਕਿ ਇਹ ਨਵੀਂ ਸ਼ੁਰੂਆਤ ਵਾਲਾ ਰੀ-ਰਾਈਟ ਨਹੀਂ ਮੰਗਦਾ। ਇਹ npm ਪੈਕੇਜਾਂ, ਜਾਣੇ-ਪਹਚਾਣੇ ਬੰਡਲਰਾਂ ਅਤੇ ਆਮ ਟੈਸਟ ਸੈਟਅਪਸ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਸਿੱਧਾ JavaScript ਵਿੱਚ ਕੰਪਾਇਲ ਹੁੰਦਾ ਹੈ। ਇਸ ਨਾਲ ਇਹ ਹੌਲੀ-ਹੌਲੀ ਰੀਪੋ ਜਾਂ ਫੋਲਡਰ ਅਨੁਸਾਰ ਲਿਆਂਦਾ ਜਾ ਸਕਦਾ ਹੈ।
"Gradual typing" ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਓਹੀ ਥਾਵਾਂ 'ਤੇ ਟਾਈਪਸ ਜੋੜ ਸਕਦੇ ਹੋ ਜਿੱਥੇ ਉਹ ਸਭ ਤੋਂ ਵੱਧ ਮੱਲ ਦਿੰਦੇ ਹਨ ਅਤੇ ਹੋਰ ਹਿੱਸਿਆਂ ਨੂੰ ਅਜੇ ਢੀਲਾ ਛੱਡ ਸਕਦੇ ਹੋ। ਤੁਸੀਂ ਘੱਟੋ-ਘੱਟ ਐਨੋਟੇਸ਼ਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ, JavaScript ਫਾਇਲਾਂ ਦੀ ਆਗਿਆ ਦੇ ਸਕਦੇ ਹੋ, ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਕਵਰੇਜ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦੇ ਹੋ—ਇਸ ਤਰ੍ਹਾਂ ਇڈیਟਰ ਆਟੋ-ਕੰਪਲੀਟ ਅਤੇ ਸੇਫ਼ ਰੀਫੈਕਟਰ ਮਿਲਦੇ ਹਨ ਬਿਨਾਂ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਪੂਰਨਤਾ ਦੀ ਲੋੜ ਦੇ।
ਵੱਡੇ ਫਰੰਟਐਂਡ ਅਸਲ ਵਿੱਚ ਛੋਟੀਆਂ ਸਹਿਮਤੀਆਂ ਦਾ ਸਮਹੂ ਹੈ: ਇੱਕ ਕੰਪੋਨੇਟ ਨੂੰ ਕਿਸੇ prop ਦੀ ਉਮੀਦ ਹੈ, ਇੱਕ ਫੰਕਸ਼ਨ ਨੂੰ ਕੁਝ ਆਰਗੁਮੈਂਟ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ API ਡੇਟਾ ਨੂੰ ਇਕ ਨਿਰਧਾਰਤ ਆਕਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। TypeScript ਉਹਨਾਂ ਸਹਿਮਤੀਆਂ ਨੂੰ ਟਾਈਪਸ ਵਿੱਚ ਬਦਲ ਕੇ ਸਪੱਸ਼ਟ ਕਰਦਾ ਹੈ—ਇਕ ਤਰ੍ਹਾਂ ਦਾ ਜੀਵੰਤ ਕੰਟ੍ਰੈਕਟ ਜੋ ਕੋਡ ਦੇ ਨੇੜੇ ਰਹਿੰਦਾ ਅਤੇ ਇਸਦੇ ਨਾਲ ਤਰੱਕੀ ਕਰਦਾ ਹੈ।
ਇੱਕ ਟਾਈਪ ਕਹਿੰਦਾ ਹੈ, “ਤੁਸੀਂ ਇਹ ਦੇਓ, ਅਤੇ ਤੁਸੀਂ ਇਹ ਪ੍ਰਾਪਤ ਕਰੋਗੇ।” ਇਹ ਛੋਟੇ ਹੈਲਪਰ ਤੋਂ ਲੈ ਕੇ ਵੱਡੇ UI ਕੰਪੋਨੈਂਟ ਤੱਕ ਸਭ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ。
type User = { id: string; name: string };
function formatUser(user: User): string {
return `${user.name} (#${user.id})`;
}
type UserCardProps = { user: User; onSelect: (id: string) => void };
ਇਹ ਪਰਿਭਾਸ਼ਾਵਾਂ ਨਾਲ, ਜੋ ਕੋਈ ਵੀ formatUser ਨੂੰ ਕਾਲ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ UserCard ਨੂੰ ਰੈਂਡਰ ਕਰ ਰਿਹਾ ਹੈ, ਤੁਰੰਤ ਉਮੀਦ ਕੀਤੀ ਸ਼ਕਲ ਵੇਖ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਪੜ੍ਹੇ। ਇਹ readability ਸੁਧਾਰਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਨਵੇਂ ਟੀਮ ਮੈਂਬਰਾਂ ਲਈ ਜੋ ਅਜੇ ਨਹੀਂ ਜਾਣਦੇ ਕਿ "ਅਸਲ ਨਿਯਮ" ਕਿੱਥੇ ਹਨ।
ਸਾਫ JavaScript ਵਿੱਚ, user.nmae ਵਰਗਾ ਟਾਈਪੋ ਜਾਂ ਗਲਤ ਆਰਗੁਮੈਂਟ ਟਾਈਪ ਅਕਸਰ ਰਨਟਾਈਮ ਤੱਕ ਪੁੱਜ ਜਾਂਦੇ ਹਨ ਅਤੇ ਤਦ ਹੀ ਫੇਲ ਹੁੰਦੇ ਹਨ। TypeScript ਨਾਲ, ਇਡੀਟਰ ਅਤੇ ਕੰਪਾਇਲਰ ਮੁਕਾਬਲੇ 'ਚ ਚੀਜ਼ਾਂ ਦਰਸਾਉਂਦੇ ਹਨ:
user.fullName ਤੇ ਐਕਸੈਸ ਕਰਨਾ ਜਦੋਂ ਸਿਰਫ name ਮੌਜੂਦ ਹੋonSelect(user) ਕਾਲ ਕਰਨਾ ਬਦਲੇ onSelect(user.id) ਕਰਨ ਦੀ ਜ਼ਰੂਰਤਇਹ ਛੋਟੀਆਂ ਗਲਤੀਆਂ ਹਨ, ਪਰ ਵੱਡੇ ਕੋਡਬੇਸ ਵਿੱਚ ਇਹ ਘੰਟਿਆਂ ਦੀ ਡੀਬੱਗਿੰਗ ਅਤੇ ਟੈਸਟਿੰਗ ਚਕਰ ਖੜੇ ਕਰ ਸਕਦੀਆਂ ਹਨ।
TypeScript ਦੀਆਂ ਚੈਕਸ ਕਰਨ ਦੀਆਂ ਗਤੀਵਿਧੀਆਂ ਤਾਂ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਬਿਲਡ ਅਤੇ ਐਡੀਟ ਕਰਨ ਸਮੇਂ ਹੀ ਹੁੰਦੀਆਂ ਹਨ। ਇਹ ਤੁਹਾਨੂੰ ਬਤਾਂਦਾ ਹੈ "ਇਹ ਕਾਲ ਕੰਟ੍ਰੈਕਟ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ" ਬਿਨਾਂ ਕੁਝ ਚਲਾਏ।
ਇਹ ਉਹ ਨਹੀਂ ਕਰਦਾ ਕਿ API ਜੇ ਅਣਖ਼ਸ ਅਣੁਮਿਤ ਡੇਟਾ ਵਾਪਸ ਕਰੇ ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਰੋਕੇ। ਇਸਦੀ ਥਾਂ, ਇਹ ਤੁਹਾਨੂੰ ਉਹ ਕੋਡ ਲਿਖਣ ਵਿਚ ਮਦਦ ਕਰਦਾ ਹੈ ਜੋ ਇੱਕ ਸਪਸ਼ਟ ਆਕਾਰ ਮੰਨਦਾ ਹੈ—ਅਤੇ ਜਿੱਥੇ ਲੋੜ ਹੋਵੇ, ਉਹ ਰਨਟਾਈਮ ਵੈਧਤਾ ਵੱਲ ਧਿਆਨ ਖਿੱਚਦਾ ਹੈ।
ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਇੱਕ ਐਸਾ ਕੋਡਬੇਸ ਬਣਦਾ ਹੈ ਜਿੱਥੇ ਬਾਊਂਡਰੀਆਂ ਵੱਧ ਸਪੱਸ਼ਟ ਹੁੰਦੀਆਂ ਹਨ: ਟਾਈਪਸ ਵਿਚ ਕੰਟ੍ਰੈਕਟ ਦਸਤਾਵੇਜ਼ ਹੁੰਦੇ ਹਨ, ਵਿਵਾਦਾਂ ਨੂੰ ਪਹਿਲਾਂ ਪਤਾ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਨਵੇਂ ਯੋਗਦਾਨਕ ਕਰਨ ਵਾਲੇ ਬਿਨਾਂ ਅਨੁਮਾਨਾਂ ਦੇ ਬਦਲਾਂ ਕਰ ਸਕਦੇ ਹਨ।
TypeScript ਸਿਰਫ਼ ਬਿਲਡ-ਟਾਈਮ 'ਤੇ ਗਲਤੀਆਂ ਫੜਦਾ ਨਹੀਂ—ਇਹ ਤੁਹਾਡੇ ਏਡੀਟਰ ਨੂੰ ਕੋਡਬੇਸ ਦਾ ਨਕਸ਼ਾ ਬਣਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ ਰਿਪੋ ਸੈਂਕੜੇ ਕੰਪੋਨੇਟ ਅਤੇ ਯੂਟਿਲਿਟੀਜ਼ ਤੱਕ ਵਧ ਜਾਂਦੀ ਹੈ, ਰੱਖ-ਰਖਾਵਯੋਗਤਾ ਆਮ ਤੌਰ 'ਤੇ ਫੇਲ ਹੁੰਦੀ ਹੈ ਨਾ ਕਿ ਕੋਡ "ਗਲਤ" ਹੋਣ ਕਾਰਨ, ਪਰ ਇਸ ਲਈ ਕਿ ਲੋਕ ਛੋਟੀ-ਛੋਟੀ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਤੇਜ਼ੀ ਨਾਲ ਨਹੀਂ ਲੱਭ ਸਕਦੇ: ਇਹ ਫੰਕਸ਼ਨ ਕੀ ਉਮੀਦ ਕਰਦਾ ਹੈ? ਇਸ ਨੂੰ ਕਿੱਥੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ? ਕੀ ਬਦਲਣ ਤੇ ਕੀ ਤੋੜੇਗਾ?
TypeScript ਨਾਲ, ਆਟੋ-ਕੰਪਲੀਟ ਸਿਰਫ਼ ਸੁਵਿਧਾ ਨਹੀਂ ਰਹਿੰਦੀ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਫੰਕਸ਼ਨ ਕਾਲ ਕਰਦੇ ਹੋ ਜਾਂ ਇੱਕ ਕੰਪੋਨੇਟ prop ਟਾਈਪ ਕਰਦੇ ਹੋ, ਏਡੀਟਰ ਅਸਲ ਟਾਈਪਸ ਦੇ ਆਧਾਰ 'ਤੇ ਵੈਧ ਵਿਕਲਪ ਸੁਝਾਉਂਦਾ ਹੈ। ਇਸ ਦਾ ਮਤਲਬ ਘੱਟ ਖੋਜ-ਟ੍ਰਿਪਸ ਅਤੇ ਘੱਟ "ਇਹ ਫਿਰ ਕਿਵੇਂ ਕਹਿੰਦੇ ਸਨ?" ਦੇ ਪਲ।
ਤੁਹਾਨੂੰ ਇਨਲਾਈਨ ਡਾਕਯੂਮੈਂਟੇਸ਼ਨ ਵੀ ਮਿਲਦੀ ਹੈ: ਪੈਰਾਮੀਟਰ ਨਾਮ, ਰਾਖਣਯੋਗ ਬਨਾਮ ਲਾਜ਼ਮੀ ਫੀਲਡ, ਅਤੇ JSDoc ਟਿੱਪਣੀਆਂ ਸਿੱਧਾ ਤੁਹਾਡੇ ਕੰਮ ਵਾਲੇ ਸਥਾਨ 'ਤੇ ਦਿੱਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਅਮਲ ਵਿੱਚ, ਇਹ ਵਾਧੂ ਫਾਇਲਾਂ ਖੋਲ੍ਹਣ ਦੀ ਲੋੜ ਘਟਾਉਂਦਾ ਹੈ ਸਿਰਫ਼ ਸਮਝਣ ਲਈ ਕਿ ਕਿਸੇ ਟੁਕੜੇ ਕੋਡ ਨੂੰ ਕਿਵੇਂ ਵਰਤਣਾ ਹੈ।
ਵੱਡੇ ਰਿਪੋ ਵਿੱਚ, ਬਹੁਤ ਵਾਰ ਸਮਾਂ grep, ਸਕਰੋਲਿੰਗ, ਅਤੇ ਕਈ ਟੈਬ ਖੋਲ੍ਹਣ ਵਿੱਚ ਖਰਚ ਹੁੰਦਾ ਹੈ। ਟਾਈਪ ਜਾਣਕਾਰੀ ਨੈਵੀਗੇਸ਼ਨ ਫੀਚਰਾਂ ਨੂੰ ਕਾਫ਼ੀ ਬੇਹਤਰ ਬਣਾਉਂਦੀ ਹੈ:
ਇਸ ਨਾਲ ਦਿਨ-ਭਰ ਦਾ ਕੰਮ ਬਦਲ ਜਾਂਦਾ ਹੈ: ਸਿਸਟਮ ਨੂੰ ਸਿਰੇ-ਅੰਤ ਤੱਕ ਆਪਣੇ ਦਿਮਾਗ ਵਿਚ ਰੱਖਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਕੋਡ ਵਿੱਚ ਇੱਕ ਭਰੋਸੇਯੋਗ ਟਰੇਲ ਫੋਲੋ ਕਰ ਸਕਦੇ ਹੋ।
ਟਾਈਪਸ ਭਾਵਨਾ ਰਿਵਿਊ ਦੌਰਾਨ ਦਿਖਾਉਂਦੇ ਹਨ। ਇੱਕ ਡਿਫ ਜੋ userId: string ਜੋੜਦਾ ਹੈ ਜਾਂ Promise<Result<Order, ApiError>> ਵਾਪਸ ਕਰਦਾ ਹੈ ਉਹ ਬਿਨਾਂ ਲੰਬੇ ਟਿੱਪਣੀਆਂ ਦੇ ਨਿਯਮ ਅਤੇ ਉਮੀਦਾਂ ਦੱਸ ਦਿੰਦਾ ਹੈ।
ਰਿਵਿਊਅਰ ਵੀਹੇਵਿਓਰ ਅਤੇ ਏਜ ਕੇਸਾਂ 'ਤੇ ਧਿਆਨ ਦੇ ਸਕਦੇ ਹਨ ਨਾ ਕਿ ਇਹ ਵਿਚਾਰ ਕਰਨ 'ਤੇ ਕਿ ਕਿਸੇ ਵੈਲਯੂ ਨੂੰ "ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ"।
ਕਈ ਟੀਮਾਂ VS Code ਵਰਤਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਇਸ ਨੂੰ ਬਾਹਰ-ਆਉਟ-ਆਫ-ਬਾਕਸ ਮਜ਼ਬੂਤ TypeScript ਸਹਾਇਤਾ ਮਿਲਦੀ ਹੈ, ਪਰ ਕਿਸੇ ਖਾਸ ਏਡੀਟਰ ਦੀ ਲੋੜ ਨਹੀਂ। ਕੋਈ ਵੀ ਮਾਹੌਲ ਜੋ TypeScript ਨੂੰ ਸਮਝਦਾ ਹੈ ਉਹੀ ਕਿਸਮ ਦੀ ਨੈਵੀਗੇਸ਼ਨ ਅਤੇ ਹਿੰਟਿੰਗ ਫੀਚਰ ਦੇ ਸਕਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇਹ ਲਾਭ ਰਸਮੀ ਬਣਾਉਣੀ ਚਾਹੁੰਦੇ ਹੋ, ਟੀਮਾਂ ਅਕਸਰ /blog/code-style-guidelines ਵਰਗੀਆਂ ਹੈਲਕੀ ਰੀਤੀਆਂ ਦੇ ਨਾਲ ਜੋੜਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਟੂਲਿੰਗ ਪ੍ਰੋਜੈਕਟ 'ਚ ਲਗਾਤਾਰ ਠੀਕ ਰਹੇ।
ਵੱਡੇ ਫਰੰਟਐਂਡ ਨੂੰ ਰੀਫੈਕਟਰ ਕਰਨਾ ਪਹਿਲਾਂ ਉਹਨੂੰ ਇੱਕ ਕਮਰੇ 'ਚ ਟ੍ਰਿਪਵਾਇਰਾਂ ਨਾਲ ਚੱਲਣ ਵਰਗਾ ਲੱਗਦਾ ਸੀ: ਤੁਸੀਂ ਇੱਕ ਇਲਾਕਾ ਸੁਧਾਰ ਸਕਦੇ ਸੀ, ਪਰ ਨਹੀਂ ਪਤਾ ਹੁੰਦਾ ਸੀ ਕਿ ਦੂਜੇ ਕੋਨੇ 'ਚ ਕੀ ਟੁਟੇਗਾ। TypeScript ਇਸ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ ਕਈ ਖਤਰਨਾਕ ਸੋਧਾਂ ਨੂੰ ਨਿਯੰਤ੍ਰਿਤ, ਯੰਤਰਕ ਕਦਮਾਂ ਵਿੱਚ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਟਾਈਪ ਬਦਲਦੇ ਹੋ, ਕੰਪਾਇਲਰ ਅਤੇ ਤੁਹਾਡਾ ਏਡੀਟਰ ਹਰ ਥਾਂ ਦਿਖਾਉਂਦੇ ਹਨ ਜੋ ਉਸ 'ਤੇ ਨਿਰਭਰ ਹੈ।
TypeScript ਰੀਫੈਕਟਰਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕੋਡਬੇਸ ਨੂੰ ਉਸ "ਆਕਾਰ" ਨਾਲ ਸੰਗਤ ਰਹਿਣ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਘੋਸ਼ਣਾ ਕਰਦੇ ਹੋ। ਯਾਦ ਤੇ ਆਧਾਰਿਤ ਯਾਦ ਦੇ ਬਦਲੇ, ਤੁਹਾਨੂੰ ਸਭ ਦ੍ਰਿਸ਼ਟੀ-ਸਥਾਨਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਮਿਲਦੀ ਹੈ ਜਿਨ੍ਹਾਂ 'ਤੇ ਅਸਰ ਪਏਗਾ।
ਕੁਝ ਆਮ ਉਦਾਹਰਨ:
Button ਪਹਿਲਾਂ isPrimary ਲੈਂਦਾ ਸੀ ਅਤੇ ਤੁਸੀਂ ਇਸ ਨੂੰ variant ਕਰ ਦਿੰਦੇ ਹੋ, TypeScript ਹਰ ਉਸ ਕੰਪੋਨੇਟ ਨੂੰ ਝਲਕਾ ਦੇਵੇਗਾ ਜੋ ਅਜੇ ਵੀ isPrimary ਪਾਸ ਕਰਦਾ ਹੈ।user.name ਹੁਣ user.fullName ਬਣਦਾ ਹੈ, ਟਾਈਪ ਅਪਡੇਟ ਸਾਰੇ ਰੀਡ ਅਤੇ ਧਾਰਨਾਵਾਂ ਨੂੰ ਦੁਆਰਾ ਪ੍ਰਗਟ ਕਰੇਗਾ।ਸਭ ਤੋਂ ਪ੍ਰਯੋਗਿਕ ਫਾਇਦਾ ਰਫ਼ਤਾਰ ਹੈ: ਇੱਕ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਟਾਈਪ ਚੈੱਕਰ ਚਲਾਉਂਦੇ ਹੋ (ਜਾਂ ਸਿਰਫ ਆਪਣੇ IDE ਨੂੰ ਵੇਖਦੇ ਹੋ) ਅਤੇ ਐਰਰਾਂ ਨੂੰ ਇੱਕ ਚੈੱਕਲਿਸਟ ਵਾਂਗ ਫੋਲੋ ਕਰਦੇ ਹੋ। ਤੁਸੀਂ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਗਾ ਰਹੇ ਕਿ ਕਿਹੜਾ ਨਿਰੀਖਣ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦਾ—ਤੁਸੀਂ ਹਰ ਉਸ ਥਾਂ ਨੂੰ ਠੀਕ ਕਰ ਰਹੇ ਹੋ ਜਿਥੇ ਕੰਪਾਇਲਰ ਦਿਖਾ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਅਨੁਕੂਲ ਨਹੀਂ।
TypeScript ਹਰ ਬੱਗ ਨਹੀਂ ਫੜ ਸਕਦਾ। ਇਹ ਯਕੀਨੀ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਸਰਵਰ ਹਕੀਕਤ ਵਿੱਚ ਉਹੀ ਡੇਟਾ ਭੇਜ ਰਿਹਾ ਹੈ ਜੋ ਇਸਨੇ ਵਾਅਦਾ ਕੀਤਾ ਸੀ, ਜਾਂ ਕਿ ਕਿਸੇ ਹੈਰਾਨੀਭਰਿਆ edge case ਵਿੱਚ ਇੱਕ ਵੈਲਯੂ null ਨਹੀਂ ਹੈ। ਯੂਜ਼ਰ ਇਨਪੁੱਟ, ਨੈੱਟਵਰਕ ਰਿਸਪਾਂਸ, ਅਤੇ ਤੀਸਰੇ-ਪੱਖ ਸਕਰਿਪਟਾਂ ਲਈ ਹਜੇ ਵੀ ਰਨਟਾਈਮ ਵੈਧਤਾ ਅਤੇ ਡਿਫੈਂਸਿਵ UI ਸਟੇਟਜ਼ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।
ਜਿੱਦਾ ਜਿਤਾ TypeScript ਰੀਫੈਕਟਰਸ ਦੌਰਾਨ ਇੱਕ ਵੱਡੀ ਸ਼੍ਰੇਣੀ ਦੀ "ਗਲਤੀ-ਸਬੰਧੀ ਟੁੱਟਣ" ਘਟਾ ਦਿੰਦਾ ਹੈ, ਬਾਕੀ ਬੱਗਜ਼ ਆਮ ਤੌਰ 'ਤੇ ਅਸਲੀ ਵਿਵਹਾਰ ਬਾਰੇ ਹੁੰਦੇ ਹਨ—ਨ ਕਿ ਛੁੱਟੇ-ਪਏ rename fallout ਬਾਰੇ।
API ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ ਕਈ ਫਰੰਟਐਂਡ ਬੱਗਜ਼ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ—ਨਾ ਕਿ ਟੀਮਾਂ ਦੀ ਲਾਪਰਵਾਹੀ ਕਰਕੇ, ਬਲਕਿ ਇਸ ਲਈ ਕਿ ਹਕੀਕਤੀ ਰਿਸਪਾਂਸ ਸਮੇਂ ਦੇ ਨਾਲ ਬਦਲਦੇ ਹਨ: ਫੀਲਡ ਜੋੜੇ ਜਾਂਦੇ ਹਨ, ਨਾਮ ਬਦਲਦੇ ਹਨ, ਵਿਕਲਪਿਕ ਬਣ ਜਾਂਦੇ ਹਨ, ਜਾਂ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ। TypeScript ਮਦਦ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਹਰ ਹੈਂਡਓਫ਼ 'ਤੇ ਡੇਟਾ ਦੇ "ਆਕਾਰ" ਨੂੰ ਸਪੱਸ਼ਟ ਬਣਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਐਂਡਪੌਇੰਟ ਵਿੱਚ ਬਦਲਾਅ ਜ਼ਿਆਦਾ ਸੰਭਵ ਹੈ ਕਿ ਇਕ ਕੰਪਾਇਲ-ਟਾਈਮ ਐਰਰ ਵਜੋਂ ਸਾਹਮਣੇ ਆਵੇ ਨਾ ਕਿ ਉਤਪਾਦਨ ਛੇਤੀਗੀਆਂ।
ਜਦੋਂ ਤੁਸੀਂ API ਰਿਸਪਾਂਸ ਨੂੰ ਟਾਈਪ ਕਰਦੇ ਹੋ (ਭਾਵroughly ਹੀ क्यों न ਹੋਵੇ), ਤੁਸੀਂ ਐਪ ਨੂੰ ਇਹ ਮਜ਼ਬੂਰ ਕਰਦੇ ਹੋ ਕਿ ਉਹ ਇਹ ਸਹਿਮਤੀ ਕਰੇ ਕਿ "ਇੱਕ user", "ਇੱਕ order", ਜਾਂ "ਇੱਕ search result" ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਦਿਸਦੇ ਹਨ। ਉਹ ਸਪੱਸ਼ਟਤਾ ਤੇਜ਼ੀ ਨਾਲ ਫੈਲਦੀ ਹੈ:
ਆਮ ਪੈਟਰਨ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਐਪ ਵਿੱਚ ਡੇਟਾ ਦਾਖਲ ਹੋਣ ਵਾਲੀ ਬਾਊਂਡਰੀ (ਤੁਹਾਡਾ fetch ਲੇਅਰ) 'ਤੇ ਟਾਈਪ ਕਰਦੇ ਹੋ, ਫਿਰ ਟਾਈਪਡ ਉਬਜੈਕਟਾਂ ਨੂੰ ਅੱਗੇ ਭੇਜਦੇ ਹੋ।
ਪ੍ਰੋਡਕਸ਼ਨ API ਅਕਸਰ ਸ਼ਾਮਲ ਹਨ:
null ਇਰਾਦਤاً ਵਰਤਿਆ ਜਾਂਦਾ)TypeScript ਤੁਹਾਡੇ ਨੂੰ ਇਹ ਕੇਸਾਂ ਇਰਾਦੇ ਨਾਲ ਸੰਭਾਲਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ। ਜੇ user.avatarUrl ਗਾਇਬ ਹੋ ਸਕਦੀ ਹੈ, ਤਾਂ UI ਨੂੰ ਫਾਲਬੈਕ ਦੇਣਾ ਪਵੇਗਾ, ਜਾਂ ਮੈਪਿੰਗ ਲੇਅਰ ਨੂੰ ਇਸਨੂੰ ਨਾਰਮਲਾਈਜ਼ ਕਰਨਾ ਪਏਗਾ। ਇਹ "ਜੇ ਇਹ ਗਾਇਬ ਹੋਵੇ ਤਾਂ ਅਸੀਂ ਕੀ ਕਰਾਂਗੇ?" ਵੱਲ ਦੇ ਫੈਸਲੇ ਕੋਡ ਰਿਵਿਊ ਵਿੱਚ ਧਕੇ ਜਾਂਦੇ ਹਨ, ਬਜਾਏ ਕਿ ਉਹ ਘੱਟੇ-ਪਏ ਮੌਕੇ 'ਤੇ ਨਿਰਭਰ ਰਹਿਣ।
TypeScript ਚੈੱਕਸ build ਸਮੇਂ ਹੁੰਦੇ ਹਨ, ਪਰ API ਡੇਟਾ ਰਨਟਾਈਮ 'ਤੇ ਆਉਂਦਾ ਹੈ। ਇਸੀ ਲਈ ਰਨਟਾਈਮ ਵੈਧਤਾ ਫਾਇਦੇਮੰਦ ਹੋ ਸਕਦੀ ਹੈ—ਖਾਸ ਕਰਕੇ ਅਣ-ਭਰੋਸੇਯੋਗ ਜਾਂ ਬਦਲ ਰਹੇ APIs ਲਈ। ਇੱਕ ਪ੍ਰਾਇਗਮੈਟਿਕ ਪਹੁੰਚ:
ਟੀਮਾਂ ਹੱਥ ਨਾਲ ਟਾਈਪ ਲਿਖ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ OpenAPI ਜਾਂ GraphQL ਸਕੀਮਾਂ ਤੋਂ ਵੀ ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ। ਜਨਰੇਸ਼ਨ ਮੈਨੂਅਲ ਡ੍ਰਿਫਟ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ, ਪਰ ਲਾਜ਼ਮੀ ਨਹੀਂ—ਕਈ ਪ੍ਰੋਜੈਕਟ ਕੁਝ ਹੱਥ-ਲਿਖੇ ਰਿਸਪਾਂਸ ਟਾਈਪਸ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਜਨਰੇਸ਼ਨ ਲਿਆਉਂਦੇ ਹਨ ਜੇ ਇਹ ਲਾਭਕਾਰੀ ਹੋਵੇ।
UI ਕੰਪੋਨੇਟ ਛੋਟੇ, ਦੁਹਰਾਉਣਯੋਗ ਬਿਲਡਿੰਗ ਬਲਾਕ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ—ਪਰ ਵੱਡੇ ਐਪਾਂ ਵਿੱਚ ਉਹ ਅਕਸਰ ਨਾਜ਼ੁਕ "ਮਿਨੀ-ਐਪਸ" ਬਣ ਜਾਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਦਰਜਨਾਂ props, ਸ਼ਰਤਾਂ ਅਨੁਸਾਰ rendering, ਅਤੇ ਨਰਮ ਧਾਰਨਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ। TypeScript ਉਹਨਾਂ ਧਾਰਨਾਵਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰ ਕੇ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਰੱਖ-ਰਖਾਵਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਕਿਸੇ ਵੀ ਆਧੁਨਿਕ UI ਫ੍ਰੇਮਵਰਕ 'ਚ, ਕੰਪੋਨੇਟ ਇਨਪੁੱਟ (props/inputs) ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ ਅਤੇ ਅੰਦਰੂਨੀ ਡੇਟਾ (state) ਨੂੰ ਮੈਨੇਜ ਕਰਦੇ ਹਨ। ਜਦ ਉਹ ਆਕਾਰ ਟਾਈਪਡ ਨਹੀਂ ਹੁੰਦੇ, ਤੁਸੀਂ ਗਲਤੀ ਨਾਲ ਗਲਤ ਵੈਲਯੂ ਦੇ ਸਕਦੇ ਹੋ ਅਤੇ ਇਹ ਸਿਰਫ਼ ਰਨਟਾਈਮ 'ਤੇ ਪਤਾ ਲੱਗੇ—ਕਈ ਵਾਰੀ ਸਿਰਫ਼ ਇੱਕ ਘੱਟ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਸਕਰੀਨ 'ਤੇ।
TypeScript ਨਾਲ, props ਅਤੇ state ਕੰਟ੍ਰੈਕਟ ਬਣ ਜਾਂਦੇ ਹਨ:
ਇਹ ਗਾਰਡਰੇਲਾਂ ਰੱਖਿਆਤਮਕ ਕੋਡ ਦੀ ਮਾਤਰਾ ਘਟਾਉਂਦੀਆਂ ਹਨ ("if (x) …") ਅਤੇ ਕੰਪੋਨੇਟ ਵਿਹੇਵਿਓਰ ਨੂੰ ਸੋਚਣਾ ਆਸਾਨ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਵੱਡੇ ਕੋਡਬੇਸ ਵਿੱਚ ਆਮ ਬੱਗ ਦਾ ਸਰੋਤ prop mismatch ਹੁੰਦਾ ਹੈ: parent ਸੋਚਦਾ ਹੈ ਕਿ ਉਹ userId ਪਾਸ ਕਰ ਰਿਹਾ ਹੈ, child id ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ; ਜਾਂ ਇੱਕ ਵੈਲਯੂ ਕਦੇ string ਹੁੰਦੀ ਹੈ ਤੇ ਕਦੇ number। TypeScript ਇਹ ਸਮੱਸਿਆਵਾਂ ਉੱਥੇ ਹੀ ਸਤਾਹਵਾਰ ਦਿਖਾ ਦਿੰਦਾ ਹੈ ਜਿੱਥੇ ਕੰਪੋਨੇਟ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੈ।
ਟਾਈਪਸ valid UI ਸਟੇਟਸ ਨੂੰ ਵੀ ਮਾਡਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ। ਥਰਡ-ਪਾਰਟੀ ਬੂਟਲੇਕਸ boolean ਜਿਵੇਂ isLoading, hasError, ਅਤੇ data ਦੀ ਥਾਂ ਤੁਸੀਂ ਇੱਕ discriminated union ਵਰਤ ਸਕਦੇ ਹੋ ਜਿਵੇਂ { status: 'loading' | 'error' | 'success' } ਜਿਸ ਨਾਲ ਹਰ ਕੇਸ ਲਈ ਉਚਿਤ ਫੀਲਡ ਹਨ। ਇਸ ਨਾਲ ਇੱਕ error view ਨੂੰ ਬਿਨਾਂ error message ਦੇ ਰੈਂਡਰ ਕਰਨ ਜਾਂ success view ਨੂੰ ਬਿਨਾਂ ਡੇਟਾ ਦਿਖਾਉਣ ਦੀ ਸਮਭਾਵਨਾ ਘੱਟ ਹੋ ਜਾਂਦੀ ਹੈ।
TypeScript ਮੁੱਖ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਇੰਟੀਗਰੇਟ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ React function components, Vue ਦੀ Composition API, ਜਾਂ Angular ਦੇ class-based ਟੈਂਪਲੇਟ ਵਰਤੋ—ਮੁੱਖ ਲਾਭ ਇੱਕੋ ਹੀ ਹੈ: ਟਾਈਪਡ ਇਨਪੁੱਟ ਅਤੇ ਭਰੋਸੇਯੋਗ ਕੰਪੋਨੇਟ ਕੰਟ੍ਰੈਕਟ ਜੋ ਟੂਲਿੰਗ ਸਮਝ ਸਕਦੀ ਹੈ।
ਸ਼ੇਅਰਡ ਕੰਪੋਨੈਂਟ ਲਾਇਬਰੇਰੀ ਵਿੱਚ, TypeScript ਪਰਿਭਾਸ਼ਾਵਾਂ ਹਰ ਉਪਭੋਗਤਾ ਟੀਮ ਲਈ ਤਤਕਾਲ ਦਸਤਾਵੇਜ਼ ਵਾਂਗ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। ਆਟੋ-ਕੰਪਲੀਟ props ਦਿਖਾਉਂਦਾ ਹੈ, ਇਨਲਾਈਨ ਹਿੰਟਸ ਸਪੱਸ਼ਟ ਕਰਦੀਆਂ ਹਨ ਕਿ ਉਹ ਕੀ ਕਰਦੇ ਹਨ, ਅਤੇ ਬ੍ਰੇਕਿੰਗ ਬਦਲਾਅ ਉੱਪਗ੍ਰੇਡ ਦੌਰਾਨ ਦਿਸ ਜਾਂਦੇ ਹਨ।
ਵਾਰਤ-ਪੰਨਾ 'ਤੇ ਵਿੱਖੇ ਇਕ wiki ਪੰਨਾ ਜਿਹੜਾ ਸਮੇਂ ਨਾਲ ਡ੍ਰਿਫਟ ਹੁੰਦਾ ਰਹਿੰਦਾ, ਉਸਦੀ ਥਾਂ ਸਚਾਈ ਦਾ ਸਰੋਤ ਕੰਪੋਨੇਟ ਨਾਲ ਨਾਲ ਚਲਦੀ ਹੈ—ਜਿਸ ਨਾਲ reuse ਸੁਰੱਖਿਅਤ ਹੁੰਦੀ ਹੈ ਅਤੇ ਲਾਇਬਰੇਰੀ ਮੈਨਟੇਨਰਾਂ ਉੱਤੇ ਸਹਾਰਾ ਘਟਦਾ ਹੈ।
ਵੱਡੇ ਫਰੰਟਐਂਡ ਪਰੋਜੈਕਟ ਅਕਸਰ ਇਸ ਲਈ ਫੇਲ ਨਹੀਂ ਹੁੰਦੇ ਕਿ ਇੱਕ ਵਿਅੱਕਤੀ ਨੇ "ਖਰਾਬ ਕੋਡ" ਲਿਖਿਆ। ਉਹ ਤਕਲੀਫ਼ਨਾਕ ਉਸ ਵੇਲੇ ਬਣਦੇ ਹਨ ਜਦੋਂ ਕਈ ਲੋਕ ਥੋੜ੍ਹਾ-ਥੋੜ੍ਹਾ ਅਲੱਗ-ਅਲੱਗ ਚੋਣਾਂ ਕਰ ਲੈਂਦੇ ਹਨ—ਨਾਂਮਕਰਨ, ਡੇਟਾ ਆਕਾਰ, ਐਰਰ ਹੈਂਡਲਿੰਗ ਵਿੱਚ ਫਰਕ—ਜਦ ਤੱਕ ਐਪ ਅਣਫਰੰਗ ਅਤੇ ਅਣਪਹਿਲੀ ਹੋ ਜਾਂਦੀ ਹੈ।
ਮੁਲਕਾਨੀ ਟੀਮਾਂ ਜਾਂ ਮਲਟੀ-ਰੀਪੋ ਮਾਹੌਲ ਵਿੱਚ, ਤੁਸੀਂ ਹਰ ਕਿਸੇ ਉੱਤੇ ਲਿਖੇ ਉਨਾਂ ਅਣ-ਲਿਖੇ ਨਿਯਮਾਂ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਰਹਿ ਸਕਦੇ। ਲੋਕ ਬਦਲਦੇ ਰਹਿੰਦੇ ਹਨ, ਠੇਕੇਦਾਰ ਆਉਂਦੇ ਹਨ, ਸੇਵਾਵਾਂ ਵਿਕਸਤ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ "ਇਥੇ ਅਸੀਂ ਇਹ ਢੰਗੋਂ ਕਰਦੇ ਹਾਂ" ਗਵਾਹੀ ਨਾਮੀ ਗਿਆਨ ਬਣ ਜਾਂਦੀ ਹੈ।
TypeScript ਉਮੀਦਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਕੇ ਮਦਦ ਕਰਦਾ ਹੈ। ਜਿਵੇਂ ਕਿ ਕਿਸੇ ਫੰਕਸ਼ਨ ਨੇ ਕੀ ਲੈਣਾ ਅਤੇ ਕੀ ਦੇਣਾ ਹੈ, ਤੁਸੀਂ ਇਹ ਟਾਈਪਸ ਵਿੱਚ ਐਨਕੋਡ ਕਰਦੇ ਹੋ ਜੋ ਹਰ ਕਾਲਰ ਨੂੰ ਪਾਲਣਾ ਕਰਨੀ ਪੈਂਦੀ ਹੈ। ਇਹ consistency ਨੂੰ ਡਿਫਾਲਟ ਬਣਾ ਦਿੰਦਾ ਹੈ ਨਾ ਕਿ ਇੱਕ ਗਾਈਡਲਾਈਨ ਜੋ ਅਸਾਨੀ ਨਾਲ ਛੱਡ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਹੈ।
ਇੱਕ ਚੰਗਾ ਟਾਈਪ ਉਹ ਨਿਯਮ ਹੈ ਜੋ ਸਾਰੀ ਟੀਮ ਸਾਂਝੀ ਕਰਦੀ ਹੈ:
User ਹਮੇਸ਼ਾ id: string ਹੋਵੇ, ਨਾਂ ਕਿ ਕਦੇ number।ਜਦੋਂ ਇਹ ਨਿਯਮ ਟਾਈਪਸ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ, ਨਵੇਂ ਸਾਥੀ ਕੋਡ ਪੜ੍ਹ ਕੇ ਅਤੇ IDE hintਾਂ ਤੋਂ ਸਿੱਖ ਸਕਦੇ ਹਨ, Slack 'ਤੇ ਪੁੱਛਣ ਜਾਂ ਕਿਸੇ ਸੀਨੀਅਰ ਇੰਜੀਨੀਅਰ ਨੂੰ ਧੂੰਡਣ ਦੀ ਲੋੜ ਘਟ ਜਾਂਦੀ ਹੈ।
TypeScript ਅਤੇ ਲਿੰਟਰ ਵੱਖ-ਵੱਖ ਸਮੱਸਿਆਵਾਂ ਹਲ ਕਰਦੇ ਹਨ:
ਇਕਠੇ ਵਰਤਣ ਨਾਲ PRs ਵਿਹੇਵਿਓਰ ਅਤੇ ਡਿਜ਼ਾਈਨ ਬਾਰੇ ਹੋਣਗੇ—ਨ ਕਿ ਬਾਇਕਸ਼ੇਡਿੰਗ ਬਾਰੇ।
ਟਾਈਪਸ ਉਤੇ-ਅਧਿਕ ਹੋ ਸਕਦੀਆਂ ਹਨ ਜੇ ਉਹ ਬਹੁਤ ਜਟਿਲ ਬਣ ਜਾਂਦੀਆਂ ਹਨ। ਕੁਝ ਪ੍ਰਾਇਗਮੈਟਿਕ ਨਿਯਮ:
type OrderStatus = ...)।unknown + narrowing ਨੂੰ ਨਿਯਤ ਤੌਰ ਤੇ ਵਰਤੋਂ ਬਜਾਏ any ਵੰਡਣ ਦੇ।ਪੜ੍ਹਨਯੋਗ ਟਾਈਪਸ ਚੰਗੇ ਦਸਤਾਵੇਜ਼ ਵਾਂਗ ਹਨ: ਸਟੀਕ, ਅਪ-ਟੂ-ਡੇਟ, ਅਤੇ ਅਸਾਨ ਫੋਲੋ ਕਰਨ ਯੋਗ।
ਵੱਡੇ ਫਰੰਟਐਂਡ ਨੂੰ JavaScript ਤੋਂ TypeScript ਵਿੱਚ ਮਾਈਗ੍ਰੇਟ ਕਰਨਾ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਛੋਟੇ, ਵਾਪਸੀਯੋਗ ਕਦਮਾਂ ਵਜੋਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ—ਨ ਕਿ ਇਕ ਵਾਰ ਦਾ ਰੀ-ਰਾਈਟ। ਮਕਸਦ ਸੁਰੱਖਿਆ ਅਤੇ ਸਪੱਸ਼ਟਤਾ ਵਧਾਉਣਾ ਹੈ ਬਿਨਾਂ ਪ੍ਰੋਡਕਟ ਕੰਮ ਨੂੰ ਰੋਕੇ。
1) "ਨਵੀਆਂ ਫਾਇਲਾਂ ਪਹਿਲਾਂ"
ਸਾਰਾ ਨਵਾਂ ਕੋਡ TypeScript ਵਿੱਚ ਲਿਖੋ ਅਤੇ ਮੌਜੂਦਾ ਮੌਡੀਊਲਾਂ ਨੂੰ ਛੱਡ ਦਿਓ। ਇਹ JS ਸਤਹ ਨੂੰ ਵਧਣ ਤੋਂ ਰੋਕਦਾ ਹੈ ਅਤੇ ਟੀਮ ਨੂੰ ਹੌਲੀ-ਹੌਲੀ ਸਿੱਖਣ ਦਿੰਦਾ ਹੈ।
2) ਮੋਡੀਊਲ-ਬਾਇ-ਮੋਡੀਊਲ ਰੂਪਾਂਤਰ
ਇੱਕ ਬਾਊਂਡਰੀ ਚੁਣੋ (ਇੱਕ ਫੀਚਰ ਫੋਲਡਰ, ਇੱਕ ਸ਼ੇਅਰਡ ਯੂਟਿਲਿਟੀ ਪੈਕੇਜ, ਜਾਂ UI ਕੰਪੋਨੇਟ ਲਾਇਬਰੇਰੀ) ਅਤੇ ਇਸਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਦਲੋ। ਜਿਹੜੇ ਮੋਡੀਊਲ ਵਿਆਪਕ ਰੂਪ ਵਿੱਚ ਵਰਤੇ ਜਾਂ ਵਾਰ-ਵਾਰ ਬਦਲੇ ਜਾਂਦੇ ਹਨ ਉਹਨਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ–ਇਹ ਸਭ ਤੋਂ ਵੱਡਾ ਲਾਭ ਦਿੰਦੇ ਹਨ।
3) ਸਖਤੀ ਦੇ ਕਦਮ
ਫਾਇਲ ਐਕਸਟੇੰਸ਼ਨ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਵੀ, ਤੁਸੀਂ ਪੜਾਅ-ਪੜਾਅ ਕਰਕੇ ਮਜ਼ਬੂਤ ਗਾਰੰਟੀਆਂ ਵੱਲ ਵਧ ਸਕਦੇ ਹੋ। ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਪਹਿਲਾਂ ਸੁਖਦਾਇਕ ਰਹਿੰਦੀਆਂ ਹਨ ਅਤੇ ਸਮੇਂ ਨਾਲ ਨਿਯਮ ਸਖਤ ਕਰਦੀਆਂ ਹਨ ਜਦੋਂ ਟਾਈਪਸ ਮੁਕੰਮਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
ਤੁਹਾਡਾ tsconfig.json ਮਾਈਗ੍ਰੇਸ਼ਨ ਦਾ ਸਟੀਅਰਿੰਗ ਹਵਾਲਾ ਹੈ। ਇੱਕ ਪ੍ਰਾਇਗਮੈਟਿਕ ਪੈਟਰਨ:
strict mode ਬਾਅਦ ਵਿੱਚ ਸਮੇਤੋ (ਜਾਂ ਇੱਕ-ਇਕ strict ਫਲੈਗ ਨੂੰ ਚਾਲੂ ਕਰੋ)।ਇਸ ਨਾਲ ਸ਼ੁਰੂਆਤੀ ਬਹੁਤ ਸਾਰੀਆਂ ਟਾਈਪ ਐਰਰਾਂ ਦਾ ਬੋਝ ਨਹੀਂ ਬਣਦਾ ਅਤੇ ਟੀਮ ਫਰਮਾਇਆ ਜਾਂਦਾ ਹੈ ਕਿ ਉਹ ਉਨ੍ਹਾਂ ਚੀਜ਼ਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਅਸਲ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਹਨ।
ਹਰ dependency ਵਧੀਆ typings ਨਾਲ ਨਹੀਂ ਆਉਂਦੀ। ਆਮ ਵਿਕਲਪ:
@types/... ਰਾਹੀਂ)any ਨੂੰ ਇੱਕ ਛੋਟੇ adapter ਲੇਅਰ ਤੱਕ ਸੀਮਤ ਰੱਖੋਨਿਯਮ: ਪੂਰੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਲਈ ਪੂਰਨ ਟਾਈਪਸ ਦੀ ਉਡੀਕ ਨਾ ਕਰੋ—ਇੱਕ ਸੁਰੱਖਿਅਤ ਬਾਊਂਡਰੀ ਬਣਾਓ ਅਤੇ ਅੱਗੇ ਵਧੋ।
ਛੋਟੇ mile-stones ਸੈੱਟ ਕਰੋ (ਉਦਾਹਰਨ: "ਸ਼ੇਅਰਡ ਯੂਟਿਲਿਟੀਜ਼ ਕਨਵਰਟ ਕਰੋ", "API ਕਲਾਇੰਟ ਨੂੰ ਟਾਈਪ ਕਰੋ", "/components ਵਿੱਚ strict") ਅਤੇ ਸਧਾਰਣ ਟੀਮ ਨਿਯਮ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: ਕਿੱਥੇ TypeScript ਲਾਜ਼ਮੀ ਹੈ, ਨਵੇਂ API ਕਿਵੇਂ ਟਾਈਪ ਕਰਨੇ, ਅਤੇ any ਕਦੋਂ ਮਨਜ਼ੂਰ ਹੈ। ਇਹ ਸਪਸ਼ਟਤਾ ਪ੍ਰਗਤੀ ਨੂੰ ਜਾਰੀ ਰੱਖਦੀ ਹੈ ਜਦੋਂ ਕਿ ਨਵਾਂ ਫੀਚਰ ਵੀ ਆ ਰਹੇ ਹੁੰਦੇ ਹਨ।
ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਆਪਣੇ ਬਣਾਉਣ ਅਤੇ ਸ਼ਿਪਿੰਗ ਤਰੀਕੇ ਨੂੰ ਵੀ ਆਧੁਨਿਕ ਕਰ ਰਹੀ ਹੈ, ਤਾਂ ਇੱਕ ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਤੁਹਾਡੀ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ chat-ਆਧਾਰਤ ਵਰਕਫਲੋ ਰਾਹੀਂ React + TypeScript ਫਰੰਟਐਂਡ ਅਤੇ Go + PostgreSQL ਬੈਕਐਂਡ scaffold ਕਰ ਸਕਦੇ ਹੋ, "planning mode" ਵਿੱਚ ਇਟਰੈਟ ਕਰ ਸਕਦੇ ਹੋ ਪਹਿਲਾਂ ਕੋਡ ਜਨਰੇਟ ਕਰਨ ਤੋਂ, ਅਤੇ ਜਦੋਂ ਤਿਆਰ ਹੋਵੋ ਤਦ ਸਰੋਤ ਕੋਡ export ਕਰ ਸਕਦੇ ਹੋ। ਠੀਕ ਤਰ੍ਹਾਂ ਵਰਤਿਆ ਜਾਵੇ ਤਾਂ ਇਹ TypeScript ਦਾ ਲਕਸ਼ਣ ਪੂਰਾ ਕਰਨ ਵਿੱਚ ਇਕ ਸਹਾਇਕ ਟੂਲ ਹੋ ਸਕਦਾ ਹੈ: ਅਣਿਸ਼ਚਿਤਤਾ ਘਟਾਉਣਾ ਅਤੇ ਡਿਲਿਵਰੀ ਰਫ਼ਤਾਰ ਨੁਰੂ ਮਹਫ਼ੂਜ਼ ਰੱਖਣਾ।
TypeScript ਵੱਡੇ ਫਰੰਟਐਂਡਸ ਨੂੰ ਬਦਲਣਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ, ਪਰ ਇਹ ਮੁਫ਼ਤ ਉੱਨਤੀ ਨਹੀਂ ਹੈ। ਟੀਮਾਂ ਨੂੰ ਅਕਸਰ ਖ਼ਰਚ ਅਪਣਾਊਣ ਅਤੇ ਭਾਰੀ ਉਤਪਾਦ-ਬਦਲਾਅ ਦੇ ਸਮੇਂ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।
ਸਿੱਖਣ ਦੀ ਝੁੰਝਲ ਅਤੇ ਜਨਰਿਕਸ, ਯੂਨੀਅਨਜ਼, ਅਤੇ narrowing ਨਾਲ ਨਵੇਂ ਡਿਵੈਲਪਰਾਂ ਲਈ ਕਰੜਾ ਹੋ ਸਕਦਾ ਹੈ। ਸ਼ੁਰੂ ਵਿੱਚ ਇਹ ਲੱਗ ਸਕਦਾ ਹੈ ਕਿ ਤੁਸੀਂ "ਕੰਪਾਇਲਰ ਨਾਲ ਲੜ ਰਹੇ ਹੋ", ਅਤੇ ਟਾਈਪ ਐਰਰ ਉਸ ਵੇਲੇ ਆਉਂਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣਾ ਚਾਹੁੰਦੇ ਹੋ।
ਤੁਸੀਂ(build) ਸੰਰਚਨਾ ਵੀ ਵੱਧਾਉਣਗੇ। ਟਾਈਪ-ਚੈਕਿੰਗ, ਟ੍ਰਾਂਸਪਾਇਲੇਸ਼ਨ, ਅਤੇ ਕਈ ਵਾਰੀ ਵੱਖਰੇ configs ਟੂਲਿੰਗ (ਬੰਡਲਰ, ਟੈਸਟ) ਲਈ ਹੋਰ ਚਲਦੇ-ਫਿਰਦੇ ਹਿੱਸੇ ਲਿਆਉਂਦੇ ਹਨ। CI धीਮਾ ਹੋ ਸਕਦਾ ਹੈ ਜੇ ਟਾਈਪ ਚੈਕਿੰਗ ਨੂੰ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਟਿਊਨ ਨਾ ਕੀਤਾ ਜਾਵੇ।
TypeScript ਉਸ ਵੇਲੇ ਡਰੇਗੀ ਬਣ ਸਕਦਾ ਹੈ ਜਦੋਂ ਟੀਮ ਹਰ ਚੀਜ਼ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ-ਟਾਈਪ ਕਰ ਦੇਵੇ। ਛੋਟੇ-ਅਵਧੀ ਕੋਡ ਜਾਂ ਆੰਤਰੀਕ ਸਕ੍ਰਿਪਟਾਂ ਲਈ ਬਹੁਤ ਵਿਸਤਾਰਿਤ ਟਾਈਪਸ ਲਿਖਣਾ ਅਕਸਰ ਜਿਆਦਾ ਖ਼ਰਚਲਾ ਹੁੰਦਾ ਹੈ।
ਦੂਜਾ ਆਮ ਸੁਸਤ ਕਰਨ ਵਾਲਾ ਕਾਰਕ unclear generics ਹਨ। ਜੇ ਕਿਸੇ ਯੂਟਿਲਿਟੀ ਦਾ ਟਾਈਪ ਸਿਗਨੇਚਰ ਬਹੁਤ ਚਤੁਰ ਹੈ, ਅਗਲਾ ਵਿਅਕਤੀ ਇਸਨੂੰ ਨਹੀਂ ਸਮਝ ਸਕਦਾ, autocomplete noisy ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਸਧਾਰਣ ਬਦਲਾਵ "ਟਾਈਪ ਪਜ਼ਲ ਸਾਲਵਿੰਗ" ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਹਨ। ਇਹ ਰੱਖ-ਰਖਾਵਯੋਗਤਾ ਦਾ ਮੁੱਦਾ ਹੈ, ਲਾਭ ਨਹੀਂ।
ਵਿਹੇ ਹਨ pragmatic ਗਾਈਡਲਾਈਨ:
unknown (ਨੈਰੋਇੰਗ ਨਾਲ) ਵਰਤੋ, any ਨਹੀਂ।any, @ts-expect-error) ਨੂੰ ਬਚਾਵ-ਹੱਥਾ ਵਜੋਂ ਘੱਟ ਵਰਤੋ ਅਤੇ ਟਿੱਪਣੀ ਦੇ ਕੇ ਦੱਸੋ ਕਿ ਕਿਉਂ ਅਤੇ ਕਦੋਂ ਹਟਾਉਣੀ ਹੈ।ਆਮ ਗਲਤ ਫਹਿਮੀ: "TypeScript ਹਰੇਕ ਬੱਗ ਰੋਕਦਾ ਹੈ।" ਇਹ ਕੁਝ ਕਿਸਮਾਂ ਦੀਆਂ ਗਲਤੀਆਂ ਰੋਕਦਾ ਹੈ, ਮੁੱਖ ਤੌਰ 'ਤੇ ਉਹ ਜਿਹੜੀਆਂ ਕੋਡ ਵਿੱਚ ਕੀਤੇ ਗਏ ਅਨੁਮਾਨਾਂ ਨਾਲ ਸੰਬੰਧਤ ਹਨ। ਇਹ runtime ਫੇਲਿਆਂ (ਨੈੱਟਵਰਕ timeout, invalid API payloads, ਜਾਂ JSON.parse ਦਾ ਫੈਂਕਣਾ) ਨੂੰ ਰੋਕਦਾ ਨਹੀਂ।
ਇਹ ਆਪਣੇ ਆਪ runtime ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਸੁਧਾਰ ਨਹੀਂ ਲਿਆਉਂਦਾ। TypeScript ਟਾਈਪਸ build ਸਮੇਂ ਹਟ ਜਾਂਦੇ ਹਨ; ਕੋਈ ਵੀ ਤੇਜ਼ੀ ਜੋ ਤੁਸੀਂ ਮਹਿਸੂਸ ਕਰੋਗੇ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਬਿਹਤਰ ਰੀਫੈਕਟਰਿੰਗ ਅਤੇ ਘੱਟ ਰਿਗ੍ਰੈਸ਼ਨ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਨਾ ਕਿ ਤੇਜ਼ ਚਲਾਨ ਤੋਂ।
ਵੱਡੇ TypeScript ਫਰੰਟਐਂਡ ਸਤਿੱਠੇ ਰਿਹਾਂਗੇ ਜਦੋਂ ਟੀਮਜ਼ ਟਾਈਪਸ ਨੂੰ ਉਤਪਾਦ ਦਾ ਹਿੱਸਾ ਸਮਝਦੀਆਂ ਹਨ—ਨਾ ਕਿ ਕੋਈ ਵਿਕਲਪਿਕ ਪਰਤ ਜੋ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਛਿੜਕ ਦਿੰਦੇ ਹੋ। ਇਹ ਚੈੱਕਲਿਸਟ ਵਰਤੋ ਦਿਖਣ ਲਈ ਕਿ ਕੀ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਕੀ ਆਹਿਸਤਾ-ਆਹਿਸਤਾ friction ਜੋੜ ਰਿਹਾ ਹੈ।
"strict": true ਵੇਖੋ (ਜਾਂ ਇਸ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਦਸਤਾਵੇਜ਼ੀ ਰੂਪ)। ਜੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ strict ਵਿਕਲਪਿਕਾਂ ਨੂੰ ਕ੍ਰਮਿਕ ਤੌਰ 'ਤੇ ਚਾਲੂ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ noImplicitAny, ਫਿਰ strictNullChecks)।/types ਜਾਂ /domain ਫੋਲਡਰ) ਅਤੇ "ਇੱਕ ਸਰੋਤ ਸਚ" ਬਣਾਓ—OpenAPI/GraphQL ਤੋਂ ਜਨਰੇਟ ਕੀਤੇ ਟਾਈਪਸ ਹੋਰ ਵੀ ਵਧੀਆ ਹਨ।ਛੋਟੇ ਮੋਡੀਊਲਾਂ ਅਤੇ ਸਪਸ਼ਟ ਬਾਊਂਡਰੀਆਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਜੇ ਇੱਕ ਫਾਇਲ ਵਿੱਚ ਡਾਟਾ ਫੇਚਿੰਗ, ਟ੍ਰਾਂਸਫਾਰਮੇਸ਼ਨ, ਅਤੇ UI ਲਾਜਿਕ ਸਭ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਬਦਲਣਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ।
ਮਾਨਾਰਥਕ ਟਾਈਪਸ ਵਰਤੋ ਬਦਲੇ ਚਤੁਰਾਈ ਦੇ: ਉਦਾਹਰਨ ਲਈ, UserId ਅਤੇ OrderId ਵਰਗੀ ਵਿਉਂਤਾਵਾਂ ਗਲਤ ਵਰਤੋਂ ਤੋਂ ਬਚਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ narrowing unions ("loading" | "ready" | "error") state machines ਨੂੰ ਪੜ੍ਹਨਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
any ਦਾ ਫੈਲਣਾ ਖ਼ਾਸ ਕਰਕੇ ਸ਼ੇਅਰਡ ਯੂਟਿਲਿਟੀਜ਼ ਵਿੱਚ।as Something) ਜੋ ਇੱਥੇ-ਉੱਥੇ ਐਰਰਾਂ ਨੂੰ ਚੁੱਪ ਕਰਦੀਆਂ ਹਨ ਬਜਾਏ ਹਕੀਕਤ ਦਰਸਾਉਣ ਦੇ।User ਆਕਾਰ ਵੱਖ-ਵੱਖ ਫੋਲਡਰਾਂ ਵਿੱਚ), ਜਿਸ ਨਾਲ ਡ੍ਰਿਫਟ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦਾ ਹੈ।TypeScript ਆਮ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ ਬਹੁ-ਆਦਮੀ ਟੀਮਾਂ, ਲੰਬੇ ਸਮੇਂ ਦੇ ਉਤਪਾਦਾਂ, ਅਤੇ ਐਪਾਂ ਲਈ ਜੋ ਬਹੁ-ਵਾਰ ਰੀਫੈਕਟਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਸਧਾਰਨ JavaScript ਚੰਗਾ ਰਹਿੰਦਾ ਹੈ ਛੋਟੇ ਪ੍ਰੋਟੋਟਾਈਪ, ਛੋਟੇ-ਅਵਧੀ ਮਾਰਕੇਟਿੰਗ ਸਾਈਟ, ਜਾਂ ਬਹੁਤ ਸਥਿਰ ਕੋਡ ਲਈ ਜਿੱਥੇ ਟੀਮ ਘੱਟ ਟੂਲਿੰਗ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦੀ ਹੈ—ਬਸ ਤੁਸੀਂ ਟਰੇਡ-ਆਫਜ਼ ਲਈ ਇਮਾਨਦਾਰ ਰਹੋ ਅਤੇ ਸਕੋਪ ਨੂੰ ਸੀਮਿਤ ਰੱਖੋ।
TypeScript compile-ਟਾਈਮ ਟਾਈਪ ਜੋੜਦਾ ਹੈ ਜੋ ਮੋਡੀਊਲ ਬਾਊਂਡਰੀਆਂ (ਫੰਕਸ਼ਨ ਇਨਪੁਟ/ਆਉਟਪੁੱਟ, ਕੰਪੋਨੇਟ props, ਸ਼ੇਅਰਡ ਯੂਟਿਲਿਟੀ) 'ਤੇ ਅਨੁਮਾਨਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਦਾ ਹੈ। ਵੱਡੇ ਕੋਡਬੇਸ ਵਿੱਚ, ਇਹ “ਚਲ ਰਿਹਾ” ਹੋਣਾ ਇੱਕ ਬਲਦੇਸ਼ੀ ਸਹਿਮਤੀ ਵਿਚ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਤੋੜ-ਮਰੋੜ ਐਡੀਟਿੰਗ/ਬਿਲਡ ਸਮੇਂ ਪਤਾ ਲੱਗਦਾ ਹੈ ਨਾ ਕਿ QA ਜਾਂ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ।
ਨਹੀਂ। TypeScript ਦੇ ਟਾਈਪ build ਸਮੇਂ ਹਟ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਉਹ ਆਪਣੇ ਆਪ API payloads, ਯੂਜ਼ਰ ਇਨਪੁੱਟ ਜਾਂ ਤੀਸਰੇ-ਪੱਖ ਸਕਸਕ੍ਰਿਪਟ ਦੀ ਵਿਹੋਵਾਰਕ ਜਾਂਚ ਨਹੀਂ ਕਰਦੇ।
TypeScript ਨੂੰ ਡਿਵੈਲਪਰ-ਟਾਈਮ ਸੁਰੱਖਿਆ ਲਈ ਵਰਤੋ, ਅਤੇ ਜਿੱਥੇ ਡੇਟਾ ਅਣ-ਭਰੋਸੇਯੋਗ ਹੈ ਜਾਂ ਫੇਲਿਊਰ ਨੂੰ ਸੰਭਾਲਣਾ ਜ਼ਰੂਰੀ ਹੈ, ਉਥੇ ਰਨਟਾਈਮ ਵੈਧਤਾ (runtime validation) ਜਾਂ ਰਖਿਆਤਮਕ UI ਸਟੇਟ ਜੋੜੋ।
“LIVING CONTRACT” ਦਾ ਮਤਲਬ ਹੈ ਇੱਕ ਅਜਿਹਾ ਟਾਈਪ ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਸਪਲਾਈ ਕਰਨੀ ਹੈ ਅਤੇ ਕੀ ਵਾਪਸ ਮਿਲੇਗਾ।
ਉਦਾਹਰਨ:
User, Order, Result)ਕਿਉਂਕਿ ਇਹ ਕੰਟ੍ਰੈਕਟ ਕੋਡ ਦੇ ਨੇੜੇ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਚੈਕ ਹੁੰਦੇ ਹਨ, ਉਹ ਆਮ ਦਸਤਾਵੇਜ਼ਾਂ ਨਾਲੋਂ ਘੱਟ ਡ੍ਰਿਫਟ ਹੋਦੇ ਹਨ।
ਅਜਿਹੀਆਂ ਗਲਤੀਆਂ ਜਿਹਨੀਆਂ ਨੂੰ TypeScript ਅਰੰਭਿਕ ਤੌਰ 'ਤੇ ਫੜ ਲੈਂਦਾ ਹੈ:
user.fullName ਜਦੋਂ ਸਿਰਫ name ਹੈ)ਇਹ ਆਮ “ਅਕਸਮਾਤੀ ਤੋੜ-ਮਰੋੜ” ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ ਜੋ ਨਹੀਂ ਚਲਣ ਵੇਲੇ ਹੀ ਸਮੇਤੀਆਂ ਜਾਂਦੀਆਂ।
ਟਾਈਪ ਜਾਣਕਾਰੀ ਐਡੀਟਰ ਫੀਚਰਾਂ ਨੂੰ ਵਧੇਰੇ ਸਹੀ ਬਣਾਉਂਦੀ ਹੈ:
ਇਸ ਨਾਲ ਫਾਈਲਾਂ ਵਿੱਚ ਲੰਮੀ ਖੋਜ ਕਰਨ ਵਾਲਾ ਸਮਾਂ ਘਟਦਾ ਹੈ ਅਤੇ ਕੋਡ ਸਮਝਣਾ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਟਾਈਪ (ਜਿਵੇਂ prop ਨਾਮ ਜਾਂ ਰਿਸਪਾਂਸ ਮਾਡਲ) ਬਦਲਦੇ ਹੋ, ਕੰਪਾਇਲਰ ਹਰ ਉਹ ਸਥਾਨ ਦਰਸਾਉਂਦਾ ਹੈ ਜੋ ਗੈਰ-ਅਨੁਕੂਲ ਹੈ।
ਇਕ ਪ੍ਰਯੋਗਿਕ ਵਰਕਫਲੋ:
ਇਸ ਤਰ੍ਹਾਂ ਬਹੁਤ ਸਾਰੇ ਰੀਫੈਕਟਰ ਮਕੈਨਿਕਲ ਅਤੇ ਟ੍ਰੈਕਬਲ ਕਦਮ ਬਣ ਜਾਂਦੇ ਹਨ ਨਾ ਕਿ ਅਨੁਮਾਨ।
API ਬਾਊਂਡਰੀ 'ਤੇ ਟਾਈਪ ਕਰਨਾ (ਭਾਵ fetch/ਕਲਾਇੰਟ ਲੇਅਰ) ਇਸ ਗੱਲ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਅੱਗੇ ਵਾਲੀ ਕੋਡ ਰੂਪ-ਰੇਖਾ ਨਾਲ ਕੰਮ ਕਰੇਗੀ।
ਆਮ ਤਰੀਕੇ:
ਉੱਚ-ਖਤਰੇ ਵਾਲੇ ਏਂਡਪੌਇੰਟ ਲਈ boundary ਲੇਅਰ ਵਿੱਚ ਰਨਟਾਈਮ ਵੈਧਤਾ ਜੋੜੋ ਅਤੇ ਬਾਕੀ ਐਪ ਨੂੰ ਟਾਈਪਡ ਰੱਖੋ।
ਟਾਈਪਡ props ਅਤੇ state assumptions ਨੂੰ ਸਪੱਸ਼ਟ ਅਤੇ ਗਲਤ ਵਰਤੋਂ ਲਈ ਮুশਕਲ ਬਣਾਉਂਦੇ ਹਨ।
ਪ੍ਰਾਇਕਟਿਕ ਫਾਇਦੇ:
loading | error | success ਵਰਗਾ ਯੂਨੀਅਨ)ਇਸ ਨਾਲ repo ਵਿੱਚ ਫੈਲੀ ਅਣ-ਲਿਖੀ ਨਿਯਮਾਂ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਰਹਿੰਦਾ।
ਇੱਕ/Bulk ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਛੋਟੇ, ਵਾਪਸੀਯੋਗ ਕਦਮਾਂ ਵਜੋਂ ਲਿਆਉਣਾ ਚੰਗਾ ਰਹਿੰਦਾ ਹੈ—ਪੂਰੇ ਰੀਫ੍ਰੈਕਟ ਦੀ ਥਾਂ। ਲਕੜੀ ਦਾ ਲਕੜੀ ਤਕਨੀਕ:
ਅਣਟਾਈਪਡ ਡਿਪੇਂਡੈਂਸੀਜ਼ ਲਈ ਇੰਸਟਾਲ ਕਰੋ ਜਾਂ ਛੋਟੀ ਲੋਕਲ ਡਿਕਲੇਰੇਸ਼ਨਾਂ ਬਣਾਓ ਅਤੇ ਨੂੰ ਇੱਕ ਛੋਟੀ ਅਡੈਪਟਰ ਲੇਅਰ ਤੱਕ ਸੀਮਤ ਰੱਖੋ।
ਆਮ ਬਦਲਾਅ ਇਹ ਹਨ:
ਮੁਫ਼ਤ-ਪੱਖੀ ਧਾਰਨਾ: ਜ਼ਿਆਦਾ-ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਟਾਈਪ ਹਰ ਦਾਅਵੇ ਨੂੰ ਦੇਰ ਕਰ ਸਕਦੇ ਹਨ—ਸਧਾਰਨ ਅਤੇ ਪੜ੍ਹਨਯੋਗ ਟਾਈਪਸ ਵਧੀਆ ਹਨ।
@types/...any