ในบทความนี้ฉันจะแสดงให้เห็นว่าการใช้เทคนิคการเขียนโปรแกรมแบบประกาศอย่างมีวิจารณญาณสามารถช่วยให้ทีมสร้างเว็บแอปพลิเคชันที่ง่ายต่อการขยายและบำรุงรักษาได้อย่างไร

“ …การเขียนโปรแกรมเชิงประกาศคือกระบวนทัศน์การเขียนโปรแกรมที่แสดงออกถึงตรรกะของการคำนวณโดยไม่ต้องอธิบายขั้นตอนการควบคุม” - เรโมเอช. แจนเซน Hands-on Functional Programming ด้วย TypeScript

เช่นเดียวกับปัญหาส่วนใหญ่ในซอฟต์แวร์การตัดสินใจใช้เทคนิคการเขียนโปรแกรมแบบเปิดเผยในแอปพลิเคชันของคุณจำเป็นต้องมีการประเมินการแลกเปลี่ยนอย่างรอบคอบ ลองดูหนึ่งในไฟล์ บทความก่อนหน้านี้ สำหรับการอภิปรายในเชิงลึกเกี่ยวกับสิ่งเหล่านี้

ที่นี่โฟกัสอยู่ที่วิธีการนำรูปแบบการเขียนโปรแกรมแบบสำแดงมาใช้สำหรับทั้งแอปพลิเคชันใหม่และที่มีอยู่แล้วที่เขียนด้วย JavaScript ซึ่งเป็นภาษาที่รองรับหลายกระบวนทัศน์

ขั้นแรกเราจะพูดถึงวิธีใช้ TypeScript ทั้งด้านหลังและส่วนหน้าเพื่อให้โค้ดของคุณแสดงออกและยืดหยุ่นต่อการเปลี่ยนแปลงมากขึ้น จากนั้นเราจะสำรวจเครื่องจักรที่มีสถานะ จำกัด (FSM) เพื่อปรับปรุงการพัฒนาส่วนหน้าและเพิ่มการมีส่วนร่วมของผู้มีส่วนได้ส่วนเสียในกระบวนการพัฒนา

FSM ไม่ใช่เทคโนโลยีใหม่ พวกเขาถูกค้นพบเมื่อเกือบ 50 ปีที่แล้วและเป็นที่นิยมในอุตสาหกรรมต่างๆเช่นการประมวลผลสัญญาณการบินและการเงินซึ่งความถูกต้องของซอฟต์แวร์อาจเป็นสิ่งสำคัญ นอกจากนี้ยังเหมาะอย่างยิ่งกับปัญหาการสร้างแบบจำลองที่มักเกิดขึ้นในการพัฒนาเว็บสมัยใหม่เช่นการประสานการอัปเดตสถานะอะซิงโครนัสที่ซับซ้อนและภาพเคลื่อนไหว

ผลประโยชน์นี้เกิดขึ้นเนื่องจากข้อ จำกัด เกี่ยวกับวิธีการจัดการของรัฐ เครื่องสถานะสามารถอยู่ในสถานะเดียวพร้อมกันและมีสถานะใกล้เคียงที่ จำกัด ซึ่งสามารถเปลี่ยนไปใช้เพื่อตอบสนองต่อเหตุการณ์ภายนอกได้ (เช่นการคลิกเมาส์หรือการดึงการตอบสนอง) ผลลัพธ์ที่ได้มักจะเป็นอัตราความบกพร่องที่ลดลงอย่างมาก อย่างไรก็ตามแนวทาง FSM อาจเป็นเรื่องยากที่จะขยายขนาดให้ทำงานได้ดีในแอปพลิเคชันขนาดใหญ่ ส่วนขยายล่าสุดของ FSM ที่เรียกว่า statecharts ช่วยให้ FSM ที่ซับซ้อนสามารถมองเห็นได้และปรับขนาดเป็นแอปพลิเคชันที่มีขนาดใหญ่กว่ามากซึ่งเป็นรสชาติของเครื่องจักรที่มีเงื่อนไข จำกัด บทความนี้มุ่งเน้นไปที่ สำหรับการสาธิตของเราเราจะใช้ไลบรารี XState ซึ่งเป็นหนึ่งในโซลูชันที่ดีที่สุดสำหรับ FSM และแผนภูมิสถิติใน JavaScript

กรอกรหัสด้านล่างเพื่อแสดงคุณสมบัติ "ชื่อ" ของวัตถุในกล่องแจ้งเตือน:

ประกาศที่ Back End ด้วย Node.js

การเขียนโปรแกรมส่วนหลังของเว็บเซิร์ฟเวอร์โดยใช้วิธีการประกาศเป็นหัวข้อใหญ่และโดยทั่วไปอาจเริ่มต้นด้วยการประเมินภาษาโปรแกรมที่ใช้งานได้บนฝั่งเซิร์ฟเวอร์ที่เหมาะสม แต่สมมติว่าคุณกำลังอ่านสิ่งนี้ในช่วงเวลาที่คุณได้เลือกไว้แล้ว (หรือกำลังพิจารณา) Node.js สำหรับส่วนหลังของคุณ .

ส่วนนี้ให้รายละเอียดวิธีการสร้างโมเดลเอนทิตีที่ส่วนหลังซึ่งมีประโยชน์ดังต่อไปนี้:

• ปรับปรุงการอ่านรหัส
• การปรับโครงสร้างใหม่ที่ปลอดภัยยิ่งขึ้น
• ศักยภาพในการปรับปรุงประสิทธิภาพเนื่องจากการสร้างแบบจำลองประเภทการรับประกันให้

การรับประกันพฤติกรรมผ่านการสร้างแบบจำลองประเภท

JavaScript

พิจารณาภารกิจในการค้นหาผู้ใช้ที่ระบุผ่านที่อยู่อีเมลใน JavaScript:

function validateEmail(email) { if (typeof email !== 'string') return false; return isWellFormedEmailAddress(email); } function lookupUser(validatedEmail) { // Assume a valid email is passed in. // Safe to pass this down to the database for a user lookup.. }

ฟังก์ชันนี้ยอมรับที่อยู่อีเมลเป็นสตริงและส่งคืนผู้ใช้ที่เกี่ยวข้องจากฐานข้อมูลเมื่อมีการจับคู่

สมมติฐานคือ lookupUser() จะถูกเรียกเมื่อทำการตรวจสอบความถูกต้องพื้นฐานแล้วเท่านั้น นี่คือสมมติฐานหลัก จะเกิดอะไรขึ้นหากหลายสัปดาห์ต่อมามีการปรับโครงสร้างใหม่และสมมติฐานนี้ไม่ได้รับการระงับอีกต่อไป นิ้วข้ามไปว่าการทดสอบหน่วยตรวจจับข้อบกพร่องหรือเราอาจจะส่งข้อความที่ไม่กรองไปยังฐานข้อมูล!

TypeScript (ความพยายามครั้งแรก)

ลองพิจารณาฟังก์ชันการตรวจสอบความถูกต้องเทียบเท่า TypeScript:

function validateEmail(email: string) { // No longer needed the type check (typeof email === 'string'). return isWellFormedEmailAddress(email); }

นี่เป็นการปรับปรุงเล็กน้อยโดยคอมไพเลอร์ TypeScript ช่วยให้เราไม่ต้องเพิ่มขั้นตอนการตรวจสอบรันไทม์เพิ่มเติม

ความปลอดภัยรับประกันได้ว่าการพิมพ์ที่แข็งแรงจะยังไม่ถูกนำมาใช้ประโยชน์อย่างแท้จริง มาดูกันดีกว่า

TypeScript (ความพยายามครั้งที่สอง)

มาปรับปรุงความปลอดภัยของประเภทและไม่อนุญาตให้ส่งผ่านสตริงที่ไม่ได้ประมวลผลเป็นอินพุตไปยัง looukupUser:

type ValidEmail = { value: string }; function validateEmail(input: string): Email | null { if (!isWellFormedEmailAddress(input)) return null; return { value: email }; } function lookupUser(email: ValidEmail): User { // No need to perform validation. Compiler has already ensured only valid emails have been passed in. return lookupUserInDatabase(email.value); }

ดีกว่า แต่ก็ยุ่งยาก การใช้งานทั้งหมดของ ValidEmail เข้าถึงที่อยู่จริงผ่าน email.value TypeScript ใช้งาน โครงสร้าง พิมพ์มากกว่า เล็กน้อย การพิมพ์ที่ใช้ภาษาเช่น Java และ C #

แม้ว่าจะมีประสิทธิภาพ แต่ก็หมายความว่าประเภทอื่น ๆ ที่ยึดตามลายเซ็นนี้จะถือว่าเทียบเท่า ตัวอย่างเช่นรหัสผ่านประเภทต่อไปนี้สามารถส่งผ่านไปยัง lookupUser() โดยไม่ต้องร้องเรียนจากคอมไพเลอร์:

type ValidPassword = { value: string }; const password = { value: 'password' }; lookupUser(password); // No error.

TypeScript (ความพยายามครั้งที่สาม)

เราสามารถพิมพ์เล็กน้อยใน TypeScript โดยใช้จุดตัด:

type ValidEmail = string & { _: 'ValidEmail' }; function validateEmail(input: string): ValidEmail { // Perform email validation checks.. return input as ValidEmail; } type ValidPassword = string & { _: 'ValidPassword' }; function validatePassword(input: string): ValidPassword { ... } lookupUser(' [email protected] '); // Error: expected type ValidEmail. lookupUser(validatePassword('MyPassword'); // Error: expected type ValidEmail. lookupUser(validateEmail(' [email protected] ')); // Ok.

ตอนนี้เราบรรลุเป้าหมายที่จะส่งต่อเฉพาะสตริงอีเมลที่ตรวจสอบแล้วไปยัง lookupUser()

เคล็ดลับ Pro: ใช้รูปแบบนี้ได้อย่างง่ายดายโดยใช้ประเภทตัวช่วยต่อไปนี้:

type Opaque = T & { __TYPE__: K }; type Email = Opaque; type Password = Opaque; type UserId = Opaque;

ข้อดี

ด้วยการพิมพ์เอนทิตีในโดเมนของคุณอย่างชัดเจนเราสามารถ:

1. ลดจำนวนการตรวจสอบที่จำเป็นต้องดำเนินการในรันไทม์ซึ่งใช้รอบ CPU ของเซิร์ฟเวอร์ที่มีค่า (แม้ว่าจะมีจำนวนน้อยมาก แต่ก็จะเพิ่มขึ้นเมื่อให้บริการหลายพันคำขอต่อนาที)
2. รักษาการทดสอบพื้นฐานน้อยลงเนื่องจากการรับประกันที่คอมไพเลอร์ TypeScript มีให้
3. ใช้ประโยชน์จากการปรับโครงสร้างที่ได้รับความช่วยเหลือจากบรรณาธิการและคอมไพเลอร์
4. ปรับปรุงการอ่านรหัสผ่านการปรับปรุง สัญญาณต่อเสียงรบกวน อัตราส่วน.

จุดด้อย

การสร้างแบบจำลองประเภทมาพร้อมกับข้อเสียที่ควรพิจารณา:

1. การแนะนำ TypeScript มักจะทำให้ toolchain ซับซ้อนขึ้นซึ่งจะทำให้เวลาในการสร้างและทดสอบชุดการทำงานนานขึ้น
2. หากเป้าหมายของคุณคือการสร้างคุณลักษณะต้นแบบและนำไปสู่มือผู้ใช้โดยเร็วความพยายามเพิ่มเติมที่จำเป็นในการสร้างแบบจำลองประเภทอย่างชัดเจนและเผยแพร่ผ่านโค้ดเบสอาจไม่คุ้มค่า

เราได้แสดงให้เห็นว่าโค้ด JavaScript ที่มีอยู่บนเซิร์ฟเวอร์หรือเลเยอร์การตรวจสอบแบ็คเอนด์ / ฟรอนต์เอนด์ที่ใช้ร่วมกันสามารถขยายได้อย่างไรเพื่อปรับปรุงการอ่านโค้ดและอนุญาตให้มีการปรับโครงสร้างใหม่ที่ปลอดภัยยิ่งขึ้นซึ่งเป็นข้อกำหนดที่สำคัญสำหรับทีม

ส่วนต่อประสานผู้ใช้ที่เปิดเผย

อินเทอร์เฟซผู้ใช้ที่พัฒนาขึ้นโดยใช้เทคนิคการเขียนโปรแกรมแบบเปิดเผยเน้นความพยายามในการอธิบาย 'อะไร' มากกว่า 'อย่างไร' สองในสามส่วนผสมพื้นฐานหลักของเว็บ CSS และ HTML เป็นภาษาการเขียนโปรแกรมที่เปิดเผยซึ่งได้รับการทดสอบมาแล้วและมากกว่า 1 พันล้านเว็บไซต์ .

การตอบสนองเป็นแบบโอเพนซอร์สโดย Facebook ในปี 2556 และได้เปลี่ยนแปลงแนวทางการพัฒนาส่วนหน้าอย่างมาก เมื่อฉันใช้มันครั้งแรกฉันชอบที่จะทำได้ ประกาศ GUI เป็นหน้าที่ของสถานะของแอปพลิเคชัน ตอนนี้ฉันสามารถเขียน UI ที่ใหญ่และซับซ้อนจากกลุ่มเอกสารขนาดเล็กโดยไม่ต้องจัดการกับรายละเอียดที่ยุ่งเหยิงของการจัดการ DOM และติดตามว่าส่วนใดของแอปที่ต้องอัปเดตเพื่อตอบสนองการกระทำของผู้ใช้ ฉันสามารถเพิกเฉยต่อไฟล์ เวลา แง่มุมเมื่อกำหนด UI และมุ่งเน้นไปที่การตรวจสอบว่าแอปพลิเคชันของฉันเปลี่ยนจากสถานะหนึ่งไปยังอีกสถานะหนึ่งอย่างถูกต้อง

เพื่อให้บรรลุวิธีที่ง่ายกว่าในการพัฒนา UIs React ได้แทรกเลเยอร์นามธรรมระหว่างผู้พัฒนาและเครื่อง / เบราว์เซอร์: DOM เสมือน .

เฟรมเวิร์ก UI ของเว็บสมัยใหม่อื่น ๆ ได้เชื่อมช่องว่างนี้เช่นกันแม้ว่าจะอยู่ในรูปแบบต่างๆ ตัวอย่างเช่น Vue ใช้ปฏิกิริยาการทำงานผ่านตัวรับ / ตัวตั้งค่า JavaScript (Vue 2) หรือพร็อกซี (Vue 3) Svelte นำเสนอปฏิกิริยาผ่านขั้นตอนการคอมไพล์ซอร์สโค้ดเพิ่มเติม (Svelte)

ตัวอย่างเหล่านี้ดูเหมือนจะแสดงให้เห็นถึงความปรารถนาอย่างยิ่งในอุตสาหกรรมของเราที่จะจัดหาเครื่องมือที่ดีขึ้นและง่ายขึ้นสำหรับนักพัฒนาในการแสดงพฤติกรรมของแอปพลิเคชันผ่านวิธีการที่เปิดเผย

สถานะและตรรกะของแอปพลิเคชันที่เปิดเผย

ในขณะที่เลเยอร์การนำเสนอยังคงวนเวียนอยู่กับ HTML บางรูปแบบ (เช่น JSX ในการตอบสนองเทมเพลตที่ใช้ HTML ที่พบใน Vue, Angular และ Svelte) ฉันตั้งสมมติฐานว่าปัญหาในการสร้างแบบจำลองสถานะของแอปพลิเคชันในลักษณะที่เป็น นักพัฒนารายอื่นเข้าใจได้ง่ายและสามารถบำรุงรักษาได้เมื่อแอปพลิเคชันเติบโตขึ้นยังไม่ได้รับการแก้ไข เราเห็นหลักฐานนี้ผ่านการเพิ่มจำนวนของห้องสมุดการจัดการของรัฐและแนวทางต่างๆที่ยังคงดำเนินต่อไปจนถึงทุกวันนี้

สถานการณ์มีความซับซ้อนโดยความคาดหวังที่เพิ่มขึ้นของเว็บแอปสมัยใหม่ ความท้าทายที่เกิดขึ้นใหม่บางประการที่แนวทางการจัดการของรัฐสมัยใหม่ต้องรองรับ:

• แอปพลิเคชันออฟไลน์แรกโดยใช้การสมัครสมาชิกขั้นสูงและเทคนิคการแคช
• การใช้โค้ดและโค้ดที่รัดกุมสำหรับความต้องการขนาดมัดที่ลดลงเรื่อย ๆ
• ความต้องการประสบการณ์ผู้ใช้ที่ซับซ้อนมากขึ้นผ่านภาพเคลื่อนไหวที่มีความเที่ยงตรงสูงและการอัปเดตแบบเรียลไทม์

(Re) การเกิดขึ้นของเครื่องจักรและแผนภูมิสถานะ จำกัด

เครื่องจักรที่มีสถานะ จำกัด ถูกนำมาใช้อย่างกว้างขวางสำหรับการพัฒนาซอฟต์แวร์ในอุตสาหกรรมบางประเภทที่ความแข็งแกร่งของแอปพลิเคชันเป็นสิ่งสำคัญเช่นการบินและการเงิน นอกจากนี้ยังได้รับความนิยมอย่างต่อเนื่องสำหรับการพัฒนาแอปพลิเคชันเว็บส่วนหน้าผ่านทางที่ยอดเยี่ยม ไลบรารี XState .

Wikipedia ให้คำจำกัดความของไฟล์ เครื่อง จำกัด สถานะ เช่น:

เครื่องจักรนามธรรมที่สามารถอยู่ในสถานะหนึ่งในจำนวน จำกัด ในเวลาใดก็ได้ FSM สามารถเปลี่ยนจากสถานะหนึ่งไปเป็นอีกสถานะหนึ่งเพื่อตอบสนองต่ออินพุตภายนอกบางอย่าง การเปลี่ยนแปลงจากสถานะหนึ่งไปเป็นอีกสถานะหนึ่งเรียกว่าการเปลี่ยนแปลง FSM ถูกกำหนดโดยรายการของสถานะสถานะเริ่มต้นและเงื่อนไขสำหรับการเปลี่ยนแปลงแต่ละครั้ง

และต่อไป:

สถานะคือคำอธิบายสถานะของระบบที่กำลังรอดำเนินการเปลี่ยนแปลง

FSM ในรูปแบบพื้นฐานไม่สามารถปรับขนาดได้ดีกับระบบขนาดใหญ่เนื่องจาก ปัญหาการระเบิดของรัฐ . เมื่อเร็ว ๆ นี้แผนภูมิสถิติ UML ถูกสร้างขึ้นเพื่อขยาย FSM ด้วยลำดับชั้นและการทำงานพร้อมกันซึ่งเป็นตัวเปิดใช้งาน FSM ในแอปพลิเคชันเชิงพาณิชย์อย่างกว้างขวาง

ประกาศลอจิกแอปพลิเคชันของคุณ

ก่อนอื่น FSM มีลักษณะเป็นรหัสอย่างไร มีหลายวิธีในการใช้งานเครื่องที่มีสถานะ จำกัด ใน JavaScript

• เครื่อง จำกัด สถานะเป็นคำสั่งสวิตช์

นี่คือเครื่องที่อธิบายสถานะที่เป็นไปได้ที่ JavaScript สามารถใช้งานได้โดยใช้คำสั่ง switch:

const initialState = { type: 'idle', error: undefined, result: undefined }; function transition(state = initialState, action) { switch (action) { case 'invoke': return { type: 'pending' }; case 'resolve': return { type: 'completed', result: action.value }; case 'error': return { type: 'completed', error: action.error ; default: return state; } }

โค้ดลักษณะนี้จะคุ้นเคยกับนักพัฒนาซอฟต์แวร์ที่เคยใช้ไลบรารีการจัดการสถานะ Redux ยอดนิยม

• เครื่อง จำกัด สถานะเป็นวัตถุ JavaScript

นี่คือเครื่องเดียวกับที่ใช้เป็นวัตถุ JavaScript โดยใช้ไลบรารี JavaScript XState:

const promiseMachine = Machine({ id: 'promise', initial: 'idle', context: { result: undefined, error: undefined, }, states: { idle: { on: { INVOKE: 'pending', }, }, pending: { on: { RESOLVE: 'success', REJECT: 'failure', }, }, success: { type: 'final', actions: assign({ result: (context, event) => event.data, }), }, failure: { type: 'final', actions: assign({ error: (context, event) => event.data, }), }, }, });

แม้ว่าเวอร์ชัน XState จะมีขนาดกะทัดรัดน้อยกว่า แต่การแสดงวัตถุมีข้อดีหลายประการ:

1. เครื่องสถานะนั้นเป็น JSON ธรรมดาซึ่งสามารถคงอยู่ได้ง่าย
2. เนื่องจากมีการเปิดเผยเครื่องจึงสามารถมองเห็นได้
3. หากใช้ TypeScript คอมไพลเลอร์จะตรวจสอบว่าดำเนินการเปลี่ยนสถานะที่ถูกต้องเท่านั้น

XState รองรับแผนภูมิสถิติและใช้งานไฟล์ SCXML สเปคซึ่งทำให้เหมาะสำหรับใช้ในงานขนาดใหญ่มาก

การแสดงภาพสถิติ ของคำสัญญา:

แนวทางปฏิบัติที่ดีที่สุดของ XState

ต่อไปนี้เป็นแนวทางปฏิบัติที่ดีที่สุดที่จะนำไปใช้เมื่อใช้ XState เพื่อช่วยให้โครงการสามารถบำรุงรักษาได้

แยกผลข้างเคียงจากลอจิก

XState อนุญาตให้มีการระบุผลข้างเคียง (ซึ่งรวมถึงกิจกรรมต่างๆเช่นการบันทึกหรือการร้องขอ API) โดยอิสระจากตรรกะของเครื่องสถานะ

สิ่งนี้มีประโยชน์ดังต่อไปนี้:

วิธีทำแบบจำลองทางการเงิน

1. ช่วยตรวจหาข้อผิดพลาดทางลอจิกโดยการรักษารหัสเครื่องของรัฐให้สะอาดและเรียบง่ายที่สุด
2. มองเห็นเครื่องแสดงสถานะได้อย่างง่ายดายโดยไม่จำเป็นต้องถอดหม้อไอน้ำพิเศษออกก่อน
3. ทดสอบเครื่องของรัฐได้ง่ายขึ้นโดยการฉีดบริการจำลอง

const fetchUsersMachine = Machine({ id: 'fetchUsers', initial: 'idle', context: { users: undefined, error: undefined, nextPage: 0, }, states: { idle: { on: { FETCH: 'fetching', }, }, fetching: { invoke: { src: (context) => fetch(`url/to/users?page=${context.nextPage}`).then((response) => response.json() ), onDone: { target: 'success', actions: assign({ users: (context, event) => [...context.users, ...event.data], // Data holds the newly fetched users nextPage: (context) => context.nextPage + 1, }), }, onError: { target: 'failure', error: (_, event) => event.data, // Data holds the error }, }, }, // success state.. // failure state.. }, });

แม้ว่าคุณจะอยากเขียน State machine ด้วยวิธีนี้ในขณะที่คุณยังทำงานอยู่ แต่การแยกข้อกังวลที่ดีขึ้นทำได้โดยการส่งผลข้างเคียงเป็นตัวเลือก:

const services = { getUsers: (context) => fetch( `url/to/users?page=${context.nextPage}` ).then((response) => response.json()) } const fetchUsersMachine = Machine({ ... states: { ... fetching: { invoke: { // Invoke the side effect at key: 'getUsers' in the supplied services object. src: 'getUsers', } on: { RESOLVE: 'success', REJECT: 'failure', }, }, ... }, // Supply the side effects to be executed on state transitions. { services } });

นอกจากนี้ยังช่วยให้สามารถทดสอบหน่วยของเครื่องสถานะได้อย่างง่ายดายทำให้สามารถเยาะเย้ยการดึงข้อมูลของผู้ใช้ได้อย่างชัดเจน:

async function testFetchUsers() { return [{ name: 'Peter', location: 'New Zealand' }]; } const machine = fetchUsersMachine.withConfig({ services: { getUsers: (context) => testFetchUsers(), }, });

แยกเครื่องจักรขนาดใหญ่

ไม่ชัดเจนในทันทีเสมอไปว่าจะจัดโครงสร้างโดเมนปัญหาให้เป็นลำดับชั้นของเครื่องที่มีสถานะ จำกัด ได้ดีที่สุดเมื่อเริ่มต้นใช้งาน

เคล็ดลับ: ใช้ลำดับชั้นของส่วนประกอบ UI ของคุณเพื่อช่วยแนะนำกระบวนการนี้ ดูหัวข้อถัดไปเกี่ยวกับวิธีการแมปสถานะเครื่องกับส่วนประกอบ UI

ประโยชน์ที่สำคัญของการใช้เครื่องของรัฐคือการสร้างแบบจำลองสถานะและการเปลี่ยนระหว่างสถานะทั้งหมดในแอปพลิเคชันของคุณอย่างชัดเจนเพื่อให้เข้าใจพฤติกรรมที่เป็นผลลัพธ์ได้อย่างชัดเจนทำให้ข้อผิดพลาดทางตรรกะหรือช่องว่างง่ายต่อการมองเห็น

เพื่อให้การทำงานนี้ทำงานได้ดีเครื่องจักรจำเป็นต้องมีขนาดเล็กและรัดกุม โชคดีที่การเขียนเครื่องของรัฐตามลำดับชั้นเป็นเรื่องง่าย ในตัวอย่างสถิติที่เป็นที่ยอมรับของระบบสัญญาณไฟจราจรสถานะ 'สีแดง' จะกลายเป็นเครื่องแสดงสถานะลูก เครื่อง 'แสง' หลักไม่ทราบสถานะภายในของ 'สีแดง' แต่จะตัดสินใจว่าเมื่อใดที่จะเข้าสู่ 'สีแดง' และลักษณะการทำงานที่ตั้งใจไว้เมื่อออกจากระบบ:

1-1 การแมป State Machines กับ Stateful UI Components

ยกตัวอย่างเช่นไซต์อีคอมเมิร์ซสมมติที่เรียบง่ายมากซึ่งมีมุมมองการตอบสนองต่อไปนี้:

setState() / useState()

กระบวนการสร้างเครื่องสถานะที่สอดคล้องกับมุมมองข้างต้นอาจคุ้นเคยสำหรับผู้ที่ใช้ไลบรารีการจัดการสถานะ Redux:

1. ส่วนประกอบมีสถานะที่ต้องสร้างแบบจำลองหรือไม่? ตัวอย่างเช่น Admin / Products อาจไม่; เพจดึงข้อมูลไปยังเซิร์ฟเวอร์พร้อมโซลูชันการแคช (เช่น SWR ) อาจเพียงพอ ในทางกลับกันส่วนประกอบเช่น SignInForm หรือ Cart มักจะมีสถานะที่ต้องจัดการเช่นข้อมูลที่ป้อนลงในฟิลด์หรือเนื้อหาในรถเข็นปัจจุบัน
2. เทคนิคของรัฐในพื้นที่ (เช่น React’s

   |_+_|

   ) เพียงพอที่จะจับปัญหาหรือไม่ การติดตามว่าโมดอลป็อปอัพรถเข็นเปิดอยู่นั้นแทบจะไม่ต้องใช้เครื่องที่มีสถานะ จำกัด หรือไม่
3. เครื่องสถานะผลลัพธ์น่าจะซับซ้อนเกินไปหรือไม่? หากเป็นเช่นนั้นให้แบ่งเครื่องออกเป็นเครื่องย่อยหลาย ๆ เครื่องโดยระบุโอกาสในการสร้างเครื่องลูกที่สามารถนำกลับมาใช้ที่อื่นได้ ตัวอย่างเช่นเครื่อง SignInForm และ RegistrationForm อาจเรียกใช้อินสแตนซ์ของลูก textFieldMachine เพื่อตรวจสอบความถูกต้องของโมเดลและระบุฟิลด์อีเมลผู้ใช้ชื่อและรหัสผ่าน

เมื่อใดควรใช้โมเดลเครื่องจักรที่มีสถานะ จำกัด

ในขณะที่แผนภูมิสถิติและ FSM สามารถแก้ปัญหาที่ท้าทายได้อย่างสวยงาม แต่การตัดสินใจเลือกเครื่องมือและแนวทางที่ดีที่สุดในการใช้สำหรับแอปพลิเคชันเฉพาะมักขึ้นอยู่กับปัจจัยหลายประการ

บางสถานการณ์ที่การใช้เครื่องจักรที่มีเงื่อนไข จำกัด ส่องแสง:

• แอปพลิเคชันของคุณมีส่วนประกอบการป้อนข้อมูลจำนวนมาก ในกรณีที่การเข้าถึงหรือการมองเห็นภาคสนามอยู่ภายใต้กฎที่ซับซ้อนตัวอย่างเช่นการกรอกแบบฟอร์มในแอปการเรียกร้องค่าสินไหมทดแทน FSM ช่วยให้มั่นใจได้ว่ากฎทางธุรกิจจะถูกนำไปใช้อย่างมีประสิทธิภาพ นอกจากนี้คุณสมบัติการแสดงภาพของแผนภูมิสถิติยังสามารถใช้เพื่อช่วยเพิ่มการทำงานร่วมกันกับผู้มีส่วนได้ส่วนเสียที่ไม่ใช่ด้านเทคนิคและระบุข้อกำหนดทางธุรกิจโดยละเอียดในช่วงต้นของการพัฒนา
• เพื่อให้ทำงานได้ดีขึ้นกับการเชื่อมต่อที่ช้าลงและมอบประสบการณ์ความเที่ยงตรงสูงให้กับผู้ใช้ เว็บแอปต้องจัดการโฟลว์ข้อมูล async ที่ซับซ้อนมากขึ้น FSM จำลองสถานะทั้งหมดที่แอปพลิเคชันสามารถเข้าได้อย่างชัดเจนและแผนภูมิสถิติสามารถมองเห็นได้เพื่อช่วยในการวินิจฉัยและแก้ไขปัญหาข้อมูลแบบอะซิงโครนัส
• แอปพลิเคชันที่ต้องการแอนิเมชั่นที่ซับซ้อนและอิงตามรัฐ สำหรับภาพเคลื่อนไหวที่ซับซ้อนเทคนิคในการสร้างโมเดลแอนิเมชั่นเมื่อสตรีมเหตุการณ์ผ่านเวลาด้วย RxJS เป็นที่นิยม สำหรับหลาย ๆ สถานการณ์วิธีนี้ใช้ได้ดีอย่างไรก็ตามเมื่อมีการรวมแอนิเมชั่นที่สมบูรณ์กับชุดสถานะที่เป็นที่รู้จักที่ซับซ้อน FSM จะให้ 'จุดพัก' ที่กำหนดไว้อย่างดีซึ่งภาพเคลื่อนไหวจะไหลไปมา FSM ที่รวมกับ RxJS ดูเหมือนจะเป็นการผสมผสานที่ลงตัวเพื่อช่วยส่งมอบประสบการณ์ผู้ใช้ที่มีความเที่ยงตรงสูง
• แอปพลิเคชันไคลเอนต์ที่หลากหลาย เช่นการตัดต่อรูปภาพหรือวิดีโอเครื่องมือสร้างไดอะแกรมหรือเกมที่ตรรกะทางธุรกิจส่วนใหญ่อยู่ที่ฝั่งไคลเอ็นต์ FSM ถูกแยกออกจากเฟรมเวิร์ก UI หรือไลบรารีโดยธรรมชาติและง่ายต่อการเขียนการทดสอบเพื่อให้แอปพลิเคชันคุณภาพสูงสามารถทำซ้ำได้อย่างรวดเร็วและจัดส่งด้วยความมั่นใจ

คำเตือนของเครื่อง จำกัด สถานะ

• แนวทางทั่วไปแนวทางปฏิบัติที่ดีที่สุดและ API สำหรับไลบรารี statechart เช่น XState เป็นสิ่งใหม่สำหรับนักพัฒนาส่วนหน้าส่วนใหญ่ซึ่งจะต้องใช้เวลาและทรัพยากรในการลงทุนเพื่อให้เกิดประสิทธิผลโดยเฉพาะอย่างยิ่งสำหรับทีมที่มีประสบการณ์น้อย
• คล้ายกับข้อแม้ก่อนหน้านี้ในขณะที่ความนิยมของ XState ยังคงเติบโตและได้รับการบันทึกไว้เป็นอย่างดีไลบรารีการจัดการสถานะที่มีอยู่เช่น Redux, MobX หรือ React Context มีการติดตามจำนวนมากที่ให้ข้อมูลออนไลน์มากมายที่ XState ยังไม่ตรงกัน
• สำหรับแอปพลิเคชันที่ทำตามโมเดล CRUD ที่เรียบง่ายขึ้นเทคนิคการจัดการสถานะที่มีอยู่รวมกับไลบรารีการแคชทรัพยากรที่ดีเช่น SWR หรือ React Query จะเพียงพอ ที่นี่ FSM มีข้อ จำกัด พิเศษในขณะที่มีประโยชน์อย่างเหลือเชื่อในแอพที่ซับซ้อนอาจทำให้การพัฒนาช้าลง
• เครื่องมือนี้มีความสมบูรณ์น้อยกว่าไลบรารีการจัดการสถานะอื่น ๆ โดยยังคงต้องดำเนินการปรับปรุงการสนับสนุน TypeScript และส่วนขยาย devtools ของเบราว์เซอร์

ห่อ

ความนิยมและการยอมรับของการเขียนโปรแกรมแบบเปิดเผยในชุมชนการพัฒนาเว็บยังคงเพิ่มขึ้นอย่างต่อเนื่อง

ในขณะที่การพัฒนาเว็บสมัยใหม่ยังคงมีความซับซ้อนมากขึ้นไลบรารีและเฟรมเวิร์กที่ใช้แนวทางการเขียนโปรแกรมแบบเปิดเผยพร้อมกับความถี่ที่เพิ่มขึ้น เหตุผลนั้นชัดเจน - ต้องมีการสร้างวิธีการเขียนซอฟต์แวร์ที่ง่ายกว่าและมีความหมายมากขึ้น

การใช้ภาษาที่พิมพ์ผิดอย่างชัดเจนเช่น TypeScript ทำให้เอนทิตีในโดเมนของแอปพลิเคชันสามารถสร้างแบบจำลองได้อย่างกระชับและชัดเจนซึ่งจะช่วยลดโอกาสที่จะเกิดข้อผิดพลาดและจำนวนของรหัสตรวจสอบที่มีแนวโน้มที่จะเกิดข้อผิดพลาดซึ่งจำเป็นต้องจัดการ การนำเครื่องจักรและแผนภูมิสถิติที่มีเงื่อนไข จำกัด มาใช้ที่ส่วนหน้าช่วยให้นักพัฒนาสามารถประกาศตรรกะทางธุรกิจของแอปพลิเคชันผ่านการเปลี่ยนสถานะทำให้สามารถพัฒนาเครื่องมือการแสดงภาพที่สมบูรณ์และเพิ่มโอกาสในการทำงานร่วมกันอย่างใกล้ชิดกับผู้ที่ไม่ใช่นักพัฒนา

เมื่อเราทำเช่นนี้เราจะเปลี่ยนโฟกัสของเราจากถั่วและสลักเกลียวของวิธีการทำงานของแอปพลิเคชันไปสู่มุมมองระดับที่สูงขึ้นซึ่งช่วยให้เราสามารถมุ่งเน้นไปที่ความต้องการของลูกค้าได้มากขึ้นและสร้างมูลค่าที่ยั่งยืน

ทำความเข้าใจพื้นฐาน

อะไรคือความแตกต่างระหว่างการเขียนโปรแกรมเชิงประกาศและแบบจำเป็น?

การเขียนโปรแกรมที่จำเป็นจะบอกคอมพิวเตอร์ว่าจะบรรลุผลลัพธ์ได้อย่างไรโดยใช้ชุดคำสั่งต่างๆเช่นในสูตรอาหารในขณะที่การเขียนโปรแกรมแบบสำแดงจะอธิบายถึงผลลัพธ์สุดท้ายที่ต้องการให้บรรลุ

เครื่องจักรที่มีสถานะ จำกัด ทำงานอย่างไร?

เครื่องที่มีสถานะ จำกัด จะเริ่มต้นในสถานะเริ่มต้นและเปลี่ยนไปยังสถานะอื่นที่ทราบเพื่อตอบสนองต่อการดำเนินการเช่นการกดปุ่มหรือการตอบสนองจากเซิร์ฟเวอร์

คุณหมายถึงอะไรโดยเครื่องจักรที่มีสถานะ จำกัด ?

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

อะไรคือความเชื่อมโยงระหว่างการสร้างแบบจำลองประเภทและการเขียนโปรแกรมเชิงประกาศ?

ประเภทช่วยให้นักพัฒนาสามารถอธิบายเอนทิตีของแอปพลิเคชันซึ่งหลีกเลี่ยงการเขียนโค้ดเพิ่มเติมเพื่อยืนยันว่ามีการใช้งานอย่างถูกต้องตลอดทั้งแอปพลิเคชัน

Statechart คืออะไร?

statechart เป็นส่วนขยายล่าสุดของเครื่อง จำกัด สถานะที่แก้ไขปัญหาบางอย่างเช่นสถานะการระเบิดโดยการแนะนำเครื่องจักรตามลำดับชั้นและช่วยให้เห็นภาพลักษณะการทำงานของระบบ