Translate File Structure

content/docs/faq-structure.md

@@ -1,18 +1,18 @@
 ---
 id: faq-structure
-title: File Structure
+title: Struktur File
 permalink: docs/faq-structure.html
 layout: docs
 category: FAQ
 ---
 
-### Is there a recommended way to structure React projects? {#is-there-a-recommended-way-to-structure-react-projects}
+### Apakah ada cara yang disarankan dalam menyusun proyek React? {#is-there-a-recommended-way-to-structure-react-projects}
 
-React doesn't have opinions on how you put files into folders. That said there are a few common approaches popular in the ecosystem you may want to consider.
+React tidak memiliki pendapat tentang bagaimana Anda memasukkan file ke folder. Namun, ada beberapa pendekatan umum pada ekosistem yang cukup populer yang mungkin ingin Anda pertimbangkan.
 
-#### Grouping by features or routes {#grouping-by-features-or-routes}
+#### Pengelompokan berdasarkan fitur atau rute {#grouping-by-features-or-routes}
 
-One common way to structure projects is locate CSS, JS, and tests together inside folders grouped by feature or route.
+Salah satu cara umum untuk menyusun proyek adalah dengan menempatkan CSS, JS, dan tes bersama di dalam folder yang dikelompokkan berdasarkan fitur atau rute.
 
 ```
 common/
@@ -35,11 +35,11 @@ profile/
   ProfileAPI.js
 ```
 
-The definition of a "feature" is not universal, and it is up to you to choose the granularity. If you can't come up with a list of top-level folders, you can ask the users of your product what major parts it consists of, and use their mental model as a blueprint.
+Definisi "fitur" tidak universal, dan terserah Anda dalam memilih rincian. Jika Anda tidak dapat membuat daftar *top-level* folder, Anda dapat bertanya kepada pengguna produk Anda apa bagian utama dari daftar tersebut, dan menggunakan *mental model*  mereka sebagai *blueprint*.
 
-#### Grouping by file type {#grouping-by-file-type}
+#### Pengelompokan berdasarkan jenis file {#grouping-by-file-type}
 
-Another popular way to structure projects is to group similar files together, for example:
+Cara populer lainnya untuk menyusun proyek adalah dengan mengelompokkan file-file yang sama, misalnya:
 
 ```
 api/
@@ -59,16 +59,16 @@ components/
   ProfileHeader.css
 ```
 
-Some people also prefer to go further, and separate components into different folders depending on their role in the application. For example, [Atomic Design](http://bradfrost.com/blog/post/atomic-web-design/) is a design methodology built on this principle. Remember that it's often more productive to treat such methodologies as helpful examples rather than strict rules to follow.
+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.
 
-#### Avoid too much nesting {#avoid-too-much-nesting}
+#### Hindari terlalu banyak *nesting* {#avoid-too-much-nesting}
 
-There are many pain points associated with deep directory nesting in JavaScript projects. It becomes harder to write relative imports between them, or to update those imports when the files are moved. Unless you have a very compelling reason to use a deep folder structure, consider limiting yourself to a maximum of three or four nested folders within a single project. Of course, this is only a recommendation, and it may not be relevant to your project.
+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.
 
-#### Don't overthink it {#dont-overthink-it}
+#### Jangan terlalu memikirkannya {#dont-overthink-it}
 
-If you're just starting a project, [don't spend more than five minutes](https://en.wikipedia.org/wiki/Analysis_paralysis) on choosing a file structure. Pick any of the above approaches (or come up with your own) and start writing code! You'll likely want to rethink it anyway after you've written some real code.
+Jika Anda baru memulai sebuah proyek, [jangan menghabiskan lebih dari lima menit](https://en.wikipedia.org/wiki/Analysis_paralysis) untuk memilih struktur file. Pilih salah satu pendekatan di atas (atau muncul dengan pendekatan Anda sendiri) dan mulailah menulis kode! Anda tetap ingin memikirkannya kembali setelah Anda menulis beberapa kode secara *real*.
 
-If you feel completely stuck, start by keeping all files in a single folder. Eventually it will grow large enough that you will want to separate some files from the rest. By that time you'll have enough knowledge to tell which files you edit together most often. In general, it is a good idea to keep files that often change together close to each other. This principle is called "colocation".
+Jika Anda merasa benar-benar *stuck*, mulailah dengan menyimpan semua file dalam satu folder. Pada akhirnya itu akan tumbuh cukup besar sehingga Anda ingin memisahkan beberapa file dari yang lain. Pada saat itu Anda akan memiliki cukup pengetahuan untuk mengetahui file mana yang paling sering Anda ubah bersama. Secara umum, sebaiknya menyimpan file yang sering berganti secara berdekatan satu sama lain. Prinsip ini disebut "colocation".
 
-As projects grow larger, they often use a mix of both of the above approaches in practice. So choosing the "right" one in the beginning isn't very important.
+Ketika proyek tumbuh lebih besar, mereka sering menggunakan campuran dari kedua pendekatan di atas dalam praktiknya. Jadi memilih yang "benar" pada awalnya tidak terlalu penting.