TypeScript ਨੇ ਵੱਡੇ JavaScript ਫਰੰਟਐਂਡਸ ਨੂੰ ਰੱਖ-ਰਖਾਵਯੋਗ ਕਿਵੇਂ ਬਣਾਇਆ

ਵੱਡੇ ਫਰੰਟਐਂਡ ਕੋਡਬੇਸ ਰੱਖ-ਰਖਾਵਯੋਗ ਕਿਉਂ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦੇ ਹਨ

ਇੱਕ ਫਰੰਟਐਂਡ ਜੋ "ਸਿਰਫ਼ ਕੁਝ ਪੰਨੇ" ਵਜੋਂ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀ, ਚੁੱਪਚਾਪ ਹਜ਼ਾਰਾਂ ਫਾਇਲਾਂ, ਦਰਜਨਾਂ ਫੀਚਰ ਖੇਤਰ, ਅਤੇ ਰੋਜ਼ਾਨਾ ਬਦਲਾਅ ਕਰਨ ਵਾਲੀਆਂ ਕਈ ਟੀਮਾਂ ਵੱਲ ਵਧ ਸਕਦਾ ਹੈ। ਇਸ ਪੱਧਰ ਤੇ, JavaScript ਦੀ ਲਚੀਲਤਾ ਆਜ਼ਾਦੀ ਲੱਗਣ ਦੀ ਥਾਂ ਅਣਿਸ਼ਚਿਤਤਾ ਬਣ ਜਾਂਦੀ ਹੈ।

"ਚਲਦਾ ਹੈ" ਦਾ ਛੁਪਿਆ ਖਰਚ

ਵੱਡੇ JavaScript ਐਪ ਵਿੱਚ, ਬਹੁਤ ਸਾਰੀਆਂ ਬੱਗਜ਼ ਉਸ جگہ ਪ੍ਰਗਟ ਨਹੀਂ ਹੁੰਦੀਆਂ ਜਿਥੇ ਉਹ ਦਰਜ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ। ਇੱਕ ਛੋਟੀ ਬਦਲਾਅ ਕਿਸੇ ਦੂਜੇ ਸਕਰੀਨ ਨੂੰ ਟੁੱਟਾ ਸਕਦੀ ਹੈ ਕਿਉਂਕਿ ਉਹਨਾਂ ਦੇ ਵਿਚਕਾਰ ਰਿਸ਼ਤਾ ਅਣੌਪਚਾਰਿਕ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਫੰਕਸ਼ਨ ਕਿਸੇ ਡੇਟਾ ਆਕਾਰ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਇੱਕ ਕੰਪੋਨੇਟ ਇਹ ਮੰਨ ਲੈਂਦਾ ਹੈ ਕਿ ਇੱਕ prop ਹਮੇਸ਼ਾ ਮੌਜੂਦ ਹੈ, ਜਾਂ ਇੱਕ ਹੈਲਪਰਾਨੂੰ ਵੱਖ-ਵੱਖ ਇਨਪੁੱਟ ਦੇ ਆਧਾਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਟਾਈਪ ਵਾਪਸ ਕਰ ਦਿੰਦਾ ਹੈ।

ਸਾਂਝੇ ਦਰਦ-ਬਿੰਦੂਆਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:

• ਮੋਡੀਊਲਾਂ ਦਰਮਿਆਨ ਅਸਪਸ਼ਟ ਸਹਿਮਤੀਆਂ: ਤੁਸੀਂ ਲਗਭਗ ਕੁਝ ਵੀ ਕਿਤੇ ਵੀ ਦੇ ਸਕਦੇ ਹੋ, ਇਸ ਲਈ ਅਕਸਰ ਲੋੜਾਂ ਨੂੰ ਸਮਝਣ ਲਈ ਤੁਸੀਂ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਪੜ੍ਹਦੇ ਹੋ।
• ਰਨਟਾਈਮ-ਸਿਰਫ਼ ਫੇਲ੍ਹਰ: ਸਮੱਸਿਆਵਾਂ QA, ਪ੍ਰੋਡਕਸ਼ਨ ਜਾਂ ਕਿਸੇ ਖਾਸ ਯੂਜ਼ਰ ਪਾਥ 'ਤੇ ਹੀ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ—ਕਿਉਂਕਿ ਕੋਈ ਚੀਜ਼ ਕੋਡ ਦੀਆਂ ਉਮੀਦਾਂ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਨਹੀਂ ਚੈਕ ਕਰਦੀ।
• ਡਰ-ਚਲਿਤ ਵਿਕਾਸ: ਇੰਜੀਨੀਅਰ ਕੋਡ ਸੁਧਾਰਣ ਤੋਂ ਕਤਰਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਅਨੁਮਾਨ ਨਹੀਂ ਲਗਾ ਸਕਦੇ ਕਿ ਕੀ ਟੁਟੇਗਾ।

ਅਮਲ ਵਿੱਚ "ਰੱਖ-ਰਖਾਵਯੋਗ" ਦਾ ਕੀ ਅਰਥ ਹੈ

ਰੱਖ-ਰਖਾਵਯੋਗਤਾ ਇਕ ਢੁੱਬੀ "ਕੋਡ ਕੁਆਲਟੀ" ਸਕੋਰ ਨਹੀਂ ਹੈ। ਟੀਮਾਂ ਲਈ, ਇਹ ਆਮ ਤੌਰ ਤੇ ਮਤਲਬ ਹੈ:

• ਬਦਲਾਅ ਦੀ ਰਫ਼ਤਾਰ: ਫੀਚਰ ਜੋੜਨਾ ਜਾਂ ਬੱਗ ਫਿਕਸ ਕਰਨਾ ਬਿਨਾਂ ਪੂਰੇ ਐਪ ਦਾ ਮੈੰਟਲ ਮਾਡਲ ਬਣਾਏ।
• ਭਰੋਸਾ: ਜਾਣਨਾ ਕਿ ਜੇ ਤੁਸੀਂ ਗਲਤੀ ਕਰਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪਤਾ ਲੱਗੇਗਾ—ਆਦਰਸ਼ ਤੌਰ 'ਤੇ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ।
• ਪਾਠਯੋਗਤਾ: ਸਮਝ ਸਕਣਾ ਕਿ ਇੱਕ ਕੋਡ ਟੁਕੜਾ ਕੀ ਉਮੀਦ ਕਰਦਾ ਹੈ ਅਤੇ ਕੀ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਬਿਨਾਂ ਪੰਜ ਫਾਇਲਾਂ ਅਤੇ ਇਕ ਰਨਟਾਈਮ ਡੀਬੱਗਰ ਦੇ ਪਿੱਛੇ ਭੱਜਣ ਦੇ।

TypeScript ਕਿੱਥੇ ਫਿੱਟ ਹੁੰਦਾ ਹੈ (ਅਤੇ ਕਿੱਥੇ ਨਹੀਂ)

TypeScript JavaScript + ਟਾਈਪਸ ਹੈ। ਇਹ ਵੈੱਬ ਪਲੈਟਫਾਰਮ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ ਅਤੇ ਨਵੀਂ ਰਨਟਾਈਮ ਦੀ ਲੋੜ ਨਹੀਂ ਦਿੰਦੈ; ਇਹ ਇੱਕ ਕੰਪਾਇਲ-ਟਾਈਮ ਪਰਤ ਜੋੜਦਾ ਹੈ ਜੋ ਡੇਟਾ ਆਕਾਰ ਅਤੇ API ਕੰਟ੍ਰੈਕਟ ਨੂੰ ਵਰਣਨ ਕਰਦੀ ਹੈ।

ਫਿਰ ਵੀ, TypeScript ਜਾਦੂ ਨਹੀਂ ਹੈ। ਇਸ ਵਿੱਚ ਕੁਝ ਪਹਿਲਾਂ ਦੀ ਕੋਸ਼ਿਸ਼ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (ਟਾਈਪਸ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨੇ, ਦਿਨਾਮਿਕ ਪੈਟਰਨਾਂ ਨਾਲ ਕਈ ਵਾਰੀ friction)। ਪਰ ਇਹ ਜ਼ਿਆਦਾਤਰ ਥਾਵਾਂ 'ਤੇ ਮਦਦ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਵੱਡੇ ਫਰੰਟਐਂਡ ਦੁੱਖੀ ਹੁੰਦੇ ਹਨ: ਮੋਡੀਊਲ ਬਾਊਂਡਰੀਆਂ ਤੇ, ਸ਼ੇਅਰਡ ਯੂਟਿਲਿਟੀਜ਼ ਵਿੱਚ, ਡੇਟਾ-ਹੈਵੀ UI ਵਿੱਚ ਅਤੇ ਰੀਫੈਕਟਰਸ ਦੌਰਾਨ ਜਦੋਂ "ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਇਹ ਸੇਫ਼ ਹੈ" ਤੋਂ "ਮੈਂ ਜਾਣਦਾ ਹਾਂ ਇਹ ਸੇਫ਼ ਹੈ" ਬਣਾਉਣਾ ਲਾਜ਼ਮੀ ਹੁੰਦਾ ਹੈ।

TypeScript ਨੇ ਕੀ ਜੋੜਿਆ ਅਤੇ ਟੀਮਾਂ ਨੇ ਇਹ ਕਿਉਂ ਗ੍ਰਹਿਣ ਕੀਤਾ

TypeScript ਨੇ JavaScript ਦੀ ਥਾਂ ਨਹੀਂ ਲੀ, ਬਲਕਿ ਇਸ ਨੂੰ ਉਸ ਚੀਜ਼ ਨਾਲ ਵਧਾਇਆ ਜੋ ਟੀਮਾਂ ਕਾਫੀ ਸਮੇਂ ਤੋਂ ਚਾਹੁੰਦੀਆਂ ਸਨ: ਇਹ ਦਰਸਾਉਣ ਦਾ ਤਰੀਕਾ ਕਿ ਕੋਡ ਨੂੰ ਕੀ ਸਵੀਕਾਰ/ਵਾਪਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਬਿਨਾਂ ਭਾਸ਼ਾ ਅਤੇ ਪਾਰਸਪਰਿਕ ਪਰਿਵਾਰ ਤੋਂ ਵੱਛੜੇ।

ਛੇਤੀ ਟਾਈਮਲਾਈਨ: ਪ੍ਰਯੋਗ ਤੋਂ ਡਿਫਾਲਟ ਚੋਣ ਤੱਕ

• Mid‑2000s ਤੋਂ early 2010s: ਵਿਕਲਪਿਕ ਟਾਈਪਿੰਗ ਪ੍ਰਯੋਗ (ਜਿਵੇਂ ActionScript, Closure types, Flow) ਨੇ ਟਾਈਪ ਜਾਣਕਾਰੀ ਦੀ ਕੀਮਤ ਦਿਖਾਈ, ਪਰ ਅਪਣਾਉ ਪ੍ਰਾਥਕ ਰਹਿਆ।
• 2012: Microsoft ਨੇ TypeScript ਰਿਲੀਜ਼ ਕੀਤਾ, ਜਿਸਦਾ ਮਕਸਦ ਮਜ਼ਬੂਤ ਟੂਲਿੰਗ ਅਤੇ JavaScript ਨਾਲ ਅਨੁਕੂਲਤਾ ਸੀ।
• Late 2010s onward: ਜਿਵੇਂ SPAs ਅਤੇ ਕੰਪੋਨੈਂਟ-ਡ੍ਰੀਵਨ UIs ਮਿਆਰ ਬਣੇ, TypeScript ਦੀ ਵਰਤੋਂ ਤੇਜ਼ ਹੋਈ ਅਤੇ ਕਈ ਟੀਮਾਂ ਨੇ ਇਸ ਨੂੰ ਨਵੇਂ ਫਰੰਟਐਂਡ ਕੰਮ ਲਈ ਡਿਫਾਲਟ ਮੰਨਣਾ ਸ਼ੁਰੂ ਕੀਤਾ।

ਫਰੰਟਐਂਡ ਦੀ ਜਟਿਲਤਾ "ਸਿਰਫ JavaScript" ਤੋਂ ਬਾਹਰ ਚਲੀ ਗਈ

ਜਿਵੇਂ ਜਿਆਦਾ ਫਰੰਟਐਂਡ ਪੂਰੇ ਐਪ ਬਣ ਗਏ, ਉਹਨਾਂ ਨੇ ਹੋਰ ਹਿਲਣ-ਡੁਲਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਜੋੜ ਲੀਆਂ: ਵੱਡੇ single-page apps, ਸ਼ੇਅਰਡ ਕੰਪੋਨੈਂਟ ਲਾਇਬਰੇਰੀਆਂ, ਕਈ API ਇੰਟੇਗ੍ਰੇਸ਼ਨ, ਕੁਠੇ ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ, ਅਤੇ ਬਿਲਡ ਪਾਈਪਲਾਈਨ। ਇੱਕ ਛੋਟੇ ਕੋਡਬੇਸ ਵਿੱਚ ਤੁਸੀਂ ਸਭ ਕੁਝ ਆਪਣੇ ਦਿਮਾਗ ਵਿੱਚ ਰੱਖ ਸਕਦੇ ਹੋ। ਇਕ ਵੱਡੇ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਤੇਜ਼ ਤਰੀਕੇ ਚਾਹੀਦੇ ਹਨ ਇਹ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਲਈ: ਇਹ ਡੇਟਾ ਕਿਹੜੇ ਆਕਾਰ ਦਾ ਹੈ? ਇਹ ਫੰਕਸ਼ਨ ਕਿੰਨੇ ਵਾਰ ਕਿੱਥੇ ਕਾਲ ਹੁੰਦਾ ਹੈ? ਜੇ ਮੈਂ ਇਹ prop ਬਦਲਾਂ ਤਾਂ ਕੀ ਟੁੱਟੇਗਾ?

ਇਹ ਮੌਜੂਦਾ JavaScript ਅਤੇ npm ਵਰਕਫਲੋਜ਼ ਨਾਲ ਫਿੱਟ ਹੋਇਆ

ਟੀਮਾਂ ਨੇ TypeScript ਨੂੰ ਇਸਲਈ ਅਪਣਾਇਆ ਕਿਉਂਕਿ ਇਹ ਨਵੀਂ ਸ਼ੁਰੂਆਤ ਵਾਲਾ ਰੀ-ਰਾਈਟ ਨਹੀਂ ਮੰਗਦਾ। ਇਹ npm ਪੈਕੇਜਾਂ, ਜਾਣੇ-ਪਹਚਾਣੇ ਬੰਡਲਰਾਂ ਅਤੇ ਆਮ ਟੈਸਟ ਸੈਟਅਪਸ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਸਿੱਧਾ JavaScript ਵਿੱਚ ਕੰਪਾਇਲ ਹੁੰਦਾ ਹੈ। ਇਸ ਨਾਲ ਇਹ ਹੌਲੀ-ਹੌਲੀ ਰੀਪੋ ਜਾਂ ਫੋਲਡਰ ਅਨੁਸਾਰ ਲਿਆਂਦਾ ਜਾ ਸਕਦਾ ਹੈ।

Gradual typing: ਅਪਣਾਉਣ ਦੀ ਕੁੰਜੀ

"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) ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ

ਇਹ ਛੋਟੀਆਂ ਗਲਤੀਆਂ ਹਨ, ਪਰ ਵੱਡੇ ਕੋਡਬੇਸ ਵਿੱਚ ਇਹ ਘੰਟਿਆਂ ਦੀ ਡੀਬੱਗਿੰਗ ਅਤੇ ਟੈਸਟਿੰਗ ਚਕਰ ਖੜੇ ਕਰ ਸਕਦੀਆਂ ਹਨ।

ਕੰਪਾਇਲ-ਟਾਈਮ ਚੈਕਸ vs ਰਨਟਾਈਮ ਵਿਵਹਾਰ (ਜਿਆਦਾ ਜਾਰਗਨ ਬਿਨਾਂ)

TypeScript ਦੀਆਂ ਚੈਕਸ ਕਰਨ ਦੀਆਂ ਗਤੀਵਿਧੀਆਂ ਤਾਂ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਬਿਲਡ ਅਤੇ ਐਡੀਟ ਕਰਨ ਸਮੇਂ ਹੀ ਹੁੰਦੀਆਂ ਹਨ। ਇਹ ਤੁਹਾਨੂੰ ਬਤਾਂਦਾ ਹੈ "ਇਹ ਕਾਲ ਕੰਟ੍ਰੈਕਟ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ" ਬਿਨਾਂ ਕੁਝ ਚਲਾਏ।

ਇਹ ਉਹ ਨਹੀਂ ਕਰਦਾ ਕਿ API ਜੇ ਅਣਖ਼ਸ ਅਣੁਮਿਤ ਡੇਟਾ ਵਾਪਸ ਕਰੇ ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਰੋਕੇ। ਇਸਦੀ ਥਾਂ, ਇਹ ਤੁਹਾਨੂੰ ਉਹ ਕੋਡ ਲਿਖਣ ਵਿਚ ਮਦਦ ਕਰਦਾ ਹੈ ਜੋ ਇੱਕ ਸਪਸ਼ਟ ਆਕਾਰ ਮੰਨਦਾ ਹੈ—ਅਤੇ ਜਿੱਥੇ ਲੋੜ ਹੋਵੇ, ਉਹ ਰਨਟਾਈਮ ਵੈਧਤਾ ਵੱਲ ਧਿਆਨ ਖਿੱਚਦਾ ਹੈ।

ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਇੱਕ ਐਸਾ ਕੋਡਬੇਸ ਬਣਦਾ ਹੈ ਜਿੱਥੇ ਬਾਊਂਡਰੀਆਂ ਵੱਧ ਸਪੱਸ਼ਟ ਹੁੰਦੀਆਂ ਹਨ: ਟਾਈਪਸ ਵਿਚ ਕੰਟ੍ਰੈਕਟ ਦਸਤਾਵੇਜ਼ ਹੁੰਦੇ ਹਨ, ਵਿਵਾਦਾਂ ਨੂੰ ਪਹਿਲਾਂ ਪਤਾ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਨਵੇਂ ਯੋਗਦਾਨਕ ਕਰਨ ਵਾਲੇ ਬਿਨਾਂ ਅਨੁਮਾਨਾਂ ਦੇ ਬਦਲਾਂ ਕਰ ਸਕਦੇ ਹਨ।

ਟੂਲਿੰਗ ਜੋ ਕੋਡ ਨੂੰ ਸਮਝਣਾ ਤੇ ਤੇਜ਼ ਨੈਵੀਗੇਟ ਕਰਨਾ ਆਸਾਨ ਬਣਾਂਦੀ ਹੈ

TypeScript ਸਿਰਫ਼ ਬਿਲਡ-ਟਾਈਮ 'ਤੇ ਗਲਤੀਆਂ ਫੜਦਾ ਨਹੀਂ—ਇਹ ਤੁਹਾਡੇ ਏਡੀਟਰ ਨੂੰ ਕੋਡਬੇਸ ਦਾ ਨਕਸ਼ਾ ਬਣਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ ਰਿਪੋ ਸੈਂਕੜੇ ਕੰਪੋਨੇਟ ਅਤੇ ਯੂਟਿਲਿਟੀਜ਼ ਤੱਕ ਵਧ ਜਾਂਦੀ ਹੈ, ਰੱਖ-ਰਖਾਵਯੋਗਤਾ ਆਮ ਤੌਰ 'ਤੇ ਫੇਲ ਹੁੰਦੀ ਹੈ ਨਾ ਕਿ ਕੋਡ "ਗਲਤ" ਹੋਣ ਕਾਰਨ, ਪਰ ਇਸ ਲਈ ਕਿ ਲੋਕ ਛੋਟੀ-ਛੋਟੀ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਤੇਜ਼ੀ ਨਾਲ ਨਹੀਂ ਲੱਭ ਸਕਦੇ: ਇਹ ਫੰਕਸ਼ਨ ਕੀ ਉਮੀਦ ਕਰਦਾ ਹੈ? ਇਸ ਨੂੰ ਕਿੱਥੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ? ਕੀ ਬਦਲਣ ਤੇ ਕੀ ਤੋੜੇਗਾ?

ਆਟੋ-ਕੰਪਲੀਟ ਜੋ ਅਸਲ ਇਰਾਦੇ ਨੂੰ ਦਰਸਾਂਦਾ ਹੈ

TypeScript ਨਾਲ, ਆਟੋ-ਕੰਪਲੀਟ ਸਿਰਫ਼ ਸੁਵਿਧਾ ਨਹੀਂ ਰਹਿੰਦੀ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਫੰਕਸ਼ਨ ਕਾਲ ਕਰਦੇ ਹੋ ਜਾਂ ਇੱਕ ਕੰਪੋਨੇਟ prop ਟਾਈਪ ਕਰਦੇ ਹੋ, ਏਡੀਟਰ ਅਸਲ ਟਾਈਪਸ ਦੇ ਆਧਾਰ 'ਤੇ ਵੈਧ ਵਿਕਲਪ ਸੁਝਾਉਂਦਾ ਹੈ। ਇਸ ਦਾ ਮਤਲਬ ਘੱਟ ਖੋਜ-ਟ੍ਰਿਪਸ ਅਤੇ ਘੱਟ "ਇਹ ਫਿਰ ਕਿਵੇਂ ਕਹਿੰਦੇ ਸਨ?" ਦੇ ਪਲ।

ਤੁਹਾਨੂੰ ਇਨਲਾਈਨ ਡਾਕਯੂਮੈਂਟੇਸ਼ਨ ਵੀ ਮਿਲਦੀ ਹੈ: ਪੈਰਾਮੀਟਰ ਨਾਮ, ਰਾਖਣਯੋਗ ਬਨਾਮ ਲਾਜ਼ਮੀ ਫੀਲਡ, ਅਤੇ JSDoc ਟਿੱਪਣੀਆਂ ਸਿੱਧਾ ਤੁਹਾਡੇ ਕੰਮ ਵਾਲੇ ਸਥਾਨ 'ਤੇ ਦਿੱਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਅਮਲ ਵਿੱਚ, ਇਹ ਵਾਧੂ ਫਾਇਲਾਂ ਖੋਲ੍ਹਣ ਦੀ ਲੋੜ ਘਟਾਉਂਦਾ ਹੈ ਸਿਰਫ਼ ਸਮਝਣ ਲਈ ਕਿ ਕਿਸੇ ਟੁਕੜੇ ਕੋਡ ਨੂੰ ਕਿਵੇਂ ਵਰਤਣਾ ਹੈ।

“Go to definition” ਅਤੇ ਤੇਜ਼ ਨੈਵੀਗੇਸ਼ਨ

ਵੱਡੇ ਰਿਪੋ ਵਿੱਚ, ਬਹੁਤ ਵਾਰ ਸਮਾਂ grep, ਸਕਰੋਲਿੰਗ, ਅਤੇ ਕਈ ਟੈਬ ਖੋਲ੍ਹਣ ਵਿੱਚ ਖਰਚ ਹੁੰਦਾ ਹੈ। ਟਾਈਪ ਜਾਣਕਾਰੀ ਨੈਵੀਗੇਸ਼ਨ ਫੀਚਰਾਂ ਨੂੰ ਕਾਫ਼ੀ ਬੇਹਤਰ ਬਣਾਉਂਦੀ ਹੈ:

• Go to definition ਸਿੱਧੇ ਉਸ ਸਿੰਬਲ 'ਤੇ ਜਾਂਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਵਰਤ ਰਹੇ ਹੋ (ਕਿਸੇ ਹੋਰ ਮਿਲਦੇ ਨਾਮ ਵਾਲੇ ਫੰਕਸ਼ਨ 'ਤੇ ਨਹੀਂ)।
• Find all references ਵਧੇਰੇ ਭਰੋਸੇਯੋਗ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਏਡੀਟਰ ਜਾਣਦਾ ਹੈ ਕਿ ਕੀ ਉਸੇ ਕਿਸਮ ਜਾਂ ਸਿੰਬਲ ਵਜੋਂ ਗਿਣਿਆ ਜਾਣਾ ਹੈ।

ਇਸ ਨਾਲ ਦਿਨ-ਭਰ ਦਾ ਕੰਮ ਬਦਲ ਜਾਂਦਾ ਹੈ: ਸਿਸਟਮ ਨੂੰ ਸਿਰੇ-ਅੰਤ ਤੱਕ ਆਪਣੇ ਦਿਮਾਗ ਵਿਚ ਰੱਖਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਕੋਡ ਵਿੱਚ ਇੱਕ ਭਰੋਸੇਯੋਗ ਟਰੇਲ ਫੋਲੋ ਕਰ ਸਕਦੇ ਹੋ।

ਸਪੱਸ਼ਟ ਕੋਡ ਰਿਵਿਊਜ਼

ਟਾਈਪਸ ਭਾਵਨਾ ਰਿਵਿਊ ਦੌਰਾਨ ਦਿਖਾਉਂਦੇ ਹਨ। ਇੱਕ ਡਿਫ ਜੋ userId: string ਜੋੜਦਾ ਹੈ ਜਾਂ Promise<Result<Order, ApiError>> ਵਾਪਸ ਕਰਦਾ ਹੈ ਉਹ ਬਿਨਾਂ ਲੰਬੇ ਟਿੱਪਣੀਆਂ ਦੇ ਨਿਯਮ ਅਤੇ ਉਮੀਦਾਂ ਦੱਸ ਦਿੰਦਾ ਹੈ।

ਰਿਵਿਊਅਰ ਵੀਹੇਵਿਓਰ ਅਤੇ ਏਜ ਕੇਸਾਂ 'ਤੇ ਧਿਆਨ ਦੇ ਸਕਦੇ ਹਨ ਨਾ ਕਿ ਇਹ ਵਿਚਾਰ ਕਰਨ 'ਤੇ ਕਿ ਕਿਸੇ ਵੈਲਯੂ ਨੂੰ "ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ"।

ਏਡੀਟਰ: ਮਦਦਗਾਰ, ਲਾਜ਼ਮੀ ਨਹੀਂ

ਕਈ ਟੀਮਾਂ VS Code ਵਰਤਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਇਸ ਨੂੰ ਬਾਹਰ-ਆਉਟ-ਆਫ-ਬਾਕਸ ਮਜ਼ਬੂਤ TypeScript ਸਹਾਇਤਾ ਮਿਲਦੀ ਹੈ, ਪਰ ਕਿਸੇ ਖਾਸ ਏਡੀਟਰ ਦੀ ਲੋੜ ਨਹੀਂ। ਕੋਈ ਵੀ ਮਾਹੌਲ ਜੋ TypeScript ਨੂੰ ਸਮਝਦਾ ਹੈ ਉਹੀ ਕਿਸਮ ਦੀ ਨੈਵੀਗੇਸ਼ਨ ਅਤੇ ਹਿੰਟਿੰਗ ਫੀਚਰ ਦੇ ਸਕਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ ਇਹ ਲਾਭ ਰਸਮੀ ਬਣਾਉਣੀ ਚਾਹੁੰਦੇ ਹੋ, ਟੀਮਾਂ ਅਕਸਰ /blog/code-style-guidelines ਵਰਗੀਆਂ ਹੈਲਕੀ ਰੀਤੀਆਂ ਦੇ ਨਾਲ ਜੋੜਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਟੂਲਿੰਗ ਪ੍ਰੋਜੈਕਟ 'ਚ ਲਗਾਤਾਰ ਠੀਕ ਰਹੇ।

ਡਰ ਨਾ ਕੇ, ਭਰੋਸੇ ਨਾਲ ਰੀਫੈਕਟਰ ਕਰੋ

ਵੱਡੇ ਫਰੰਟਐਂਡ ਨੂੰ ਰੀਫੈਕਟਰ ਕਰਨਾ ਪਹਿਲਾਂ ਉਹਨੂੰ ਇੱਕ ਕਮਰੇ 'ਚ ਟ੍ਰਿਪਵਾਇਰਾਂ ਨਾਲ ਚੱਲਣ ਵਰਗਾ ਲੱਗਦਾ ਸੀ: ਤੁਸੀਂ ਇੱਕ ਇਲਾਕਾ ਸੁਧਾਰ ਸਕਦੇ ਸੀ, ਪਰ ਨਹੀਂ ਪਤਾ ਹੁੰਦਾ ਸੀ ਕਿ ਦੂਜੇ ਕੋਨੇ 'ਚ ਕੀ ਟੁਟੇਗਾ। TypeScript ਇਸ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ ਕਈ ਖਤਰਨਾਕ ਸੋਧਾਂ ਨੂੰ ਨਿਯੰਤ੍ਰਿਤ, ਯੰਤਰਕ ਕਦਮਾਂ ਵਿੱਚ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਟਾਈਪ ਬਦਲਦੇ ਹੋ, ਕੰਪਾਇਲਰ ਅਤੇ ਤੁਹਾਡਾ ਏਡੀਟਰ ਹਰ ਥਾਂ ਦਿਖਾਉਂਦੇ ਹਨ ਜੋ ਉਸ 'ਤੇ ਨਿਰਭਰ ਹੈ।

ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਰੀਫੈਕਟਰ

TypeScript ਰੀਫੈਕਟਰਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕੋਡਬੇਸ ਨੂੰ ਉਸ "ਆਕਾਰ" ਨਾਲ ਸੰਗਤ ਰਹਿਣ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਘੋਸ਼ਣਾ ਕਰਦੇ ਹੋ। ਯਾਦ ਤੇ ਆਧਾਰਿਤ ਯਾਦ ਦੇ ਬਦਲੇ, ਤੁਹਾਨੂੰ ਸਭ ਦ੍ਰਿਸ਼ਟੀ-ਸਥਾਨਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਮਿਲਦੀ ਹੈ ਜਿਨ੍ਹਾਂ 'ਤੇ ਅਸਰ ਪਏਗਾ।

ਕੁਝ ਆਮ ਉਦਾਹਰਨ:

• props ਦਾ ਨਾਮ ਬਦਲਣਾ: ਜੇ Button ਪਹਿਲਾਂ isPrimary ਲੈਂਦਾ ਸੀ ਅਤੇ ਤੁਸੀਂ ਇਸ ਨੂੰ variant ਕਰ ਦਿੰਦੇ ਹੋ, TypeScript ਹਰ ਉਸ ਕੰਪੋਨੇਟ ਨੂੰ ਝਲਕਾ ਦੇਵੇਗਾ ਜੋ ਅਜੇ ਵੀ isPrimary ਪਾਸ ਕਰਦਾ ਹੈ।
• API ਰਿਸਪਾਂਸ ਆਕਾਰ ਬਦਲਣਾ: ਜੇ ਇੱਕ endpoint ਦਾ user.name ਹੁਣ user.fullName ਬਣਦਾ ਹੈ, ਟਾਈਪ ਅਪਡੇਟ ਸਾਰੇ ਰੀਡ ਅਤੇ ਧਾਰਨਾਵਾਂ ਨੂੰ ਦੁਆਰਾ ਪ੍ਰਗਟ ਕਰੇਗਾ।
• ਫਾਇਲਾਂ/exports ਨੂੰ ਸਥਾਨਾਂਤਰਿਤ ਕਰਨਾ: ਜਦੋਂ ਤੁਸੀਂ ਮੋਡੀਊਲਾਂ ਨੂੰ ਦੁਬਾਰਾ ਸੁਤੰਤਰ ਕੀਤਾ, TypeScript ਇੰپورਟ ਪਥ ਅਤੇ ਐਕਸਪੋਰਟ ਕੀਤੇ ਮੈਂਬਰਾਂ ਨੂੰ ਸੁਨਿਸ਼ਚਿਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ IDE ਦੇ "rename symbol" ਅਤੇ "move file" ਕਾਰਵਾਈਆਂ ਨਾਲ ਮਿਲ ਕੇ।

ਐਰਰ ਜਿਹੜੇ ਸਿੱਧਾ ਦੱਸਦੇ ਹਨ ਕਿ ਕੀ ਠੀਕ ਕਰਨਾ ਹੈ

ਸਭ ਤੋਂ ਪ੍ਰਯੋਗਿਕ ਫਾਇਦਾ ਰਫ਼ਤਾਰ ਹੈ: ਇੱਕ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਟਾਈਪ ਚੈੱਕਰ ਚਲਾਉਂਦੇ ਹੋ (ਜਾਂ ਸਿਰਫ ਆਪਣੇ IDE ਨੂੰ ਵੇਖਦੇ ਹੋ) ਅਤੇ ਐਰਰਾਂ ਨੂੰ ਇੱਕ ਚੈੱਕਲਿਸਟ ਵਾਂਗ ਫੋਲੋ ਕਰਦੇ ਹੋ। ਤੁਸੀਂ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਗਾ ਰਹੇ ਕਿ ਕਿਹੜਾ ਨਿਰੀਖਣ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦਾ—ਤੁਸੀਂ ਹਰ ਉਸ ਥਾਂ ਨੂੰ ਠੀਕ ਕਰ ਰਹੇ ਹੋ ਜਿਥੇ ਕੰਪਾਇਲਰ ਦਿਖਾ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਅਨੁਕੂਲ ਨਹੀਂ।

ਸੀਮਾਵਾਂ (ਅਤੇ ਕਿਉਂ ਰਨਟਾਈਮ ਚੈਕ ਹਜੇ ਵੀ ਜ਼ਰੂਰੀ ਹਨ)

TypeScript ਹਰ ਬੱਗ ਨਹੀਂ ਫੜ ਸਕਦਾ। ਇਹ ਯਕੀਨੀ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਸਰਵਰ ਹਕੀਕਤ ਵਿੱਚ ਉਹੀ ਡੇਟਾ ਭੇਜ ਰਿਹਾ ਹੈ ਜੋ ਇਸਨੇ ਵਾਅਦਾ ਕੀਤਾ ਸੀ, ਜਾਂ ਕਿ ਕਿਸੇ ਹੈਰਾਨੀਭਰਿਆ edge case ਵਿੱਚ ਇੱਕ ਵੈਲਯੂ null ਨਹੀਂ ਹੈ। ਯੂਜ਼ਰ ਇਨਪੁੱਟ, ਨੈੱਟਵਰਕ ਰਿਸਪਾਂਸ, ਅਤੇ ਤੀਸਰੇ-ਪੱਖ ਸਕਰਿਪਟਾਂ ਲਈ ਹਜੇ ਵੀ ਰਨਟਾਈਮ ਵੈਧਤਾ ਅਤੇ ਡਿਫੈਂਸਿਵ UI ਸਟੇਟਜ਼ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।

ਜਿੱਦਾ ਜਿਤਾ TypeScript ਰੀਫੈਕਟਰਸ ਦੌਰਾਨ ਇੱਕ ਵੱਡੀ ਸ਼੍ਰੇਣੀ ਦੀ "ਗਲਤੀ-ਸਬੰਧੀ ਟੁੱਟਣ" ਘਟਾ ਦਿੰਦਾ ਹੈ, ਬਾਕੀ ਬੱਗਜ਼ ਆਮ ਤੌਰ 'ਤੇ ਅਸਲੀ ਵਿਵਹਾਰ ਬਾਰੇ ਹੁੰਦੇ ਹਨ—ਨ ਕਿ ਛੁੱਟੇ-ਪਏ rename fallout ਬਾਰੇ।

APIs ਤੋਂ ਡੇਟਾ ਨਿਬਾਢਣਾ ਹੋਰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ

API ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ ਕਈ ਫਰੰਟਐਂਡ ਬੱਗਜ਼ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ—ਨਾ ਕਿ ਟੀਮਾਂ ਦੀ ਲਾਪਰਵਾਹੀ ਕਰਕੇ, ਬਲਕਿ ਇਸ ਲਈ ਕਿ ਹਕੀਕਤੀ ਰਿਸਪਾਂਸ ਸਮੇਂ ਦੇ ਨਾਲ ਬਦਲਦੇ ਹਨ: ਫੀਲਡ ਜੋੜੇ ਜਾਂਦੇ ਹਨ, ਨਾਮ ਬਦਲਦੇ ਹਨ, ਵਿਕਲਪਿਕ ਬਣ ਜਾਂਦੇ ਹਨ, ਜਾਂ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ। TypeScript ਮਦਦ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਹਰ ਹੈਂਡਓਫ਼ 'ਤੇ ਡੇਟਾ ਦੇ "ਆਕਾਰ" ਨੂੰ ਸਪੱਸ਼ਟ ਬਣਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਐਂਡਪੌਇੰਟ ਵਿੱਚ ਬਦਲਾਅ ਜ਼ਿਆਦਾ ਸੰਭਵ ਹੈ ਕਿ ਇਕ ਕੰਪਾਇਲ-ਟਾਈਮ ਐਰਰ ਵਜੋਂ ਸਾਹਮਣੇ ਆਵੇ ਨਾ ਕਿ ਉਤਪਾਦਨ ਛੇਤੀਗੀਆਂ।

API ਰਿਸਪਾਂਸ ਨੂੰ ਟਾਈਪ ਕਰਨਾ ਡੇਟਾ ਆਕਾਰ ਸਪੱਸ਼ਟ ਕਰਦਾ ਹੈ

ਜਦੋਂ ਤੁਸੀਂ API ਰਿਸਪਾਂਸ ਨੂੰ ਟਾਈਪ ਕਰਦੇ ਹੋ (ਭਾਵroughly ਹੀ क्यों न ਹੋਵੇ), ਤੁਸੀਂ ਐਪ ਨੂੰ ਇਹ ਮਜ਼ਬੂਰ ਕਰਦੇ ਹੋ ਕਿ ਉਹ ਇਹ ਸਹਿਮਤੀ ਕਰੇ ਕਿ "ਇੱਕ user", "ਇੱਕ order", ਜਾਂ "ਇੱਕ search result" ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਦਿਸਦੇ ਹਨ। ਉਹ ਸਪੱਸ਼ਟਤਾ ਤੇਜ਼ੀ ਨਾਲ ਫੈਲਦੀ ਹੈ:

• UI ਕੰਪੋਨੈਂਟ ਜਾਣਦੇ ਹਨ ਕਿ ਉਹ ਕੀ ਰੈਂਡਰ ਕਰ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਅਨੁਮਾਨ ਦੇ
• ਡੇਟਾ-ਮੈਪਿੰਗ ਫੰਕਸ਼ਨਸ ਇਰਾਦਾ ਦਸਤਾਵੇਜ਼ ਕਰਦੇ ਹਨ (ਉਦਾਹਰਨ: ਸੈਂਟ ਨੂੰ ਕਰੰਸੀ ਵਿੱਚ ਬਦਲਨਾ)
• ਕਾਲ ਸਾਈਟਸ "ਸਰਵਰ ਨੇ ਜੋ ਦਿੱਤਾ" ਨੂੰ ਅੱਗੇ ਨਹੀਂ ਭੇਜਦੀਆਂ

ਆਮ ਪੈਟਰਨ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਐਪ ਵਿੱਚ ਡੇਟਾ ਦਾਖਲ ਹੋਣ ਵਾਲੀ ਬਾਊਂਡਰੀ (ਤੁਹਾਡਾ fetch ਲੇਅਰ) 'ਤੇ ਟਾਈਪ ਕਰਦੇ ਹੋ, ਫਿਰ ਟਾਈਪਡ ਉਬਜੈਕਟਾਂ ਨੂੰ ਅੱਗੇ ਭੇਜਦੇ ਹੋ।

ਵਿਕਲਪਿਕ ਫੀਲਡ, null, ਅਤੇ undefined: ਹਕੀਕਤ ਨਾਲ ਨਿਪਟਣਾ

ਪ੍ਰੋਡਕਸ਼ਨ API ਅਕਸਰ ਸ਼ਾਮਲ ਹਨ:

• ਵਿਕਲਪਿਕ ਪ੍ਰਾਪਰਟੀਜ਼ (ਸਿਰਫ਼ ਕੁਝ ਕੇਸਾਂ ਵਿੱਚ ਮੌਜੂਦ)
• ਨੱਲੇਬਲ ਫੀਲਡਜ਼ (null ਇਰਾਦਤاً ਵਰਤਿਆ ਜਾਂਦਾ)
• ਗੈਰ-ਮੌਜੂਦ ਫੀਲਡਜ਼ (ਬਿਲਕੁਲ ਸ਼ਾਮਲ ਨਹੀਂ)

TypeScript ਤੁਹਾਡੇ ਨੂੰ ਇਹ ਕੇਸਾਂ ਇਰਾਦੇ ਨਾਲ ਸੰਭਾਲਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ। ਜੇ user.avatarUrl ਗਾਇਬ ਹੋ ਸਕਦੀ ਹੈ, ਤਾਂ UI ਨੂੰ ਫਾਲਬੈਕ ਦੇਣਾ ਪਵੇਗਾ, ਜਾਂ ਮੈਪਿੰਗ ਲੇਅਰ ਨੂੰ ਇਸਨੂੰ ਨਾਰਮਲਾਈਜ਼ ਕਰਨਾ ਪਏਗਾ। ਇਹ "ਜੇ ਇਹ ਗਾਇਬ ਹੋਵੇ ਤਾਂ ਅਸੀਂ ਕੀ ਕਰਾਂਗੇ?" ਵੱਲ ਦੇ ਫੈਸਲੇ ਕੋਡ ਰਿਵਿਊ ਵਿੱਚ ਧਕੇ ਜਾਂਦੇ ਹਨ, ਬਜਾਏ ਕਿ ਉਹ ਘੱਟੇ-ਪਏ ਮੌਕੇ 'ਤੇ ਨਿਰਭਰ ਰਹਿਣ।

TypeScript ਟਾਈਪਸ vs ਰਨਟਾਈਮ ਵੈਧਤਾ

TypeScript ਚੈੱਕਸ build ਸਮੇਂ ਹੁੰਦੇ ਹਨ, ਪਰ API ਡੇਟਾ ਰਨਟਾਈਮ 'ਤੇ ਆਉਂਦਾ ਹੈ। ਇਸੀ ਲਈ ਰਨਟਾਈਮ ਵੈਧਤਾ ਫਾਇਦੇਮੰਦ ਹੋ ਸਕਦੀ ਹੈ—ਖਾਸ ਕਰਕੇ ਅਣ-ਭਰੋਸੇਯੋਗ ਜਾਂ ਬਦਲ ਰਹੇ APIs ਲਈ। ਇੱਕ ਪ੍ਰਾਇਗਮੈਟਿਕ ਪਹੁੰਚ:

• ਡਿਵੈਲਪਰ ਰਫਤਾਰ ਅਤੇ ਸੇਫ਼ ਰੀਫੈਕਟਰ ਲਈ TypeScript ਟਾਈਪਸ ਵਰਤੋ।
• ਜੇਕਰ ਕਰੈਕਟ_endpoint ਹਨ ਜਿਥੇ ਫੇਲਸ ਨੂੰ ਕੰਟਰੋਲ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ (ਸੁਹਾਵਣਾ ਐਰਰ ਦਿਖਾਉਣਾ, ਲਾਗ ਕਰਨਾ, ਰੀਟ੍ਰਾਈ), ਤਾਂ ਬਾਉਂਡਰੀ ਲਈ ਰਨਟਾਈਮ ਵੈਧਤਾ ਜੋੜੋ।

ਜਨਰੇਟ ਕੀਤੇ ਟਾਈਪਸ (ਵੈਕਲਪਿਕ, ਲਾਜ਼ਮੀ ਨਹੀਂ)

ਟੀਮਾਂ ਹੱਥ ਨਾਲ ਟਾਈਪ ਲਿਖ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ OpenAPI ਜਾਂ GraphQL ਸਕੀਮਾਂ ਤੋਂ ਵੀ ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ। ਜਨਰੇਸ਼ਨ ਮੈਨੂਅਲ ਡ੍ਰਿਫਟ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ, ਪਰ ਲਾਜ਼ਮੀ ਨਹੀਂ—ਕਈ ਪ੍ਰੋਜੈਕਟ ਕੁਝ ਹੱਥ-ਲਿਖੇ ਰਿਸਪਾਂਸ ਟਾਈਪਸ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਜਨਰੇਸ਼ਨ ਲਿਆਉਂਦੇ ਹਨ ਜੇ ਇਹ ਲਾਭਕਾਰੀ ਹੋਵੇ।

ਆਧੁਨਿਕ UI ਫ੍ਰੇਮਵਰਕਸ ਵਿੱਚ ਕੰਪੋਨੈਂਟ ਦੀ ਰੱਖ-ਰਖਾਵਯੋਗਤਾ

UI ਕੰਪੋਨੇਟ ਛੋਟੇ, ਦੁਹਰਾਉਣਯੋਗ ਬਿਲਡਿੰਗ ਬਲਾਕ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ—ਪਰ ਵੱਡੇ ਐਪਾਂ ਵਿੱਚ ਉਹ ਅਕਸਰ ਨਾਜ਼ੁਕ "ਮਿਨੀ-ਐਪਸ" ਬਣ ਜਾਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਦਰਜਨਾਂ props, ਸ਼ਰਤਾਂ ਅਨੁਸਾਰ rendering, ਅਤੇ ਨਰਮ ਧਾਰਨਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ। TypeScript ਉਹਨਾਂ ਧਾਰਨਾਵਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰ ਕੇ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਰੱਖ-ਰਖਾਵਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।

ਟਾਈਪਡ props ਅਤੇ state ਇੱਕ ਗਾਰਡਰੇਲ ਵਜੋਂ

ਕਿਸੇ ਵੀ ਆਧੁਨਿਕ UI ਫ੍ਰੇਮਵਰਕ 'ਚ, ਕੰਪੋਨੇਟ ਇਨਪੁੱਟ (props/inputs) ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ ਅਤੇ ਅੰਦਰੂਨੀ ਡੇਟਾ (state) ਨੂੰ ਮੈਨੇਜ ਕਰਦੇ ਹਨ। ਜਦ ਉਹ ਆਕਾਰ ਟਾਈਪਡ ਨਹੀਂ ਹੁੰਦੇ, ਤੁਸੀਂ ਗਲਤੀ ਨਾਲ ਗਲਤ ਵੈਲਯੂ ਦੇ ਸਕਦੇ ਹੋ ਅਤੇ ਇਹ ਸਿਰਫ਼ ਰਨਟਾਈਮ 'ਤੇ ਪਤਾ ਲੱਗੇ—ਕਈ ਵਾਰੀ ਸਿਰਫ਼ ਇੱਕ ਘੱਟ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਸਕਰੀਨ 'ਤੇ।

TypeScript ਨਾਲ, props ਅਤੇ state ਕੰਟ੍ਰੈਕਟ ਬਣ ਜਾਂਦੇ ਹਨ:

• ਇਕ ਕੰਪੋਨੇਟ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਡਿਕਲੇਅਰ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਉਹ ਕਿੜੇ props ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਕਿਹੜੇ ਵਿਕਲਪਿਕ ਹਨ, ਅਤੇ ਕਿਹੜੇ ਮੁੱਲ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ।
• state ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਮਾਡਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਕਿ "ਅਸੰਭਵ" ਸਥਿਤੀਆਂ ਕੰਪਾਇਲ ਹੀ ਨਹੀਂ ਹੁੰਦੀਆਂ (ਉਦਾਹਰਨ: ਇੱਕੋ ਸਮੇਂ ਡਾਟਾ ਲੋਡ ਹੋ ਰਹੀ ਅਤੇ ਸਾਦਾ ਸਮੱਗਰੀ ਦਿਖਾਉਣਾ)।

ਇਹ ਗਾਰਡਰੇਲਾਂ ਰੱਖਿਆਤਮਕ ਕੋਡ ਦੀ ਮਾਤਰਾ ਘਟਾਉਂਦੀਆਂ ਹਨ ("if (x) …") ਅਤੇ ਕੰਪੋਨੇਟ ਵਿਹੇਵਿਓਰ ਨੂੰ ਸੋਚਣਾ ਆਸਾਨ ਬਣਾਉਂਦੀਆਂ ਹਨ।

ਮਿਲਦੇ-ਜੁਲਦੇ props ਅਤੇ ਗਲਤ UI ਸਟੇਟ ਰੋਕਣਾ

ਵੱਡੇ ਕੋਡਬੇਸ ਵਿੱਚ ਆਮ ਬੱਗ ਦਾ ਸਰੋਤ 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 ਨੂੰ ਬਿਨਾਂ ਡੇਟਾ ਦਿਖਾਉਣ ਦੀ ਸਮਭਾਵਨਾ ਘੱਟ ਹੋ ਜਾਂਦੀ ਹੈ।

ਫਰੇਮਵਰਕ-ਨੈਊਟਰਲ ਸਹਾਇਤਾ: React, Vue, Angular

TypeScript ਮੁੱਖ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਇੰਟੀਗਰੇਟ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ React function components, Vue ਦੀ Composition API, ਜਾਂ Angular ਦੇ class-based ਟੈਂਪਲੇਟ ਵਰਤੋ—ਮੁੱਖ ਲਾਭ ਇੱਕੋ ਹੀ ਹੈ: ਟਾਈਪਡ ਇਨਪੁੱਟ ਅਤੇ ਭਰੋਸੇਯੋਗ ਕੰਪੋਨੇਟ ਕੰਟ੍ਰੈਕਟ ਜੋ ਟੂਲਿੰਗ ਸਮਝ ਸਕਦੀ ਹੈ।

ਸ਼ੇਅਰਡ ਕੰਪोਨੈਂਟ ਲਾਇਬਰੇਰੀਆਂ: ਟਾਈਪਸ ਉਪਭੋਗਤਾ ਦਸਤਾਵੇਜ਼ ਵਜੋਂ

ਸ਼ੇਅਰਡ ਕੰਪੋਨੈਂਟ ਲਾਇਬਰੇਰੀ ਵਿੱਚ, TypeScript ਪਰਿਭਾਸ਼ਾਵਾਂ ਹਰ ਉਪਭੋਗਤਾ ਟੀਮ ਲਈ ਤਤਕਾਲ ਦਸਤਾਵੇਜ਼ ਵਾਂਗ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। ਆਟੋ-ਕੰਪਲੀਟ props ਦਿਖਾਉਂਦਾ ਹੈ, ਇਨਲਾਈਨ ਹਿੰਟਸ ਸਪੱਸ਼ਟ ਕਰਦੀਆਂ ਹਨ ਕਿ ਉਹ ਕੀ ਕਰਦੇ ਹਨ, ਅਤੇ ਬ੍ਰੇਕਿੰਗ ਬਦਲਾਅ ਉੱਪਗ੍ਰੇਡ ਦੌਰਾਨ ਦਿਸ ਜਾਂਦੇ ਹਨ।

ਵਾਰਤ-ਪੰਨਾ 'ਤੇ ਵਿੱਖੇ ਇਕ wiki ਪੰਨਾ ਜਿਹੜਾ ਸਮੇਂ ਨਾਲ ਡ੍ਰਿਫਟ ਹੁੰਦਾ ਰਹਿੰਦਾ, ਉਸਦੀ ਥਾਂ ਸਚਾਈ ਦਾ ਸਰੋਤ ਕੰਪੋਨੇਟ ਨਾਲ ਨਾਲ ਚਲਦੀ ਹੈ—ਜਿਸ ਨਾਲ reuse ਸੁਰੱਖਿਅਤ ਹੁੰਦੀ ਹੈ ਅਤੇ ਲਾਇਬਰੇਰੀ ਮੈਨਟੇਨਰਾਂ ਉੱਤੇ ਸਹਾਰਾ ਘਟਦਾ ਹੈ।

ਵੱਡੀਆਂ ਟੀਮਾਂ ਨੂੰ ਸਥਿਰ ਕੋਡ ਰਾਹੀਂ ਇਕ ਰੂਪ 'ਤੇ ਰੱਖਣਾ

ਵੱਡੇ ਫਰੰਟਐਂਡ ਪਰੋਜੈਕਟ ਅਕਸਰ ਇਸ ਲਈ ਫੇਲ ਨਹੀਂ ਹੁੰਦੇ ਕਿ ਇੱਕ ਵਿਅੱਕਤੀ ਨੇ "ਖਰਾਬ ਕੋਡ" ਲਿਖਿਆ। ਉਹ ਤਕਲੀਫ਼ਨਾਕ ਉਸ ਵੇਲੇ ਬਣਦੇ ਹਨ ਜਦੋਂ ਕਈ ਲੋਕ ਥੋੜ੍ਹਾ-ਥੋੜ੍ਹਾ ਅਲੱਗ-ਅਲੱਗ ਚੋਣਾਂ ਕਰ ਲੈਂਦੇ ਹਨ—ਨਾਂਮਕਰਨ, ਡੇਟਾ ਆਕਾਰ, ਐਰਰ ਹੈਂਡਲਿੰਗ ਵਿੱਚ ਫਰਕ—ਜਦ ਤੱਕ ਐਪ ਅਣਫਰੰਗ ਅਤੇ ਅਣਪਹਿਲੀ ਹੋ ਜਾਂਦੀ ਹੈ।

ਬਹੁ-ਟੀਮ ਕੋਡਬੇਸ ਵਿੱਚ consistency ਹੀ ਹੀਰੋਇਕਸ ਤੋਂ ਚੰਗਾ ਹੈ

ਮੁਲਕਾਨੀ ਟੀਮਾਂ ਜਾਂ ਮਲਟੀ-ਰੀਪੋ ਮਾਹੌਲ ਵਿੱਚ, ਤੁਸੀਂ ਹਰ ਕਿਸੇ ਉੱਤੇ ਲਿਖੇ ਉਨਾਂ ਅਣ-ਲਿਖੇ ਨਿਯਮਾਂ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਰਹਿ ਸਕਦੇ। ਲੋਕ ਬਦਲਦੇ ਰਹਿੰਦੇ ਹਨ, ਠੇਕੇਦਾਰ ਆਉਂਦੇ ਹਨ, ਸੇਵਾਵਾਂ ਵਿਕਸਤ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ "ਇਥੇ ਅਸੀਂ ਇਹ ਢੰਗੋਂ ਕਰਦੇ ਹਾਂ" ਗਵਾਹੀ ਨਾਮੀ ਗਿਆਨ ਬਣ ਜਾਂਦੀ ਹੈ।

TypeScript ਉਮੀਦਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਕੇ ਮਦਦ ਕਰਦਾ ਹੈ। ਜਿਵੇਂ ਕਿ ਕਿਸੇ ਫੰਕਸ਼ਨ ਨੇ ਕੀ ਲੈਣਾ ਅਤੇ ਕੀ ਦੇਣਾ ਹੈ, ਤੁਸੀਂ ਇਹ ਟਾਈਪਸ ਵਿੱਚ ਐਨਕੋਡ ਕਰਦੇ ਹੋ ਜੋ ਹਰ ਕਾਲਰ ਨੂੰ ਪਾਲਣਾ ਕਰਨੀ ਪੈਂਦੀ ਹੈ। ਇਹ consistency ਨੂੰ ਡਿਫਾਲਟ ਬਣਾ ਦਿੰਦਾ ਹੈ ਨਾ ਕਿ ਇੱਕ ਗਾਈਡਲਾਈਨ ਜੋ ਅਸਾਨੀ ਨਾਲ ਛੱਡ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਹੈ।

ਟਾਈਪਸ ਨੂੰ ਸਾਂਝੇ ਰਿਵਾਜ ਵਜੋਂ ਵਰਤੋ (ਤੇ ਘੱਟ ਟ੍ਰਾਈਬਲ ਗਿਆਨ)

ਇੱਕ ਚੰਗਾ ਟਾਈਪ ਉਹ ਨਿਯਮ ਹੈ ਜੋ ਸਾਰੀ ਟੀਮ ਸਾਂਝੀ ਕਰਦੀ ਹੈ:

• ਇੱਕ User ਹਮੇਸ਼ਾ id: string ਹੋਵੇ, ਨਾਂ ਕਿ ਕਦੇ number।
• ਇੱਕ ਕੰਪੋਨੇਟ ਦੇ props ਸਥਿਰ ਅਤੇ ਖੋਜਯੋਗ ਹੋਣ, ਨਾ ਕਿ "ਹੋਰ ਫਾਇਲਾਂ ਨੂੰ ਦੇਖੋ ਕਿ ਇਹ ਕਿਵੇਂ ਕਹਿੰਦੇ ਹਨ"।
• API ਰਿਸਪਾਂਸ ਨੂੰ ਇੱਕ ਵਾਰੀ ਵੈਧ/ਨਾਰਮਲਾਈਜ਼ ਕੀਤਾ ਜਾਵੇ, ਅਤੇ ਬਾਕੀ UI ਇੱਕ ਪੂਰਨ ਆਕਾਰ ਨਾਲ ਕੰਮ ਕਰੇ।

ਜਦੋਂ ਇਹ ਨਿਯਮ ਟਾਈਪਸ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ, ਨਵੇਂ ਸਾਥੀ ਕੋਡ ਪੜ੍ਹ ਕੇ ਅਤੇ IDE hintਾਂ ਤੋਂ ਸਿੱਖ ਸਕਦੇ ਹਨ, Slack 'ਤੇ ਪੁੱਛਣ ਜਾਂ ਕਿਸੇ ਸੀਨੀਅਰ ਇੰਜੀਨੀਅਰ ਨੂੰ ਧੂੰਡਣ ਦੀ ਲੋੜ ਘਟ ਜਾਂਦੀ ਹੈ।

ਲਿੰਟਿੰਗ ਅਤੇ ਫਾਰਮੇਟਿੰਗ ਨਾਲ TypeScript ਨੂੰ ਜੋੜੋ

TypeScript ਅਤੇ ਲਿੰਟਰ ਵੱਖ-ਵੱਖ ਸਮੱਸਿਆਵਾਂ ਹਲ ਕਰਦੇ ਹਨ:

• TypeScript ਫਾਈਲ ਬਾਊਂਡਰੀਆਂ 'ਤੇ ਸਹੀਤਾ ਚੈੱਕ ਕਰਦਾ ਹੈ (ਉਦਾਹਰਨ: ਫੰਕਸ਼ਨ ਨੂੰ ਸਹੀ ਡੇਟਾ ਨਾਲ ਕਾਲ ਕਰਨਾ)
• Linting (ESLint) ਕੋਡ ਕੁਆਲਟੀ ਅਤੇ ਸ਼ੈਲੀ ਨਿਯਮ ਲਾਗੂ ਕਰਦਾ ਹੈ (ਉਦਾਹਰਨ: unused vars ਨਾ ਹੋਣ)
• Formatting (Prettier) ਕੋਡ ਦੀ ਲੁੱਕ-ਫੀਲ ਅੱਖਰਬੰਦ ਕਰਦਾ ਹੈ (ਉਦਾਹਰਨ: ਲਾਈਨ ਬ੍ਰੇਕ, ਕੋਟੇਸ)

ਇਕਠੇ ਵਰਤਣ ਨਾਲ PRs ਵਿਹੇਵਿਓਰ ਅਤੇ ਡਿਜ਼ਾਈਨ ਬਾਰੇ ਹੋਣਗੇ—ਨ ਕਿ ਬਾਇਕਸ਼ੇਡਿੰਗ ਬਾਰੇ।

ਟਾਈਪਸ ਪੜ੍ਹਨਯੋਗ ਰੱਖੋ (ਚਤੁਰਾਈ ਤੋਂ ਬਚੋ)

ਟਾਈਪਸ ਉਤੇ-ਅਧਿਕ ਹੋ ਸਕਦੀਆਂ ਹਨ ਜੇ ਉਹ ਬਹੁਤ ਜਟਿਲ ਬਣ ਜਾਂਦੀਆਂ ਹਨ। ਕੁਝ ਪ੍ਰਾਇਗਮੈਟਿਕ ਨਿਯਮ:

• ਗਹਿਰੇ nested generics ਦੀ ਥਾਂ ਸਧਾਰਣ, ਨਾਮਵਾਲੇ ਟਾਈਪਸ ਵਰਤੋਂ (type OrderStatus = ...)।
• ਉਹ ਡੇਟਾ ਮਾਡਲ ਕਰੋ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਵਰਤਦੇ ਹੋ, ਨਾ ਕਿ ਹਰ ਸੰਭਵੀ ਆਕਾਰ।
• unknown + narrowing ਨੂੰ ਨਿਯਤ ਤੌਰ ਤੇ ਵਰਤੋਂ ਬਜਾਏ any ਵੰਡਣ ਦੇ।

ਪੜ੍ਹਨਯੋਗ ਟਾਈਪਸ ਚੰਗੇ ਦਸਤਾਵੇਜ਼ ਵਾਂਗ ਹਨ: ਸਟੀਕ, ਅਪ-ਟੂ-ਡੇਟ, ਅਤੇ ਅਸਾਨ ਫੋਲੋ ਕਰਨ ਯੋਗ।

JavaScript ਤੋਂ TypeScript ਲਈ ਵਿਹੇਵਿਕ ਮਾਈਗ੍ਰੇਸ਼ਨ ਰਾਹ

ਵੱਡੇ ਫਰੰਟਐਂਡ ਨੂੰ JavaScript ਤੋਂ TypeScript ਵਿੱਚ ਮਾਈਗ੍ਰੇਟ ਕਰਨਾ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਛੋਟੇ, ਵਾਪਸੀਯੋਗ ਕਦਮਾਂ ਵਜੋਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ—ਨ ਕਿ ਇਕ ਵਾਰ ਦਾ ਰੀ-ਰਾਈਟ। ਮਕਸਦ ਸੁਰੱਖਿਆ ਅਤੇ ਸਪੱਸ਼ਟਤਾ ਵਧਾਉਣਾ ਹੈ ਬਿਨਾਂ ਪ੍ਰੋਡਕਟ ਕੰਮ ਨੂੰ ਰੋਕੇ。

ਅਮਲ ਵਿੱਚ ਆਨ ਵਾਲੇ ਤਰੀਕੇ ਜੋ ਅਸਲ ਵਿੱਚ ਲਾਗੂ ਹੁੰਦੇ ਹਨ

1) "ਨਵੀਆਂ ਫਾਇਲਾਂ ਪਹਿਲਾਂ"
ਸਾਰਾ ਨਵਾਂ ਕੋਡ TypeScript ਵਿੱਚ ਲਿਖੋ ਅਤੇ ਮੌਜੂਦਾ ਮੌਡੀਊਲਾਂ ਨੂੰ ਛੱਡ ਦਿਓ। ਇਹ JS ਸਤਹ ਨੂੰ ਵਧਣ ਤੋਂ ਰੋਕਦਾ ਹੈ ਅਤੇ ਟੀਮ ਨੂੰ ਹੌਲੀ-ਹੌਲੀ ਸਿੱਖਣ ਦਿੰਦਾ ਹੈ।

2) ਮੋਡੀਊਲ-ਬਾਇ-ਮੋਡੀਊਲ ਰੂਪਾਂਤਰ
ਇੱਕ ਬਾਊਂਡਰੀ ਚੁਣੋ (ਇੱਕ ਫੀਚਰ ਫੋਲਡਰ, ਇੱਕ ਸ਼ੇਅਰਡ ਯੂਟਿਲਿਟੀ ਪੈਕੇਜ, ਜਾਂ UI ਕੰਪੋਨੇਟ ਲਾਇਬਰੇਰੀ) ਅਤੇ ਇਸਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਦਲੋ। ਜਿਹੜੇ ਮੋਡੀਊਲ ਵਿਆਪਕ ਰੂਪ ਵਿੱਚ ਵਰਤੇ ਜਾਂ ਵਾਰ-ਵਾਰ ਬਦਲੇ ਜਾਂਦੇ ਹਨ ਉਹਨਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ–ਇਹ ਸਭ ਤੋਂ ਵੱਡਾ ਲਾਭ ਦਿੰਦੇ ਹਨ।

3) ਸਖਤੀ ਦੇ ਕਦਮ
ਫਾਇਲ ਐਕਸਟੇੰਸ਼ਨ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਵੀ, ਤੁਸੀਂ ਪੜਾਅ-ਪੜਾਅ ਕਰਕੇ ਮਜ਼ਬੂਤ ਗਾਰੰਟੀਆਂ ਵੱਲ ਵਧ ਸਕਦੇ ਹੋ। ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਪਹਿਲਾਂ ਸੁਖਦਾਇਕ ਰਹਿੰਦੀਆਂ ਹਨ ਅਤੇ ਸਮੇਂ ਨਾਲ ਨਿਯਮ ਸਖਤ ਕਰਦੀਆਂ ਹਨ ਜਦੋਂ ਟਾਈਪਸ ਮੁਕੰਮਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।

ਮੁੱਖ ਸੰਰਚਨਾਤਮਕ ਸੰਕਲਪ (tsconfig)

ਤੁਹਾਡਾ tsconfig.json ਮਾਈਗ੍ਰੇਸ਼ਨ ਦਾ ਸਟੀਅਰਿੰਗ ਹਵਾਲਾ ਹੈ। ਇੱਕ ਪ੍ਰਾਇਗਮੈਟਿਕ ਪੈਟਰਨ:

• ਸ਼ੁਰੂਆਤ ਵਿੱਚ TypeScript ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਕੰਪਾਇਲ ਕਰਨ ਦਿਓ ਕਿ build ਟੁੱਟੇ ਨਾ।
• strict mode ਬਾਅਦ ਵਿੱਚ ਸਮੇਤੋ (ਜਾਂ ਇੱਕ-ਇਕ strict ਫਲੈਗ ਨੂੰ ਚਾਲੂ ਕਰੋ)।
• ਇੰਕ੍ਰੀਮੈਂਟਲ ਟਾਈਟਨਿੰਗ: ਇੱਕ ਫੋਲਡਰ/ਪੈਕੇਜ ਲਈ ਸਪਸ਼ਟ ਮਾਪਦੰਡ ਰੱਖੋ ਕਿ ਕਦੋਂ ਉਹ "graduate" ਕਰ ਸਕਦਾ ਹੈ।

ਇਸ ਨਾਲ ਸ਼ੁਰੂਆਤੀ ਬਹੁਤ ਸਾਰੀਆਂ ਟਾਈਪ ਐਰਰਾਂ ਦਾ ਬੋਝ ਨਹੀਂ ਬਣਦਾ ਅਤੇ ਟੀਮ ਫਰਮਾਇਆ ਜਾਂਦਾ ਹੈ ਕਿ ਉਹ ਉਨ੍ਹਾਂ ਚੀਜ਼ਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਅਸਲ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਹਨ।

ਤੀਸਰੇ-ਪੱਖ ਲਾਇਬਰੇਰੀਆਂ ਅਤੇ ਗਾਇਬ ਟਾਈਪਸ

ਹਰ dependency ਵਧੀਆ typings ਨਾਲ ਨਹੀਂ ਆਉਂਦੀ। ਆਮ ਵਿਕਲਪ:

• community types ਇੰਸਟਾਲ ਕਰੋ (ਅਕਸਰ @types/... ਰਾਹੀਂ)
• ਜੋ ਕੁਝ ਤੁਸੀਂ ਇਸ਼ਤੇਮਾਲ ਕਰਦੇ ਹੋ ਉਸ ਲਈ ਘੱਟੋ-ਘੱਟ ਲੋਕਲ ਡਿਕਲੇਰੇਸ਼ਨਾਂ ਜੋੜੋ
• untyped ਬਾਊਂਡਰੀਆਂ ਨੂੰ ਅਲੱਗ ਕਰੋ ਅਤੇ any ਨੂੰ ਇੱਕ ਛੋਟੇ adapter ਲੇਅਰ ਤੱਕ ਸੀਮਤ ਰੱਖੋ

ਨਿਯਮ: ਪੂਰੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਲਈ ਪੂਰਨ ਟਾਈਪਸ ਦੀ ਉਡੀਕ ਨਾ ਕਰੋ—ਇੱਕ ਸੁਰੱਖਿਅਤ ਬਾਊਂਡਰੀ ਬਣਾਓ ਅਤੇ ਅੱਗੇ ਵਧੋ।

ਡਿਲਿਵਰੀ ਰੁਕੀ ਨਾ ਰਹਿ ਜਾਵੇ

ਛੋਟੇ mile-stones ਸੈੱਟ ਕਰੋ (ਉਦਾਹਰਨ: "ਸ਼ੇਅਰਡ ਯੂਟਿਲਿਟੀਜ਼ ਕਨਵਰਟ ਕਰੋ", "API ਕਲਾਇੰਟ ਨੂੰ ਟਾਈਪ ਕਰੋ", "/components ਵਿੱਚ strict") ਅਤੇ ਸਧਾਰਣ ਟੀਮ ਨਿਯਮ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: ਕਿੱਥੇ TypeScript ਲਾਜ਼ਮੀ ਹੈ, ਨਵੇਂ API ਕਿਵੇਂ ਟਾਈਪ ਕਰਨੇ, ਅਤੇ any ਕਦੋਂ ਮਨਜ਼ੂਰ ਹੈ। ਇਹ ਸਪਸ਼ਟਤਾ ਪ੍ਰਗਤੀ ਨੂੰ ਜਾਰੀ ਰੱਖਦੀ ਹੈ ਜਦੋਂ ਕਿ ਨਵਾਂ ਫੀਚਰ ਵੀ ਆ ਰਹੇ ਹੁੰਦੇ ਹਨ।

ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਆਪਣੇ ਬਣਾਉਣ ਅਤੇ ਸ਼ਿਪਿੰਗ ਤਰੀਕੇ ਨੂੰ ਵੀ ਆਧੁਨਿਕ ਕਰ ਰਹੀ ਹੈ, ਤਾਂ ਇੱਕ ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਤੁਹਾਡੀ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ chat-ਆਧਾਰਤ ਵਰਕਫਲੋ ਰਾਹੀਂ React + TypeScript ਫਰੰਟਐਂਡ ਅਤੇ Go + PostgreSQL ਬੈਕਐਂਡ scaffold ਕਰ ਸਕਦੇ ਹੋ, "planning mode" ਵਿੱਚ ਇਟਰੈਟ ਕਰ ਸਕਦੇ ਹੋ ਪਹਿਲਾਂ ਕੋਡ ਜਨਰੇਟ ਕਰਨ ਤੋਂ, ਅਤੇ ਜਦੋਂ ਤਿਆਰ ਹੋਵੋ ਤਦ ਸਰੋਤ ਕੋਡ export ਕਰ ਸਕਦੇ ਹੋ। ਠੀਕ ਤਰ੍ਹਾਂ ਵਰਤਿਆ ਜਾਵੇ ਤਾਂ ਇਹ TypeScript ਦਾ ਲਕਸ਼ਣ ਪੂਰਾ ਕਰਨ ਵਿੱਚ ਇਕ ਸਹਾਇਕ ਟੂਲ ਹੋ ਸਕਦਾ ਹੈ: ਅਣਿਸ਼ਚਿਤਤਾ ਘਟਾਉਣਾ ਅਤੇ ਡਿਲਿਵਰੀ ਰਫ਼ਤਾਰ ਨੁਰੂ ਮਹਫ਼ੂਜ਼ ਰੱਖਣਾ।

ਟਰੇਡ-ਆਫ਼ ਅਤੇ ਆਮ ਗਲਤ ਫਹਿਮੀਆਂ

TypeScript ਵੱਡੇ ਫਰੰਟਐਂਡਸ ਨੂੰ ਬਦਲਣਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ, ਪਰ ਇਹ ਮੁਫ਼ਤ ਉੱਨਤੀ ਨਹੀਂ ਹੈ। ਟੀਮਾਂ ਨੂੰ ਅਕਸਰ ਖ਼ਰਚ ਅਪਣਾਊਣ ਅਤੇ ਭਾਰੀ ਉਤਪਾਦ-ਬਦਲਾਅ ਦੇ ਸਮੇਂ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।

ਆਮ friction ਬਿੰਦੂ

ਸਿੱਖਣ ਦੀ ਝੁੰਝਲ ਅਤੇ ਜਨਰਿਕਸ, ਯੂਨੀਅਨਜ਼, ਅਤੇ narrowing ਨਾਲ ਨਵੇਂ ਡਿਵੈਲਪਰਾਂ ਲਈ ਕਰੜਾ ਹੋ ਸਕਦਾ ਹੈ। ਸ਼ੁਰੂ ਵਿੱਚ ਇਹ ਲੱਗ ਸਕਦਾ ਹੈ ਕਿ ਤੁਸੀਂ "ਕੰਪਾਇਲਰ ਨਾਲ ਲੜ ਰਹੇ ਹੋ", ਅਤੇ ਟਾਈਪ ਐਰਰ ਉਸ ਵੇਲੇ ਆਉਂਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣਾ ਚਾਹੁੰਦੇ ਹੋ।

ਤੁਸੀਂ(build) ਸੰਰਚਨਾ ਵੀ ਵੱਧਾਉਣਗੇ। ਟਾਈਪ-ਚੈਕਿੰਗ, ਟ੍ਰਾਂਸਪਾਇਲੇਸ਼ਨ, ਅਤੇ ਕਈ ਵਾਰੀ ਵੱਖਰੇ configs ਟੂਲਿੰਗ (ਬੰਡਲਰ, ਟੈਸਟ) ਲਈ ਹੋਰ ਚਲਦੇ-ਫਿਰਦੇ ਹਿੱਸੇ ਲਿਆਉਂਦੇ ਹਨ। CI धीਮਾ ਹੋ ਸਕਦਾ ਹੈ ਜੇ ਟਾਈਪ ਚੈਕਿੰਗ ਨੂੰ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਟਿਊਨ ਨਾ ਕੀਤਾ ਜਾਵੇ।

ਕਿੱਥੇ ਟਾਈਪਸ ਤੁਹਾਨੂੰ ਸੁਸਤੀ ਕਰ ਸਕਦੇ ਹਨ

TypeScript ਉਸ ਵੇਲੇ ਡਰੇਗੀ ਬਣ ਸਕਦਾ ਹੈ ਜਦੋਂ ਟੀਮ ਹਰ ਚੀਜ਼ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ-ਟਾਈਪ ਕਰ ਦੇਵੇ। ਛੋਟੇ-ਅਵਧੀ ਕੋਡ ਜਾਂ ਆੰਤਰੀਕ ਸਕ੍ਰਿਪਟਾਂ ਲਈ ਬਹੁਤ ਵਿਸਤਾਰਿਤ ਟਾਈਪਸ ਲਿਖਣਾ ਅਕਸਰ ਜਿਆਦਾ ਖ਼ਰਚਲਾ ਹੁੰਦਾ ਹੈ।

ਦੂਜਾ ਆਮ ਸੁਸਤ ਕਰਨ ਵਾਲਾ ਕਾਰਕ unclear generics ਹਨ। ਜੇ ਕਿਸੇ ਯੂਟਿਲਿਟੀ ਦਾ ਟਾਈਪ ਸਿਗਨੇਚਰ ਬਹੁਤ ਚਤੁਰ ਹੈ, ਅਗਲਾ ਵਿਅਕਤੀ ਇਸਨੂੰ ਨਹੀਂ ਸਮਝ ਸਕਦਾ, autocomplete noisy ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਸਧਾਰਣ ਬਦਲਾਵ "ਟਾਈਪ ਪਜ਼ਲ ਸਾਲਵਿੰਗ" ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਹਨ। ਇਹ ਰੱਖ-ਰਖਾਵਯੋਗਤਾ ਦਾ ਮੁੱਦਾ ਹੈ, ਲਾਭ ਨਹੀਂ।

ਰਫ਼ਤਾਰ ਅਤੇ ਸੁਰੱਖਿਆ ਵਿੱਚ ਸੰਤੁਲਨ

ਵਿਹੇ ਹਨ pragmatic ਗਾਈਡਲਾਈਨ:

• ਪੂਰਨ ਟਾਈਪਸ ਤੋਂ ਵਧੇਰੇ ਸਧਾਰਣ, ਪੜ੍ਹਨਯੋਗ ਟਾਈਪਸ ਨੂੰ ਤਰਜੀਹ ਦਿਓ।
• ਅਣ-ਭਰੋਸੇਯੋਗ ਡੇਟਾ ਲਈ unknown (ਨੈਰੋਇੰਗ ਨਾਲ) ਵਰਤੋ, any ਨਹੀਂ।
• escape hatches (any, @ts-expect-error) ਨੂੰ ਬਚਾਵ-ਹੱਥਾ ਵਜੋਂ ਘੱਟ ਵਰਤੋ ਅਤੇ ਟਿੱਪਣੀ ਦੇ ਕੇ ਦੱਸੋ ਕਿ ਕਿਉਂ ਅਤੇ ਕਦੋਂ ਹਟਾਉਣੀ ਹੈ।

TypeScript ਕੀ ਨਹੀਂ ਸਲਵ ਕਰਦਾ

ਆਮ ਗਲਤ ਫਹਿਮੀ: "TypeScript ਹਰੇਕ ਬੱਗ ਰੋਕਦਾ ਹੈ।" ਇਹ ਕੁਝ ਕਿਸਮਾਂ ਦੀਆਂ ਗਲਤੀਆਂ ਰੋਕਦਾ ਹੈ, ਮੁੱਖ ਤੌਰ 'ਤੇ ਉਹ ਜਿਹੜੀਆਂ ਕੋਡ ਵਿੱਚ ਕੀਤੇ ਗਏ ਅਨੁਮਾਨਾਂ ਨਾਲ ਸੰਬੰਧਤ ਹਨ। ਇਹ runtime ਫੇਲਿਆਂ (ਨੈੱਟਵਰਕ timeout, invalid API payloads, ਜਾਂ JSON.parse ਦਾ ਫੈਂਕਣਾ) ਨੂੰ ਰੋਕਦਾ ਨਹੀਂ।

ਇਹ ਆਪਣੇ ਆਪ runtime ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਸੁਧਾਰ ਨਹੀਂ ਲਿਆਉਂਦਾ। TypeScript ਟਾਈਪਸ build ਸਮੇਂ ਹਟ ਜਾਂਦੇ ਹਨ; ਕੋਈ ਵੀ ਤੇਜ਼ੀ ਜੋ ਤੁਸੀਂ ਮਹਿਸੂਸ ਕਰੋਗੇ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਬਿਹਤਰ ਰੀਫੈਕਟਰਿੰਗ ਅਤੇ ਘੱਟ ਰਿਗ੍ਰੈਸ਼ਨ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਨਾ ਕਿ ਤੇਜ਼ ਚਲਾਨ ਤੋਂ।

TypeScript ਫਰੰਟਐਂਡ ਲਈ ਰੱਖ-ਰਖਾਵਯੋਗਤਾ ਚੈੱਕਲਿਸਟ

ਵੱਡੇ TypeScript ਫਰੰਟਐਂਡ ਸਤਿੱਠੇ ਰਿਹਾਂਗੇ ਜਦੋਂ ਟੀਮਜ਼ ਟਾਈਪਸ ਨੂੰ ਉਤਪਾਦ ਦਾ ਹਿੱਸਾ ਸਮਝਦੀਆਂ ਹਨ—ਨਾ ਕਿ ਕੋਈ ਵਿਕਲਪਿਕ ਪਰਤ ਜੋ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਛਿੜਕ ਦਿੰਦੇ ਹੋ। ਇਹ ਚੈੱਕਲਿਸਟ ਵਰਤੋ ਦਿਖਣ ਲਈ ਕਿ ਕੀ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਕੀ ਆਹਿਸਤਾ-ਆਹਿਸਤਾ friction ਜੋੜ ਰਿਹਾ ਹੈ।

ਚੈੱਕਲਿਸਟ: ਕੀ ਸਥਿਰ ਕਰਨਾ ਹੈ

• Strictness level: "strict": true ਵੇਖੋ (ਜਾਂ ਇਸ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਦਸਤਾਵੇਜ਼ੀ ਰੂਪ)। ਜੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ strict ਵਿਕਲਪਿਕਾਂ ਨੂੰ ਕ੍ਰਮਿਕ ਤੌਰ 'ਤੇ ਚਾਲੂ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ noImplicitAny, ਫਿਰ strictNullChecks)।
• Shared types: API/domain ਟਾਈਪਸ ਨੂੰ ਇੱਕ ਸਾਂਝੀ ਥਾਂ ਵਿੱਚ ਰੱਖੋ (ਅਕਸਰ /types ਜਾਂ /domain ਫੋਲਡਰ) ਅਤੇ "ਇੱਕ ਸਰੋਤ ਸਚ" ਬਣਾਓ—OpenAPI/GraphQL ਤੋਂ ਜਨਰੇਟ ਕੀਤੇ ਟਾਈਪਸ ਹੋਰ ਵੀ ਵਧੀਆ ਹਨ।
• Review practices: ਕੋਡ ਰਿਵਿਊ ਦੌਰਾਨ "type-driven design" (ਸਪਸ਼ਟ ਇਨਪੁੱਟ/ਆਉਟਪੁੱਟ) ਲਈ ਚੈਕ ਕਰੋ ਅਤੇ ਉਹ ਪੇਚ ਦੱਸ਼ਾਂ ਜਿਨ੍ਹਾਂ ਨਾਲ ਅਣਪੱਕੇਪਨ ਆ ਰਿਹਾ ਹੈ ਨੂੰ ਰੱਦ ਕਰੋ।

ਸਮੇਂ ਨਾਲ ਲਾਭ ਦਿੰਦੀਆਂ ਪੈਟਰਨਜ਼

ਛੋਟੇ ਮੋਡੀਊਲਾਂ ਅਤੇ ਸਪਸ਼ਟ ਬਾਊਂਡਰੀਆਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਜੇ ਇੱਕ ਫਾਇਲ ਵਿੱਚ ਡਾਟਾ ਫੇਚਿੰਗ, ਟ੍ਰਾਂਸਫਾਰਮੇਸ਼ਨ, ਅਤੇ UI ਲਾਜਿਕ ਸਭ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਬਦਲਣਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ।

ਮਾਨਾਰਥਕ ਟਾਈਪਸ ਵਰਤੋ ਬਦਲੇ ਚਤੁਰਾਈ ਦੇ: ਉਦਾਹਰਨ ਲਈ, UserId ਅਤੇ OrderId ਵਰਗੀ ਵਿਉਂਤਾਵਾਂ ਗਲਤ ਵਰਤੋਂ ਤੋਂ ਬਚਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ narrowing unions ("loading" | "ready" | "error") state machines ਨੂੰ ਪੜ੍ਹਨਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।

ਜਲਦੀ ਠੀਕ ਕਰਨ ਵਾਲੇ ਰੈਡ ਫਲੈਗ

• any ਦਾ ਫੈਲਣਾ ਖ਼ਾਸ ਕਰਕੇ ਸ਼ੇਅਰਡ ਯੂਟਿਲਿਟੀਜ਼ ਵਿੱਚ।
• ਟਾਈਪ ਐਸਰਸ਼ਨਜ਼ ਬਹੁਤ ਜ਼ਿਆਦਾ (as Something) ਜੋ ਇੱਥੇ-ਉੱਥੇ ਐਰਰਾਂ ਨੂੰ ਚੁੱਪ ਕਰਦੀਆਂ ਹਨ ਬਜਾਏ ਹਕੀਕਤ ਦਰਸਾਉਣ ਦੇ।
• ਡੁਪਲੀਕੇਟਡ ਡੇਟਾ ਮਾਡਲ (ਥੋੜ੍ਹੇ-ਬਹੁਤ ਵੱਖਰੇ User ਆਕਾਰ ਵੱਖ-ਵੱਖ ਫੋਲਡਰਾਂ ਵਿੱਚ), ਜਿਸ ਨਾਲ ਡ੍ਰਿਫਟ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦਾ ਹੈ।

ਕਦੋਂ TypeScript ਲਾਭਕਾਰਕ ਹੈ (ਅਤੇ ਕਦੋਂ JS ਠੀਕ ਹੈ)

TypeScript ਆਮ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ ਬਹੁ-ਆਦਮੀ ਟੀਮਾਂ, ਲੰਬੇ ਸਮੇਂ ਦੇ ਉਤਪਾਦਾਂ, ਅਤੇ ਐਪਾਂ ਲਈ ਜੋ ਬਹੁ-ਵਾਰ ਰੀਫੈਕਟਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਸਧਾਰਨ JavaScript ਚੰਗਾ ਰਹਿੰਦਾ ਹੈ ਛੋਟੇ ਪ੍ਰੋਟੋਟਾਈਪ, ਛੋਟੇ-ਅਵਧੀ ਮਾਰਕੇਟਿੰਗ ਸਾਈਟ, ਜਾਂ ਬਹੁਤ ਸਥਿਰ ਕੋਡ ਲਈ ਜਿੱਥੇ ਟੀਮ ਘੱਟ ਟੂਲਿੰਗ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦੀ ਹੈ—ਬਸ ਤੁਸੀਂ ਟਰੇਡ-ਆਫਜ਼ ਲਈ ਇਮਾਨਦਾਰ ਰਹੋ ਅਤੇ ਸਕੋਪ ਨੂੰ ਸੀਮਿਤ ਰੱਖੋ।