From 81f178134313b98a7e4db1fcc5c9dfc17093541e Mon Sep 17 00:00:00 2001 From: Ted Le Date: Tue, 14 Sep 2021 23:57:42 +0200 Subject: [PATCH 1/4] Translate faq-structure.md Translated faq-structure.md file into Vietnamese --- content/docs/faq-structure.md | 35 +++++++++++++++++++++-------------- 1 file changed, 21 insertions(+), 14 deletions(-) diff --git a/content/docs/faq-structure.md b/content/docs/faq-structure.md index 361d681fb..764a7a289 100644 --- a/content/docs/faq-structure.md +++ b/content/docs/faq-structure.md @@ -6,13 +6,15 @@ layout: docs category: FAQ --- -### Is there a recommended way to structure React projects? {#is-there-a-recommended-way-to-structure-react-projects} +### Có cách nào được khuyên dùng để sắp xếp các dự án 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 không có ý kiến về cách bạn sắp xếp các files trong các thư mục. Tuy nhiên, có một số cách tiếp cận thông dụng mà các bạn nên cân nhắc. -#### Grouping by features or routes {#grouping-by-features-or-routes} -One common way to structure projects is to locate CSS, JS, and tests together inside folders grouped by feature or route. +#### Phân nhóm theo tính năng hoặc đường dẫn {#grouping-by-features-or-routes} + +Một cách thông thường để hệ thống hoá dự án là nhóm các file CSS, JS, và tests chung một thư mục và phân các thư mục này theo tính năng hoặc đường dẫn. + ``` common/ @@ -35,11 +37,13 @@ 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. +Định nghĩa của "tính năng" tuỳ thuộc vào cách các bạn định nghĩa, không có khái niệm chung ở đây. Nếu bạn không thể nghĩ ra một danh sách các thư mục top-level, bạn có thể hỏi những người dùng đâu là các thành phần thiết yếu của sản phẩm, và dùng các thành phần này để định hình cách sắp xếp cho dự án. + + +#### Nhóm các file theo phân loại{#grouping-by-file-type} -#### Grouping by file type {#grouping-by-file-type} +Một cách phổ biến khác để sắp xếp dự án chính là nhóm các file giống nhau lại chung với nhau, ví dụ: -Another popular way to structure projects is to group similar files together, for example: ``` api/ @@ -59,16 +63,19 @@ 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. +Một vài người sẽ muốn tối ưu hơn, và sắp xếp các components vào những thư mục tuỳ vào nhiệm vụ của chúng trong ứng dụng. Ví dụ, [Atomic Design](http://bradfrost.com/blog/post/atomic-web-design/) là một phương pháp thiết kế được xây dựng dựa trên nguyên tắc này. Hãy nhớ rằng đôi lúc nên sử dụng các phương pháp này như những ví dụ thay vì xem chúng như những quy luật cần phải tuân thủ. + + +#### Tránh đan xen quá nhiều {#avoid-too-much-nesting} + +Nhiều niềm đau khổ xuất phát từ các thư mục JavaScript bị đan xen quá nhiều trong các dự án. Nó trở nên quá khó khăn để viết các lệnh import giữa chúng, hoặc để cập nhật các import khi các file bị di chuyển. Trừ khi bạn có một lý do khá thuyết phục để dùng một cấu trúc thư mục chằn chịt, hãy hạn chế bản thân bạn ở 3 đến 4 lớp thư mục trong 1 dự án. Đương nhiên, đây chỉ là một lời khuyên, và nó có thề sẽ không phù hợp với dự án của bạn. -#### Avoid too much 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. +#### Đừng suy nghĩ phức tạp {#dont-overthink-it} -#### Don't overthink it {#dont-overthink-it} +Nếu bạn vừa bắt đầu một dự án, [đừng tốn quá 5 phút](https://en.wikipedia.org/wiki/Analysis_paralysis) cho việc lựa chọn một cấu trúc file. Hãy chọn bất kỳ cách tiếp cận được nêu trên (hoặc hãy tự nghĩ ra cách của bạn) và bắt đầu viết code! Khả năng cao là bạn sẽ phải suy nghĩ lại về cách sắp xếp sau khi bạn bắt đầu viết code thực sự. -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. +Nếu bạn cảm thấy hoàn toàn bế tắc, hãy bắt đầu bằng cách để hết tất cả các file vào chỉ duy nhất 1 thư mục. Dần dần thư mục này sẽ đủ lớn để bạn bắt đầu cảm thấy phải tách một số file khỏi các file còn lại. Tới khi đó bạn sẽ có đủ am tường để nhận ra các file nào bạn thường xuyên phải chỉnh sửa chung với nhau. Nhìn chung, bạn nên giữ các file bạn thường xuyên chỉnh sửa chung cùng một thư mục. Nguyên tắc này được gọi là "colocation". -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". +Một khi các dự án trở nên lớn hơn chúng sẽ dùng kết hợp của 2 cách tiếp cận trên. Vì vậy việc lựa chọn "đúng" cách tiếp cận khi đang bắt đầu dự án là việc không quan trọng. -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. From 8ca3c139fe57a12dc42f53bb9a5867d9d5b5b437 Mon Sep 17 00:00:00 2001 From: Ted Le Date: Wed, 15 Sep 2021 00:14:05 +0200 Subject: [PATCH 2/4] Update translation of faq-structure.md minor update to keep translation structure uniform with original structure --- content/docs/faq-structure.md | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/content/docs/faq-structure.md b/content/docs/faq-structure.md index 764a7a289..a005b61f2 100644 --- a/content/docs/faq-structure.md +++ b/content/docs/faq-structure.md @@ -10,12 +10,10 @@ category: FAQ React không có ý kiến về cách bạn sắp xếp các files trong các thư mục. Tuy nhiên, có một số cách tiếp cận thông dụng mà các bạn nên cân nhắc. - #### Phân nhóm theo tính năng hoặc đường dẫn {#grouping-by-features-or-routes} Một cách thông thường để hệ thống hoá dự án là nhóm các file CSS, JS, và tests chung một thư mục và phân các thư mục này theo tính năng hoặc đường dẫn. - ``` common/ Avatar.js @@ -39,12 +37,10 @@ profile/ Định nghĩa của "tính năng" tuỳ thuộc vào cách các bạn định nghĩa, không có khái niệm chung ở đây. Nếu bạn không thể nghĩ ra một danh sách các thư mục top-level, bạn có thể hỏi những người dùng đâu là các thành phần thiết yếu của sản phẩm, và dùng các thành phần này để định hình cách sắp xếp cho dự án. - #### Nhóm các file theo phân loại{#grouping-by-file-type} Một cách phổ biến khác để sắp xếp dự án chính là nhóm các file giống nhau lại chung với nhau, ví dụ: - ``` api/ APIUtils.js @@ -65,17 +61,14 @@ components/ Một vài người sẽ muốn tối ưu hơn, và sắp xếp các components vào những thư mục tuỳ vào nhiệm vụ của chúng trong ứng dụng. Ví dụ, [Atomic Design](http://bradfrost.com/blog/post/atomic-web-design/) là một phương pháp thiết kế được xây dựng dựa trên nguyên tắc này. Hãy nhớ rằng đôi lúc nên sử dụng các phương pháp này như những ví dụ thay vì xem chúng như những quy luật cần phải tuân thủ. - #### Tránh đan xen quá nhiều {#avoid-too-much-nesting} Nhiều niềm đau khổ xuất phát từ các thư mục JavaScript bị đan xen quá nhiều trong các dự án. Nó trở nên quá khó khăn để viết các lệnh import giữa chúng, hoặc để cập nhật các import khi các file bị di chuyển. Trừ khi bạn có một lý do khá thuyết phục để dùng một cấu trúc thư mục chằn chịt, hãy hạn chế bản thân bạn ở 3 đến 4 lớp thư mục trong 1 dự án. Đương nhiên, đây chỉ là một lời khuyên, và nó có thề sẽ không phù hợp với dự án của bạn. - #### Đừng suy nghĩ phức tạp {#dont-overthink-it} Nếu bạn vừa bắt đầu một dự án, [đừng tốn quá 5 phút](https://en.wikipedia.org/wiki/Analysis_paralysis) cho việc lựa chọn một cấu trúc file. Hãy chọn bất kỳ cách tiếp cận được nêu trên (hoặc hãy tự nghĩ ra cách của bạn) và bắt đầu viết code! Khả năng cao là bạn sẽ phải suy nghĩ lại về cách sắp xếp sau khi bạn bắt đầu viết code thực sự. Nếu bạn cảm thấy hoàn toàn bế tắc, hãy bắt đầu bằng cách để hết tất cả các file vào chỉ duy nhất 1 thư mục. Dần dần thư mục này sẽ đủ lớn để bạn bắt đầu cảm thấy phải tách một số file khỏi các file còn lại. Tới khi đó bạn sẽ có đủ am tường để nhận ra các file nào bạn thường xuyên phải chỉnh sửa chung với nhau. Nhìn chung, bạn nên giữ các file bạn thường xuyên chỉnh sửa chung cùng một thư mục. Nguyên tắc này được gọi là "colocation". -Một khi các dự án trở nên lớn hơn chúng sẽ dùng kết hợp của 2 cách tiếp cận trên. Vì vậy việc lựa chọn "đúng" cách tiếp cận khi đang bắt đầu dự án là việc không quan trọng. - +Một khi các dự án trở nên lớn hơn chúng sẽ dùng kết hợp của 2 cách tiếp cận trên. Vì vậy việc lựa chọn "đúng" cách tiếp cận khi đang bắt đầu dự án là việc không quan trọng. \ No newline at end of file From 3ee18e40d9b23265f30725d1e7a8fa1fcaf25e7a Mon Sep 17 00:00:00 2001 From: Ted Le Date: Wed, 15 Sep 2021 00:32:28 +0200 Subject: [PATCH 3/4] 3rd time is the charm --- content/docs/faq-structure.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/docs/faq-structure.md b/content/docs/faq-structure.md index a005b61f2..77c4bc5e5 100644 --- a/content/docs/faq-structure.md +++ b/content/docs/faq-structure.md @@ -1,16 +1,16 @@ --- id: faq-structure -title: File Structure +title: Cấu Trúc Dự Án permalink: docs/faq-structure.html layout: docs category: FAQ --- -### Có cách nào được khuyên dùng để sắp xếp các dự án React? {#is-there-a-recommended-way-to-structure-react-projects} +### Có cách nào được khuyên dùng để sắp xếp các dự án React? {#Có-cách-nào-được-khuyên-dùng-để-sắp-xếp-các-dự-án-React} React không có ý kiến về cách bạn sắp xếp các files trong các thư mục. Tuy nhiên, có một số cách tiếp cận thông dụng mà các bạn nên cân nhắc. -#### Phân nhóm theo tính năng hoặc đường dẫn {#grouping-by-features-or-routes} +#### Phân nhóm theo tính năng hoặc đường dẫn {#Phân-nhóm-theo-tính-năng-hoặc-đường-dẫn} Một cách thông thường để hệ thống hoá dự án là nhóm các file CSS, JS, và tests chung một thư mục và phân các thư mục này theo tính năng hoặc đường dẫn. @@ -37,7 +37,7 @@ profile/ Định nghĩa của "tính năng" tuỳ thuộc vào cách các bạn định nghĩa, không có khái niệm chung ở đây. Nếu bạn không thể nghĩ ra một danh sách các thư mục top-level, bạn có thể hỏi những người dùng đâu là các thành phần thiết yếu của sản phẩm, và dùng các thành phần này để định hình cách sắp xếp cho dự án. -#### Nhóm các file theo phân loại{#grouping-by-file-type} +#### Nhóm các file theo phân loại {#Nhóm-các-file-theo-phân-loại} Một cách phổ biến khác để sắp xếp dự án chính là nhóm các file giống nhau lại chung với nhau, ví dụ: @@ -61,11 +61,11 @@ components/ Một vài người sẽ muốn tối ưu hơn, và sắp xếp các components vào những thư mục tuỳ vào nhiệm vụ của chúng trong ứng dụng. Ví dụ, [Atomic Design](http://bradfrost.com/blog/post/atomic-web-design/) là một phương pháp thiết kế được xây dựng dựa trên nguyên tắc này. Hãy nhớ rằng đôi lúc nên sử dụng các phương pháp này như những ví dụ thay vì xem chúng như những quy luật cần phải tuân thủ. -#### Tránh đan xen quá nhiều {#avoid-too-much-nesting} +#### Tránh đan xen quá nhiều {#Tránh-đan-xen-quá-nhiều} Nhiều niềm đau khổ xuất phát từ các thư mục JavaScript bị đan xen quá nhiều trong các dự án. Nó trở nên quá khó khăn để viết các lệnh import giữa chúng, hoặc để cập nhật các import khi các file bị di chuyển. Trừ khi bạn có một lý do khá thuyết phục để dùng một cấu trúc thư mục chằn chịt, hãy hạn chế bản thân bạn ở 3 đến 4 lớp thư mục trong 1 dự án. Đương nhiên, đây chỉ là một lời khuyên, và nó có thề sẽ không phù hợp với dự án của bạn. -#### Đừng suy nghĩ phức tạp {#dont-overthink-it} +#### Đừng suy nghĩ phức tạp {#Đừng-suy-nghĩ-phức-tạp} Nếu bạn vừa bắt đầu một dự án, [đừng tốn quá 5 phút](https://en.wikipedia.org/wiki/Analysis_paralysis) cho việc lựa chọn một cấu trúc file. Hãy chọn bất kỳ cách tiếp cận được nêu trên (hoặc hãy tự nghĩ ra cách của bạn) và bắt đầu viết code! Khả năng cao là bạn sẽ phải suy nghĩ lại về cách sắp xếp sau khi bạn bắt đầu viết code thực sự. From 5ff8c753fcfac6e714620e46938c2b278a9b1bd3 Mon Sep 17 00:00:00 2001 From: Ted Le Date: Wed, 15 Sep 2021 01:12:48 +0200 Subject: [PATCH 4/4] Another edi --- content/docs/faq-structure.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/docs/faq-structure.md b/content/docs/faq-structure.md index 77c4bc5e5..a005b61f2 100644 --- a/content/docs/faq-structure.md +++ b/content/docs/faq-structure.md @@ -1,16 +1,16 @@ --- id: faq-structure -title: Cấu Trúc Dự Án +title: File Structure permalink: docs/faq-structure.html layout: docs category: FAQ --- -### Có cách nào được khuyên dùng để sắp xếp các dự án React? {#Có-cách-nào-được-khuyên-dùng-để-sắp-xếp-các-dự-án-React} +### Có cách nào được khuyên dùng để sắp xếp các dự án React? {#is-there-a-recommended-way-to-structure-react-projects} React không có ý kiến về cách bạn sắp xếp các files trong các thư mục. Tuy nhiên, có một số cách tiếp cận thông dụng mà các bạn nên cân nhắc. -#### Phân nhóm theo tính năng hoặc đường dẫn {#Phân-nhóm-theo-tính-năng-hoặc-đường-dẫn} +#### Phân nhóm theo tính năng hoặc đường dẫn {#grouping-by-features-or-routes} Một cách thông thường để hệ thống hoá dự án là nhóm các file CSS, JS, và tests chung một thư mục và phân các thư mục này theo tính năng hoặc đường dẫn. @@ -37,7 +37,7 @@ profile/ Định nghĩa của "tính năng" tuỳ thuộc vào cách các bạn định nghĩa, không có khái niệm chung ở đây. Nếu bạn không thể nghĩ ra một danh sách các thư mục top-level, bạn có thể hỏi những người dùng đâu là các thành phần thiết yếu của sản phẩm, và dùng các thành phần này để định hình cách sắp xếp cho dự án. -#### Nhóm các file theo phân loại {#Nhóm-các-file-theo-phân-loại} +#### Nhóm các file theo phân loại{#grouping-by-file-type} Một cách phổ biến khác để sắp xếp dự án chính là nhóm các file giống nhau lại chung với nhau, ví dụ: @@ -61,11 +61,11 @@ components/ Một vài người sẽ muốn tối ưu hơn, và sắp xếp các components vào những thư mục tuỳ vào nhiệm vụ của chúng trong ứng dụng. Ví dụ, [Atomic Design](http://bradfrost.com/blog/post/atomic-web-design/) là một phương pháp thiết kế được xây dựng dựa trên nguyên tắc này. Hãy nhớ rằng đôi lúc nên sử dụng các phương pháp này như những ví dụ thay vì xem chúng như những quy luật cần phải tuân thủ. -#### Tránh đan xen quá nhiều {#Tránh-đan-xen-quá-nhiều} +#### Tránh đan xen quá nhiều {#avoid-too-much-nesting} Nhiều niềm đau khổ xuất phát từ các thư mục JavaScript bị đan xen quá nhiều trong các dự án. Nó trở nên quá khó khăn để viết các lệnh import giữa chúng, hoặc để cập nhật các import khi các file bị di chuyển. Trừ khi bạn có một lý do khá thuyết phục để dùng một cấu trúc thư mục chằn chịt, hãy hạn chế bản thân bạn ở 3 đến 4 lớp thư mục trong 1 dự án. Đương nhiên, đây chỉ là một lời khuyên, và nó có thề sẽ không phù hợp với dự án của bạn. -#### Đừng suy nghĩ phức tạp {#Đừng-suy-nghĩ-phức-tạp} +#### Đừng suy nghĩ phức tạp {#dont-overthink-it} Nếu bạn vừa bắt đầu một dự án, [đừng tốn quá 5 phút](https://en.wikipedia.org/wiki/Analysis_paralysis) cho việc lựa chọn một cấu trúc file. Hãy chọn bất kỳ cách tiếp cận được nêu trên (hoặc hãy tự nghĩ ra cách của bạn) và bắt đầu viết code! Khả năng cao là bạn sẽ phải suy nghĩ lại về cách sắp xếp sau khi bạn bắt đầu viết code thực sự.