[VueJS] Style guide: viết code vue.js 3 "Dê" - dễ phát triển, dễ hiểu, dễ bảo trì
Tản mạn đêm khuya Khi bắt đầu học, tìm hiểu về một ngôn ngữ lập trình, một framework mới thì cách tiếp cận của mình đó là xác định tổng quan về mục đích mà ngôn ngữ đó được ra đời, tại sao mình nên học nó, sau đó tìm hiểu các khái niệm cơ bản, làm các ví dụ và bắt đầu tự làm project nhỏ demo để ...
Tản mạn đêm khuya
Khi bắt đầu học, tìm hiểu về một ngôn ngữ lập trình, một framework mới thì cách tiếp cận của mình đó là xác định tổng quan về mục đích mà ngôn ngữ đó được ra đời, tại sao mình nên học nó, sau đó tìm hiểu các khái niệm cơ bản, làm các ví dụ và bắt đầu tự làm project nhỏ demo để hiểu hơn về ngôn ngữ lập trình đó. Nhưng sau một thời gian được làm project với một số nhóm thực tế thì mình nhận ra rằng mình đã thiếu đi một phần rất quan trọng đó là học cách viết code có quy tắc. Việc viết code có quy tắc sẽ giúp code dễ đọc code của người khác cũng như của mình, dễ bảo trì, giúp cho chúng ta tránh một số lỗi không đáng có, và cả các anti-patterns. Tuy nhiên không phải quy tắc nào, hay thời điểm nào cũng phù hợp để áp dụng mà có thể còn tùy đội dự án hay project mà chúng ta đang làm lớn nhỏ khác nhau, cần nhanh chóng hay khả năng mở rộng... Cách tốt nhất đó là kết hợp giữa kinh nghiệm lập trình của bản thân, các công nghệ áp dụng và dựa trên nguyên tắc code chuẩn. VueJS thật tuyệt vời khi chính trong trang chủ của framework này đội ngũ core members đã có những chia sẻ cụ thể cho chúng ta về những nguyên tắc nên áp dụng, tham khảo khi code. Bài viết sau đây mình xin phép được dịch từ bài gốc Style guide: Priority B Rules: Strongly Recommended (Improving Readability) và kết hợp kinh nghiệm bản thân trình bày một số phần theo ý hiểu.
Priority B Rules: Strongly Recommended (Improving Readability)
Đây là nguyên tắc số 2 trong 4 nguyên tắc được đề cập tới bài viết Priority A Rules: Essential (Error Prevention) Priority B Rules: Strongly Recommended (Improving Readability) Priority C Rules: Recommended (Minimizing Arbitrary Choices and Cognitive Overhead) Priority D Rules: Use with Caution (Potentially Dangerous Patterns)
#Component file
Khi xây dựng hệ thống mà sẵn sàng sử dụng chung, kết hợp nhiều files thì mỗi component nên được xây dựng trong từng file tách biệt của riêng chúng. Điều này giúp chúng ta nhanh chóng hơn trong việc tìm kiếm component, sửa chữa hoặc xem lại cách sử dụng của nó.
Bad
Vue.component('TodoList', { // ... }) Vue.component('TodoItem', { // ... })
Good
components/ |- TodoList.vue |- TodoItem.vue
#Singlesfile component filename casing
Tên của single file component nên để dạng PascalCase (in hoa chữ cái đầu mỗi từ) hoặc kebab-case (chữ thường toàn bộ và có có gạch nối - giữa các từ)
Bad
components/ |- mycomponent.vue components/ |- myComponent.vue
Good
components/ |- MyComponent.vue components/ |- my-component.vue
#Base component names
Base component là component thành phần hay component cở sở sẽ được sử dụng ở trong component khác. Những component được xây dựng để đáp ứng về thiết kế hoặc một số hành vi cụ thể trong ứng dụng của chúng ta. Nó có thể chỉ bao gồm:
- HTML elements
- Một hoặc nhiều Base component khác, và
- Các thành phần UI của bên thứ 3
Nhưng nó sẽ không bao giờ chứa component state (ví dụ như Vuex store) Tên của những component này sẽ bào gồm phần prefix là Base | App | V và theo sau là tên của element mà nó thể hiện (ví dụ BaseButton | AppButton | VButton). Những lợi ích của việc đặt tên này:
- Khi mà trình biên dịch của chúng ta tổ chức file theo thứ tự từ điển thì những component này sẽ được sắp xếp liền nhau và chúng ta có thể dễ dàng nhận ra chúng.
- Khi mà tên của component luôn phải đặt theo nguyên tắc multi-words thì cách đặt tên này ngăn ngừa chúng ta lựa chọn từ bắt đầu trong tên của component một cách tùy tiện (vd: MyButton* | VueButton).
- Khi những component này thường xuyên được sử dụng thì chúng ta có thể cài đặt chúng là global thay vì phải import nó trong mỗi file component mà mình sử dụng.
Bad
components/ |- MyButton.vue
Good
components/ |- BaseButton.vue components/ |- AppButton.vue components/ |- VButton.vue
#Tightly coupled component names
Là những component con mà được kết hợp chặt chẽ với component cha của nó thì khi đặt tên nên thêm tên của componet cha làm tiền tố cho component con. Cách giải quyết khác có thể mình tạo phân cấp folder cha con với tên folder cha giống tên component cha như sau:
// (*) components/ |- TodoList/ |- Item/ |- Button.vue |- Item.vue |- TodoList.vue
Nhưng với cách (*) sẽ có bất tiện đó là:
- Khi mình muốn mở file trên editor trong trường hợp có nhiều component con cùng tên ví dụ như Button có thể có cả trong LoginForm component chẳng hạn và nhiều hơn thế nữa thì lúc này khi tìm kiếm theo tên file sẽ gây ra kho khăn cho chúng ta lựa chọn đúng file component mà mình muốn sử dụng.
- Khi cây phân cấp của mình có độ sâu tương đối lớn thì việc mở file thông qua sidebar của editor đúng là khủng khiếp