Perorganisasian Struktur Proyek Vue.js

 

Teman-teman mahasiswa, mari kita mempelajari materi pengayan untuk lebih dalam mengenai hal yang terlihat sederhana dan mungkin sepele, tapi hal ini penting. Menentukan standar berdasarkan best practice yang disepakati bersama akan lebih memudahkan dalam pengembangan proyek.

Sehingga prinsip umum penataan proyek adalah:

1. Prediktabilitas > "terlihat keren". Struktur yang konsisten itu jauh lebih penting dan dipriorotaskan daripada pola yang unuk. Misal, menggunakan konvensi penamaan atau lokasi yang mudah untuk ditebak. Misal:

a. Base*.vue  untuk komponenen generik yang lintas aplikasi

contoh:

components/

|- BaseButton.vue

|- BaseTable.vue

|- BaseIcon.vue

components/

|- AppButton.vue

|- AppTable.vue

|- AppIcon.vue

components/

|- VButton.vue

|- VTable.vue

|- VIcon.vue

b. The*.vue untuk komponenen yang single instance

contoh:

components/

|- TheHeader.vue

c. ParentChild.vue untuk child module yang melekat pada parent module

contoh:

components/

|- TodoList.vue (main parent)

|- TodoListItem.vue (child of main parent)

|- TodoListItemButton.vue (child of child of main parent)

|- SearchSidebar.vue (main parent)

|- SearchSidebarNavigation.vue (child of main parent)

2. Co-location seperlunya. Kita perlu letakan file yang saling terkait dan berdekatan (komponen, style, test) agar mudah dirawat. Hindari nested folder yang terlalu dalam

3. Pisah "lapisan" dari fitur.

Pada proyek skala kecil, pola berlapis (component, view, store) sudah cukup.

Pada proyek skala menengah/besar, kita perlu mempertimbangkan feature modular (domain seperti users/, checkout/)

Nah sekarang mari kita mempelajari template struktur berdasakan ukuran proyek. Jadi, struktur perngorganisasian file memang melekat dengan sebesar apa proyek yang ingin dibangun untuk memudahkan tim melakukan maintenance.

A. Template struktur berdasarkan ukuran proyek

1. Kecil (untuk tugas kuliah, prototipe, 1-5 komponen halaman)

Struktur ini cocok untuk mahasiswa yang baru belajar vue-router, state sederhana, dan 1-2 layanan API

Argumentasi yang mendukung struktur ini sebagai best practice untuk skala ukuran kecil adalah minimalis tetapi rapi, komponen umum di 'components/', halaman di 'views/', menggunakan prefiks 'Base' atau 'The' untuk konsistensi

2.Menengah (tim kecil, > 10 halaman, sudah mulai ada domain)

Untuk ukuran proyek menengah, kita mulai bergeser ke folder 'feature' agar skala yang bertambah tetap terkelola

Argumentasi: cohesion per-fitur lebih tinggi; memudahkan pembagian kerja dan code-splitting. Struktur ini sejalan dengan contoh “core/modules” pada artikel di gist dan pola domain-module seperti pada artikel alexop.dev.

3. Besar/Enterprise (banyak domain, tim majemuk)

Pada struktur proyek bersakala besar/enterprise, best practice yang direkomendasikan adalag menambahkan lapisan shared & composables, serta pemisahan API/adapter dan types.

Argumentasi: memisahkan infrastruktur (core/app/shared) dari domain (features); memudahkan ownership dan scalability. Pada artikel di Vueschool dan alexop.dev menekankan prediktabilitas & konvensi naming. Pada artikel di gist mencontohkan core/ & modules/.

Catatan tambahan dan alternatif lain: beberapa tim menerapkan Atomic Design (Atoms/Molecules/Organisms/Templates/Pages) untuk layer presentasi. Hal ini efektif apabila sudah disepakati bersama pada skala lintas-tim.

Nah konvensi dan pola apa sih yang disarankan?

Penamaan: SFC PascalCase, multi-kata; Base* untuk reusable, The* untuk single-instance, ParentChild untuk child yang “melekat” pada induk.

Satu berkas per komponen (SFC), hindari “god component”; pecah berdasarkan tanggung jawab.

Service layer terpisah dari komponen (folder services/ per-fitur): memudahkan testing dan pergantian API.

Store per domain (module/pinia store per fitur) ketimbang satu monolith store besar.

Aliasing (@/features/...) untuk menghindari relative path panjang; konfigurasikan di bundler.

Co-locate test/story/style dekat komponen (MyCard.vue, MyCard.spec.ts, MyCard.stories.ts).

Kesalahan umum yang sering terjadi:

1. Semua komponen di satu folder, menyebabkan kesulitan untuk menavigasi

2. Folder store dibuat secara monolith jika sudah berukuran skala besar. Sebaiknya dipecah per domain, masing0masing mempunyai actions/getters/state

3. Services bercampur dengan komponen. Sebaiknya diekstrak ke services/ dan diinjeksikan. Sehingga memudahkan test & reuse

4. Tidak menggunakan konvensi penamaan seperti menerapkan Base*

5. Folder terlalu dalam, tidak membatasi kedalaman. Prioritaskan co-location yang wajar.

Referensi Sumber untuk Dapat Dibaca Lebih Lanjut:

https://gist.github.com/plinionaves/1e619a414602cd535c6b73a035ae2f75

https://alexop.dev/posts/how-to-structure-vue-projects/

https://medium.com/@alemrandev/7-best-practices-for-structuring-large-scale-vue-js-applications-cbf47beedb99

https://vueschool.io/articles/vuejs-tutorials/structuring-vue-components/

Vue’s style guide for multi-word component names

https://vueschool.io/articles/vuejs-tutorials/how-to-structure-a-large-scale-vue-js-application/

https://medium.com/@mohandabdiche/building-efficient-frontends-a-vue-3-blueprint-for-modern-medium-sized-applications-671dd403ca62

https://vuex.vuejs.org/guide/structure.html

https://vuejs.org/style-guide/rules-strongly-recommended.html