#1 คิดในแบบของ {เซต(Set)}
#2 ทำความเข้าใจประเภทที่ประกาศไว้และประเภทที่ถูกทำให้แคบลง (narrowed)
#3 ใช้ discriminated union แทน optional field
#4 ใช้ type predicate เพื่อหลีกเลี่ยง type assertion
#5 ควบคุมการกระจายของ union type
#6 ตรวจสอบเคสที่ไม่ได้ถูกจัดการตอนคอมไพล์ด้วยการตรวจเช็กอย่างเข้มงวด
#7 ใช้ type แทน interface
#8 ในสถานการณ์ที่เหมาะสม ให้ใช้ tuple แทน array
#9 ควบคุมให้ประเภทที่อนุมานได้มีความทั่วไปหรือเฉพาะเจาะจงตามต้องการ
#10 ใช้ infer เพื่อสร้างพารามิเตอร์ประเภท generic เพิ่มเติม
#11 ใช้ความคิดสร้างสรรค์กับการจัดการประเภทเพื่อคงความเป็น DRY
บทสรุป
6 ความคิดเห็น
ข้อ 7 ดูเหมือนจะเขียนจากมุมมองของ React นะครับ
สำหรับผม ผมชอบ
Interfaceมากกว่าTypeเพราะเป็นไวยากรณ์ที่มีในภาษาอื่นด้วยผมก็เหมือนกันครับ จำได้ว่าเมื่อก่อนใน TypeScript Handbook ก็มีคำแนะนำให้พยายามใช้ interface เป็นอันดับแรกเท่าที่ทำได้ด้วย
นี่คือเนื้อหานี้ครับ
ทุกข้อก็ดีหมด แต่ข้อ 7 ที่บอกให้ใช้
typeมากกว่าinterfaceนี่จำเป็นต้องพูดถึงด้วยเหรอ? คงเรียกว่าเป็นทิปไม่ได้ เพราะมีกรณีที่interfaceแสดงความหมายได้ดีกว่า เช่นinterface Foo {(b: number): A; (): B}ไม่ได้จะสนับสนุน
typeนะ แต่ยังไม่ค่อยเข้าใจตัวอย่างที่ว่ามีความสามารถในการแสดงออกที่ดีกว่า ตัวอย่างประโยคนี้ก็สามารถเขียนแบบเดียวกันด้วยtypeได้ไม่ใช่หรือครับ?interface Foo {(b: number): A; (): B}
type Foo = {(b: number): A; (): B}
ในหนังสือ Effective TypeScript มีส่วนที่สรุปไว้ว่า ระหว่าง type กับ interface ควรใช้อะไร ผมเลยขอยกมาอ้างอิงครับ。
ถ้าเป็นโปรเจกต์ที่ยังไม่มีการกำหนดสไตล์ที่ชัดเจน ก็ควรคิดเผื่อไว้ว่ามีโอกาสที่จะต้องมีการเสริมขยายในอนาคตหรือไม่ ถ้าคุณต้องเขียน type declaration ให้กับ API ใด API หนึ่ง การใช้ interface จะเหมาะกว่า เพราะเมื่อ API เปลี่ยน ผู้ใช้สามารถรวม field ใหม่ผ่าน interface ได้ จึงมีประโยชน์มากกว่า แต่ในทางกลับกัน การเกิด declaration merging กับ type ที่ใช้ภายในโปรเจกต์ถือเป็นการออกแบบที่ไม่เหมาะสม ดังนั้นในกรณีนี้ควรใช้ type ครับ