Cách tiếp cận khi làm library component - Angular
Tại bài viết trước, chúng ta đã tìm hiểu về những mindset cần có khi bắt đầu làm library component trong Angular. Bài viết này sẽ sẽ là phần tiếp theo, với mục đích hướng dẫn và giải thích các cách tiếp cận về mặt coding để tạo ra library component trong Angular.Đây là một series bài viết hướng dẫn từ mindset tới cách tiếp cận và ví dụ code minh họa khi làm library component trong Angular. Các phần đã có trong series:
Sau khi đã thấm nhuần những tôn chỉ trên, hẳn bạn sẽ rất nóng lòng muốn nhảy vào các ví dụ code luôn đúng không? Không nhanh vậy đâu sói à, chúng ta còn phải quyết định một thứ rất quan trọng khác: Cách tiếp cận.
Cách tiếp cận?
Đúng vậy!
Bạn nghĩ rằng cứ nhảy vào code 1 cái component, implement đủ ValueControlAssessor, với những business states
như loading, invalid, … là đủ ư? Ừ thì…nó cũng tương đối đủ, nhưng như vậy là chưa đủ tốt!
Trước khi bạn bắt tay vào tạo một component, bạn có nghĩ rằng mình nhất thiết phải override lại toàn bộ behavior của một thẻ HTML native không?
Liệu bạn có nghĩ rằng, với một cái nút ngoài styling ra, thực chất nó chả có gì ngoài thêm HTML element trước/sau
label, hay cùng lắm thêm trạng thái loading sẵn cho nút là xong? Nếu ta xài luôn natitve element <button> đó, ta sẽ không
phải lo về [disable] state, hay các event như (focus), (hover), (click), … Thậm chí nó còn có sẵn các event liên quan tới touch
như (touchstart), (touchend), (touchcancel), …
Hãy thử nghĩ xem, nếu bạn định làm một cái component wrap cái native <button> đó, bạn sẽ phải re-invent the wheel
nhiều tới mức nào?
Dưới đây sẽ là 2 ví dụ phổ biến nhất mà bạn sẽ phải làm khi phải làm library component:
- Input
- Button
