From af15db7f2ad07989136ebd61e8e7d651a945f6bc Mon Sep 17 00:00:00 2001 From: RinatRezyapov Date: Tue, 12 Feb 2019 21:02:34 +0500 Subject: [PATCH 1/7] Translation faq-structure --- content/docs/faq-structure.md | 31 +++++++++++++++---------------- content/docs/nav.yml | 2 +- 2 files changed, 16 insertions(+), 17 deletions(-) diff --git a/content/docs/faq-structure.md b/content/docs/faq-structure.md index 4241a04dd..a208380ad 100644 --- a/content/docs/faq-structure.md +++ b/content/docs/faq-structure.md @@ -1,18 +1,18 @@ --- id: faq-structure -title: File Structure +title: Структура файлов 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} +### Как мне структурировать 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. +Единого мнения на этот счёт не существует. Тем не менее есть несколько общих подходов, популярных в экосистеме, которые вы, возможно, захотите рассмотреть. -#### Grouping by features or routes {#grouping-by-features-or-routes} +#### Группировка по функционалу или маршруту {#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. +Один из подходов это размещение файлов CSS, JS и тестов в папках, сгруппированных по функционалу или маршруту. ``` 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. +Понятие «функционал» не является универсальным и поэтому выбор уровня детализации остается за вами. Если у вас не получается составить список папок верхнего уровня, вы можете спросить у пользователей вашего продукта, из каких основных частей этот продукт состоит, и взять модель мышления пользователей за образец. -#### Grouping by file type {#grouping-by-file-type} +#### Группировка по типу файла {#grouping-by-file-type} -Another popular way to structure projects is to group similar files together, for example: +Другим популярным способом структурирования проектов является группировка файлов на основе схожести, например: ``` api/ @@ -58,17 +58,16 @@ components/ ProfileHeader.js ProfileHeader.css ``` +Некоторые предпочитают идти еще дальше и размещать компоненты в различные папки в зависимости от их роли в приложении. К примеру, методология разработки [Atomic Design](http://bradfrost.com/blog/post/atomic-web-design/) построена на этом принципе. Помните, что данные методологии следует рассматривать как полезные примеры, а не как строгие правила. -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. +#### Избегайте чрезмерной вложенности {#avoid-too-much-nesting} -#### Avoid too much nesting {#avoid-too-much-nesting} +Проблем, связанных с чрезмерной вложенностью папок в JavaScript проектах, может возникнуть достаточно много. Одна из них -- это сложность контроля относительных импортов или обновления этих импортов при перемещении файлов. Если у вас нет веских оснований использовать глубокую вложенность папок, подумайте о том, чтобы ограничить себя максимум тремя или четырьмя уровнями вложенности в рамках одного проекта. Разумеется, это всего лишь рекомендация и она может быть не актуальна в конкретном случае. -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. +#### Не переусердствуйте {#dont-overthink-it} -#### Don't overthink it {#dont-overthink-it} +Если вы только начинаете проект, [не тратьте более 5 минут](https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%BF%D0%B0%D1%80%D0%B0%D0%BB%D0%B8%D1%87) на выбор структуры проекта. Используйте любой из перечисленных выше подходов (или придумайте свой собственный) и начинайте писать код! Есть большая вероятность что вы вернетесь к переосмыслению структуры проекта после написания некоторого количества кода. -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. +Если вы чувствуете что окончательно застряли, начинайте с одной папки. Со временем, она станет настолько большой, что вам захочется разделить некоторые файлы от остальных. К этому времени у вас будет достаточно знаний, чтобы определить, какие файлы вы редактируете чаще всего. Как правило, файлы, которые часто меняются вместе, следует держать ближе друг к другу. Этот принцип называется «совместное размещение». -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". - -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. +На практике, проекты часто используют сочетание нескольких вышеупомянутых подходов. Поэтому выбор «правильного» подхода, в самом начале проекта, не слишком важен. \ No newline at end of file diff --git a/content/docs/nav.yml b/content/docs/nav.yml index fd6bdeb14..7e338788d 100644 --- a/content/docs/nav.yml +++ b/content/docs/nav.yml @@ -146,7 +146,7 @@ - id: faq-styling title: Styling and CSS - id: faq-structure - title: File Structure + title: Структура файлов - id: faq-versioning title: Versioning Policy - id: faq-internals From 3031b4c626846b262952a41a1be5cb097a1e9688 Mon Sep 17 00:00:00 2001 From: RinatRezyapov Date: Wed, 13 Feb 2019 21:04:40 +0500 Subject: [PATCH 2/7] Translation faq-structure fix 1 --- content/docs/faq-structure.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/content/docs/faq-structure.md b/content/docs/faq-structure.md index a208380ad..a1031a605 100644 --- a/content/docs/faq-structure.md +++ b/content/docs/faq-structure.md @@ -6,13 +6,13 @@ layout: docs category: FAQ --- -### Как мне структурировать React проекты? {#is-there-a-recommended-way-to-structure-react-projects} +### Как мне структурировать React-проекты? {#is-there-a-recommended-way-to-structure-react-projects} -Единого мнения на этот счёт не существует. Тем не менее есть несколько общих подходов, популярных в экосистеме, которые вы, возможно, захотите рассмотреть. +Единого мнения на этот счёт не существует. Тем не менее, есть несколько общих подходов, популярных в экосистеме, которые вы, возможно, захотите рассмотреть. #### Группировка по функционалу или маршруту {#grouping-by-features-or-routes} -Один из подходов это размещение файлов CSS, JS и тестов в папках, сгруппированных по функционалу или маршруту. +Один из популярных подходов -- это размещение файлов CSS, JS и тестов в папках, сгруппированных по функционалу или маршруту. ``` common/ @@ -39,7 +39,7 @@ profile/ #### Группировка по типу файла {#grouping-by-file-type} -Другим популярным способом структурирования проектов является группировка файлов на основе схожести, например: +Другим популярным способом структурирования проектов является группировка похожих файлов, например: ``` api/ @@ -58,15 +58,15 @@ components/ ProfileHeader.js ProfileHeader.css ``` -Некоторые предпочитают идти еще дальше и размещать компоненты в различные папки в зависимости от их роли в приложении. К примеру, методология разработки [Atomic Design](http://bradfrost.com/blog/post/atomic-web-design/) построена на этом принципе. Помните, что данные методологии следует рассматривать как полезные примеры, а не как строгие правила. +Некоторые предпочитают идти ещё дальше и размещать компоненты в различные папки в зависимости от их роли в приложении. К примеру, методология разработки [Atomic Design](http://bradfrost.com/blog/post/atomic-web-design/) построена на этом принципе. Помните, что данные методологии следует рассматривать как полезные примеры, а не как строгие правила. #### Избегайте чрезмерной вложенности {#avoid-too-much-nesting} -Проблем, связанных с чрезмерной вложенностью папок в JavaScript проектах, может возникнуть достаточно много. Одна из них -- это сложность контроля относительных импортов или обновления этих импортов при перемещении файлов. Если у вас нет веских оснований использовать глубокую вложенность папок, подумайте о том, чтобы ограничить себя максимум тремя или четырьмя уровнями вложенности в рамках одного проекта. Разумеется, это всего лишь рекомендация и она может быть не актуальна в конкретном случае. +Проблем, связанных с чрезмерной вложенностью папок в JavaScript-проектах, может возникнуть достаточно много. Одна из них -- это сложность контроля относительных импортов или обновления этих импортов при перемещении файлов. Если у вас нет веских оснований использовать глубокую вложенность папок, подумайте о том, чтобы ограничить себя максимум тремя или четырьмя уровнями вложенности в рамках одного проекта. Разумеется, это всего лишь рекомендация и она может быть не актуальна в случае вашего проекта. #### Не переусердствуйте {#dont-overthink-it} -Если вы только начинаете проект, [не тратьте более 5 минут](https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%BF%D0%B0%D1%80%D0%B0%D0%BB%D0%B8%D1%87) на выбор структуры проекта. Используйте любой из перечисленных выше подходов (или придумайте свой собственный) и начинайте писать код! Есть большая вероятность что вы вернетесь к переосмыслению структуры проекта после написания некоторого количества кода. +Если вы только начинаете проект, [не тратьте более 5 минут](https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%BF%D0%B0%D1%80%D0%B0%D0%BB%D0%B8%D1%87) на выбор структуры проекта. Используйте любой из перечисленных выше подходов (или придумайте свой собственный) и начинайте писать код! Есть большая вероятность, что вы вернётесь к переосмыслению структуры проекта после написания некоторого количества кода. Если вы чувствуете что окончательно застряли, начинайте с одной папки. Со временем, она станет настолько большой, что вам захочется разделить некоторые файлы от остальных. К этому времени у вас будет достаточно знаний, чтобы определить, какие файлы вы редактируете чаще всего. Как правило, файлы, которые часто меняются вместе, следует держать ближе друг к другу. Этот принцип называется «совместное размещение». From f5951191b19430db5ba4d545279cc33f7f32d98a Mon Sep 17 00:00:00 2001 From: RinatRezyapov Date: Thu, 14 Feb 2019 19:41:30 +0500 Subject: [PATCH 3/7] Translation faq-structure fix 2 --- content/docs/faq-structure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/faq-structure.md b/content/docs/faq-structure.md index a1031a605..e27fa22b4 100644 --- a/content/docs/faq-structure.md +++ b/content/docs/faq-structure.md @@ -68,6 +68,6 @@ components/ Если вы только начинаете проект, [не тратьте более 5 минут](https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%BF%D0%B0%D1%80%D0%B0%D0%BB%D0%B8%D1%87) на выбор структуры проекта. Используйте любой из перечисленных выше подходов (или придумайте свой собственный) и начинайте писать код! Есть большая вероятность, что вы вернётесь к переосмыслению структуры проекта после написания некоторого количества кода. -Если вы чувствуете что окончательно застряли, начинайте с одной папки. Со временем, она станет настолько большой, что вам захочется разделить некоторые файлы от остальных. К этому времени у вас будет достаточно знаний, чтобы определить, какие файлы вы редактируете чаще всего. Как правило, файлы, которые часто меняются вместе, следует держать ближе друг к другу. Этот принцип называется «совместное размещение». +Если вы чувствуете что окончательно застряли, начинайте с одной папки. Со временем, она станет настолько большой, что вам захочется отделить некоторые файлы от остальных. К этому времени у вас будет достаточно знаний, чтобы определить, какие файлы вы редактируете чаще всего. Как правило, файлы, которые часто меняются вместе, следует держать ближе друг к другу. Этот принцип называется «совместное размещение». На практике, проекты часто используют сочетание нескольких вышеупомянутых подходов. Поэтому выбор «правильного» подхода, в самом начале проекта, не слишком важен. \ No newline at end of file From 3b575c7e9fdaeb49212958b156277f2397665639 Mon Sep 17 00:00:00 2001 From: RinatRezyapov Date: Sat, 16 Feb 2019 13:07:29 +0500 Subject: [PATCH 4/7] Translation faq-structure fix 3 --- 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 e27fa22b4..18172ff4a 100644 --- a/content/docs/faq-structure.md +++ b/content/docs/faq-structure.md @@ -66,8 +66,8 @@ components/ #### Не переусердствуйте {#dont-overthink-it} -Если вы только начинаете проект, [не тратьте более 5 минут](https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%BF%D0%B0%D1%80%D0%B0%D0%BB%D0%B8%D1%87) на выбор структуры проекта. Используйте любой из перечисленных выше подходов (или придумайте свой собственный) и начинайте писать код! Есть большая вероятность, что вы вернётесь к переосмыслению структуры проекта после написания некоторого количества кода. +Если вы только начинаете проект, [не тратьте более 5 минут](https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%BF%D0%B0%D1%80%D0%B0%D0%BB%D0%B8%D1%87) на выбор структуры проекта. Выберите любой из перечисленных выше подходов (или придумайте свой собственный) и начните писать код! Есть большая вероятность, что вы вернётесь к переосмыслению структуры проекта после написания некоторого количества кода. Если вы чувствуете что окончательно застряли, начинайте с одной папки. Со временем, она станет настолько большой, что вам захочется отделить некоторые файлы от остальных. К этому времени у вас будет достаточно знаний, чтобы определить, какие файлы вы редактируете чаще всего. Как правило, файлы, которые часто меняются вместе, следует держать ближе друг к другу. Этот принцип называется «совместное размещение». -На практике, проекты часто используют сочетание нескольких вышеупомянутых подходов. Поэтому выбор «правильного» подхода, в самом начале проекта, не слишком важен. \ No newline at end of file +На практике проекты часто используют сочетание нескольких вышеупомянутых подходов. Поэтому выбор «правильного» подхода, в самом начале проекта, не слишком важен. \ No newline at end of file From f38fdd5c9d3ba3227b1d24fdebb91b16d7472b4a Mon Sep 17 00:00:00 2001 From: RinatRezyapov Date: Sat, 16 Feb 2019 13:13:36 +0500 Subject: [PATCH 5/7] Translation faq-structure fix 4 --- content/docs/faq-structure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/faq-structure.md b/content/docs/faq-structure.md index 18172ff4a..898050dbf 100644 --- a/content/docs/faq-structure.md +++ b/content/docs/faq-structure.md @@ -70,4 +70,4 @@ components/ Если вы чувствуете что окончательно застряли, начинайте с одной папки. Со временем, она станет настолько большой, что вам захочется отделить некоторые файлы от остальных. К этому времени у вас будет достаточно знаний, чтобы определить, какие файлы вы редактируете чаще всего. Как правило, файлы, которые часто меняются вместе, следует держать ближе друг к другу. Этот принцип называется «совместное размещение». -На практике проекты часто используют сочетание нескольких вышеупомянутых подходов. Поэтому выбор «правильного» подхода, в самом начале проекта, не слишком важен. \ No newline at end of file +На практике проекты часто используют сочетание нескольких вышеупомянутых подходов. Поэтому выбор «правильного» подхода в самом начале проекта не слишком важен. \ No newline at end of file From 0b2f0dff00e7b5a301e3e2174ba810654fbb645d Mon Sep 17 00:00:00 2001 From: RinatRezyapov Date: Tue, 19 Feb 2019 20:47:17 +0500 Subject: [PATCH 6/7] Translation faq-structure fix 5 --- 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 898050dbf..e19c22272 100644 --- a/content/docs/faq-structure.md +++ b/content/docs/faq-structure.md @@ -6,13 +6,13 @@ layout: docs category: FAQ --- -### Как мне структурировать React-проекты? {#is-there-a-recommended-way-to-structure-react-projects} +### Есть ли рекомендации по структуре React-проектов? {#is-there-a-recommended-way-to-structure-react-projects} -Единого мнения на этот счёт не существует. Тем не менее, есть несколько общих подходов, популярных в экосистеме, которые вы, возможно, захотите рассмотреть. +Единого мнения не существует. Однако, есть несколько популярных подходов, которые вы можете рассмотреть. -#### Группировка по функционалу или маршруту {#grouping-by-features-or-routes} +#### Группировка по возможностям или маршрутам {#grouping-by-features-or-routes} -Один из популярных подходов -- это размещение файлов CSS, JS и тестов в папках, сгруппированных по функционалу или маршруту. +Один из популярных подходов -- это размещение файлов CSS, JS и тестов в папках, сгруппированных по возможности или маршруту. ``` common/ @@ -35,7 +35,7 @@ profile/ ProfileAPI.js ``` -Понятие «функционал» не является универсальным и поэтому выбор уровня детализации остается за вами. Если у вас не получается составить список папок верхнего уровня, вы можете спросить у пользователей вашего продукта, из каких основных частей этот продукт состоит, и взять модель мышления пользователей за образец. +Понятие «возможность» не является универсальным, поэтому выбор уровня детализации остается за вами. Если у вас не получается составить список папок верхнего уровня, вы можете спросить у пользователей вашего продукта, из каких основных частей он состоит, и взять модель мышления пользователей за образец. #### Группировка по типу файла {#grouping-by-file-type} @@ -68,6 +68,6 @@ components/ Если вы только начинаете проект, [не тратьте более 5 минут](https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%BF%D0%B0%D1%80%D0%B0%D0%BB%D0%B8%D1%87) на выбор структуры проекта. Выберите любой из перечисленных выше подходов (или придумайте свой собственный) и начните писать код! Есть большая вероятность, что вы вернётесь к переосмыслению структуры проекта после написания некоторого количества кода. -Если вы чувствуете что окончательно застряли, начинайте с одной папки. Со временем, она станет настолько большой, что вам захочется отделить некоторые файлы от остальных. К этому времени у вас будет достаточно знаний, чтобы определить, какие файлы вы редактируете чаще всего. Как правило, файлы, которые часто меняются вместе, следует держать ближе друг к другу. Этот принцип называется «совместное размещение». +Если вы чувствуете что окончательно застряли, начинайте с одной папки. Со временем, когда она станет настолько большой, что вам захочется отделить некоторые файлы от остальных, у вас будет достаточно знаний, чтобы определить, какие файлы вы редактируете чаще всего. Как правило, файлы, которые часто меняются вместе, следует держать ближе друг к другу. Этот принцип называется «совместное размещение». На практике проекты часто используют сочетание нескольких вышеупомянутых подходов. Поэтому выбор «правильного» подхода в самом начале проекта не слишком важен. \ No newline at end of file From 526a45e0d75a53cd1d2becc215d4433abb8a1317 Mon Sep 17 00:00:00 2001 From: RinatRezyapov Date: Thu, 21 Feb 2019 20:24:22 +0500 Subject: [PATCH 7/7] Translation faq-structure fix 6 --- content/docs/faq-structure.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/docs/faq-structure.md b/content/docs/faq-structure.md index e19c22272..c001b8f4b 100644 --- a/content/docs/faq-structure.md +++ b/content/docs/faq-structure.md @@ -10,9 +10,9 @@ category: FAQ Единого мнения не существует. Однако, есть несколько популярных подходов, которые вы можете рассмотреть. -#### Группировка по возможностям или маршрутам {#grouping-by-features-or-routes} +#### Группировка по функциональности или маршруту {#grouping-by-features-or-routes} -Один из популярных подходов -- это размещение файлов CSS, JS и тестов в папках, сгруппированных по возможности или маршруту. +Один из популярных подходов -- это размещение файлов CSS, JS и тестов в папках, сгруппированных по функциональности или маршруту. ``` common/ @@ -35,7 +35,7 @@ profile/ ProfileAPI.js ``` -Понятие «возможность» не является универсальным, поэтому выбор уровня детализации остается за вами. Если у вас не получается составить список папок верхнего уровня, вы можете спросить у пользователей вашего продукта, из каких основных частей он состоит, и взять модель мышления пользователей за образец. +Понятие «функциональность» не является универсальным, поэтому выбор уровня детализации остается за вами. Если у вас не получается составить список папок верхнего уровня, вы можете спросить у пользователей вашего продукта, из каких основных частей он состоит, и взять модель мышления пользователей за образец. #### Группировка по типу файла {#grouping-by-file-type}