Vue 3: Composition API vs Options API untuk perpustakaan komponen besar

Mengapa pilihan ini penting di perpustakaan komponen admin besar

Perpustakaan komponen besar di aplikasi admin bukan situs pemasaran dengan beberapa tombol. Ini puluhan (atau ratusan) blok bangunan yang berulang di banyak layar: tabel data dengan sorting dan aksi massal, panel filter, formulir dengan aturan validasi, drawer dan modal, alur konfirmasi, serta utilitas kecil seperti pemilih tanggal dan guard izin.

Karena pola ini muncul di mana-mana, tim sering menyalin dan mengubah kode demi tenggat. Satu tabel mendapat filter bar kustom, tabel lain sedikit berbeda, dan cepat atau lambat Anda punya lima versi yang “nyaris sama”. Di sinilah pertanyaan Composition API vs Options API berhenti menjadi preferensi pribadi dan mulai memengaruhi kesehatan keseluruhan pustaka.

Yang biasanya rusak pertama kali adalah konsistensi. UI masih berjalan, tapi perilaku bergeser: satu modal menutup dengan Escape di satu tempat tapi tidak di tempat lain; field yang sama melakukan validasi on blur di satu halaman dan on submit di halaman lain. Setelah itu, kecepatan kerja turun karena setiap perubahan memaksa pencarian di banyak duplikat. Terakhir, rasa percaya diri turun: orang menghindari refactor karena tak bisa memperkirakan apa yang akan terpengaruh.

Tiga keputusan praktis yang paling berpengaruh di pustaka bersama:

• Reuse kode: bagaimana Anda mengemas logika bersama tanpa dependensi yang kusut.
• Pengujian: seberapa mudah memverifikasi perilaku tanpa tes UI yang rapuh.
• Onboarding: seberapa cepat kontributor baru bisa membaca sebuah komponen dan melakukan perubahan aman.

Contoh sederhana: admin Anda punya 20 halaman daftar, dan produk minta fitur “Saved filters”. Jika tabel, filter, dan logika sinkronisasi URL tersebar dan tidak konsisten, Anda akan mengirimkan fitur perlahan atau mengirimkannya penuh bug. Gaya API yang Anda pilih membentuk apakah logika itu tinggal di satu tempat yang dapat dipakai ulang, bagaimana ia terhubung jelas ke setiap layar, dan seberapa mudah orang baru dapat memperluasnya.

Jika Anda membangun aplikasi admin Vue 3 (termasuk tim yang memakai Vue 3 di platform seperti AppMaster untuk lapisan UI web), membuat pilihan ini lebih awal bisa menghemat bulan perawatan nanti.

Perbedaan Options dan Composition dalam kode sehari-hari

Cara tercepat merasakan perbedaannya adalah membuka komponen admin besar dan bertanya: “Di mana saya mengubah perilaku untuk fitur ini?” Di pustaka komponen, pertanyaan itu muncul setiap hari.

Dengan Options API, kode dikelompokkan berdasarkan tipe: data untuk state, methods untuk aksi, computed untuk nilai turunan, dan watch untuk efek samping. Struktur itu mudah dipindai saat komponen kecil. Di komponen tabel atau formulir besar, logika untuk satu fitur (mis. aksi massal atau validasi field) sering tersebar di beberapa blok. Anda bisa menjaga rapi, tapi butuh disiplin dan penamaan konsisten agar tidak terjadi alur “lompat-lompat di file”.

Dengan Composition API, kode biasanya dikelompokkan per fitur. Anda mendefinisikan state terkait, nilai turunan, efek samping, dan helper di samping satu sama lain, dan Anda bisa memindahkan logika berulang ke composable. Di pustaka bergaya admin, ini sering sesuai dengan cara orang berpikir: “semua tentang filtering ada di sini,” “semua tentang seleksi baris ada di sini.” Ini juga dapat mengurangi duplikasi lintas komponen serupa, mis. menggunakan usePagination di banyak tabel.

Perbedaan besar sehari-hari terlihat pada bagaimana dependensi muncul.

• Options API bisa terasa lebih implisit: sebuah method mungkin bergantung pada this.user, this.filters, dan this.loading, dan Anda baru tahu dengan membaca di dalam method.
• Composition API cenderung lebih eksplisit: ketika fungsi menutup filters dan loading, Anda bisa melihat variabel-variabel itu didefinisikan di dekatnya, dan Anda bisa meneruskannya ke helper jika perlu.

Tradeoff-nya: Composition API bisa jadi berisik jika semuanya ditumpuk di satu setup() tanpa struktur.

Aturan praktis singkat:

• Pilih Options API saat komponen sebagian besar presentasional dan logikanya ringan.
• Pilih Composition API saat komponen memiliki banyak fitur dengan aturan bersama di seluruh pustaka.
• Jika memilih Composition API, sepakati tata letak sederhana yang mengelompokkan kode per fitur (bukan “semua ref dulu”).
• Jika memilih Options API, tegakkan penamaan dan jaga logika terkait tetap dekat dengan komentar singkat dan nama method konsisten.

Keduanya bisa bekerja. Intinya adalah memilih gaya organisasi yang membuat perubahan berikutnya terasa jelas, bukan cerdik.

Reuse kode: apa yang bertahan bersih dan apa yang menjadi berantakan

Di aplikasi bergaya admin, reuse bukan sekadar nice-to-have. Anda mengulang perilaku yang sama di puluhan layar, dan ketidakkonsistenan kecil berubah jadi bug dan tiket support.

Kebanyakan kebutuhan reuse jatuh ke beberapa kategori berulang: sorting/filtering/pagination yang cocok dengan backend, validasi formulir dan pemetaan error, pengecekan izin dan pembatasan UI, sinkron query (param URL, saved views, filter default), dan aksi massal dengan aturan seleksi tabel.

Reuse di Options API: kuat, tapi mudah menyembunyikan kompleksitas

Dengan Options API, reuse sering dimulai dengan mixin, extends, atau plugin.

Mixin cepat, tapi skalanya buruk karena menyembunyikan dari mana sebuah metode atau nilai computed berasal. Dua mixin bisa bertabrakan pada nama metode yang sama, dan sekarang Anda sedang debug perilaku yang tak terlihat di file komponen. extends terasa lebih bersih daripada mixin, tapi tetap menciptakan teka-teki pewarisan di mana Anda harus membaca banyak file untuk mengerti apa yang sebenarnya dilakukan komponen. Plugin cocok untuk concern tingkat aplikasi (directive global, layanan bersama), namun bukan tempat terbaik untuk aturan bisnis yang berbeda antar layar.

Momen berantakan biasanya muncul ketika reuse menjadi implisit. Kontributor baru tak bisa menjawab “dari mana data ini datang?” tanpa mencari ke seluruh codebase.

Reuse di Composition API: composable yang tetap eksplisit

Reuse dengan Composition API biasanya dibangun di sekitar composable: fungsi kecil yang mengembalikan refs, computed, dan handler. Kemenangan besar adalah reuse menjadi terlihat di bagian atas komponen, dan Anda dapat meneruskan parameter alih-alih bergantung pada konteks komponen yang tersembunyi.

Misalnya, composable usePagination bisa menerima default dan mengeluarkan perubahan dalam bentuk yang konsisten, sementara usePermissions bisa menerima role saat ini dan nama fitur. Pada titik itu, pilihan menjadi soal apakah pustaka Anda lebih mengutamakan wiring eksplisit daripada pewarisan implisit.

Untuk menjaga reuse dapat diprediksi, perlakukan setiap unit reusable seperti API kecil: beri nama jelas, definisikan input dan output, dan jaga satu tanggung jawab. Jika sebuah composable mulai menangani pagination, caching, izin, dan notifikasi sekaligus — pisahkan. Lebih mudah mengganti satu bagian nanti tanpa merusak keseluruhan.

Membangun formulir dan tabel yang dapat dipakai ulang tanpa sakit kepala

Di aplikasi admin, formulir dan tabel adalah tempat pustaka komponen membuat nilai atau menjadi labirin. Kedua API bisa bekerja. Perbedaannya adalah bagaimana Anda mengemas perilaku bersama seperti dirty state, pemetaan error, dan alur submit tanpa membuat setiap komponen terasa “spesial”.

Untuk logika formulir bersama, Options API biasanya mendorong penggunaan mixin atau helper bersama. Mixin nyaman awalnya, tapi nanti sulit menjawab pertanyaan dasar: “Dari mana error field ini?” atau “Kenapa submit dinonaktifkan?”

Composition API membuat reuse semacam ini lebih terlihat karena Anda bisa memindahkan logika ke composable (mis. useDirtyState, useFormErrors, useSubmitFlow) dan melihat jelas apa yang dipakai oleh komponen formulir. Di pustaka besar, kejelasan ini sering lebih penting daripada menghemat beberapa baris.

Cara praktis menjaga API komponen tetap stabil adalah memperlakukan surface publik sebagai kontrak: props, emits, dan slots harus jarang berubah, meski Anda merombak internals. Kontrak ini serupa di kedua gaya, tapi Composition API sering membuat refactor lebih aman karena Anda bisa mengganti satu composable-per-satu tanpa menyentuh API template.

Pola yang umumnya tetap sehat saat pustaka tumbuh:

• Bangun komponen dasar yang melakukan satu tugas dengan baik (BaseInput, BaseSelect, BaseTable), lalu gabungkan menjadi komponen fitur.
• Lebih suka slots untuk fleksibilitas layout (area aksi, empty states, rendering sel) daripada menambah props untuk tiap edge case.
• Normalisasi event sejak awal (mis. update:modelValue, submit, rowClick) sehingga aplikasi tidak tergantung pada detail internal.
• Jaga validasi dan formatting dekat input, tapi taruh aturan bisnis di luar (di composable atau container parent).

Over-abstraction adalah jebakan umum. “Super form” yang meng-handle semua tipe field, semua aturan validasi, dan semua opsi layout sering jadi lebih sulit dipakai daripada Vue biasa. Aturan praktis: jika sebuah base component butuh lebih dari beberapa props untuk menutupi kebutuhan semua tim, mungkin itu harus jadi dua komponen.

Kadang duplikasi kecil adalah pilihan yang benar. Jika hanya satu layar butuh header tabel aneh dengan pengelompokan multi-baris, salin sedikit kode dan biarkan lokal. Abstraksi cerdik punya biaya pemeliharaan panjang, apalagi saat kontributor baru bergabung dan mencoba mengerti perbedaan antara komponen “normal” dan framework di dalam framework.

Jika Anda memutuskan antara Composition dan Options untuk pustaka formulir dan tabel besar, optimalkan untuk keterbacaan alur data terlebih dahulu. Reuse bagus, tapi bukan ketika menyembunyikan jalur dari aksi pengguna ke event yang diemit.

Dampak pada pengujian: apa yang lebih mudah diverifikasi

Di pustaka komponen, tes umumnya jatuh ke tiga kategori: logika murni (formatting, validasi, filtering), rendering (apa yang muncul untuk state tertentu), dan interaksi (klik, input, keyboard, emits). Gaya API yang Anda pilih mengubah seberapa sering Anda bisa menguji kategori pertama tanpa me-mount komponen penuh.

Tes Options API sering terlihat seperti “mount komponen, ubah state instance, assert DOM.” Itu bekerja, tapi bisa mendorong tes yang lebih besar karena logika tercampur di methods, computed, watch, dan lifecycle hooks. Saat sesuatu gagal, Anda juga menghabiskan waktu mencari tahu apakah itu timing watcher, efek lifecycle, atau logika itu sendiri.

Options API biasanya terasa langsung untuk:

• Alur pengguna yang bergantung pada urutan lifecycle (fetch saat mount, reset saat route change)
• Perilaku yang digerakkan oleh watcher (auto-save, sinkron query)
• Emisi event dari method komponen (save(), reset(), applyFilter())

Composition API menggeser keseimbangan. Jika Anda memindahkan logika ke composable, Anda bisa unit test logika itu sebagai fungsi biasa, dengan input kecil dan output jelas. Itu mengurangi jumlah tes “mount dan klik” yang diperlukan, dan membuat kegagalan lebih lokal. Juga membuat dependensi lebih mudah dikontrol: alih-alih mock global, Anda meneruskan dependensi (mis. fungsi fetch, formatter tanggal, atau pengecek izin) ke composable.

Contoh konkret: AdminTable yang bisa dipakai ulang dengan sorting, pagination, dan baris terpilih. Dengan Composition API, logika seleksi bisa hidup di useRowSelection() dan diuji tanpa merender tabel sama sekali (toggle, clear, select all, preserve antar halaman). Lalu Anda pertahankan set kecil tes komponen untuk memastikan template mengikat tombol, checkbox, dan event yang diemit dengan benar.

Untuk menjaga tes kecil dan terbaca (apa pun gayanya):

• Letakkan aturan bisnis di fungsi murni atau composable, bukan di watcher.
• Simpan efek samping (fetch, storage, timer) di balik dependensi yang diinjeksi.
• Lebih suka beberapa integration test fokus per komponen, bukan satu tes besar “semua”.
• Beri nama state dan event konsisten di seluruh pustaka (mengurangi setup tes).
• Hindari coupling tersembunyi (mis. method A tergantung watcher B agar berjalan).

Jika tujuan Anda memilih gaya yang meningkatkan stabilitas tes, dorong ke arah lebih sedikit perilaku yang digerakkan lifecycle dan lebih banyak unit logika terisolasi yang bisa diverifikasi tanpa DOM.

Onboarding kontributor baru: seberapa cepat orang jadi produktif

Di pustaka komponen admin besar, onboarding kurang soal mengajar Vue dan lebih soal membantu orang menemukan hal, mengikuti konvensi yang sama, dan merasa aman melakukan perubahan. Sebagian besar perlambatan datang dari tiga celah: navigasi (logika di mana?), konvensi (bagaimana kita lakukan di sini?), dan rasa percaya diri (bagaimana saya mengubah ini tanpa memecah lima layar?).

Dengan Options API, pendatang biasanya lebih cepat bergerak hari pertama karena strukturnya familiar: props, data, computed, methods, watchers. Tradeoff-nya, perilaku nyata sering tersebar. Satu fitur seperti “server-side filtering” mungkin terpecah ke watcher, computed, dua method, plus mixin. Orang bisa membaca tiap blok, tapi mereka menghabiskan waktu menyusun cerita itu.

Dengan Composition API, keuntungan onboarding adalah logika terkait bisa ditempatkan bersama: state, efek samping, dan helper di satu tempat. Biayanya adalah literasi composable. Kontributor baru perlu paham pola seperti useTableState() dan bagaimana nilai reaktif mengalir melalui banyak composable. Tanpa batasan jelas, bisa terasa seperti melompat antar file tanpa peta.

Beberapa konvensi menghilangkan sebagian besar pertanyaan, apapun gaya yang dipilih:

• Gunakan struktur yang dapat diprediksi: components/, composables/, types/, tests/.
• Pilih pola penamaan dan patuhi (mis. useX, XTable, XForm).
• Tambahkan docblock singkat: apa yang dilakukan komponen, prop penting, dan event utama.
• Definisikan satu aturan “escape hatch” (kapan boleh menambah composable atau helper baru).
• Simpan satu komponen “emas” kecil yang menunjukkan pola yang disukai.

Contoh: jika tim Anda menghasilkan panel admin Vue 3 lalu menyesuaikannya (mis. aplikasi web dibangun di AppMaster dan diperluas oleh developer), onboarding meningkat ketika ada satu tempat jelas untuk menyesuaikan perilaku tabel (sorting, filter, pagination) dan satu tempat jelas untuk menyesuaikan wiring UI (slots, renderer kolom, aksi baris). Kejelasan itu lebih penting daripada API yang Anda pilih.

Langkah demi langkah: memilih gaya dan memperkenalkannya dengan aman

Untuk pustaka UI admin besar, cara paling aman menyelesaikan pertanyaan ini adalah mulai dengan satu fitur yang dibatasi dengan baik dan perlakukan seperti pilot, bukan rewrite.

Pilih satu modul dengan perilaku jelas dan reuse tinggi, seperti pemfilteran tabel atau validasi formulir. Sebelum menyentuh kode, tuliskan apa yang dilakukannya saat ini: input (props, param query, aksi pengguna), output (event, emits, perubahan URL), dan edge case (empty state, reset, error server).

Selanjutnya, tetapkan batasan. Putuskan apa yang harus tetap di dalam komponen (rendering, event DOM, detail aksesibilitas) dan apa yang bisa dipindah ke kode bersama (parsing filter, debouncing, membangun param API, state default). Di sinilah pustaka sering salah: jika Anda memindahkan keputusan UI ke kode bersama, Anda justru membuatnya sulit dipakai ulang.

Rencana rollout praktis:

• Pilih satu komponen yang menunjukkan pola dengan jelas dan dipakai di banyak layar.
• Ekstrak satu unit bersama (composable atau helper biasa) dengan API kecil dan eksplisit.
• Tambahkan tes fokus untuk unit itu terlebih dahulu, berdasarkan skenario admin nyata.
• Refactor komponen yang dipilih end-to-end memakai unit baru itu.
• Terapkan pola yang sama ke satu komponen lagi untuk memastikan skalanya.

Jaga API bersama membosankan dan jelas. Misal, composable useTableFilters() bisa menerima filter awal dan mengekspos filters, apply(), reset(), dan fungsi toRequestParams(). Hindari “magic” yang membaca global state kecuali itu sudah aturan teguh di aplikasi Anda.

Setelah pilot, terbitkan pedoman internal singkat dengan satu contoh yang bisa disalin kontributor. Satu aturan konkret lebih berguna daripada dokumen panjang, mis. “Semua logika pemfilteran tabel tinggal di composable; komponen hanya mengikat kontrol UI dan memanggil apply().”

Sebelum meluas, gunakan definisi selesai sederhana:

• Kode baru terbaca sama di dua komponen berbeda.
• Tes mencakup logika bersama tanpa me-mount UI penuh.
• Kontributor baru bisa mengubah aturan filter tanpa menyentuh file tak terkait.

Jika tim Anda juga membangun portal admin dengan alat tanpa kode seperti AppMaster, pakai pola pilot yang sama: pilih satu workflow (mis. approvals), definisikan perilaku, lalu standarkan pola sebelum mengskalakan.

Kesalahan umum dan jebakan di pustaka besar

Masalah terbesar di pustaka komponen besar jarang soal sintaks. Mereka muncul dari keputusan lokal kecil yang menumpuk dan membuat reuse, pengujian, dan pemeliharaan lebih sulit.

Salah satu jebakan umum adalah mencampur pola secara acak. Jika setengah pustaka memakai Options API dan setengahnya lagi Composition API tanpa aturan, setiap komponen baru jadi bahan perdebatan gaya. Anda juga berakhir dengan solusi yang terduplikasi untuk masalah sama, hanya ditulis dengan bentuk berbeda. Jika Anda mengizinkan kedua gaya, tulis kebijakan jelas: komponen baru gunakan satu gaya, legacy hanya disentuh bila perlu, dan logika bersama tinggal di satu tempat yang disepakati.

Jebakan lain adalah “god composable.” Ia sering dimulai sebagai useAdminPage() atau useTable() yang membantu lalu perlahan menyerap routing, fetching, caching, seleksi, dialog, toast, dan izin. Sulit diuji karena satu pemanggilan memicu banyak efek samping. Sulit dipakai ulang karena tiap layar hanya perlu 30% darinya tapi menanggung kompleksitas 100%.

Watcher juga sumber masalah. Mereka mudah ditambahkan saat sesuatu terasa tidak sinkron, tapi bug timing muncul kemudian (apalagi dengan data async dan input debounced). Ketika orang melaporkan “kadang seleksiku terhapus”, Anda bisa menghabiskan jam mencoba mereproduksi.

Tanda bahaya yang biasanya berarti pustaka menuju masalah:

• Komponen bekerja hanya bila digunakan dalam urutan prop dan event yang tepat.
• Composable membaca dan menulis state global tanpa terlihat jelas.
• Banyak watcher memperbarui state yang sama.
• Refactor terus memecah layar consumer sedikit demi sedikit.
• Kontributor menghindari menyentuh “file itu” karena terasa berisiko.

Jebakan terakhir adalah merusak API publik saat refactor. Di admin, komponen seperti tabel, filter, dan field formulir cepat menyebar. Mengganti nama prop, event, atau mengubah slot bisa memecah puluhan layar. Pendekatan lebih aman adalah memperlakukan API komponen seperti kontrak: deprecate alih-alih menghapus, pertahankan compatibility shim sementara, dan tambahkan tes penggunaan sederhana yang me-mount komponen seperti konsumen.

Jika Anda membangun interface admin Vue 3 yang digenerasi oleh alat seperti AppMaster, hal ini makin penting: kontrak komponen yang konsisten memudahkan reuse layar dan menjaga perubahan tetap dapat diprediksi.

Cek cepat sebelum Anda commit ke sebuah pola

Sebelum memilih Composition API, Options API, atau campuran, lakukan beberapa cek cepat pada komponen nyata dari pustaka Anda. Tujuannya sederhana: buat logika mudah ditemukan, bisa dipakai ulang dengan aman, dan diuji bagian yang benar-benar penting bagi admin.

1) Bisakah seseorang menemukan logika dengan cepat?

Buka komponen admin khas (filter + tabel + izin + aksi massal). Sekarang pura-pura Anda baru di codebase.

Tanda yang baik adalah ketika kontributor bisa menjawab “di mana logika filter?” atau “apa yang menentukan tombol dinonaktifkan?” dalam kurang dari 2 menit. Dengan Options API, ini biasanya berarti logika jelas terbagi di computed, methods, dan watcher. Dengan Composition API, berarti setup() terorganisasi ke blok bernama kecil (atau composable) dan menghindari fungsi raksasa.

2) Apakah utilitas bersama berperilaku seperti fungsi, bukan magic?

Apapun pola Anda, kode bersama harus punya input dan output jelas, dan efek samping minimal. Jika helper meraih global state, memutasi objek yang diteruskan, atau memicu panggilan jaringan tanpa terlihat, reuse jadi berisiko.

Cek cepat:

• Bisakah Anda menebak apa yang dikembalikan dari signature composable atau helper?
• Bisakah Anda menggunakannya di dua komponen tanpa setup tersembunyi?
• Bisakah Anda mereset state-nya di tes tanpa trik?

3) Apakah tes Anda fokus pada perilaku admin?

Aplikasi admin gagal dengan cara yang dapat diprediksi: filter salah diterapkan, izin membocorkan aksi, formulir validasi tidak konsisten, dan state tabel rusak setelah edit.

Daripada mengetes detail implementasi (watcher vs ref), tulis tes seputar perilaku: “dengan role X, aksi Y tersembunyi”, “simpan menampilkan error dan mempertahankan input pengguna”, “perubahan filter memperbarui query dan pesan empty state”. Ini membuat tes stabil walau Anda refactor gaya.

4) Apakah Anda punya standar untuk state async?

Pustaka besar menghasilkan banyak flow async kecil: load opsi, validasi field, fetch baris tabel, retry pada kegagalan. Jika tiap komponen menciptakan loading/error sendiri, onboarding dan debugging melambat.

Pilih satu bentuk jelas untuk state async (loading, error, retries, pembatalan). Composition API sering mendorong composable useAsyncX(), sementara Options API bisa menstandarkan data() plus method bersama. Keduanya OK jika konsisten.

5) Apakah API publik komponen stabil dan mudah dimengerti?

Perlakukan komponen seperti produk. Props, event yang diemit, dan slots adalah kontrak. Jika kontrak sering berubah, setiap layar jadi rapuh.

Cari komentar yang menjelaskan intent (bukan mekanik): apa arti props, event apa yang dijamin, dan apa yang dianggap internal. Jika Anda membangun tools internal dengan platform seperti AppMaster, pola pikir yang sama membantu: blok bangunan stabil membuat layar masa depan lebih cepat dikirim.

Contoh skenario dan langkah selanjutnya untuk tim Anda

Bayangkan halaman “Users” admin yang Anda bangun ulang: filter bar (status, role, tanggal dibuat), tabel dengan baris terpilih, aksi massal (disable, delete, export), dan akses berbasis peran (hanya admin bisa bulk delete, manager bisa edit role).

Dengan Composition API vs Options API, UI bisa sama, tapi kode cenderung terorganisasi berbeda.

Di Options API, Anda sering berakhir dengan satu komponen besar yang punya data untuk filter dan seleksi, computed untuk state turunan, dan methods untuk fetching, aksi massal, dan pengecekan izin. Reuse biasanya muncul sebagai mixin atau helper bersama. Familiar, tapi logika terkait bisa tersebar (fetching di methods, sinkron query di watcher, izin di computed).

Di Composition API, Anda biasanya memecah halaman menjadi composable fokus: satu untuk query dan filter, satu untuk seleksi tabel dan aksi massal, dan satu untuk izin. Komponen halaman menjadi assemblage dari potongan-potongan ini, dan logika tiap concern tetap bersama. Tradeoff-nya: perlu penamaan dan konvensi folder yang jelas agar kontributor tidak merasa semua “magic di setup”.

Reuse cenderung muncul secara alami di pustaka admin untuk hal-hal seperti filter yang sinkron ke URL, pola tabel server-side (pagination, sorting, select-all, guard aksi massal), pengecekan izin dan pembatasan UI (tombol, kolom, aksi baris), dan empty/loading states yang konsisten antar halaman.

Rencana langkah berikut yang bekerja untuk kebanyakan tim:

1. Pilih gaya default untuk kode baru, dan izinkan pengecualian hanya dengan alasan tertulis.
2. Definisikan konvensi: di mana composable berada, bagaimana penamaannya, apa yang boleh di-import, dan apa yang harus dikembalikan.
3. Tambahkan halaman referensi kecil (seperti halaman Users ini) sebagai standar emas pola dan struktur.
4. Tulis tes dulu untuk bagian yang dapat dipakai ulang (filter, izin, aksi massal), bukan layout visual.
5. Jika kecepatan lebih penting daripada kustomisasi mendalam untuk beberapa layar admin, pertimbangkan menghasilkan layar tersebut dengan alat tanpa kode seperti AppMaster, dan fokuskan pustaka tangan Anda pada bagian yang benar-benar unik.

Jika Anda sudah membangun dengan AppMaster, membantu menjaga model mental yang sama antara bagian yang digenerasi dan yang ditulis tangan: kontrak komponen stabil, dan logika bersama dikemas sebagai unit kecil dan eksplisit. Untuk tim yang mengevaluasi no-code untuk tools internal, AppMaster (appmaster.io) dirancang untuk menghasilkan aplikasi penuh (backend, web, dan mobile) sambil tetap memungkinkan Anda menstandarkan UI web Vue 3 di area yang penting.

Jika Anda hanya melakukan satu hal minggu ini, jadikan halaman Users template Anda dan tegakkan di code review. Satu contoh jelas akan lebih membantu konsistensi daripada pedoman panjang.