JavaScript และ TypeScript ทำให้การปฏิบัติกับ object reference เหมือนเป็นของที่ใช้แล้วทิ้งนั้นทำได้ง่ายจนน่ากลัว คุณสร้างออบเจกต์ ส่งมันไปยังฟังก์ชัน เก็บไว้ในแคช และต่อมาก็แทนที่ตัวแปรนั้นด้วยอินสแตนซ์ใหม่ ภาษาจะไม่แจ้งเตือนใดๆ Reference เก่ายังคงมีอยู่ ณ ที่แห่งหนึ่งในโปรแกรมของคุณ โดยชี้ไปยังข้อมูลที่ไม่อัปเดตแล้ว นี่ไม่ใช่การแครช (crash) แต่มันคือสิ่งที่แย่กว่านั้น นั่นคือความไม่สอดคล้องกันอย่างเงียบเชียบ (silent divergence) ระหว่างสองส่วนของโค้ดที่คุณเขียน ซึ่งทั้งคู่ต่างคิดว่าตนเองถือครองความจริง (truth) อยู่

วินัยที่ช่วยป้องกันเรื่องนี้เรียกว่า Hard Object References มันไม่ใช่ไลบรารีหรือฟีเจอร์ของคอมไพเลอร์ แต่มันคือข้อตกลง (contract) ที่คุณต้องบังคับใช้ในโค้ดของคุณเอง

ปัญหา Stale Alias

Stale alias เกิดขึ้นเมื่อโมดูลหนึ่งถือ reference ของออบเจกต์ไว้ ในขณะที่อีกโมดูลหนึ่งแทนที่ออบเจกต์นั้นด้วยออบเจกต์ใหม่ Reference แรกยังคงเป็นโค้ดที่ใช้งานได้ แต่ไม่ได้ชี้ไปยังข้อมูลที่เป็นปัจจุบันอีกต่อไป

ลองนึกภาพข้อมูลผู้ใช้ในเว็บแอปพลิเคชันทั่วไป:

const user = {
  name: "Alice",
  address: {
    city: "Seoul",
    country: "KR"
  }
};

คอมโพเนนต์การจัดส่งบันทึกที่อยู่ไว้ตั้งแต่ช่วงแรก:

const shippingAddress = user.address;

ต่อมามีการอัปเดตโปรไฟล์ Reducer หรือ service handler ตัดสินใจแทนที่ออบเจกต์ทั้งหมด:

user.address = { city: "Tokyo", country: "JP" };

ณ จุดนี้ user.address ชี้ไปที่โตเกียว แต่ shippingAddress ยังคงชี้ไปที่ออบเจกต์เก่าในโซล ไม่มีการโยน exception ใดๆ TypeScript ก็ยังทำงานได้ปกติเพราะ type ยังคงตรงกัน UI อาจแสดงเมืองที่อัปเดตแล้วในหน้าโปรไฟล์ ในขณะที่ฉลากการจัดส่งกลับพิมพ์ที่อยู่เก่าออกมาอย่างเงียบๆ บั๊กนี้จะปรากฏออกมาก็ต่อเมื่อผู้ใช้ร้องเรียนว่าพัสดุของพวกเขาถูกส่งไปผิดประเทศ

สิ่งนี้เกิดขึ้นเพราะ JavaScript แยก identity ออกจาก value เมื่อคุณแทนที่ property ของออบเจกต์ด้วย object literal ใหม่ คุณได้ทำลายสายโซ่ความเชื่อมโยงลง ออบเจกต์เก่าไม่ได้ถูกทำลาย แต่มันกลายเป็นออบเจกต์กำพร้า ใครก็ตามที่ยังถือมันอยู่กำลังทำงานกับ "ข้อมูลผี" (ghost)

ความหมายของ Hard Object References

กฎนั้นง่ายมาก: แทนที่ค่าที่เป็น primitive ได้ แต่ห้ามแทนที่ object หรือ array reference เมื่อมีข้อมูลใหม่เข้ามา ให้คัดลอกข้อมูลนั้นลงใน container เดิม แทนที่จะเปลี่ยน container ใหม่

เรื่องนี้ต้องอาศัยนิสัยที่ชัดเจน 3 ประการ

อย่างแรก ประกาศออบเจกต์และอาร์เรย์ด้วย const เพื่อลดความต้องการที่จะผูกตัวแปรระดับบน (top-level variable) เข้ากับอินสแตนซ์ใหม่ ตัวแปรควรจะคงที่ตลอดอายุการใช้งานของ scope นั้น

อย่างที่สอง อย่าแทนที่ property ที่เก็บออบเจกต์หรืออาร์เรย์ด้วยอันที่สร้างขึ้นใหม่ หากคุณต้องการอัปเดตที่อยู่ ให้ทำการ mutate properties ภายในออบเจกต์นั้นแทน

อย่างที่สาม หากคุณต้องการล้างหรือรีเซ็ต state ให้ทำให้โครงสร้างเดิมว่างเปล่า แทนที่จะทิ้งมันไปแล้วใช้ object หรือ array ว่างอันใหม่

หากย้อนกลับไปดูตัวอย่างที่อยู่ การอัปเดตที่ถูกต้องควรเป็นดังนี้:

user.address.city = "Tokyo";
user.address.country = "JP";

หากข้อมูลที่เข้ามาเป็นแบบบางส่วน (partial) หรือเป็นแบบไดนามิก ให้ใช้ Object.assign เพื่อเขียนข้อมูลลงใน target เดิมที่มีอยู่:

Object.assign(user.address, incomingAddressData);

ตัวแปร shippingAddress ซึ่งชี้ไปยังออบเจกต์เดิมในหน่วยความจำ จะเห็นฟิลด์ใหม่ในทันที โดยมีออบเจกต์หลัก (canonical object) เพียงหนึ่งเดียวที่ทำหน้าที่เป็นแหล่งข้อมูลความจริง (source of truth) ที่ใช้งานอยู่

จุดที่เรื่องนี้สำคัญที่สุด

วินัยนี้อาจดูเหมือนเกินความจำเป็นสำหรับ object ตั้งค่า (configuration object) แบบเรียบๆ แต่จะกลายเป็นเรื่องสำคัญทันทีเมื่อ state ของคุณเติบโตขึ้นเป็นกราฟ (graph) ที่มีระบบย่อยหลายระบบถือ pointer ไปยังโหนดที่ทับซ้อนกัน

ลองพิจารณาโปรแกรมแก้ไขข้อความแบบ Rich Text โมเดลของเอกสารคือโครงสร้างแบบต้นไม้ (tree) ของโหนดต่างๆ โมเดลการเลือก (selection model) จะถือ reference ไปยังโหนดเริ่มต้นและโหนดสิ้นสุด History buffer จะถือ reference ไปยังโหนดที่เปลี่ยนแปลงในการทำงานล่าสุด และเลเยอร์การเรนเดอร์ (rendering layer) จะถือ reference ไปยังโหนดที่มันวัดขนาดเพื่อจัดเลย์เอาต์ หาก state manager แทนที่โหนดพารากราฟด้วยออบเจกต์ใหม่เพราะข้อความเปลี่ยน ระบบย่อยเหล่านั้นทั้งหมดจะถือ stale alias ทันที การเลือกจะไฮไลต์ผิดตำแหน่ง ระบบ history ไม่สามารถย้อนกลับได้อย่างถูกต้อง หรือเลเยอร์เรนเดอร์อาจแครช หรือที่แย่กว่านั้นคือแสดงเคอร์เซอร์ผี (phantom cursors) ออกมา

ความเสี่ยงแบบเดียวกันนี้ยังปรากฏในโปรไฟล์ผู้ใช้ที่มีการตั้งค่าและสิทธิ์แบบซ้อนกัน (nested settings and permissions) ซึ่งถูกอ้างอิงโดย UI, เลเยอร์ควบคุมการเข้าถึง (access-control layer) และรูทีนการบันทึกอัตโนมัติ (autosave routine) มันปรากฏใน layout engines ที่ container หลักทำแคชการวัดขนาดของโหนดลูก และปรากฏใน visual editors หรือเครื่องมือ canvas ที่ตัวควบคุม runtime ติดตามเอนทิตีที่ใช้งานอยู่ผ่าน reference ในทุกๆ โดเมนเหล่านี้ คอมโพเนนต์ต่างๆ จะคว้า handle ของออบเจกต์ไว้และคาดหวังว่า handle นั้นจะเป็นมุมมองที่สดใหม่ของความจริงเสมอ

Hard Object References ปฏิบัติต่อออบเจกต์เสมือนเป็นที่อยู่ที่คงที่ เฟอร์นิเจอร์ข้างในอาจเปลี่ยนไปได้ แต่ประตูยังคงอยู่ที่เดิม ใครก็ตามที่มีที่อยู่นี้สามารถเดินเข้าไปและเห็นการจัดวางปัจจุบันได้เสมอ

Reactivity แทนการแทนที่

If you have worked with Redux or similar immutable state libraries, this model probably sounds backward. In those systems, change is signaled by producing a new object. The reference change is the signal. Components compare prevProps.data === nextProps.data to know whether to re-render.

Hard Object References require you to flip that assumption. Because the reference stays constant, reference equality tells you nothing about whether the data changed. You need a different way to broadcast updates.

In practice, this means relying on reactivity systems, explicit observers, or dirty flags. Mutating user.address.city can trigger a setter that notifies subscribers. An object can emit a change event through an event bus. A game loop or canvas tool might set a global dirty flag and re-scan the graph at the end of the frame. The reference is stable, so you must make the data flow visible through other mechanisms.

This architectural shift is why the approach fits best in complex frontend state, large component-local state, visual editors, canvas tools, and runtime controllers. These systems already rely on granular updates, direct mutations, or imperative APIs. Forcing immutability on top often creates excessive allocation pressure and reference churn without buying proportional clarity. When every frame matters, allocating a new object graph just to move a slider is wasteful. Keeping the reference hard and mutating the interior matches the actual mechanics of the problem.

Making It Stick

One of the overlooked benefits of this rule is