ส่วนประกอบเชิงมุม 101 — ภาพรวม
เผยแพร่แล้ว: 2022-03-11คอมโพเนนต์มีอยู่ใน Angular ตั้งแต่ต้น อย่างไรก็ตาม หลายคนยังคงพบว่าตัวเองใช้ส่วนประกอบอย่างไม่ถูกต้อง ในงานของฉัน ฉันเคยเห็นคนที่ไม่ได้ใช้เลย สร้างส่วนประกอบแทนคำสั่งแอตทริบิวต์ และอื่นๆ อีกมากมาย สิ่งเหล่านี้เป็นปัญหาที่นักพัฒนา Angular รุ่นน้องและรุ่นพี่มักจะสร้าง รวมถึงตัวฉันเองด้วย ดังนั้น โพสต์นี้มีไว้สำหรับคนที่ชอบฉันในตอนที่ฉันเรียน Angular เนื่องจากทั้งเอกสารอย่างเป็นทางการและเอกสารที่ไม่เป็นทางการเกี่ยวกับส่วนประกอบต่าง ๆ อธิบายกรณีการใช้งานว่าจะใช้ส่วนประกอบอย่างไรและเมื่อใด
ในบทความนี้ ฉันจะระบุวิธีที่ถูกต้องและไม่ถูกต้องในการใช้ส่วนประกอบเชิงมุมพร้อมตัวอย่าง โพสต์นี้ควรให้แนวคิดที่ชัดเจนแก่คุณเกี่ยวกับ:
- คำจำกัดความขององค์ประกอบเชิงมุม
- เมื่อใดที่คุณ ควร สร้างส่วนประกอบเชิงมุมที่แยกจากกัน และ
- เมื่อใดที่คุณ ไม่ควร สร้างส่วนประกอบเชิงมุมแยกต่างหาก
ก่อนที่เราจะเข้าสู่การใช้งานส่วนประกอบเชิงมุมที่ถูกต้อง ฉันต้องการสัมผัสหัวข้อส่วนประกอบโดยทั่วไปสั้น ๆ โดยทั่วไป แอปพลิเคชัน Angular แต่ละรายการมีองค์ประกอบอย่างน้อยหนึ่งองค์ประกอบตามค่าเริ่มต้น นั่นคือ root component จากตรงนั้น อยู่ที่เราจะออกแบบแอปพลิเคชันของเราอย่างไร โดยปกติ คุณจะต้องสร้างส่วนประกอบสำหรับหน้าแยกกัน จากนั้นแต่ละหน้าจะมีรายการส่วนประกอบแยกจากกัน ตามหลักการทั่วไป องค์ประกอบต้องเป็นไปตามเกณฑ์ต่อไปนี้:
- ต้องมีคลาสที่กำหนดไว้ซึ่งเก็บข้อมูลและตรรกะ และ
- ต้องเชื่อมโยงกับเทมเพลต HTML ที่แสดงข้อมูลสำหรับผู้ใช้ปลายทาง
ลองนึกภาพสถานการณ์ที่เรามีแอปพลิเคชันซึ่งมีสองหน้า: งานที่กำลังจะมีขึ้น และ งานที่ทำเสร็จ แล้ว ในหน้า งานที่กำลังจะมีขึ้น เราสามารถดูงานที่กำลังจะมาถึง ทำเครื่องหมายว่า "เสร็จสิ้น" และเพิ่มงานใหม่ได้ในที่สุด ในทำนองเดียวกัน ในหน้า งานที่เสร็จสมบูรณ์ เราสามารถดูงานที่เสร็จแล้วและทำเครื่องหมายว่า "เลิกทำ" สุดท้าย เรามีลิงก์การนำทาง ซึ่งช่วยให้เรานำทางระหว่างหน้าต่างๆ ได้ ดังที่กล่าวไปแล้ว เราสามารถแบ่งหน้าต่อไปนี้ออกเป็นสามส่วน: ส่วนประกอบรูท เพจ ส่วนประกอบที่ใช้ซ้ำได้
จากภาพหน้าจอด้านบน เราจะเห็นได้อย่างชัดเจนว่าโครงสร้างของแอปพลิเคชันจะมีลักษณะดังนี้:
── myTasksApplication ├── components │ ├── header-menu.component.ts │ ├── header-menu.component.html │ ├── task-list.component.ts │ └── task-list.component.html ├── pages │ ├── upcoming-tasks.component.ts │ ├── upcoming-tasks.component.html │ ├── completed-tasks.component.ts │ └── completed-tasks.component.html ├── app.component.ts └── app.component.htmlเรามาเชื่อมโยงไฟล์ส่วนประกอบกับองค์ประกอบจริงบนโครงร่างด้านบนกัน:
-
header-menu.componentและtask-list.componentเป็นส่วนประกอบที่นำกลับมาใช้ใหม่ได้ ซึ่งจะแสดงด้วยเส้นขอบสีเขียวในภาพหน้าจอโครงร่าง -
upcoming-tasks.componentและcompleted-tasks.componentเป็นหน้าซึ่งแสดงด้วยเส้นขอบสีเหลืองในภาพหน้าจอโครงร่างด้านบน และ - สุดท้าย
app.componentเป็นองค์ประกอบหลักซึ่งแสดงด้วยเส้นขอบสีแดงในภาพหน้าจอโครงร่าง
ดังที่กล่าวไปแล้ว เราสามารถระบุตรรกะและการออกแบบแยกกันสำหรับแต่ละส่วนประกอบ จากโครงร่างด้านบน เรามีสองหน้าที่นำองค์ประกอบหนึ่งกลับมาใช้ใหม่ task-list.component คำถามก็จะเกิดขึ้น—เราจะระบุประเภทข้อมูลที่เราควรแสดงบนหน้าใดหน้าหนึ่งได้อย่างไร? โชคดีที่เราไม่ต้องกังวลเรื่องนั้น เพราะเมื่อคุณสร้างส่วนประกอบ คุณยังสามารถระบุตัวแปร อินพุต และ เอาต์พุต ได้
ตัวแปรอินพุต
ตัวแปรอินพุตถูกใช้ภายในส่วนประกอบเพื่อส่งผ่านข้อมูลบางส่วนจากองค์ประกอบหลัก ในตัวอย่างข้างต้น เราสามารถมีพารามิเตอร์อินพุตสองตัวสำหรับ task-list.component — tasks และ listType ดังนั้น tasks จะเป็นรายการของสตริงซึ่งจะแสดงแต่ละสตริงในแถวที่แยกจากกัน ในขณะที่ listType จะเป็นรายการ กำลังจะมาถึง หรือ เสร็จสิ้น ซึ่งจะระบุว่ามีการทำเครื่องหมายที่ช่องทำเครื่องหมายหรือไม่ ด้านล่างนี้ คุณจะพบข้อมูลโค้ดขนาดเล็กว่าองค์ประกอบจริงจะมีลักษณะอย่างไร
// task-list.component.ts import { Component, Input } from '@angular/core'; @Component({ selector: 'app-task-list', templateUrl: 'task-list.component.html' }) export class TaskListComponent { @Input() tasks: string[] = []; // List of tasks which should be displayed. @Input() listType: 'upcoming' | 'completed' = 'upcoming'; // Type of the task list. constructor() { } }ตัวแปรเอาต์พุต
เช่นเดียวกับตัวแปรอินพุต ตัวแปรเอาต์พุตสามารถใช้เพื่อส่งข้อมูลบางอย่างระหว่างส่วนประกอบต่างๆ แต่คราวนี้ไปยังองค์ประกอบหลัก ตัวอย่างเช่น สำหรับ task-list.component เราอาจมีตัวแปร itemChecked มันจะแจ้งองค์ประกอบหลักหากมีการตรวจสอบหรือยกเลิกการเลือกรายการ ตัวแปรเอาต์พุตต้องเป็นตัวปล่อยเหตุการณ์ ด้านล่างนี้ คุณจะพบข้อมูลโค้ดขนาดเล็กว่าคอมโพเนนต์จะมีลักษณะอย่างไรเมื่อใช้ตัวแปรเอาต์พุต
// task-list.component.ts import { Component, Input, Output } from '@angular/core'; @Component({ selector: 'app-task-list', templateUrl: 'task-list.component.html' }) export class TaskListComponent { @Input() tasks: string[] = []; // List of tasks which should be displayed. @Input() listType: 'upcoming' | 'completed' = 'upcoming'; // Type of the task list. @Output() itemChecked: EventEmitter<boolean> = new EventEmitter(); @Output() tasksChange: EventEmitter<string[]> = new EventEmitter(); constructor() { } /** * Is called when an item from the list is checked. * @param selected---Value which indicates if the item is selected or deselected. */ onItemCheck(selected: boolean) { this.itemChecked.emit(selected); } /** * Is called when task list is changed. * @param changedTasks---Changed task list value, which should be sent to the parent component. */ onTasksChanged(changedTasks: string[]) { this.taskChange.emit(changedTasks); } }task-list.component.ts ที่เป็นไปได้หลังจากเพิ่มตัวแปรเอาต์พุตการใช้ส่วนประกอบย่อยและการผูกตัวแปร
มาดูวิธีใช้ส่วนประกอบนี้ภายในองค์ประกอบหลักและวิธีผูกตัวแปรประเภทต่างๆ กัน ใน Angular มีสองวิธีในการผูกตัวแปรอินพุต—การโยงทางเดียว ซึ่งหมายความว่าคุณสมบัติต้องถูกห่อด้วยวงเล็บเหลี่ยม [] และการรวมสองทาง ซึ่งหมายความว่าคุณสมบัติจะต้องถูกห่อด้วยวงเล็บเหลี่ยมและวงเล็บกลม [()] . ดูตัวอย่างด้านล่างและดูวิธีต่างๆ ในการส่งข้อมูลระหว่างส่วนประกอบต่างๆ
<h1>Upcoming Tasks</h1> <app-task-list [(tasks)]="upcomingTasks" [listType]="'upcoming'" (itemChecked)="onItemChecked($event)"></app-task-list>upcoming-tasks.component.htmlมาดูแต่ละพารามิเตอร์กัน:
- พารามิเตอร์
tasksถูกส่งโดยใช้การเชื่อมโยงสองทาง ซึ่งหมายความว่า ในกรณีที่พารามิเตอร์งานมีการเปลี่ยนแปลงภายในองค์ประกอบลูก ส่วนประกอบหลักจะสะท้อนการเปลี่ยนแปลงเหล่านั้นบนตัวแปรงานupcomingTasksในการอนุญาตการเชื่อมโยงข้อมูลแบบสองทาง คุณต้องสร้างพารามิเตอร์เอาต์พุต ซึ่งตามหลังเทมเพลต "[inputParameterName]Change" ในกรณีนี้tasksChange - พารามิเตอร์
listTypeถูกส่งผ่านโดยใช้การโยงทางเดียว ซึ่งหมายความว่าสามารถเปลี่ยนแปลงได้ภายในองค์ประกอบย่อย แต่จะไม่ปรากฏในองค์ประกอบหลัก โปรดทราบว่าฉันสามารถกำหนดค่า'upcoming'ให้กับพารามิเตอร์ภายในส่วนประกอบและส่งผ่านสิ่งนั้นแทน—มันจะไม่สร้างความแตกต่าง - สุดท้าย พารามิเตอร์
itemCheckedเป็นฟังก์ชันฟัง และจะถูกเรียกเมื่อใดก็ตามที่ดำเนินการ onItemCheck บนtask-list.componentหากมีการตรวจสอบรายการ$eventจะเก็บค่าtrueแต่ถ้าไม่ได้ตรวจสอบ ก็จะเก็บค่าfalse
อย่างที่คุณเห็น โดยทั่วไปแล้ว Angular มีวิธีที่ยอดเยี่ยมในการส่งผ่านและแบ่งปันข้อมูลระหว่างหลายองค์ประกอบ ดังนั้นคุณไม่ควรกลัวที่จะใช้มัน เพียงใช้อย่างระมัดระวังและอย่าใช้มากเกินไป
เมื่อใดควรสร้างส่วนประกอบเชิงมุมแยกต่างหาก
ดังที่ได้กล่าวไว้ก่อนหน้านี้ คุณไม่ควรกลัวที่จะใช้ส่วนประกอบเชิงมุม แต่คุณควรใช้อย่างชาญฉลาด
คุณควร สร้างองค์ประกอบเชิงมุมเมื่อใด
- คุณ ควร สร้างส่วนประกอบแยกต่างหากเสมอ หากส่วนประกอบนั้นสามารถนำมาใช้ซ้ำได้ในหลายๆ ที่ เช่นกับ
task-list.componentของเรา เราเรียกว่า ส่วนประกอบที่ใช้ซ้ำ ได้ - คุณ ควรพิจารณา สร้างส่วนประกอบแยกต่างหากหากส่วนประกอบนั้นจะทำให้ส่วนประกอบหลักอ่านง่ายขึ้นและอนุญาตให้เพิ่มการทดสอบครอบคลุมเพิ่มเติม เราสามารถเรียกมันว่า องค์ประกอบการจัดระเบียบรหัส
- คุณ ควร สร้างส่วนประกอบแยกต่างหากเสมอ หากคุณมีส่วนของหน้าเว็บที่ไม่จำเป็นต้องอัปเดตบ่อยๆ และต้องการเพิ่มประสิทธิภาพ สิ่งนี้เกี่ยวข้องกับกลยุทธ์การตรวจจับการเปลี่ยนแปลง เราสามารถเรียกมันว่า องค์ประกอบการเพิ่มประสิทธิภาพ .
กฎสามข้อนี้ช่วยให้ฉันระบุได้ว่าฉันจำเป็นต้องสร้างองค์ประกอบใหม่หรือไม่ และกฎเหล่านี้จะให้วิสัยทัศน์ที่ชัดเจนเกี่ยวกับบทบาทสำหรับองค์ประกอบนั้นโดยอัตโนมัติ ตามหลักการแล้ว เมื่อคุณสร้างส่วนประกอบ คุณควรรู้อยู่แล้วว่าบทบาทขององค์ประกอบนั้นจะอยู่ในแอปพลิเคชันอย่างไร
เนื่องจากเราได้ดูการใช้งาน ส่วนประกอบที่นำกลับมาใช้ใหม่ ได้แล้ว มาดูการใช้ส่วนประกอบการ จัดรหัส กัน สมมติว่าเรามีแบบฟอร์มการลงทะเบียน และด้านล่างของแบบฟอร์ม เรามีกล่องที่มี ข้อกำหนดในการ ให้บริการ โดยปกติ นักกฎหมายมักจะมีขนาดใหญ่มาก ใช้พื้นที่มาก ในกรณีนี้คือในเทมเพลต HTML ลองดูตัวอย่างนี้แล้วดูว่าเราจะเปลี่ยนแปลงได้อย่างไร

ในตอนเริ่มต้น เรามีองค์ประกอบเดียว นั่นคือ register.component ซึ่งมีทุกอย่าง รวมถึงแบบฟอร์มการลง registration.component ตลอดจนข้อกำหนดและเงื่อนไขด้วย
<h2>Registration</h2> <label for="username">Username</label><br /> <input type="text" name="username" [(ngModel)]="username" /><br /> <label for="password">Password</label><br /> <input type="password" name="password" [(ngModel)]="password" /><br /> <div class="terms-and-conditions-box"> Text with very long terms and conditions. </div> <button (click)="onRegistrate()">Registrate</button> เทมเพลตตอนนี้ดูเล็ก แต่ลองนึกภาพว่าถ้าเราจะแทนที่ "ข้อความที่มีข้อกำหนดและเงื่อนไขที่ยาวมาก" ด้วยบิตของข้อความจริงที่มีมากกว่า 1,000 คำ จะทำให้การแก้ไขไฟล์ยากและไม่สบายใจ เรามีวิธีแก้ปัญหาอย่างรวดเร็ว—เราสามารถคิดค้นส่วนประกอบ terms-and-conditions.component ใหม่ ซึ่งจะเก็บทุกอย่างที่เกี่ยวข้องกับข้อกำหนดและเงื่อนไข มาดูไฟล์ HTML สำหรับ terms-and-conditions.component กัน
<div class="terms-and-conditions-box"> Text with very long terms and conditions. </div> และตอนนี้เราสามารถปรับเปลี่ยน registration.component และใช้ terms-and-conditions.component ภายในได้
<h2>Registration</h2> <label for="username">Username</label><br /> <input type="text" name="username" [(ngModel)]="username" /><br /> <label for="password">Password</label><br /> <input type="password" name="password" [(ngModel)]="password" /><br /> <app-terms-and-conditions></app-terms-and-conditions> <button (click)="onRegistrate()">Registrate</button> ยินดีด้วย! เราเพิ่งลดขนาด registration.component หลายร้อยบรรทัด และทำให้อ่านโค้ดได้ง่ายขึ้น ในตัวอย่างข้างต้น เราเปลี่ยนแปลงเทมเพลตของส่วนประกอบ แต่สามารถใช้หลักการเดียวกันนี้กับตรรกะของส่วนประกอบได้
สุดท้าย สำหรับ องค์ประกอบการเพิ่มประสิทธิภาพ ฉันขอแนะนำอย่างยิ่งให้คุณอ่านบทความนี้ เนื่องจากจะให้ข้อมูลทั้งหมดที่จำเป็นต่อการทำความเข้าใจการตรวจจับการเปลี่ยนแปลง และกรณีเฉพาะที่คุณนำไปใช้ได้ คุณจะไม่ใช้มันบ่อยนัก แต่อาจมีบางกรณี และหากคุณสามารถข้ามการตรวจสอบปกติในส่วนประกอบหลายๆ อย่างโดยไม่จำเป็น ก็เป็น win-win สำหรับประสิทธิภาพ
ดังที่กล่าวไปแล้ว เราไม่ควรสร้างส่วนประกอบแยกจากกันเสมอไป ดังนั้น มาดูกันว่าเมื่อใดที่คุณควรหลีกเลี่ยงการสร้างส่วนประกอบแยกต่างหาก
เมื่อใดควรหลีกเลี่ยงการสร้างส่วนประกอบเชิงมุมที่แยกจากกัน
มีสามประเด็นหลักตามที่ฉันแนะนำให้สร้างองค์ประกอบเชิงมุมแยกต่างหาก แต่มีบางกรณีที่ฉันจะหลีกเลี่ยงการสร้างองค์ประกอบแยกต่างหากเช่นกัน
อีกครั้ง เรามาดูหัวข้อย่อยกันซึ่งจะช่วยให้คุณเข้าใจได้ง่ายว่าเมื่อใดที่คุณ ไม่ควร สร้างส่วนประกอบแยกต่างหาก
- คุณ ไม่ควร สร้างส่วนประกอบสำหรับการจัดการ DOM คุณควรใช้คำสั่งแอตทริบิวต์
- คุณ ไม่ควร สร้างส่วนประกอบถ้ามันจะทำให้โค้ดของคุณวุ่นวายมากขึ้น นี่คือสิ่งที่ตรงกันข้ามกับ องค์ประกอบการจัดระเบียบโค้ด
ตอนนี้ มาดูอย่างใกล้ชิดและตรวจสอบทั้งสองกรณีในตัวอย่าง สมมติว่าเราต้องการให้มีปุ่มที่บันทึกข้อความเมื่อมีการคลิก สิ่งนี้อาจถูกเข้าใจผิดและสามารถสร้างส่วนประกอบแยกต่างหากสำหรับการทำงานเฉพาะนี้ ซึ่งจะถือปุ่มและการดำเนินการเฉพาะ มาตรวจสอบวิธีการที่ไม่ถูกต้องกันก่อน:
// log-button.component.ts import { Component, Input, Output } from '@angular/core'; @Component({ selector: 'app-log-button', templateUrl: 'log-button.component.html' }) export class LogButtonComponent { @Input() name: string; // Name of the button. @Output() buttonClicked: EventEmitter<boolean> = new EventEmitter(); constructor() { } /** * Is called when button is clicked. * @param clicked - Value which indicates if the button was clicked. */ onButtonClick(clicked: boolean) { console.log('I just clicked a button on this website'); this.buttonClicked.emit(clicked); } }log-button.component.tsดังนั้น องค์ประกอบนี้จึงมาพร้อมกับมุมมอง html ต่อไปนี้
<button (click)="onButtonClick(true)">{{ name }}</button>log-button.component.html ไม่ถูกต้องดังที่คุณเห็น ตัวอย่างข้างต้นจะได้ผล และคุณสามารถใช้องค์ประกอบด้านบนนี้ตลอดมุมมองของคุณ มันจะทำสิ่งที่คุณต้องการในทางเทคนิค แต่วิธีแก้ปัญหาที่ถูกต้องในที่นี้คือการใช้คำสั่ง ที่จะช่วยให้คุณไม่เพียงแต่ลดจำนวนโค้ดที่คุณต้องเขียน แต่ยังเพิ่มความเป็นไปได้ในการใช้ฟังก์ชันนี้กับองค์ประกอบใดๆ ที่คุณต้องการ ไม่ใช่แค่เพียงปุ่ม
import { Directive } from '@angular/core'; @Directive({ selector: "[logButton]", hostListeners: { 'click': 'onButtonClick()', }, }) class LogButton { constructor() {} /** * Fired when element is clicked. */ onButtonClick() { console.log('I just clicked a button on this website'); } }logButton ซึ่งสามารถกำหนดให้กับองค์ประกอบใดก็ได้ ตอนนี้เมื่อเราสร้างคำสั่งแล้ว เราก็สามารถใช้คำสั่งนี้กับแอปพลิเคชันของเราและกำหนดให้กับองค์ประกอบใดก็ได้ที่เราต้องการ ตัวอย่างเช่น มาใช้ registration.component ของเราอีกครั้ง
<h2>Registration</h2> <label for="username">Username</label><br /> <input type="text" name="username" [(ngModel)]="username" /><br /> <label for="password">Password</label><br /> <input type="password" name="password" [(ngModel)]="password" /><br /> <app-terms-and-conditions></app-terms-and-conditions> <button (click)="onRegistrate()" logButton>Registrate</button>logButton ที่ใช้กับปุ่มแบบฟอร์มลงทะเบียน ตอนนี้ เราสามารถดูที่กรณีที่สอง ซึ่งเราไม่ควรสร้างส่วนประกอบแยกต่างหาก และนั่นคือสิ่งที่ตรงกันข้ามกับ ส่วนประกอบการปรับโค้ด ให้เหมาะสม หากองค์ประกอบที่สร้างขึ้นใหม่ทำให้โค้ดของคุณซับซ้อนและใหญ่ขึ้น ไม่จำเป็นต้องสร้างมันขึ้นมา ลองมาเป็นตัวอย่างของเรา registration.component กรณีหนึ่งคือการสร้างส่วนประกอบแยกต่างหากสำหรับป้ายกำกับและช่องป้อนข้อมูลด้วยพารามิเตอร์อินพุตจำนวนมาก มาดูการปฏิบัติที่ไม่ดีนี้กัน
// form-input-with-label.component.ts import { Component, Input} from '@angular/core'; @Component({ selector: 'app-form-input-with-label', templateUrl: 'form-input-with-label.component.html' }) export class FormInputWithLabelComponent { @Input() name: string; // Name of the field @Input() id: string; // Id of the field @Input() label: string; // Label of the field @Input() type: 'text' | 'password'; // Type of the field @Input() model: any; // Model of the field constructor() { } }form-input-with-label.componentและนี่อาจเป็นมุมมองขององค์ประกอบนี้
<label for="{{ id }}">{{ label }}</label><br /> <input type="{{ type }}" name="{{ name }}" [(ngModel)]="model" /><br />form-input-with-label.component แน่นอน จำนวนโค้ดจะลดลงใน registration.component แต่จะทำให้ลอจิกโดยรวมของโค้ดเข้าใจและอ่านง่ายขึ้นหรือไม่ ฉันคิดว่าเราเห็นได้ชัดเจนว่ามันทำให้โค้ดซับซ้อนกว่าที่เคยเป็นมาโดยไม่จำเป็น
ขั้นตอนถัดไป: ส่วนประกอบเชิงมุม 102?
เพื่อสรุป: อย่ากลัวที่จะใช้ส่วนประกอบ เพียงให้แน่ใจว่าคุณมีวิสัยทัศน์ที่ชัดเจนเกี่ยวกับสิ่งที่คุณต้องการบรรลุ สถานการณ์ที่ฉันได้ระบุไว้ข้างต้นเป็นสถานการณ์ที่พบบ่อยที่สุด และฉันคิดว่าสถานการณ์เหล่านี้มีความสำคัญและเป็นเรื่องธรรมดาที่สุด อย่างไรก็ตาม สถานการณ์ของคุณอาจไม่ซ้ำกัน และขึ้นอยู่กับคุณที่จะตัดสินใจอย่างมีข้อมูล ฉันหวังว่าคุณจะได้เรียนรู้เพียงพอที่จะตัดสินใจได้ดี
หากคุณต้องการเรียนรู้เพิ่มเติมเกี่ยวกับกลยุทธ์การตรวจจับการเปลี่ยนแปลงของ Angular และกลยุทธ์ OnPush ฉันแนะนำให้อ่าน Angular Change Detection และ OnPush Strategy มันมีความเกี่ยวข้องอย่างใกล้ชิดกับส่วนประกอบต่างๆ และดังที่ได้กล่าวไปแล้วในโพสต์ มันสามารถปรับปรุงประสิทธิภาพของแอปพลิเคชันได้อย่างมาก
เนื่องจากส่วนประกอบเป็นเพียงส่วนหนึ่งของคำสั่งที่ Angular จัดเตรียมไว้ จึงเป็นการดีที่จะทำความรู้จักกับ คำสั่งแอตทริบิวต์ และคำ สั่งเชิงโครงสร้าง การทำความเข้าใจคำสั่งทั้งหมดจะทำให้โปรแกรมเมอร์เขียนโค้ดได้ดีขึ้นโดยรวมได้ง่ายขึ้น
