From 45887cda9b6ff480aa7a0f0c78b88a9dd87f8753 Mon Sep 17 00:00:00 2001 From: Bangun Bagustapa Date: Fri, 7 Feb 2020 19:29:53 +0700 Subject: [PATCH] Update translate --- content/docs/faq-structure.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/docs/faq-structure.md b/content/docs/faq-structure.md index f86afe1ff..6d9d5b630 100644 --- a/content/docs/faq-structure.md +++ b/content/docs/faq-structure.md @@ -39,7 +39,7 @@ Definisi "fitur" tidak universal, dan terserah Anda dalam memilih rincian. Jika #### Pengelompokan berdasarkan jenis file {#grouping-by-file-type} -Cara populer lainnya untuk menyusun proyek adalah dengan mengelompokkan file-file yang sama, misalnya: +Cara populer lainnya untuk menyusun proyek adalah dengan mengelompokkan *file-file* yang sama, misalnya: ``` api/ @@ -61,7 +61,7 @@ components/ Beberapa orang juga lebih suka melangkah lebih jauh, dan memisahkan komponen ke dalam folder yang berbeda tergantung pada peran mereka dalam aplikasi. Misalnya, [Atomic Design](http://bradfrost.com/blog/post/atomic-web-design/) adalah metodologi desain yang dibangun berdasarkan prinsip ini. Ingatlah bahwa biasanya akan lebih produktif untuk menggunakan metodologi seperti ini sebagai contoh yang bermanfaat daripada mengikuti aturan ketat. -#### Hindari terlalu banyak *nesting* {#avoid-too-much-nesting} +#### Hindari terlalu banyak nesting {#avoid-too-much-nesting} Ada banyak *pain points* terkait dengan *nesting* direktori yang dalam pada proyek JavaScript. Itu akan menjadi lebih sulit saat menulis impor relatif di antara mereka, atau memperbarui impor tersebut ketika file dipindahkan. Kecuali jika Anda memiliki alasan yang sangat kuat untuk menggunakan struktur folder yang dalam, pertimbangkan untuk membatasi diri hingga maksimum tiga atau empat *nesting* folder dalam satu proyek. Tentu saja, ini hanya rekomendasi, dan mungkin tidak relevan dengan proyek Anda.