ใส่ type ให้ฟังก์ชัน — parameter, return, arrow function

tsc  Version 7.0.2
node v24.14.0

ฟังก์ชันคืออะไร ในภาษาที่ไม่ต้องมีศัพท์

ฟังก์ชันคือเครื่องหนึ่งเครื่อง ที่คุณป้อนของเข้าไปแล้วมันคายของออกมา
ตอนเขียน JavaScript ธรรมดา คุณบอกได้แค่ว่า "เครื่องนี้ชื่อ sum และรับของสองชิ้น" แต่บอกไม่ได้ว่าของที่รับต้องเป็นอะไร และของที่คายออกมาจะเป็นอะไร

TypeScript เพิ่มที่ว่างสามจุดให้คุณเขียนสิ่งนี้ลงไป — และนี่คือทั้งหมดที่สไลด์หน้า 26 วาดลูกศรชี้:

function sum(num1: number, num2: number): number {
  return num1 + num2;
}
//            ↑ ชนิดของ       ↑ ชนิดของ      ↑ ชนิดของ
//              ของเข้าชิ้นที่ 1  ของเข้าชิ้นที่ 2   ของที่คายออกมา

เขียนสามจุดนี้เสร็จ คุณได้อะไรกลับมาทันที: คนอื่นอ่านบรรทัดแรกบรรทัดเดียวก็ใช้ฟังก์ชันนี้เป็น ไม่ต้องไล่อ่านข้างในเลย และเครื่องมือ (tsc) จะเริ่มด่าแทนคุณเมื่อมีใครใช้ผิด

ผมคอมไพล์แล้วรันด้วย node จริง — sum(2, 3) ได้:

5

เขียนอีกแบบ: arrow function

สไลด์หน้า 27 เอาฟังก์ชันเดิมเป๊ะ ๆ มาเขียนใหม่ด้วยอีกทรงหนึ่ง เรียกว่า arrow function สิ่งที่เปลี่ยนคือรูปประโยค ไม่ใช่ความสามารถ:

function sum(num1: number, num2: number): number {
  return num1 + num2;
}

const sum = (num1: number, num2: number): number => {
  return num1 + num2;
};

ผมใส่สองอันนี้ในไฟล์เดียวกัน คอมไพล์แล้วรันจริง เรียกทั้งคู่ด้วย (2, 3) ได้:

5
5

ตำแหน่งของ type อยู่ที่เดิมทั้งสองทรง — หลังชื่อ parameter หนึ่งจุด และหลังวงเล็บปิดอีกหนึ่งจุด ต่างกันแค่ว่าทรงที่ 2 ไม่มีคำว่า function แล้วเอา => มาคั่นก่อนปีกกา

แล้วจะเลือกอันไหน? เอาจริง ๆ ในโค้ดฝั่ง frontend สมัยนี้คุณจะเห็น arrow function เยอะกว่ามาก เหตุผลใหญ่ข้อหนึ่งคือเรื่อง this ซึ่งผมเก็บไว้ท้ายบทเพราะมันต้องรันให้ดู

TypeScript เดา return type ให้เองได้ — แล้วจะเขียนกำกับไปทำไม

ถ้าคุณไม่เขียน : number ตรงหลังวงเล็บ TypeScript ก็ยังรู้ว่าฟังก์ชันคืนอะไร มันอ่านจากบรรทัด return เอาเอง เรื่องนี้จริง ไม่ได้หลอก

คำถามที่ควรถามจึงไม่ใช่ "มันเดาได้ไหม" แต่คือ "ตอนโค้ดผิด มันจะบอกเราตรงไหน" — และคำตอบของสองแบบนี้ไม่เหมือนกัน

ผมเขียนฟังก์ชันที่ตั้งใจให้ผิด: ชื่อบอกว่าคำนวณราคา แต่ดันเผลอต่อสตริง

// infer-a.ts
function priceOf(qty: number) {
  return "" + qty * 20;
}

const total: number = priceOf(3);
console.log(total);

// infer-b.ts
function priceOf(qty: number): number {
  return "" + qty * 20;
}

const total: number = priceOf(3);
console.log(total);

สั่ง tsc --noEmit --strict ทีละไฟล์ ได้ผลนี้:

=== A (ไม่เขียน return type) ===
infer-a.ts(6,7): error TS2322: Type 'string' is not assignable to type 'number'.

=== B (เขียน return type) ===
infer-b.ts(3,3): error TS2322: Type 'string' is not assignable to type 'number'.

เลข error เดียวกัน ข้อความเดียวกัน — แต่คนละบรรทัด
· แบบ A ชี้ที่ บรรทัด 6 คือบรรทัด const total = priceOf(3) ที่เรียกใช้
· แบบ B ชี้ที่ บรรทัด 3 คือบรรทัด return ที่เขียนผิด
(เลขบรรทัดนับรวมบรรทัดคอมเมนต์ // infer-a.ts ที่อยู่บนสุดด้วย — ถ้าคุณก็อปโค้ดไปโดยไม่เอาคอมเมนต์ เลขจะเลื่อนขึ้นหนึ่ง เป็น 5 กับ 2)

parameter ที่ไม่ต้องใส่ก็ได้ — เครื่องหมาย ?

บางทีคุณอยากให้ช่องหนึ่งใส่หรือไม่ใส่ก็ได้ TypeScript ให้เติม ? ท้ายชื่อ parameter — และสไลด์หน้า 28 ยกตัวอย่างไว้แบบนี้

ผมพิมพ์ตามสไลด์เป๊ะทุกตัวอักษร แล้วสั่ง tsc --noEmit --strict:

// slide28a.ts — โค้ดจากสไลด์หน้า 28 ก้อนบน
const sum = (num1: number = 0, num2?: number): number => {
  return num1 + num2
}

slide28a.ts(3,17): error TS18048: 'num2' is possibly 'undefined'.

สไลด์ไม่ผ่าน และเหตุผลที่ไม่ผ่านคือหัวใจของเครื่องหมาย ? ทั้งอัน:
พอคุณเขียน num2?: number ชนิดจริงของ num2 ไม่ใช่ number แต่เป็น number | undefined — คือ "เป็นตัวเลข หรือ ไม่มีค่าเลย" อย่างใดอย่างหนึ่ง
เอาสิ่งที่อาจจะ "ไม่มีค่าเลย" ไปบวก TypeScript เลยยกมือห้ามไว้ก่อน

const sum = (num1: number = 0, num2?: number): any => {
  return num1 + (num2 as any);
};

console.log(sum(2, 3));
console.log(sum(2));

5
NaN

วิธีแก้ที่ถูกคือถามก่อนว่ามีค่าไหม แล้วค่อยใช้:

const sum = (num1: number = 0, num2?: number): number => {
  if (num2 === undefined) {
    return num1;
  }
  return num1 + num2;   // ตรงนี้ TypeScript รู้แล้วว่า num2 เป็น number แน่ ๆ
};

console.log(sum(2, 3));
console.log(sum(2));
console.log(sum());

tsc --noEmit --strict เงียบสนิท (ไม่มี error) และรันด้วย node ได้:

5
2
0

parameter ที่มีค่าตั้งต้น — = ค่า

อีกวิธีที่ทำให้ "ไม่ใส่ก็ได้" คือใส่ค่าตั้งต้นไว้ ด้วยเครื่องหมาย = วิธีนี้ต่างจาก ? ตรงจุดสำคัญจุดเดียว: ค่าไม่มีวันเป็น undefined จึงไม่ต้องเช็คก่อนใช้

function greet(name: string, greeting: string = "สวัสดี"): string {
  return greeting + " " + name;
}

console.log(greet("สมชาย"));
console.log(greet("สมชาย", "หวัดดี"));
console.log(greet("สมชาย", undefined));   // ส่ง undefined เข้าไปตรง ๆ เลย

tsc --noEmit --strict ผ่าน และ node พิมพ์ออกมา:

สวัสดี สมชาย
หวัดดี สมชาย
สวัสดี สมชาย

บรรทัดที่สามคือจุดที่คนสะดุดกันเยอะ — เราส่ง undefined เข้าไปด้วยมือ แท้ ๆ แต่ยังได้ "สวัสดี" อยู่ดี
เพราะกฎของค่าตั้งต้นคือ "ถ้าค่าที่ได้รับเป็น undefined ให้ใช้ค่าตั้งต้นแทน" ไม่ใช่ "ถ้าไม่ได้ส่งมา" — สองประโยคนี้ฟังคล้ายกันแต่ไม่เท่ากัน และเวลาคุณส่งค่าที่มาจากตัวแปรอีกที (เช่น greet(name, userPref)) ความต่างนี้จะโผล่มาทันที

และถ้าคุณลองใส่ทั้งสองอย่างพร้อมกัน TypeScript ตัดจบเลย:

function sum(num1: number, num2?: number = 0): number {
  return num1 + num2;
}

both.ts(1,28): error TS1015: Parameter cannot have question mark and initializer.

เลือกอย่างใดอย่างหนึ่ง — และเลือกไม่ยาก: ถ้ามีค่าที่สมเหตุสมผลให้ใช้แทนได้ ใช้ = (จะได้ไม่ต้องเช็คทีหลัง) · ถ้า "ไม่มีค่า" เป็นสถานะที่มีความหมายจริง ๆ ใช้ ? แล้วยอมเช็ค

รับกี่ตัวก็ได้ — rest parameter ...

สไลด์หน้า 28 ก้อนล่างเป็นเรื่องนี้: จะทำยังไงถ้าไม่รู้ล่วงหน้าว่าจะมีของเข้ามากี่ชิ้น
คำตอบคือจุดสามจุดหน้าชื่อ parameter แล้วประกาศชนิดเป็นอาเรย์

ผมพิมพ์ตามสไลด์เป๊ะอีกครั้ง แล้วสั่ง tsc --noEmit --strict:

// slide28b.ts — โค้ดจากสไลด์หน้า 28 ก้อนล่าง
const sum = (...num: number[]): number => {
  return numbers.reduce((total, n) => total + n, 0);
}

slide28b.ts(3,10): error TS2552: Cannot find name 'numbers'. Did you mean 'Number'?
slide28b.ts(3,26): error TS7006: Parameter 'total' implicitly has an 'any' type.
slide28b.ts(3,33): error TS7006: Parameter 'n' implicitly has an 'any' type.

สาม error จากโค้ดสามบรรทัด — แต่ต้นเหตุมีอันเดียว: ประกาศชื่อ parameter ว่า num แต่ในตัวฟังก์ชันเรียกว่า numbers
อีกสอง error ที่เหลือเป็นผลพวง: พอ TypeScript ไม่รู้จัก numbers มันก็ไม่รู้ว่า reduce ของอะไร เลยเดา type ของ total กับ n ไม่ออกตามไปด้วย

แก้ให้ชื่อตรงกัน (ผมตั้งเป็น nums) แล้วใส่ console.log ดูของจริงข้างใน:

const sum = (...nums: number[]): number => {
  console.log("ข้างในฟังก์ชัน nums =", nums);
  return nums.reduce((total, n) => total + n, 0);
};

console.log(sum(1, 2, 3));
console.log(sum());

tsc --noEmit --strict เงียบ และ node พิมพ์:

ข้างในฟังก์ชัน nums = [ 1, 2, 3 ]
6
ข้างในฟังก์ชัน nums = []
0

สังเกตสองอย่างที่ผลรันบอกเรา:
1. ตอนเรียกคุณส่งของแยกชิ้น (1, 2, 3) แต่ข้างในฟังก์ชันมันกลายเป็น อาเรย์ก้อนเดียว ([ 1, 2, 3 ]) — rest parameter คือคนเก็บกวาดตรงนี้ให้
2. เรียกโดยไม่ส่งอะไรเลย ได้ อาเรย์ว่าง [] ไม่ใช่ undefined
ข้อ 2 สำคัญกว่าที่คิด: rest parameter ไม่มีวันเป็น undefined คุณจึงเรียก .length หรือ .reduce() ต่อได้เลยโดยไม่ต้องเช็คก่อน ต่างจาก ? อย่างสิ้นเชิง

ลำดับของ parameter มีกฎอยู่

สามอย่างที่เพิ่งเรียนมาต่อกันมั่วไม่ได้ ผมลองเขียนผิดสองแบบให้ดู:

// order.ts
function greet(name?: string, age: number): string {
  return name + " " + age;
}

function tally(...nums: number[], label: string): number {
  return nums.length;
}

order.ts(2,31): error TS1016: A required parameter cannot follow an optional parameter.
order.ts(6,16): error TS1014: A rest parameter must be last in a parameter list.

เหตุผลของทั้งสองข้อคือเรื่องเดียวกัน: ตอนเรียกใช้ เราระบุ argument ด้วยตำแหน่ง ไม่ใช่ด้วยชื่อ
ถ้าช่องที่ข้ามได้อยู่ตรงกลาง แล้วมีคนเรียก greet("โบ") — TypeScript จะรู้ได้ยังไงว่า "โบ" คือ name หรือคือ age ที่เลื่อนมาแทน
ส่วน rest parameter กวาดของที่เหลือทั้งหมด ถ้ามีช่องอยู่หลังมัน ก็จะไม่เหลืออะไรให้ช่องนั้นตลอดกาล

ของแถมที่ tsc จับให้ฟรี ๆ ตอนเรียกใช้

พอบรรทัดบนสุดของฟังก์ชันมี type ครบ ฝั่งคนเรียกก็ถูกตรวจให้ด้วย:

// callsite.ts
function sum(num1: number, num2: number): number {
  return num1 + num2;
}

sum(2);
sum(2, 3, 4);
sum(2, "3");

callsite.ts(6,1): error TS2554: Expected 2 arguments, but got 1.
callsite.ts(7,11): error TS2554: Expected 2 arguments, but got 3.
callsite.ts(8,8): error TS2345: Argument of type 'string' is not assignable to parameter of type 'number'.

ทั้งสามอันนี้ใน JavaScript ธรรมดารันผ่านหมด ไม่มีใครทัก — sum(2) จะได้ NaN · sum(2, "3") จะได้สตริง "23"
ส่วนสองอันนี้คือกับดักของคนที่เพิ่งย้ายมาจาก JavaScript แล้วยังไม่ชิน:

// noparam.ts — ลืมใส่ type ให้ parameter
function greet(name) {
  return "สวัสดี " + name;
}

noparam.ts(2,16): error TS7006: Parameter 'name' implicitly has an 'any' type.

// voidret.ts — บอกว่าไม่คืนอะไร แต่ดัน return
function logIt(msg: string): void {
  console.log(msg);
  return msg.length;
}

voidret.ts(4,3): error TS2322: Type 'number' is not assignable to type 'void'.

void คือ return type ที่แปลว่า "ฟังก์ชันนี้ไม่คายอะไรออกมา" ใช้กับฟังก์ชันที่มีไว้ทำอะไรบางอย่าง (พิมพ์จอ · ยิง API · เปลี่ยนหน้าจอ) ไม่ได้มีไว้คำนวณค่า

ความต่างที่จับต้องได้ระหว่าง arrow function กับ function ปกติ: this

ตอนต้นบทผมบอกว่าสองทรงนี้ต่างกันแค่รูปประโยค — เกือบจริง มีอยู่จุดหนึ่งที่ต่างกันจริง ๆ และมันเป็นเหตุผลที่ arrow function ชนะใจคนเขียน frontend

this คือคำที่ใช้อ้างถึง "ก้อนที่ฟังก์ชันนี้สังกัดอยู่" ปัญหาคือใน function ปกติ ค่าของ this ถูกตัดสินตอนถูกเรียก ไม่ใช่ตอนเขียน ส่วน arrow function ไม่มี this ของตัวเอง มันหยิบของที่ล้อมมันอยู่มาใช้

ผมเขียนของก้อนเดียวกัน วนลูปแบบเดียวกัน ต่างกันแค่ทรงของฟังก์ชันข้างใน:

const cart = {
  label: "ตะกร้า",
  items: ["ไข่", "นม"],

  withArrow(): void {
    this.items.forEach((item) => {
      console.log("arrow  → this.label =", this.label, "| item =", item);
    });
  },

  withNormal(): void {
    this.items.forEach(function (this: any, item: string) {
      console.log("normal → this =", this, "| item =", item);
    });
  },
};

cart.withArrow();
cart.withNormal();

คอมไพล์แล้วรันด้วย node จริง ได้:

arrow  → this.label = ตะกร้า | item = ไข่
arrow  → this.label = ตะกร้า | item = นม
normal → this = undefined | item = ไข่
normal → this = undefined | item = นม

บรรทัดสามกับสี่คือของจริง — this ข้างใน function ปกติ ที่ถูกส่งให้ forEach ไปเรียก กลายเป็น undefined ทั้งที่มันเขียนอยู่ในตัว cart แท้ ๆ ห่างกันสองบรรทัด
ส่วน arrow function เห็น this.label เป็น "ตะกร้า" ตามที่ควรจะเป็น

และถ้าคุณไม่ได้เขียน this: any กำกับไว้อย่างในตัวอย่างข้างบน TypeScript แบบ --strict จะไม่ยอมให้คอมไพล์ตั้งแต่แรก:

// this-bad.ts
const cart = {
  label: "ตะกร้า",
  items: ["ไข่", "นม"],

  withNormal(): void {
    this.items.forEach(function (item: string) {
      console.log(this.label, item);
    });
  },
};

this-bad.ts(8,19): error TS2683: 'this' implicitly has type 'any' because it does not have a type annotation.

function bill(base: number, vat: number = 0, ...extras: number[]): number {
  const more = extras.reduce((t, n) => t + n, 0);
  return base + vat + more;
}

const cases: [number, string][] = [
  [bill(100), "A ไม่ส่ง vat ไม่ส่ง extras"],
  [bill(100, 7), "B ส่ง vat"],
];
const want = [100, 107];

cases.forEach(([got, name], i) => {
  if (got !== want[i]) {
    throw new Error(name + " พัง: ได้ " + got + " ควรได้ " + want[i]);
  }
});

ทดสอบความเข้าใจ

อ้างอิง

• TypeScript Handbook — More on Functions — อ่านสองหัวข้อพอ: Optional Parameters และ Rest Parameters หัวข้อแรกมีประโยคสำคัญที่บทนี้พิสูจน์ให้ดูแล้วว่า ? ทำให้ชนิดกลายเป็น union กับ undefined · ที่เหลือในหน้านั้น (overload, generic) ยังไม่ต้องอ่านตอนนี้
• TypeScript Handbook — Everyday Types §Functions — สั้นมาก อ่านให้จบทั้งหัวข้อ เป็นที่ที่อธิบายว่าทำไม return type ถึงไม่ต้องเขียนก็ได้ อ่านคู่กับหัวข้อ "TypeScript เดา return type ให้เองได้" ในบทนี้ แล้วคุณจะเห็นว่าเอกสารไม่ได้บอก เรื่องตำแหน่งที่ error ไปโผล่ — ซึ่งเป็นเหตุผลจริงที่ทีมส่วนใหญ่บังคับให้เขียน
• MDN — Arrow function expressions — อ่านหัวข้อ Cannot be used as methods ซึ่งเป็นอีกด้านของเรื่อง this ที่บทนี้รันให้ดู · MDN ยกตัวอย่างตรงข้ามกับของผม (ผมโชว์ว่า arrow ชนะตอนเป็น callback · MDN โชว์ว่า arrow แพ้ตอนเป็น method) อ่านทั้งสองแล้วจะได้กฎครบทั้งสองทิศ
• tsconfig — strict — ดูรายการธงย่อยที่ strict เปิดให้ทั้งหมด ตัวที่เกี่ยวกับบทนี้โดยตรงคือ strictNullChecks (ต้นทางของ TS18048) · noImplicitAny (TS7006) · noImplicitThis (TS2683) — รู้ว่าเลขไหนมาจากธงไหน จะเดาได้ทันทีว่าโปรเจกต์ที่เงียบผิดปกติปิดอะไรไว้
• MDN — NaN — อ่านย่อหน้าแรกกับหัวข้อ Testing against NaN จะเจอกับดักที่ต่อจากบทนี้พอดี: NaN === NaN เป็น false คุณจึงตรวจจับมันด้วย === ไม่ได้ ต้องใช้ Number.isNaN()