From a917a29537224b7a3dc9d48c67afd8cc0d37487f Mon Sep 17 00:00:00 2001 From: echobrain Date: Mon, 11 Mar 2019 00:52:46 +0300 Subject: [PATCH 01/51] translation --- content/docs/design-principles.md | 83 ++++++++++++++++--------------- 1 file changed, 42 insertions(+), 41 deletions(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 9e10f39d5..4a73fb740 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -1,6 +1,6 @@ --- id: design-principles -title: Design Principles +title: Принципы разработки layout: contributing permalink: docs/design-principles.html prev: implementation-notes.html @@ -8,85 +8,86 @@ redirect_from: - "contributing/design-principles.html" --- -We wrote this document so that you have a better idea of how we decide what React does and what React doesn't do, and what our development philosophy is like. While we are excited to see community contributions, we are not likely to choose a path that violates one or more of these principles. +Мы написали эту статью, чтобы вы лучше понимали, как принимаются решения о том что React должен делать и чего не должен, и что из себя представляют наши принципы разработки. Хоть мы и рады видеть вклад сообщества, вряд ли мы выберем путь, который нарушает один или несколько из этих принципов. ->**Note:** +>**Примечание:** > ->This document assumes a strong understanding of React. It describes the design principles of *React itself*, not React components or applications. +>Эта статья подразумевает глубокое понимание React. В ней описаны концепции разработки *самого React*, но не React-компонент или приложений. > ->For an introduction to React, check out [Thinking in React](/docs/thinking-in-react.html) instead. +>Для знакомства с React лучше почитайте [Философия React](/docs/thinking-in-react.html). -### Composition {#composition} +### Композиция {#composition} -The key feature of React is composition of components. Components written by different people should work well together. It is important to us that you can add functionality to a component without causing rippling changes throughout the codebase. +Ключевая возможность React – это композиция компонент. Компоненты, написанные разными людьми, должны хорошо работать вместе. Для нас важно, что вы можете добавлять в компонент функционал, не вызывая волну изменений по всему коду. -For example, it should be possible to introduce some local state into a component without changing any of the components using it. Similarly, it should be possible to add some initialization and teardown code to any component when necessary. +Например, должна быть возможность вводить некое локальное состояние в компонент без изменения использующих его компонент. Так же, должна быть возможность добавлять при необходимости код инициализации и разрушения в любой компонент. -There is nothing "bad" about using state or lifecycle methods in components. Like any powerful feature, they should be used in moderation, but we have no intention to remove them. On the contrary, we think they are integral parts of what makes React useful. We might enable [more functional patterns](https://github.com/reactjs/react-future/tree/master/07%20-%20Returning%20State) in the future, but both local state and lifecycle methods will be a part of that model. +Нет ничего "плохого" в использовании состояния или методов жизненного цикла в компонентах. Как и любую мощную возможность, их стоит использовать в меру, но мы не собираемся их удалять. Напротив, мы считаем, что они являются неотъемлемой частью того, что делает React полезным. Возможно, мы добавим [больше функциональных шаблонов](https://github.com/reactjs/react-future/tree/master/07%20-%20Returning%20State) в будущем, но как локальное состояние, так и методы жизненного цикла будут частью этой модели. -Components are often described as "just functions" but in our view they need to be more than that to be useful. In React, components describe any composable behavior, and this includes rendering, lifecycle, and state. Some external libraries like [Relay](https://facebook.github.io/relay/) augment components with other responsibilities such as describing data dependencies. It is possible that those ideas might make it back into React too in some form. +Компоненты часто описываются как "просто функции", но, на наш взгляд, они должны быть более полезными. В React компоненты описывают любое поведение композиции, включая рендеринг, жизненный цикл и состояние. Некоторые сторонние библиотеки, вроде [Relay](https://facebook.github.io/relay/), дополняют компоненты другими функциями, например описанием зависимостей данных. Вполне возможно, что в той или иной форме эти идеи могут прийти в React. -### Common Abstraction {#common-abstraction} +### Общая абстракция {#common-abstraction} -In general we [resist adding features](https://www.youtube.com/watch?v=4anAwXYqLG8) that can be implemented in userland. We don't want to bloat your apps with useless library code. However, there are exceptions to this. +В целом, мы [против добавления функционала](https://www.youtube.com/watch?v=4anAwXYqLG8), который может быть реализован в пользовательских приложениях. Мы не хотим раздувать ваши приложения бесполезным кодом библиотеки. Но, из этого правила есть исключения. -For example, if React didn't provide support for local state or lifecycle methods, people would create custom abstractions for them. When there are multiple abstractions competing, React can't enforce or take advantage of the properties of either of them. It has to work with the lowest common denominator. +Например, если бы React не предоставлял поддержку локального состояния или методов жизненного цикла, люди бы создавали собственные абстракции для них. Когда есть несколько конкурирующих абстракций, React не может применить или использовать их свойства. Он должен работать с наименьшим общим знаменателем. -This is why sometimes we add features to React itself. If we notice that many components implement a certain feature in incompatible or inefficient ways, we might prefer to bake it into React. We don't do it lightly. When we do it, it's because we are confident that raising the abstraction level benefits the whole ecosystem. State, lifecycle methods, cross-browser event normalization are good examples of this. +Вот почему иногда мы добавляем функционал в сам React. Если мы замечаем, что какой-то функционал реализуется несовместимо или неэффективно во многих компонентах, мы можем захотеть внедрить его в React. Это не происходит просто так. +Если мы добавляем новый функционал, значит мы уверены, что повышение уровня абстракции принесет выгоду всей экосистеме. Хорошие примеры для этого – состояние, методы жизненного цикла, кросс-браузерная нормализация событий. -We always discuss such improvement proposals with the community. You can find some of those discussions by the ["big picture"](https://github.com/facebook/react/issues?q=is:open+is:issue+label:"Type:+Big+Picture") label on the React issue tracker. +Мы всегда обсуждаем с сообществом такие предложения по улучшению. Некоторые их этих обсуждений можно найти по метке ["big picture"](https://github.com/facebook/react/issues?q=is:open+is:issue+label:"Type:+Big+Picture") в трекере задач React. -### Escape Hatches {#escape-hatches} +### Лазейки {#escape-hatches} -React is pragmatic. It is driven by the needs of the products written at Facebook. While it is influenced by some paradigms that are not yet fully mainstream such as functional programming, staying accessible to a wide range of developers with different skills and experience levels is an explicit goal of the project. +React прагматичен. Это обусловлено потребностями продуктов, написанных в Facebook. Хоть на него и влияют некоторые не самые популярные парадигмы, такие как функциональное программирование, цель проекта – оставаться доступным для широкого круга разработчиков с разным уровнем опыта и навыками. -If we want to deprecate a pattern that we don't like, it is our responsibility to consider all existing use cases for it and [educate the community about the alternatives](/blog/2016/07/13/mixins-considered-harmful.html) before we deprecate it. If some pattern that is useful for building apps is hard to express in a declarative way, we will [provide an imperative API](/docs/more-about-refs.html) for it. If we can't figure out a perfect API for something that we found necessary in many apps, we will [provide a temporary subpar working API](/docs/legacy-context.html) as long as it is possible to get rid of it later and it leaves the door open for future improvements. +Если мы хотим отказаться от паттерна, который нам не нравится, мы должны рассмотреть все существующие варианты его использования и [проинформировать сообщество об альтернативах](/blog/2016/07/13/mixins-considered-harmful.html), прежде чем отказаться от него. Если какой-то паттерн, полезный для создания приложений, трудно описать декларативно, мы [предоставим для него императивное API](/docs/more-about-refs.html). Если мы не можем найти идеальное API для того, что мы считаем необходимым во многих приложениях, мы [предоставим временное, частично работающее API](/docs/legacy-context.html), позже от него можно будет избавиться. Это оставляет открытую дверь для будущих улучшений. -### Stability {#stability} +### Стабильность {#stability} -We value API stability. At Facebook, we have more than 50 thousand components using React. Many other companies, including [Twitter](https://twitter.com/) and [Airbnb](https://www.airbnb.com/), are also heavy users of React. This is why we are usually reluctant to change public APIs or behavior. +Мы ценим стабильность API. У нас в Facebook более 50 тысяч компонент, использующих React. Многие другие компании, включая [Twitter](https://twitter.com/) и [Airbnb](https://www.airbnb.com/), также активно используют React. Поэтому мы обычно неохотно меняем публичные API или поведение. -However we think stability in the sense of "nothing changes" is overrated. It quickly turns into stagnation. Instead, we prefer the stability in the sense of "It is heavily used in production, and when something changes, there is a clear (and preferably automated) migration path." +Однако, мы считаем преувеличением думать, что стабильность это когда "ничего не меняется". Это быстро приводит к застою. Вместо этого, мы предпочитаем воспринимать стабильность в смысле "это много используется в продакшене и когда что-то меняется, существует четкий (и желательно автоматизированный) план миграции". -When we deprecate a pattern, we study its internal usage at Facebook and add deprecation warnings. They let us assess the impact of the change. Sometimes we back out if we see that it is too early, and we need to think more strategically about getting the codebases to the point where they are ready for this change. +Когда мы исключаем паттерн, мы изучаем как он используется внутри Facebook и добавляем предупреждения об исключении. Что позволяет нам оценить эффект изменения. Иногда мы отменяем изменения, если видим, что еще слишком рано и нам нужно продумать стратегию продвижения кодовой базы к точке готовности к изменениям. -If we are confident that the change is not too disruptive and the migration strategy is viable for all use cases, we release the deprecation warning to the open source community. We are closely in touch with many users of React outside of Facebook, and we monitor popular open source projects and guide them in fixing those deprecations. +Если мы уверены, что изменение не слишком большое и для всех случаев использования возможна миграция, мы выпускаем предупреждение об исключении в OSS-сообщество. Мы тесно общаемся со многими React-пользователями вне Facebook, следим за популярными OSS-проектами и помогаем им исправлять устаревший код. -Given the sheer size of the Facebook React codebase, successful internal migration is often a good indicator that other companies won't have problems either. Nevertheless sometimes people point out additional use cases we haven't thought of, and we add escape hatches for them or rethink our approach. +Учитывая огромный размер кодовой базы React в Facebook, успешная внутренняя миграция часто является хорошим индикатором того, что в других компаниях также не будет проблем. Тем не менее, люди иногда указывают на неучтенные варианты использования и мы добавляем лазейки или пересматриваем подход. -We don't deprecate anything without a good reason. We recognize that sometimes deprecations warnings cause frustration but we add them because deprecations clean up the road for the improvements and new features that we and many people in the community consider valuable. +Мы ничего не исключаем без веской причины. Мы понимаем, что иногда предупреждения об исключениях разочаровывают. Но мы их добавляем, так как исключения открывают дорогу для улучшений и новых возможностей, которые мы и сообщество считаем важными. -For example, we added a [warning about unknown DOM props](/warnings/unknown-prop.html) in React 15.2.0. Many projects were affected by this. However fixing this warning is important so that we can introduce the support for [custom attributes](https://github.com/facebook/react/issues/140) to React. There is a reason like this behind every deprecation that we add. +Например, мы добавили [предупреждение о неизвестных DOM-свойствах](/warnings/unknown-prop.html) в React 15.2.0. Этим мы затронули многие проекты. Однако, исправление этого предупреждения важно для добавления в React поддержки [пользовательских атрибутов](https://github.com/facebook/react/issues/140). Подобная причина стоит за каждым исключением, которое мы добавляем. -When we add a deprecation warning, we keep it for the rest of the current major version, and [change the behavior in the next major version](/blog/2016/02/19/new-versioning-scheme.html). If there is a lot of repetitive manual work involved, we release a [codemod](https://www.youtube.com/watch?v=d0pOgY8__JM) script that automates most of the change. Codemods enable us to move forward without stagnation in a massive codebase, and we encourage you to use them as well. +При добавлении предупреждения об исключении, мы не удаляем его пока текущая мажорная версия не устарела, [изменяя поведение только в следующей мажорной версии](/blog/2016/02/19/new-versioning-scheme.html). Если исключение создает много повторяющейся ручной работы, мы публикуем [codemod-скрипт](https://www.youtube.com/watch?v=d0pOgY8__JM), который автоматизирует большую часть изменений. Codemod-скрипты дают нам возможность двигаться вперед, не закапываясь в куче кода. Рекомендуем вам тоже их использовать. -You can find the codemods that we released in the [react-codemod](https://github.com/reactjs/react-codemod) repository. +Вы можете найти уже вышедшие codemod-скрипты в [react-codemod](https://github.com/reactjs/react-codemod) репозитории. -### Interoperability {#interoperability} +### Совместимость {#interoperability} -We place high value in interoperability with existing systems and gradual adoption. Facebook has a massive non-React codebase. Its website uses a mix of a server-side component system called XHP, internal UI libraries that came before React, and React itself. It is important to us that any product team can [start using React for a small feature](https://www.youtube.com/watch?v=BF58ZJ1ZQxY) rather than rewrite their code to bet on it. +Мы придаем большое значение совместимости с существующими системами и возможности постепенного внедрения. В Facebook есть много кода, написанного не на React. Сайт использует смесь из XHP – системы серверных компонент, внутренних UI-библиотек, которые пришли до React, и самого React. Для нас важно, что любая продуктовая команда может [начать использовать React для небольшого функционала](https://www.youtube.com/watch?v=BF58ZJ1ZQxY), а не делать ставку на переписывание своего кода. -This is why React provides escape hatches to work with mutable models, and tries to work well together with other UI libraries. You can wrap an existing imperative UI into a declarative component, and vice versa. This is crucial for gradual adoption. +По этой причине React предоставляет лазейки для работы с изменяемыми моделями и пытается хорошо работать вместе с другими UI-библиотеками. Вы можете обернуть существующий императивный UI в декларативный компонент и наоборот. Это очень важно для постепенного внедрения. -### Scheduling {#scheduling} +### Планирование {#scheduling} -Even when your components are described as functions, when you use React you don't call them directly. Every component returns a [description of what needs to be rendered](/blog/2015/12/18/react-components-elements-and-instances.html#elements-describe-the-tree), and that description may include both user-written components like `` and platform-specific components like `
`. It is up to React to "unroll" `` at some point in the future and actually apply changes to the UI tree according to the render results of the components recursively. +Даже если компоненты описаны как функции, при использовании React они не вызываются напрямую. Каждый компонент возвращает [описание того, что должно быть отрендерено](/blog/2015/12/18/react-components-elements-and-instances.html#elements-describe-the-tree). Описание может включать как пользовательские компоненты, такие как ``, так и платформо-зависимые компоненты, такие как `
`. В дальнейшем в какой-то момент React может "развернуть" `` и фактически применить изменения к UI-дереву в соответствии с результатами рекурсивного рендеринга компонент. -This is a subtle distinction but a powerful one. Since you don't call that component function but let React call it, it means React has the power to delay calling it if necessary. In its current implementation React walks the tree recursively and calls render functions of the whole updated tree during a single tick. However in the future it might start [delaying some updates to avoid dropping frames](https://github.com/facebook/react/issues/6170). +Это тонкое, но сильное различие. Поскольку вы не вызываете этот функциональный компонент, а позволяете React вызывать его, это означает, что React может отложить вызов при необходимости. В текущей реализации React рекурсивно обходит дерево и вызывает функции рендера всего обновленного дерева за один проход. Но в будущем он может начать [задерживать некоторые обновления, чтобы избежать потери кадров](https://github.com/facebook/react/issues/6170). -This is a common theme in React design. Some popular libraries implement the "push" approach where computations are performed when the new data is available. React, however, sticks to the "pull" approach where computations can be delayed until necessary. +Это основная тема в дизайне React. Некоторые популярные библиотеки реализуют "push" подход, когда вычисления выполняются при наличии новых данных. React, наоборот, придерживается "pull" подхода, когда вычисления могут быть отложены до необходимости. -React is not a generic data processing library. It is a library for building user interfaces. We think that it is uniquely positioned in an app to know which computations are relevant right now and which are not. +React не является универсальной библиотекой обработки данных. Это библиотека для создания пользовательских интерфейсов. Мы считаем, что приложение должно знать какие вычисления сейчас актуальны, а какие нет. -If something is offscreen, we can delay any logic related to it. If data is arriving faster than the frame rate, we can coalesce and batch updates. We can prioritize work coming from user interactions (such as an animation caused by a button click) over less important background work (such as rendering new content just loaded from the network) to avoid dropping frames. +Если что-то находится вне экрана, мы можем отложить любую связанную с этим логику. Если данные поступают быстрее, чем кадры успевают обновиться, мы можем объединить их и обновлять пакетами. Мы можем приоритизировать работу, вызванную пользовательским взаимодействием (например, анимация нажатия кнопки), над менее важной фоновой работой (например, рендеринг только что загруженного из сети компонента), чтобы избежать потери кадров. -To be clear, we are not taking advantage of this right now. However the freedom to do something like this is why we prefer to have control over scheduling, and why `setState()` is asynchronous. Conceptually, we think of it as "scheduling an update". +Чтобы было понятно, мы не пользуемся этим прямо сейчас. Однако, подобная свобода объясняет, почему мы предпочитаем контролировать планирование и почему `setState()` асинхронна. Концептуально мы думаем об этом как о "планировании обновления". -The control over scheduling would be harder for us to gain if we let the user directly compose views with a "push" based paradigm common in some variations of [Functional Reactive Programming](https://en.wikipedia.org/wiki/Functional_reactive_programming). We want to own the "glue" code. +Нам было бы труднее получить контроль над планированием, если бы мы позволили пользователям напрямую создавать представления на основе "push" парадигмы, распространенной в некоторых вариациях [Функционального Реактивного Программирования](https://en.wikipedia.org/wiki/Functional_reactive_programming). Мы хотим владеть "склеивающим" кодом. -It is a key goal for React that the amount of the user code that executes before yielding back into React is minimal. This ensures that React retains the capability to schedule and split work in chunks according to what it knows about the UI. +Ключевая задача для React - минимизировать количество пользовательского кода, выполняемого перед возвращением обратно в React. Это гарантирует, что React сохранит возможность планировать и разбивать работу на части в соответствии с тем, что ему известно о UI. -There is an internal joke in the team that React should have been called "Schedule" because React does not want to be fully "reactive". +В команде есть внутренняя шутка, что React должен был называться "Schedule", потому что React не хочет быть полностью "реактивным". ### Developer Experience {#developer-experience} From bde5b2e060d739578acd909b04f1f75828de2ea9 Mon Sep 17 00:00:00 2001 From: echobrain Date: Mon, 11 Mar 2019 01:11:58 +0300 Subject: [PATCH 02/51] typos --- content/docs/design-principles.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 4a73fb740..9f5f54712 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -30,24 +30,24 @@ redirect_from: В целом, мы [против добавления функционала](https://www.youtube.com/watch?v=4anAwXYqLG8), который может быть реализован в пользовательских приложениях. Мы не хотим раздувать ваши приложения бесполезным кодом библиотеки. Но, из этого правила есть исключения. -Например, если бы React не предоставлял поддержку локального состояния или методов жизненного цикла, люди бы создавали собственные абстракции для них. Когда есть несколько конкурирующих абстракций, React не может применить или использовать их свойства. Он должен работать с наименьшим общим знаменателем. +Например, если бы React не предоставлял поддержку локального состояния или методов жизненного цикла, люди бы создавали собственные абстракции для них. Когда есть несколько конкурирующих абстракций, React не может применять или использовать их свойства. Он должен работать с наименьшим общим знаменателем. Вот почему иногда мы добавляем функционал в сам React. Если мы замечаем, что какой-то функционал реализуется несовместимо или неэффективно во многих компонентах, мы можем захотеть внедрить его в React. Это не происходит просто так. Если мы добавляем новый функционал, значит мы уверены, что повышение уровня абстракции принесет выгоду всей экосистеме. Хорошие примеры для этого – состояние, методы жизненного цикла, кросс-браузерная нормализация событий. -Мы всегда обсуждаем с сообществом такие предложения по улучшению. Некоторые их этих обсуждений можно найти по метке ["big picture"](https://github.com/facebook/react/issues?q=is:open+is:issue+label:"Type:+Big+Picture") в трекере задач React. +Мы всегда обсуждаем с сообществом такие предложения по улучшению. Некоторые из этих обсуждений можно найти по метке ["big picture"](https://github.com/facebook/react/issues?q=is:open+is:issue+label:"Type:+Big+Picture") в трекере задач React. ### Лазейки {#escape-hatches} React прагматичен. Это обусловлено потребностями продуктов, написанных в Facebook. Хоть на него и влияют некоторые не самые популярные парадигмы, такие как функциональное программирование, цель проекта – оставаться доступным для широкого круга разработчиков с разным уровнем опыта и навыками. -Если мы хотим отказаться от паттерна, который нам не нравится, мы должны рассмотреть все существующие варианты его использования и [проинформировать сообщество об альтернативах](/blog/2016/07/13/mixins-considered-harmful.html), прежде чем отказаться от него. Если какой-то паттерн, полезный для создания приложений, трудно описать декларативно, мы [предоставим для него императивное API](/docs/more-about-refs.html). Если мы не можем найти идеальное API для того, что мы считаем необходимым во многих приложениях, мы [предоставим временное, частично работающее API](/docs/legacy-context.html), позже от него можно будет избавиться. Это оставляет открытую дверь для будущих улучшений. +Если мы хотим отказаться от паттерна, который нам не нравится, мы должны рассмотреть все существующие варианты его использования и [проинформировать сообщество об альтернативах](/blog/2016/07/13/mixins-considered-harmful.html), прежде чем отказаться от него. Если какой-то полезный для создания приложений паттерн трудно описать декларативно, мы [предоставим для него императивное API](/docs/more-about-refs.html). Если мы не можем найти идеальное API для того, что мы считаем необходимым во многих приложениях, мы [предоставим временное, частично работающее API](/docs/legacy-context.html), позже от него можно будет избавиться. Это оставляет открытую дверь для будущих улучшений. ### Стабильность {#stability} -Мы ценим стабильность API. У нас в Facebook более 50 тысяч компонент, использующих React. Многие другие компании, включая [Twitter](https://twitter.com/) и [Airbnb](https://www.airbnb.com/), также активно используют React. Поэтому мы обычно неохотно меняем публичные API или поведение. +Мы ценим стабильность API. У нас в Facebook более 50 тысяч компонент, использующих React. Многие другие компании, включая [Twitter](https://twitter.com/) и [Airbnb](https://www.airbnb.com/), также активно используют React. Поэтому мы обычно нехотя меняем публичное API или поведение. -Однако, мы считаем преувеличением думать, что стабильность это когда "ничего не меняется". Это быстро приводит к застою. Вместо этого, мы предпочитаем воспринимать стабильность в смысле "это много используется в продакшене и когда что-то меняется, существует четкий (и желательно автоматизированный) план миграции". +Однако, мы считаем преувеличением думать, что стабильность – это когда "ничего не меняется". Это быстро приводит к застою. Вместо этого, мы предпочитаем воспринимать стабильность в смысле "это много используется в продакшене и когда что-то меняется, существует четкий (и желательно автоматизированный) план миграции". Когда мы исключаем паттерн, мы изучаем как он используется внутри Facebook и добавляем предупреждения об исключении. Что позволяет нам оценить эффект изменения. Иногда мы отменяем изменения, если видим, что еще слишком рано и нам нужно продумать стратегию продвижения кодовой базы к точке готовности к изменениям. From 1eaa01233449758b5a7b5ed7e573ea39e6d2e0a2 Mon Sep 17 00:00:00 2001 From: echobrain Date: Mon, 11 Mar 2019 09:18:18 +0300 Subject: [PATCH 03/51] =?UTF-8?q?=D1=91?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/docs/design-principles.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 9f5f54712..840558dcb 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -49,17 +49,17 @@ React прагматичен. Это обусловлено потребност Однако, мы считаем преувеличением думать, что стабильность – это когда "ничего не меняется". Это быстро приводит к застою. Вместо этого, мы предпочитаем воспринимать стабильность в смысле "это много используется в продакшене и когда что-то меняется, существует четкий (и желательно автоматизированный) план миграции". -Когда мы исключаем паттерн, мы изучаем как он используется внутри Facebook и добавляем предупреждения об исключении. Что позволяет нам оценить эффект изменения. Иногда мы отменяем изменения, если видим, что еще слишком рано и нам нужно продумать стратегию продвижения кодовой базы к точке готовности к изменениям. +Когда мы исключаем паттерн, мы изучаем как он используется внутри Facebook и добавляем предупреждения об исключении. Что позволяет нам оценить эффект изменения. Иногда мы отменяем изменения, если видим, что ещё слишком рано и нам нужно продумать стратегию продвижения кодовой базы к точке готовности к изменениям. -Если мы уверены, что изменение не слишком большое и для всех случаев использования возможна миграция, мы выпускаем предупреждение об исключении в OSS-сообщество. Мы тесно общаемся со многими React-пользователями вне Facebook, следим за популярными OSS-проектами и помогаем им исправлять устаревший код. +Если мы уверены, что изменение не слишком большое и для всех случаев использования возможна миграция, то предупреждение об исключении выпускается в OSS-сообщество. Мы тесно общаемся со многими React-пользователями вне Facebook, следим за популярными OSS-проектами и помогаем им исправлять устаревший код. Учитывая огромный размер кодовой базы React в Facebook, успешная внутренняя миграция часто является хорошим индикатором того, что в других компаниях также не будет проблем. Тем не менее, люди иногда указывают на неучтенные варианты использования и мы добавляем лазейки или пересматриваем подход. -Мы ничего не исключаем без веской причины. Мы понимаем, что иногда предупреждения об исключениях разочаровывают. Но мы их добавляем, так как исключения открывают дорогу для улучшений и новых возможностей, которые мы и сообщество считаем важными. +Ничего не исключается без веской причины. Мы понимаем, что иногда предупреждения об исключениях разочаровывают. Но они добавляются, так как исключения открывают дорогу для улучшений и новых возможностей, которые мы и сообщество считаем важными. Например, мы добавили [предупреждение о неизвестных DOM-свойствах](/warnings/unknown-prop.html) в React 15.2.0. Этим мы затронули многие проекты. Однако, исправление этого предупреждения важно для добавления в React поддержки [пользовательских атрибутов](https://github.com/facebook/react/issues/140). Подобная причина стоит за каждым исключением, которое мы добавляем. -При добавлении предупреждения об исключении, мы не удаляем его пока текущая мажорная версия не устарела, [изменяя поведение только в следующей мажорной версии](/blog/2016/02/19/new-versioning-scheme.html). Если исключение создает много повторяющейся ручной работы, мы публикуем [codemod-скрипт](https://www.youtube.com/watch?v=d0pOgY8__JM), который автоматизирует большую часть изменений. Codemod-скрипты дают нам возможность двигаться вперед, не закапываясь в куче кода. Рекомендуем вам тоже их использовать. +При добавлении предупреждения об исключении, мы не удаляем его пока текущая мажорная версия не устарела, [изменяя поведение только в следующей мажорной версии](/blog/2016/02/19/new-versioning-scheme.html). Если исключение создаёт много повторяющейся ручной работы, мы публикуем [codemod-скрипт](https://www.youtube.com/watch?v=d0pOgY8__JM), который автоматизирует большую часть изменений. Codemod-скрипты дают нам возможность двигаться вперёд, не закапываясь в куче кода. Рекомендуем вам тоже их использовать. Вы можете найти уже вышедшие codemod-скрипты в [react-codemod](https://github.com/reactjs/react-codemod) репозитории. @@ -73,17 +73,17 @@ React прагматичен. Это обусловлено потребност Даже если компоненты описаны как функции, при использовании React они не вызываются напрямую. Каждый компонент возвращает [описание того, что должно быть отрендерено](/blog/2015/12/18/react-components-elements-and-instances.html#elements-describe-the-tree). Описание может включать как пользовательские компоненты, такие как ``, так и платформо-зависимые компоненты, такие как `
`. В дальнейшем в какой-то момент React может "развернуть" `` и фактически применить изменения к UI-дереву в соответствии с результатами рекурсивного рендеринга компонент. -Это тонкое, но сильное различие. Поскольку вы не вызываете этот функциональный компонент, а позволяете React вызывать его, это означает, что React может отложить вызов при необходимости. В текущей реализации React рекурсивно обходит дерево и вызывает функции рендера всего обновленного дерева за один проход. Но в будущем он может начать [задерживать некоторые обновления, чтобы избежать потери кадров](https://github.com/facebook/react/issues/6170). +Это тонкое, но сильное различие. Поскольку вы не вызываете этот функциональный компонент, а позволяете React вызывать его, это означает, что React может отложить вызов при необходимости. В текущей реализации React рекурсивно обходит дерево и вызывает функции рендера всего обновлённого дерева за один проход. Но в будущем он может начать [задерживать некоторые обновления, чтобы избежать потери кадров](https://github.com/facebook/react/issues/6170). Это основная тема в дизайне React. Некоторые популярные библиотеки реализуют "push" подход, когда вычисления выполняются при наличии новых данных. React, наоборот, придерживается "pull" подхода, когда вычисления могут быть отложены до необходимости. React не является универсальной библиотекой обработки данных. Это библиотека для создания пользовательских интерфейсов. Мы считаем, что приложение должно знать какие вычисления сейчас актуальны, а какие нет. -Если что-то находится вне экрана, мы можем отложить любую связанную с этим логику. Если данные поступают быстрее, чем кадры успевают обновиться, мы можем объединить их и обновлять пакетами. Мы можем приоритизировать работу, вызванную пользовательским взаимодействием (например, анимация нажатия кнопки), над менее важной фоновой работой (например, рендеринг только что загруженного из сети компонента), чтобы избежать потери кадров. +Если что-то находится вне экрана, можно отложить любую связанную с этим логику. Если данные поступают быстрее, чем кадры успевают обновиться, можно объединить их и обновлять пакетами. Мы можем приоритизировать работу, вызванную пользовательским взаимодействием (например, анимация нажатия кнопки), над менее важной фоновой работой (например, рендеринг только что загруженного из сети компонента), чтобы избежать потери кадров. Чтобы было понятно, мы не пользуемся этим прямо сейчас. Однако, подобная свобода объясняет, почему мы предпочитаем контролировать планирование и почему `setState()` асинхронна. Концептуально мы думаем об этом как о "планировании обновления". -Нам было бы труднее получить контроль над планированием, если бы мы позволили пользователям напрямую создавать представления на основе "push" парадигмы, распространенной в некоторых вариациях [Функционального Реактивного Программирования](https://en.wikipedia.org/wiki/Functional_reactive_programming). Мы хотим владеть "склеивающим" кодом. +Нам было бы труднее получить контроль над планированием, если бы мы позволили пользователям напрямую создавать представления на основе "push" парадигмы, распространённой в некоторых вариациях [Функционального Реактивного Программирования](https://en.wikipedia.org/wiki/Functional_reactive_programming). Мы хотим владеть "склеивающим" кодом. Ключевая задача для React - минимизировать количество пользовательского кода, выполняемого перед возвращением обратно в React. Это гарантирует, что React сохранит возможность планировать и разбивать работу на части в соответствии с тем, что ему известно о UI. From 680bf5291bf02e167a18855c9dfcc8456996ba10 Mon Sep 17 00:00:00 2001 From: Leonid Fedorov Date: Tue, 12 Mar 2019 08:41:09 +0300 Subject: [PATCH 04/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 840558dcb..e5ff28264 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -18,7 +18,7 @@ redirect_from: ### Композиция {#composition} -Ключевая возможность React – это композиция компонент. Компоненты, написанные разными людьми, должны хорошо работать вместе. Для нас важно, что вы можете добавлять в компонент функционал, не вызывая волну изменений по всему коду. +Ключевая возможность React — это композиция компонент. Компоненты, написанные разными людьми, должны хорошо работать вместе. Для нас важно, что вы можете добавлять в компонент функционал, не вызывая волну изменений по всему коду. Например, должна быть возможность вводить некое локальное состояние в компонент без изменения использующих его компонент. Так же, должна быть возможность добавлять при необходимости код инициализации и разрушения в любой компонент. From ef5c7e37dfd53a26dcb07f7e5e1125d5eb21b0f6 Mon Sep 17 00:00:00 2001 From: Leonid Fedorov Date: Tue, 12 Mar 2019 08:41:24 +0300 Subject: [PATCH 05/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index e5ff28264..fc37dbffe 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -39,7 +39,7 @@ redirect_from: ### Лазейки {#escape-hatches} -React прагматичен. Это обусловлено потребностями продуктов, написанных в Facebook. Хоть на него и влияют некоторые не самые популярные парадигмы, такие как функциональное программирование, цель проекта – оставаться доступным для широкого круга разработчиков с разным уровнем опыта и навыками. +React прагматичен. Это обусловлено потребностями продуктов, написанных в Facebook. Хоть на него и влияют некоторые не самые популярные парадигмы, такие как функциональное программирование, цель проекта — оставаться доступным для широкого круга разработчиков с разным уровнем опыта и навыками. Если мы хотим отказаться от паттерна, который нам не нравится, мы должны рассмотреть все существующие варианты его использования и [проинформировать сообщество об альтернативах](/blog/2016/07/13/mixins-considered-harmful.html), прежде чем отказаться от него. Если какой-то полезный для создания приложений паттерн трудно описать декларативно, мы [предоставим для него императивное API](/docs/more-about-refs.html). Если мы не можем найти идеальное API для того, что мы считаем необходимым во многих приложениях, мы [предоставим временное, частично работающее API](/docs/legacy-context.html), позже от него можно будет избавиться. Это оставляет открытую дверь для будущих улучшений. From dc1f29e475e22d49bee3866d18132a0d6d34a816 Mon Sep 17 00:00:00 2001 From: Leonid Fedorov Date: Tue, 12 Mar 2019 08:41:49 +0300 Subject: [PATCH 06/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index fc37dbffe..7c3ba9f30 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -33,7 +33,7 @@ redirect_from: Например, если бы React не предоставлял поддержку локального состояния или методов жизненного цикла, люди бы создавали собственные абстракции для них. Когда есть несколько конкурирующих абстракций, React не может применять или использовать их свойства. Он должен работать с наименьшим общим знаменателем. Вот почему иногда мы добавляем функционал в сам React. Если мы замечаем, что какой-то функционал реализуется несовместимо или неэффективно во многих компонентах, мы можем захотеть внедрить его в React. Это не происходит просто так. -Если мы добавляем новый функционал, значит мы уверены, что повышение уровня абстракции принесет выгоду всей экосистеме. Хорошие примеры для этого – состояние, методы жизненного цикла, кросс-браузерная нормализация событий. +Если мы добавляем новый функционал, значит мы уверены, что повышение уровня абстракции принесёт выгоду всей экосистеме. Хорошие примеры для этого — состояние, методы жизненного цикла, кросс-браузерная нормализация событий. Мы всегда обсуждаем с сообществом такие предложения по улучшению. Некоторые из этих обсуждений можно найти по метке ["big picture"](https://github.com/facebook/react/issues?q=is:open+is:issue+label:"Type:+Big+Picture") в трекере задач React. From bde9b7758c3df86d6b47aa3db7fb9dd10dbf3e6e Mon Sep 17 00:00:00 2001 From: Leonid Fedorov Date: Tue, 12 Mar 2019 08:42:05 +0300 Subject: [PATCH 07/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 7c3ba9f30..ed9b55b75 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -47,7 +47,7 @@ React прагматичен. Это обусловлено потребност Мы ценим стабильность API. У нас в Facebook более 50 тысяч компонент, использующих React. Многие другие компании, включая [Twitter](https://twitter.com/) и [Airbnb](https://www.airbnb.com/), также активно используют React. Поэтому мы обычно нехотя меняем публичное API или поведение. -Однако, мы считаем преувеличением думать, что стабильность – это когда "ничего не меняется". Это быстро приводит к застою. Вместо этого, мы предпочитаем воспринимать стабильность в смысле "это много используется в продакшене и когда что-то меняется, существует четкий (и желательно автоматизированный) план миграции". +Однако, мы считаем преувеличением думать, что стабильность — это когда "ничего не меняется". Это быстро приводит к застою. Вместо этого, мы предпочитаем воспринимать стабильность в смысле "это много используется в продакшене и когда что-то меняется, существует четкий (и желательно автоматизированный) план миграции". Когда мы исключаем паттерн, мы изучаем как он используется внутри Facebook и добавляем предупреждения об исключении. Что позволяет нам оценить эффект изменения. Иногда мы отменяем изменения, если видим, что ещё слишком рано и нам нужно продумать стратегию продвижения кодовой базы к точке готовности к изменениям. From 9519b5360907254189772e46c32eba7162645455 Mon Sep 17 00:00:00 2001 From: Leonid Fedorov Date: Tue, 12 Mar 2019 08:42:26 +0300 Subject: [PATCH 08/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index ed9b55b75..1bd581ed9 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -65,7 +65,7 @@ React прагматичен. Это обусловлено потребност ### Совместимость {#interoperability} -Мы придаем большое значение совместимости с существующими системами и возможности постепенного внедрения. В Facebook есть много кода, написанного не на React. Сайт использует смесь из XHP – системы серверных компонент, внутренних UI-библиотек, которые пришли до React, и самого React. Для нас важно, что любая продуктовая команда может [начать использовать React для небольшого функционала](https://www.youtube.com/watch?v=BF58ZJ1ZQxY), а не делать ставку на переписывание своего кода. +Мы придаём большое значение совместимости с существующими системами и возможности постепенного внедрения. В Facebook есть много кода, написанного не на React. Сайт использует смесь из XHP — системы серверных компонент, внутренних UI-библиотек, которые пришли до React, и самого React. Для нас важно, что любая продуктовая команда может [начать использовать React для небольшого функционала](https://www.youtube.com/watch?v=BF58ZJ1ZQxY), а не делать ставку на переписывание своего кода. По этой причине React предоставляет лазейки для работы с изменяемыми моделями и пытается хорошо работать вместе с другими UI-библиотеками. Вы можете обернуть существующий императивный UI в декларативный компонент и наоборот. Это очень важно для постепенного внедрения. From a98257172e40fed9e42c21d94653b3d739de6a2b Mon Sep 17 00:00:00 2001 From: Leonid Fedorov Date: Tue, 12 Mar 2019 08:43:38 +0300 Subject: [PATCH 09/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 1bd581ed9..cb1168715 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -71,7 +71,7 @@ React прагматичен. Это обусловлено потребност ### Планирование {#scheduling} -Даже если компоненты описаны как функции, при использовании React они не вызываются напрямую. Каждый компонент возвращает [описание того, что должно быть отрендерено](/blog/2015/12/18/react-components-elements-and-instances.html#elements-describe-the-tree). Описание может включать как пользовательские компоненты, такие как ``, так и платформо-зависимые компоненты, такие как `
`. В дальнейшем в какой-то момент React может "развернуть" `` и фактически применить изменения к UI-дереву в соответствии с результатами рекурсивного рендеринга компонент. +Даже если компоненты описаны как функции, при использовании React они не вызываются напрямую. Каждый компонент возвращает [описание того, что должно быть отрендерено](/blog/2015/12/18/react-components-elements-and-instances.html#elements-describe-the-tree). Описание может включать как пользовательские компоненты, такие как ``, так и платформо-зависимые компоненты, такие как `
`. В дальнейшем в какой-то момент React может "развернуть" `` и фактически применить изменения к UI-дереву в соответствии с результатами рекурсивного рендеринга компонент. Это тонкое, но сильное различие. Поскольку вы не вызываете этот функциональный компонент, а позволяете React вызывать его, это означает, что React может отложить вызов при необходимости. В текущей реализации React рекурсивно обходит дерево и вызывает функции рендера всего обновлённого дерева за один проход. Но в будущем он может начать [задерживать некоторые обновления, чтобы избежать потери кадров](https://github.com/facebook/react/issues/6170). From 3ed7288120a989da454d33310904c25d6007bc9a Mon Sep 17 00:00:00 2001 From: Leonid Fedorov Date: Tue, 12 Mar 2019 08:44:02 +0300 Subject: [PATCH 10/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index cb1168715..bbbe2e0c3 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -85,7 +85,7 @@ React не является универсальной библиотекой о Нам было бы труднее получить контроль над планированием, если бы мы позволили пользователям напрямую создавать представления на основе "push" парадигмы, распространённой в некоторых вариациях [Функционального Реактивного Программирования](https://en.wikipedia.org/wiki/Functional_reactive_programming). Мы хотим владеть "склеивающим" кодом. -Ключевая задача для React - минимизировать количество пользовательского кода, выполняемого перед возвращением обратно в React. Это гарантирует, что React сохранит возможность планировать и разбивать работу на части в соответствии с тем, что ему известно о UI. +Ключевая задача для React — минимизировать количество пользовательского кода, выполняемого перед возвращением обратно в React. Это гарантирует, что React сохранит возможность планировать и разбивать работу на части в соответствии с тем, что ему известно о UI. В команде есть внутренняя шутка, что React должен был называться "Schedule", потому что React не хочет быть полностью "реактивным". From 1fcfd2257b78d04ccbd0ab3efc89d7a83aef30ba Mon Sep 17 00:00:00 2001 From: Anton Ahatov Date: Tue, 12 Mar 2019 08:47:35 +0300 Subject: [PATCH 11/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index bbbe2e0c3..80c6ee927 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -14,7 +14,7 @@ redirect_from: > >Эта статья подразумевает глубокое понимание React. В ней описаны концепции разработки *самого React*, но не React-компонент или приложений. > ->Для знакомства с React лучше почитайте [Философия React](/docs/thinking-in-react.html). +>Для знакомства с React почитайте [Философия React](/docs/thinking-in-react.html). ### Композиция {#composition} From b9d1e73ad4714186806ff59a717d99b310330b92 Mon Sep 17 00:00:00 2001 From: Anton Ahatov Date: Tue, 12 Mar 2019 08:48:00 +0300 Subject: [PATCH 12/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 80c6ee927..d5ea1e0df 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -20,7 +20,7 @@ redirect_from: Ключевая возможность React — это композиция компонент. Компоненты, написанные разными людьми, должны хорошо работать вместе. Для нас важно, что вы можете добавлять в компонент функционал, не вызывая волну изменений по всему коду. -Например, должна быть возможность вводить некое локальное состояние в компонент без изменения использующих его компонент. Так же, должна быть возможность добавлять при необходимости код инициализации и разрушения в любой компонент. +Например, должна быть возможность вводить некое внутреннее состояние в компонент без изменения использующих его компонентов. Так же, должна быть возможность добавлять при необходимости код инициализации и разрушения в любой компонент. Нет ничего "плохого" в использовании состояния или методов жизненного цикла в компонентах. Как и любую мощную возможность, их стоит использовать в меру, но мы не собираемся их удалять. Напротив, мы считаем, что они являются неотъемлемой частью того, что делает React полезным. Возможно, мы добавим [больше функциональных шаблонов](https://github.com/reactjs/react-future/tree/master/07%20-%20Returning%20State) в будущем, но как локальное состояние, так и методы жизненного цикла будут частью этой модели. From 305c9dae91eeab62dd533b20bbefe2c3634a9ddd Mon Sep 17 00:00:00 2001 From: Anton Ahatov Date: Tue, 12 Mar 2019 08:49:18 +0300 Subject: [PATCH 13/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index d5ea1e0df..23582fd98 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -87,7 +87,7 @@ React не является универсальной библиотекой о Ключевая задача для React — минимизировать количество пользовательского кода, выполняемого перед возвращением обратно в React. Это гарантирует, что React сохранит возможность планировать и разбивать работу на части в соответствии с тем, что ему известно о UI. -В команде есть внутренняя шутка, что React должен был называться "Schedule", потому что React не хочет быть полностью "реактивным". +В команде есть внутренняя шутка, что React должен был называться «Schedule», потому что React не хочет быть полностью «реактивным». ### Developer Experience {#developer-experience} From 45ea7fa08a901b4eb0cc501ffaf3113f61a30d2a Mon Sep 17 00:00:00 2001 From: Anton Ahatov Date: Tue, 12 Mar 2019 08:49:42 +0300 Subject: [PATCH 14/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 23582fd98..161ad290c 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -83,7 +83,7 @@ React не является универсальной библиотекой о Чтобы было понятно, мы не пользуемся этим прямо сейчас. Однако, подобная свобода объясняет, почему мы предпочитаем контролировать планирование и почему `setState()` асинхронна. Концептуально мы думаем об этом как о "планировании обновления". -Нам было бы труднее получить контроль над планированием, если бы мы позволили пользователям напрямую создавать представления на основе "push" парадигмы, распространённой в некоторых вариациях [Функционального Реактивного Программирования](https://en.wikipedia.org/wiki/Functional_reactive_programming). Мы хотим владеть "склеивающим" кодом. +Нам было бы труднее получить контроль над планированием, если бы мы позволили пользователям напрямую создавать представления на основе «push» парадигмы, распространённой в некоторых вариациях [Функционального реактивного программирования](https://en.wikipedia.org/wiki/Functional_reactive_programming). Мы хотим владеть «склеивающим» кодом. Ключевая задача для React — минимизировать количество пользовательского кода, выполняемого перед возвращением обратно в React. Это гарантирует, что React сохранит возможность планировать и разбивать работу на части в соответствии с тем, что ему известно о UI. From a32055249ed5f09e204294cd8a80fafca01dba09 Mon Sep 17 00:00:00 2001 From: Anton Ahatov Date: Tue, 12 Mar 2019 08:50:07 +0300 Subject: [PATCH 15/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 161ad290c..a4dd1428c 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -81,7 +81,7 @@ React не является универсальной библиотекой о Если что-то находится вне экрана, можно отложить любую связанную с этим логику. Если данные поступают быстрее, чем кадры успевают обновиться, можно объединить их и обновлять пакетами. Мы можем приоритизировать работу, вызванную пользовательским взаимодействием (например, анимация нажатия кнопки), над менее важной фоновой работой (например, рендеринг только что загруженного из сети компонента), чтобы избежать потери кадров. -Чтобы было понятно, мы не пользуемся этим прямо сейчас. Однако, подобная свобода объясняет, почему мы предпочитаем контролировать планирование и почему `setState()` асинхронна. Концептуально мы думаем об этом как о "планировании обновления". +Чтобы было понятно, мы не пользуемся этим прямо сейчас. Однако, подобная свобода объясняет, почему мы предпочитаем контролировать планирование и почему `setState()` асинхронна. Концептуально мы думаем об этом как о «планировании обновления». Нам было бы труднее получить контроль над планированием, если бы мы позволили пользователям напрямую создавать представления на основе «push» парадигмы, распространённой в некоторых вариациях [Функционального реактивного программирования](https://en.wikipedia.org/wiki/Functional_reactive_programming). Мы хотим владеть «склеивающим» кодом. From 1c86ad951655989ffdebe94b6f3c4dd7dfbb95c9 Mon Sep 17 00:00:00 2001 From: Anton Ahatov Date: Tue, 12 Mar 2019 08:51:14 +0300 Subject: [PATCH 16/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index a4dd1428c..3e15afd70 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -22,7 +22,7 @@ redirect_from: Например, должна быть возможность вводить некое внутреннее состояние в компонент без изменения использующих его компонентов. Так же, должна быть возможность добавлять при необходимости код инициализации и разрушения в любой компонент. -Нет ничего "плохого" в использовании состояния или методов жизненного цикла в компонентах. Как и любую мощную возможность, их стоит использовать в меру, но мы не собираемся их удалять. Напротив, мы считаем, что они являются неотъемлемой частью того, что делает React полезным. Возможно, мы добавим [больше функциональных шаблонов](https://github.com/reactjs/react-future/tree/master/07%20-%20Returning%20State) в будущем, но как локальное состояние, так и методы жизненного цикла будут частью этой модели. +Нет ничего «плохого» в использовании состояния или методов жизненного цикла в компонентах. Как и любую мощную возможность, их стоит использовать в меру, но мы не собираемся их удалять. Напротив, мы считаем, что они являются неотъемлемой частью того, что делает React полезным. Возможно, мы добавим [больше функциональных шаблонов](https://github.com/reactjs/react-future/tree/master/07%20-%20Returning%20State) в будущем, но как внутреннее состояние, так и методы жизненного цикла будут частью этой модели. Компоненты часто описываются как "просто функции", но, на наш взгляд, они должны быть более полезными. В React компоненты описывают любое поведение композиции, включая рендеринг, жизненный цикл и состояние. Некоторые сторонние библиотеки, вроде [Relay](https://facebook.github.io/relay/), дополняют компоненты другими функциями, например описанием зависимостей данных. Вполне возможно, что в той или иной форме эти идеи могут прийти в React. From d8c68343352a8173715ca38ae06e2e2d76410f13 Mon Sep 17 00:00:00 2001 From: Anton Ahatov Date: Tue, 12 Mar 2019 09:01:50 +0300 Subject: [PATCH 17/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 3e15afd70..9a3c4372b 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -28,7 +28,7 @@ redirect_from: ### Общая абстракция {#common-abstraction} -В целом, мы [против добавления функционала](https://www.youtube.com/watch?v=4anAwXYqLG8), который может быть реализован в пользовательских приложениях. Мы не хотим раздувать ваши приложения бесполезным кодом библиотеки. Но, из этого правила есть исключения. +В целом, мы [против добавления функциональности](https://www.youtube.com/watch?v=4anAwXYqLG8), которая может быть реализована в пользовательских приложениях. Мы не хотим заполнять ваше приложения бесполезным кодом библиотеки. Но, из этого правила есть исключения. Например, если бы React не предоставлял поддержку локального состояния или методов жизненного цикла, люди бы создавали собственные абстракции для них. Когда есть несколько конкурирующих абстракций, React не может применять или использовать их свойства. Он должен работать с наименьшим общим знаменателем. From deb9bd1789e9a0f3de4029bfe8a6c7e9a2e4c394 Mon Sep 17 00:00:00 2001 From: Anton Ahatov Date: Tue, 12 Mar 2019 09:03:02 +0300 Subject: [PATCH 18/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 9a3c4372b..43614d964 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -30,7 +30,7 @@ redirect_from: В целом, мы [против добавления функциональности](https://www.youtube.com/watch?v=4anAwXYqLG8), которая может быть реализована в пользовательских приложениях. Мы не хотим заполнять ваше приложения бесполезным кодом библиотеки. Но, из этого правила есть исключения. -Например, если бы React не предоставлял поддержку локального состояния или методов жизненного цикла, люди бы создавали собственные абстракции для них. Когда есть несколько конкурирующих абстракций, React не может применять или использовать их свойства. Он должен работать с наименьшим общим знаменателем. +Например, если бы React не предоставлял поддержку внутреннего состояния или методов жизненного цикла, люди бы создавали собственные абстракции для них. Когда есть несколько конкурирующих абстракций, React не может применять или использовать их свойства. Он должен работать с наименьшим общим знаменателем. Вот почему иногда мы добавляем функционал в сам React. Если мы замечаем, что какой-то функционал реализуется несовместимо или неэффективно во многих компонентах, мы можем захотеть внедрить его в React. Это не происходит просто так. Если мы добавляем новый функционал, значит мы уверены, что повышение уровня абстракции принесёт выгоду всей экосистеме. Хорошие примеры для этого — состояние, методы жизненного цикла, кросс-браузерная нормализация событий. From 2f64eb45d035b29fd3bd70f3ca034fc62517a576 Mon Sep 17 00:00:00 2001 From: Anton Ahatov Date: Tue, 12 Mar 2019 09:12:49 +0300 Subject: [PATCH 19/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 43614d964..0be08d758 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -75,7 +75,7 @@ React прагматичен. Это обусловлено потребност Это тонкое, но сильное различие. Поскольку вы не вызываете этот функциональный компонент, а позволяете React вызывать его, это означает, что React может отложить вызов при необходимости. В текущей реализации React рекурсивно обходит дерево и вызывает функции рендера всего обновлённого дерева за один проход. Но в будущем он может начать [задерживать некоторые обновления, чтобы избежать потери кадров](https://github.com/facebook/react/issues/6170). -Это основная тема в дизайне React. Некоторые популярные библиотеки реализуют "push" подход, когда вычисления выполняются при наличии новых данных. React, наоборот, придерживается "pull" подхода, когда вычисления могут быть отложены до необходимости. +Это основная тема в дизайне React. Некоторые популярные библиотеки реализуют «push» подход, когда вычисления выполняются при наличии новых данных. React, наоборот, придерживается «pull» подхода, когда вычисления могут быть отложены до необходимости. React не является универсальной библиотекой обработки данных. Это библиотека для создания пользовательских интерфейсов. Мы считаем, что приложение должно знать какие вычисления сейчас актуальны, а какие нет. From eb01b6f8d2460e8efcec1a3874248905c4e2c614 Mon Sep 17 00:00:00 2001 From: Aleksei Date: Tue, 12 Mar 2019 09:27:32 +0300 Subject: [PATCH 20/51] Update design-principles.md --- content/docs/design-principles.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 0be08d758..4867457ab 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -18,7 +18,7 @@ redirect_from: ### Композиция {#composition} -Ключевая возможность React — это композиция компонент. Компоненты, написанные разными людьми, должны хорошо работать вместе. Для нас важно, что вы можете добавлять в компонент функционал, не вызывая волну изменений по всему коду. +Ключевая возможность React — это композиция компонентов. Компоненты, написанные разными людьми, должны хорошо работать вместе. Для нас важно, что вы можете добавлять в компонент функционал, не вызывая волну изменений по всему коду. Например, должна быть возможность вводить некое внутреннее состояние в компонент без изменения использующих его компонентов. Так же, должна быть возможность добавлять при необходимости код инициализации и разрушения в любой компонент. @@ -47,7 +47,7 @@ React прагматичен. Это обусловлено потребност Мы ценим стабильность API. У нас в Facebook более 50 тысяч компонент, использующих React. Многие другие компании, включая [Twitter](https://twitter.com/) и [Airbnb](https://www.airbnb.com/), также активно используют React. Поэтому мы обычно нехотя меняем публичное API или поведение. -Однако, мы считаем преувеличением думать, что стабильность — это когда "ничего не меняется". Это быстро приводит к застою. Вместо этого, мы предпочитаем воспринимать стабильность в смысле "это много используется в продакшене и когда что-то меняется, существует четкий (и желательно автоматизированный) план миграции". +Однако, мы считаем преувеличением думать, что стабильность — это когда «ничего не меняется». Это быстро приводит к застою. Вместо этого, мы предпочитаем воспринимать стабильность в смысле «это много используется в продакшене и когда что-то меняется, существует четкий (и желательно автоматизированный) план миграции». Когда мы исключаем паттерн, мы изучаем как он используется внутри Facebook и добавляем предупреждения об исключении. Что позволяет нам оценить эффект изменения. Иногда мы отменяем изменения, если видим, что ещё слишком рано и нам нужно продумать стратегию продвижения кодовой базы к точке готовности к изменениям. From 52bd57e842f021b54669fb6c671d8988d7ed8fab Mon Sep 17 00:00:00 2001 From: Anton Ahatov Date: Tue, 12 Mar 2019 09:31:50 +0300 Subject: [PATCH 21/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 4867457ab..a1ef17337 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -8,7 +8,7 @@ redirect_from: - "contributing/design-principles.html" --- -Мы написали эту статью, чтобы вы лучше понимали, как принимаются решения о том что React должен делать и чего не должен, и что из себя представляют наши принципы разработки. Хоть мы и рады видеть вклад сообщества, вряд ли мы выберем путь, который нарушает один или несколько из этих принципов. +Мы написали этот документ, чтобы у вас было лучшее представление о том, как мы решаем, что делает React, а что нет, и какова наша философия разработки. Хоть мы и рады видеть вклад сообщества, вряд ли мы выберем путь, который нарушает один или несколько из этих принципов. >**Примечание:** > From 5b6908735474be87f742514c4cdd701b2812b0ff Mon Sep 17 00:00:00 2001 From: Aleksei Date: Tue, 12 Mar 2019 09:34:23 +0300 Subject: [PATCH 22/51] Update design-principles.md --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index a1ef17337..3b1ea23a3 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -71,7 +71,7 @@ React прагматичен. Это обусловлено потребност ### Планирование {#scheduling} -Даже если компоненты описаны как функции, при использовании React они не вызываются напрямую. Каждый компонент возвращает [описание того, что должно быть отрендерено](/blog/2015/12/18/react-components-elements-and-instances.html#elements-describe-the-tree). Описание может включать как пользовательские компоненты, такие как ``, так и платформо-зависимые компоненты, такие как `
`. В дальнейшем в какой-то момент React может "развернуть" `` и фактически применить изменения к UI-дереву в соответствии с результатами рекурсивного рендеринга компонент. +Даже если компоненты описаны как функции, при использовании React они не вызываются напрямую. Каждый компонент возвращает [описание того, что должно быть отрендерено](/blog/2015/12/18/react-components-elements-and-instances.html#elements-describe-the-tree). Описание может включать как пользовательские компоненты, такие как ``, так и платформо-зависимые компоненты, такие как `
`. В дальнейшем в какой-то момент React может «развернуть» `` и фактически применить изменения к UI-дереву в соответствии с результатами рекурсивного рендеринга компонент. Это тонкое, но сильное различие. Поскольку вы не вызываете этот функциональный компонент, а позволяете React вызывать его, это означает, что React может отложить вызов при необходимости. В текущей реализации React рекурсивно обходит дерево и вызывает функции рендера всего обновлённого дерева за один проход. Но в будущем он может начать [задерживать некоторые обновления, чтобы избежать потери кадров](https://github.com/facebook/react/issues/6170). From 3a0a848f344ee50bcea20ed1c8ee8223de0a55c1 Mon Sep 17 00:00:00 2001 From: Aleksei Date: Tue, 12 Mar 2019 09:42:58 +0300 Subject: [PATCH 23/51] Update design-principles.md --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 3b1ea23a3..6df47e8ef 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -35,7 +35,7 @@ redirect_from: Вот почему иногда мы добавляем функционал в сам React. Если мы замечаем, что какой-то функционал реализуется несовместимо или неэффективно во многих компонентах, мы можем захотеть внедрить его в React. Это не происходит просто так. Если мы добавляем новый функционал, значит мы уверены, что повышение уровня абстракции принесёт выгоду всей экосистеме. Хорошие примеры для этого — состояние, методы жизненного цикла, кросс-браузерная нормализация событий. -Мы всегда обсуждаем с сообществом такие предложения по улучшению. Некоторые из этих обсуждений можно найти по метке ["big picture"](https://github.com/facebook/react/issues?q=is:open+is:issue+label:"Type:+Big+Picture") в трекере задач React. +Мы всегда обсуждаем с сообществом такие предложения по улучшению. Некоторые из этих обсуждений можно найти по метке [«big picture»](https://github.com/facebook/react/issues?q=is:open+is:issue+label:"Type:+Big+Picture") в трекере задач React. ### Лазейки {#escape-hatches} From 9e88a6a316e128cf17399cd51d1d5e50469127cf Mon Sep 17 00:00:00 2001 From: echobrain Date: Wed, 13 Mar 2019 20:10:06 +0300 Subject: [PATCH 24/51] fixed composition translation --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 6df47e8ef..a00e5c219 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -24,7 +24,7 @@ redirect_from: Нет ничего «плохого» в использовании состояния или методов жизненного цикла в компонентах. Как и любую мощную возможность, их стоит использовать в меру, но мы не собираемся их удалять. Напротив, мы считаем, что они являются неотъемлемой частью того, что делает React полезным. Возможно, мы добавим [больше функциональных шаблонов](https://github.com/reactjs/react-future/tree/master/07%20-%20Returning%20State) в будущем, но как внутреннее состояние, так и методы жизненного цикла будут частью этой модели. -Компоненты часто описываются как "просто функции", но, на наш взгляд, они должны быть более полезными. В React компоненты описывают любое поведение композиции, включая рендеринг, жизненный цикл и состояние. Некоторые сторонние библиотеки, вроде [Relay](https://facebook.github.io/relay/), дополняют компоненты другими функциями, например описанием зависимостей данных. Вполне возможно, что в той или иной форме эти идеи могут прийти в React. +Компоненты часто описываются как «просто функции», но, по нашему мнению, они должны быть чем-то большим, чтобы быть полезными. Компоненты в React описывают поведение, которое можно композировать. Эта идея распространяется в том числе на рендеринг, жизненный цикл и состояние. Некоторые сторонние библиотеки, вроде [Relay](https://facebook.github.io/relay/), дополняют компоненты другими возможностями, например, описанием зависимостей данных. Вполне возможно, что эти идеи могут попасть в React в той или иной форме. ### Общая абстракция {#common-abstraction} From 52105965fa63688b48d3da32f64641b8e7073e26 Mon Sep 17 00:00:00 2001 From: echobrain Date: Wed, 13 Mar 2019 20:18:44 +0300 Subject: [PATCH 25/51] fixed schedule translation --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index a00e5c219..dd4c3aa38 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -75,7 +75,7 @@ React прагматичен. Это обусловлено потребност Это тонкое, но сильное различие. Поскольку вы не вызываете этот функциональный компонент, а позволяете React вызывать его, это означает, что React может отложить вызов при необходимости. В текущей реализации React рекурсивно обходит дерево и вызывает функции рендера всего обновлённого дерева за один проход. Но в будущем он может начать [задерживать некоторые обновления, чтобы избежать потери кадров](https://github.com/facebook/react/issues/6170). -Это основная тема в дизайне React. Некоторые популярные библиотеки реализуют «push» подход, когда вычисления выполняются при наличии новых данных. React, наоборот, придерживается «pull» подхода, когда вычисления могут быть отложены до необходимости. +Это частая тема в архитектуре React. Некоторые популярные библиотеки реализуют подход «прослушивание», когда вычисления выполняются при появлении новых данных. React, наоборот, придерживается подхода «опрашивание», когда вычисления могут быть запрошены при необходимости. React не является универсальной библиотекой обработки данных. Это библиотека для создания пользовательских интерфейсов. Мы считаем, что приложение должно знать какие вычисления сейчас актуальны, а какие нет. From c1411ef853ad42a3cdfbb8f13ba743dfbdfe57df Mon Sep 17 00:00:00 2001 From: echobrain Date: Wed, 13 Mar 2019 20:24:40 +0300 Subject: [PATCH 26/51] navigation title --- content/docs/nav.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/nav.yml b/content/docs/nav.yml index 7cb2b0887..e03216e47 100644 --- a/content/docs/nav.yml +++ b/content/docs/nav.yml @@ -132,7 +132,7 @@ - id: implementation-notes title: Implementation Notes - id: design-principles - title: Design Principles + title: Принципы проектирования React - title: FAQ items: - id: faq-ajax From cf3054951e887fa4949d6463c434d74eb6b996a2 Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:25:54 +0300 Subject: [PATCH 27/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index dd4c3aa38..708ed38b4 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -1,6 +1,6 @@ --- id: design-principles -title: Принципы разработки +title: Принципы проектирования React layout: contributing permalink: docs/design-principles.html prev: implementation-notes.html From 1c5ca9e52a39cf733e04ae49f364c37886937fd6 Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:26:54 +0300 Subject: [PATCH 28/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 708ed38b4..35d238d6a 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -8,7 +8,7 @@ redirect_from: - "contributing/design-principles.html" --- -Мы написали этот документ, чтобы у вас было лучшее представление о том, как мы решаем, что делает React, а что нет, и какова наша философия разработки. Хоть мы и рады видеть вклад сообщества, вряд ли мы выберем путь, который нарушает один или несколько из этих принципов. +Мы написали этот документ, чтобы у вас было лучшее представление о том, как мы решаем, что делает React, а что нет, и какова наша философия разработки. Хоть мы и рады видеть вклад сообщества, мы вряд ли выберем путь, который нарушает один или несколько из этих принципов. >**Примечание:** > From cb4d41c23c27ac3cba14c047bef352e50cdb1e17 Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:27:17 +0300 Subject: [PATCH 29/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 35d238d6a..d87d8de15 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -12,7 +12,7 @@ redirect_from: >**Примечание:** > ->Эта статья подразумевает глубокое понимание React. В ней описаны концепции разработки *самого React*, но не React-компонент или приложений. +>Эта статья подразумевает глубокое понимание React. В ней описаны концепции разработки *самого React*, но не React-компонентов или приложений. > >Для знакомства с React почитайте [Философия React](/docs/thinking-in-react.html). From 695100ed7fc50b206754038eefce963655fbefeb Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:27:31 +0300 Subject: [PATCH 30/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index d87d8de15..c6aa57492 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -14,7 +14,7 @@ redirect_from: > >Эта статья подразумевает глубокое понимание React. В ней описаны концепции разработки *самого React*, но не React-компонентов или приложений. > ->Для знакомства с React почитайте [Философия React](/docs/thinking-in-react.html). +>Для знакомства с React почитайте главу [Философия React](/docs/thinking-in-react.html). ### Композиция {#composition} From 61b9e57ce8d1d281eb28f6ff5ffb367c1f33f009 Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:27:56 +0300 Subject: [PATCH 31/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index c6aa57492..bd14f9e2d 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -18,7 +18,7 @@ redirect_from: ### Композиция {#composition} -Ключевая возможность React — это композиция компонентов. Компоненты, написанные разными людьми, должны хорошо работать вместе. Для нас важно, что вы можете добавлять в компонент функционал, не вызывая волну изменений по всему коду. +Ключевая возможность React — это композиция компонентов. Компоненты, написанные разными людьми, должны хорошо работать вместе. Для нас важно, чтобы вы могли добавлять в компонент функциональность, не вызывая волну изменений по всему коду. Например, должна быть возможность вводить некое внутреннее состояние в компонент без изменения использующих его компонентов. Так же, должна быть возможность добавлять при необходимости код инициализации и разрушения в любой компонент. From 75cf68ad9ea8bd878fed462357c88ab1a0170bd1 Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:29:13 +0300 Subject: [PATCH 32/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index bd14f9e2d..2b5c5e85d 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -65,7 +65,7 @@ React прагматичен. Это обусловлено потребност ### Совместимость {#interoperability} -Мы придаём большое значение совместимости с существующими системами и возможности постепенного внедрения. В Facebook есть много кода, написанного не на React. Сайт использует смесь из XHP — системы серверных компонент, внутренних UI-библиотек, которые пришли до React, и самого React. Для нас важно, что любая продуктовая команда может [начать использовать React для небольшого функционала](https://www.youtube.com/watch?v=BF58ZJ1ZQxY), а не делать ставку на переписывание своего кода. +Мы придаём большое значение совместимости с существующими системами и возможности постепенного внедрения. В Facebook есть много кода, написанного не на React. Сайт использует смесь из XHP — системы серверных компонент, внутренних UI-библиотек, которые пришли до React, и самого React. Для нас важно, чтобы любая продуктовая команда могла [начать использовать React для небольшой возможности](https://www.youtube.com/watch?v=BF58ZJ1ZQxY), а не делать ставку на переписывание своего кода. По этой причине React предоставляет лазейки для работы с изменяемыми моделями и пытается хорошо работать вместе с другими UI-библиотеками. Вы можете обернуть существующий императивный UI в декларативный компонент и наоборот. Это очень важно для постепенного внедрения. From 2f347978693908951ebbbaf3e47b14c1e75e1844 Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:30:08 +0300 Subject: [PATCH 33/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 2b5c5e85d..2f4479496 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -20,7 +20,7 @@ redirect_from: Ключевая возможность React — это композиция компонентов. Компоненты, написанные разными людьми, должны хорошо работать вместе. Для нас важно, чтобы вы могли добавлять в компонент функциональность, не вызывая волну изменений по всему коду. -Например, должна быть возможность вводить некое внутреннее состояние в компонент без изменения использующих его компонентов. Так же, должна быть возможность добавлять при необходимости код инициализации и разрушения в любой компонент. +Например, должна быть возможность вводить некое внутреннее состояние в компонент без изменения зависящих от него компонентов. Также должна быть возможность добавлять при необходимости код инициализации и разрушения в любой компонент. Нет ничего «плохого» в использовании состояния или методов жизненного цикла в компонентах. Как и любую мощную возможность, их стоит использовать в меру, но мы не собираемся их удалять. Напротив, мы считаем, что они являются неотъемлемой частью того, что делает React полезным. Возможно, мы добавим [больше функциональных шаблонов](https://github.com/reactjs/react-future/tree/master/07%20-%20Returning%20State) в будущем, но как внутреннее состояние, так и методы жизненного цикла будут частью этой модели. From c21fd699a546ecbfb9c8d2e6f40510fdbf8eb4f0 Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:31:06 +0300 Subject: [PATCH 34/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 2f4479496..e6fe58ddb 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -22,7 +22,7 @@ redirect_from: Например, должна быть возможность вводить некое внутреннее состояние в компонент без изменения зависящих от него компонентов. Также должна быть возможность добавлять при необходимости код инициализации и разрушения в любой компонент. -Нет ничего «плохого» в использовании состояния или методов жизненного цикла в компонентах. Как и любую мощную возможность, их стоит использовать в меру, но мы не собираемся их удалять. Напротив, мы считаем, что они являются неотъемлемой частью того, что делает React полезным. Возможно, мы добавим [больше функциональных шаблонов](https://github.com/reactjs/react-future/tree/master/07%20-%20Returning%20State) в будущем, но как внутреннее состояние, так и методы жизненного цикла будут частью этой модели. +Нет ничего «плохого» в использовании состояния или методов жизненного цикла в компонентах. Как и любую мощную возможность, их стоит использовать в меру, но мы не собираемся их удалять. Напротив, мы считаем, что они являются неотъемлемой частью того, что делает React полезным. Возможно, мы добавим [больше паттернов функционального программирования](https://github.com/reactjs/react-future/tree/master/07%20-%20Returning%20State) в будущем, но как внутреннее состояние, так и методы жизненного цикла будут частью этой модели. Компоненты часто описываются как «просто функции», но, по нашему мнению, они должны быть чем-то большим, чтобы быть полезными. Компоненты в React описывают поведение, которое можно композировать. Эта идея распространяется в том числе на рендеринг, жизненный цикл и состояние. Некоторые сторонние библиотеки, вроде [Relay](https://facebook.github.io/relay/), дополняют компоненты другими возможностями, например, описанием зависимостей данных. Вполне возможно, что эти идеи могут попасть в React в той или иной форме. From 454c9cacc6653df1c740c46542ed5c2e18d4cc34 Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:31:53 +0300 Subject: [PATCH 35/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index e6fe58ddb..b75dd379f 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -71,7 +71,7 @@ React прагматичен. Это обусловлено потребност ### Планирование {#scheduling} -Даже если компоненты описаны как функции, при использовании React они не вызываются напрямую. Каждый компонент возвращает [описание того, что должно быть отрендерено](/blog/2015/12/18/react-components-elements-and-instances.html#elements-describe-the-tree). Описание может включать как пользовательские компоненты, такие как ``, так и платформо-зависимые компоненты, такие как `
`. В дальнейшем в какой-то момент React может «развернуть» `` и фактически применить изменения к UI-дереву в соответствии с результатами рекурсивного рендеринга компонент. +Даже если компоненты описаны как функции, при использовании React они не вызываются напрямую. Каждый компонент возвращает [описание того, что должно быть отрендерено](/blog/2015/12/18/react-components-elements-and-instances.html#elements-describe-the-tree). Описание может включать как пользовательские компоненты, такие как ``, так и платформо-зависимые компоненты, такие как `
`. В дальнейшем в какой-то момент React может «развернуть» `` и фактически применить изменения к UI-дереву в соответствии с результатами рекурсивного рендеринга компонентов. Это тонкое, но сильное различие. Поскольку вы не вызываете этот функциональный компонент, а позволяете React вызывать его, это означает, что React может отложить вызов при необходимости. В текущей реализации React рекурсивно обходит дерево и вызывает функции рендера всего обновлённого дерева за один проход. Но в будущем он может начать [задерживать некоторые обновления, чтобы избежать потери кадров](https://github.com/facebook/react/issues/6170). From d542d26c0a9bea2793c9a4d8fd7211ece848b68a Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:35:39 +0300 Subject: [PATCH 36/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index b75dd379f..64ccdb9a6 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -81,7 +81,7 @@ React не является универсальной библиотекой о Если что-то находится вне экрана, можно отложить любую связанную с этим логику. Если данные поступают быстрее, чем кадры успевают обновиться, можно объединить их и обновлять пакетами. Мы можем приоритизировать работу, вызванную пользовательским взаимодействием (например, анимация нажатия кнопки), над менее важной фоновой работой (например, рендеринг только что загруженного из сети компонента), чтобы избежать потери кадров. -Чтобы было понятно, мы не пользуемся этим прямо сейчас. Однако, подобная свобода объясняет, почему мы предпочитаем контролировать планирование и почему `setState()` асинхронна. Концептуально мы думаем об этом как о «планировании обновления». +Уточним, что это на сегодняшний день это ещё не реализовано. Однако, подобная свобода иллюстрирует, почему мы предпочитаем контролировать планирование и почему функция `setState()` работает асинхронно. Концептуально мы думаем об этом как о «планировании обновления». Нам было бы труднее получить контроль над планированием, если бы мы позволили пользователям напрямую создавать представления на основе «push» парадигмы, распространённой в некоторых вариациях [Функционального реактивного программирования](https://en.wikipedia.org/wiki/Functional_reactive_programming). Мы хотим владеть «склеивающим» кодом. From 9aaf2d424dfa144657b71c66632d109e9a84c1e8 Mon Sep 17 00:00:00 2001 From: Anton Ahatov Date: Wed, 13 Mar 2019 20:38:26 +0300 Subject: [PATCH 37/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 64ccdb9a6..cf353d5d4 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -83,7 +83,7 @@ React не является универсальной библиотекой о Уточним, что это на сегодняшний день это ещё не реализовано. Однако, подобная свобода иллюстрирует, почему мы предпочитаем контролировать планирование и почему функция `setState()` работает асинхронно. Концептуально мы думаем об этом как о «планировании обновления». -Нам было бы труднее получить контроль над планированием, если бы мы позволили пользователям напрямую создавать представления на основе «push» парадигмы, распространённой в некоторых вариациях [Функционального реактивного программирования](https://en.wikipedia.org/wiki/Functional_reactive_programming). Мы хотим владеть «склеивающим» кодом. +Нам будет сложнее контролировать планирование, если мы позволим пользователям использовать подход «выталкивание при наличии данных», распространённый в [функциональном реактивном программировании](https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%B0%D0%BA%D1%82%D0%B8%D0%B2%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5#%D0%A4%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5_%D1%80%D0%B5%D0%B0%D0%BA%D1%82%D0%B8%D0%B2%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B). Мы хотим, чтобы наш код был «связующим». Ключевая задача для React — минимизировать количество пользовательского кода, выполняемого перед возвращением обратно в React. Это гарантирует, что React сохранит возможность планировать и разбивать работу на части в соответствии с тем, что ему известно о UI. From 588fb8ae38524cee34e3f2912a985253975ed153 Mon Sep 17 00:00:00 2001 From: Anton Ahatov Date: Wed, 13 Mar 2019 20:38:55 +0300 Subject: [PATCH 38/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index cf353d5d4..8c3e31774 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -87,7 +87,7 @@ React не является универсальной библиотекой о Ключевая задача для React — минимизировать количество пользовательского кода, выполняемого перед возвращением обратно в React. Это гарантирует, что React сохранит возможность планировать и разбивать работу на части в соответствии с тем, что ему известно о UI. -В команде есть внутренняя шутка, что React должен был называться «Schedule», потому что React не хочет быть полностью «реактивным». +В команде есть внутренняя шутка, что React должен был называться «Планировщик», потому что React не хочет быть полностью «реактивным». ### Developer Experience {#developer-experience} From cafe9a820f1cbbef4da75c9faeb909e32391ec55 Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:40:17 +0300 Subject: [PATCH 39/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 8c3e31774..5269764eb 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -28,7 +28,7 @@ redirect_from: ### Общая абстракция {#common-abstraction} -В целом, мы [против добавления функциональности](https://www.youtube.com/watch?v=4anAwXYqLG8), которая может быть реализована в пользовательских приложениях. Мы не хотим заполнять ваше приложения бесполезным кодом библиотеки. Но, из этого правила есть исключения. +В целом, мы [против добавления функциональности](https://www.youtube.com/watch?v=4anAwXYqLG8), которая может быть реализована в пользовательских приложениях. Мы не хотим раздувать ваше приложение бесполезным кодом библиотеки. Но и у этого правила есть свои исключения. Например, если бы React не предоставлял поддержку внутреннего состояния или методов жизненного цикла, люди бы создавали собственные абстракции для них. Когда есть несколько конкурирующих абстракций, React не может применять или использовать их свойства. Он должен работать с наименьшим общим знаменателем. From ac0dd9140d5c7bd05cfd909e7993110d4097dc3f Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:40:59 +0300 Subject: [PATCH 40/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 5269764eb..81742e0ef 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -30,7 +30,7 @@ redirect_from: В целом, мы [против добавления функциональности](https://www.youtube.com/watch?v=4anAwXYqLG8), которая может быть реализована в пользовательских приложениях. Мы не хотим раздувать ваше приложение бесполезным кодом библиотеки. Но и у этого правила есть свои исключения. -Например, если бы React не предоставлял поддержку внутреннего состояния или методов жизненного цикла, люди бы создавали собственные абстракции для них. Когда есть несколько конкурирующих абстракций, React не может применять или использовать их свойства. Он должен работать с наименьшим общим знаменателем. +Например, если бы React не предоставлял поддержку внутреннего состояния или методов жизненного цикла, люди бы создавали собственные абстракции для них. Когда есть несколько конкурирующих абстракций, React не может применять или использовать их свойства. Для работы React нужен некий наименьший общий знаменатель. Вот почему иногда мы добавляем функционал в сам React. Если мы замечаем, что какой-то функционал реализуется несовместимо или неэффективно во многих компонентах, мы можем захотеть внедрить его в React. Это не происходит просто так. Если мы добавляем новый функционал, значит мы уверены, что повышение уровня абстракции принесёт выгоду всей экосистеме. Хорошие примеры для этого — состояние, методы жизненного цикла, кросс-браузерная нормализация событий. From 639010cfdc9ee080579783663d2a8db275f6a1d9 Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:41:34 +0300 Subject: [PATCH 41/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 81742e0ef..293c40cdb 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -32,7 +32,7 @@ redirect_from: Например, если бы React не предоставлял поддержку внутреннего состояния или методов жизненного цикла, люди бы создавали собственные абстракции для них. Когда есть несколько конкурирующих абстракций, React не может применять или использовать их свойства. Для работы React нужен некий наименьший общий знаменатель. -Вот почему иногда мы добавляем функционал в сам React. Если мы замечаем, что какой-то функционал реализуется несовместимо или неэффективно во многих компонентах, мы можем захотеть внедрить его в React. Это не происходит просто так. +Вот почему иногда мы добавляем возможности в сам React. Если мы замечаем, что какая-то возможность реализуется плохо совместимым или неэффективным способом во многих компонентах, мы можем захотеть внедрить эту возможность в React. Мы подходим к таким изменениям со всей серьёзностью. Если мы добавляем новый функционал, значит мы уверены, что повышение уровня абстракции принесёт выгоду всей экосистеме. Хорошие примеры для этого — состояние, методы жизненного цикла, кросс-браузерная нормализация событий. Мы всегда обсуждаем с сообществом такие предложения по улучшению. Некоторые из этих обсуждений можно найти по метке [«big picture»](https://github.com/facebook/react/issues?q=is:open+is:issue+label:"Type:+Big+Picture") в трекере задач React. From fe02083408b2f72cda1b70575da71765e4b47409 Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:42:19 +0300 Subject: [PATCH 42/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 293c40cdb..e0bf50836 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -33,7 +33,7 @@ redirect_from: Например, если бы React не предоставлял поддержку внутреннего состояния или методов жизненного цикла, люди бы создавали собственные абстракции для них. Когда есть несколько конкурирующих абстракций, React не может применять или использовать их свойства. Для работы React нужен некий наименьший общий знаменатель. Вот почему иногда мы добавляем возможности в сам React. Если мы замечаем, что какая-то возможность реализуется плохо совместимым или неэффективным способом во многих компонентах, мы можем захотеть внедрить эту возможность в React. Мы подходим к таким изменениям со всей серьёзностью. -Если мы добавляем новый функционал, значит мы уверены, что повышение уровня абстракции принесёт выгоду всей экосистеме. Хорошие примеры для этого — состояние, методы жизненного цикла, кросс-браузерная нормализация событий. +Если мы добавляем новую возможность, значит мы уверены, что повышение уровня абстракции принесёт выгоду всей экосистеме. Хорошие примеры для этого — состояние, методы жизненного цикла, кросс-браузерная нормализация событий. Мы всегда обсуждаем с сообществом такие предложения по улучшению. Некоторые из этих обсуждений можно найти по метке [«big picture»](https://github.com/facebook/react/issues?q=is:open+is:issue+label:"Type:+Big+Picture") в трекере задач React. From 4272c2e8555bae303af84ef1290eb7eb0f31221a Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:43:17 +0300 Subject: [PATCH 43/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index e0bf50836..3a7afbdf4 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -41,7 +41,7 @@ redirect_from: React прагматичен. Это обусловлено потребностями продуктов, написанных в Facebook. Хоть на него и влияют некоторые не самые популярные парадигмы, такие как функциональное программирование, цель проекта — оставаться доступным для широкого круга разработчиков с разным уровнем опыта и навыками. -Если мы хотим отказаться от паттерна, который нам не нравится, мы должны рассмотреть все существующие варианты его использования и [проинформировать сообщество об альтернативах](/blog/2016/07/13/mixins-considered-harmful.html), прежде чем отказаться от него. Если какой-то полезный для создания приложений паттерн трудно описать декларативно, мы [предоставим для него императивное API](/docs/more-about-refs.html). Если мы не можем найти идеальное API для того, что мы считаем необходимым во многих приложениях, мы [предоставим временное, частично работающее API](/docs/legacy-context.html), позже от него можно будет избавиться. Это оставляет открытую дверь для будущих улучшений. +Если мы хотим отказаться от паттерна, который нам не нравится, на нас лежит ответственность рассмотреть все существующие варианты его использования и [проинформировать сообщество об альтернативах](/blog/2016/07/13/mixins-considered-harmful.html), прежде чем отказаться от него. Если какой-то полезный для создания приложений паттерн трудно описать декларативно, мы [предоставим для него императивный API](/docs/more-about-refs.html). Если мы не можем найти идеальный API для того, что мы считаем необходимым во многих приложениях, мы [предоставим временный, частично работающий API](/docs/legacy-context.html), при условии, что от него можно будет избавиться позже. Это оставляет открытой дверь для будущих улучшений. ### Стабильность {#stability} From 6954438ef0912138e8993ab204fcc281d978c1a4 Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:44:05 +0300 Subject: [PATCH 44/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 3a7afbdf4..f058d66bb 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -45,7 +45,7 @@ React прагматичен. Это обусловлено потребност ### Стабильность {#stability} -Мы ценим стабильность API. У нас в Facebook более 50 тысяч компонент, использующих React. Многие другие компании, включая [Twitter](https://twitter.com/) и [Airbnb](https://www.airbnb.com/), также активно используют React. Поэтому мы обычно нехотя меняем публичное API или поведение. +Мы ценим стабильность API. У нас в Facebook более 50 тысяч компонентов, использующих React. Многие другие компании, включая [Twitter](https://twitter.com/) и [Airbnb](https://www.airbnb.com/), также активно используют React. Поэтому мы обычно нехотя меняем публичный API или поведение. Однако, мы считаем преувеличением думать, что стабильность — это когда «ничего не меняется». Это быстро приводит к застою. Вместо этого, мы предпочитаем воспринимать стабильность в смысле «это много используется в продакшене и когда что-то меняется, существует четкий (и желательно автоматизированный) план миграции». From 18092228f813d63e25724ae809be070a4a93f66d Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:44:36 +0300 Subject: [PATCH 45/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index f058d66bb..ab1735ba3 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -47,7 +47,7 @@ React прагматичен. Это обусловлено потребност Мы ценим стабильность API. У нас в Facebook более 50 тысяч компонентов, использующих React. Многие другие компании, включая [Twitter](https://twitter.com/) и [Airbnb](https://www.airbnb.com/), также активно используют React. Поэтому мы обычно нехотя меняем публичный API или поведение. -Однако, мы считаем преувеличением думать, что стабильность — это когда «ничего не меняется». Это быстро приводит к застою. Вместо этого, мы предпочитаем воспринимать стабильность в смысле «это много используется в продакшене и когда что-то меняется, существует четкий (и желательно автоматизированный) план миграции». +Однако, мы считаем переоценённой идею, что стабильность — это когда «ничего не меняется». Она быстро приводит к застою. Вместо этого, мы предпочитаем воспринимать стабильность в смысле «это много используется в продакшене и когда что-то меняется, существует четкий (и желательно автоматизированный) план миграции». Когда мы исключаем паттерн, мы изучаем как он используется внутри Facebook и добавляем предупреждения об исключении. Что позволяет нам оценить эффект изменения. Иногда мы отменяем изменения, если видим, что ещё слишком рано и нам нужно продумать стратегию продвижения кодовой базы к точке готовности к изменениям. From 64e24eba5d26c4ee03d51959c7452eb2a0d0484a Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:45:30 +0300 Subject: [PATCH 46/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index ab1735ba3..613de72e7 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -49,7 +49,7 @@ React прагматичен. Это обусловлено потребност Однако, мы считаем переоценённой идею, что стабильность — это когда «ничего не меняется». Она быстро приводит к застою. Вместо этого, мы предпочитаем воспринимать стабильность в смысле «это много используется в продакшене и когда что-то меняется, существует четкий (и желательно автоматизированный) план миграции». -Когда мы исключаем паттерн, мы изучаем как он используется внутри Facebook и добавляем предупреждения об исключении. Что позволяет нам оценить эффект изменения. Иногда мы отменяем изменения, если видим, что ещё слишком рано и нам нужно продумать стратегию продвижения кодовой базы к точке готовности к изменениям. +Когда мы объявляем паттерн устаревшим, мы сперва изучаем как он используется внутри Facebook и добавляем предупреждения об устаревании. Это позволяет нам оценить масштабы последствий изменения. Иногда мы отменяем изменение, если видим, что ещё слишком рано приступать к его воплощению и нам нужно продумать стратегию продвижения кодовой базы к состоянию готовности. Если мы уверены, что изменение не слишком большое и для всех случаев использования возможна миграция, то предупреждение об исключении выпускается в OSS-сообщество. Мы тесно общаемся со многими React-пользователями вне Facebook, следим за популярными OSS-проектами и помогаем им исправлять устаревший код. From e34452de051f9ee55f6ae691a4de93ea54c4b918 Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:46:06 +0300 Subject: [PATCH 47/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 613de72e7..d3e43fe82 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -51,7 +51,7 @@ React прагматичен. Это обусловлено потребност Когда мы объявляем паттерн устаревшим, мы сперва изучаем как он используется внутри Facebook и добавляем предупреждения об устаревании. Это позволяет нам оценить масштабы последствий изменения. Иногда мы отменяем изменение, если видим, что ещё слишком рано приступать к его воплощению и нам нужно продумать стратегию продвижения кодовой базы к состоянию готовности. -Если мы уверены, что изменение не слишком большое и для всех случаев использования возможна миграция, то предупреждение об исключении выпускается в OSS-сообщество. Мы тесно общаемся со многими React-пользователями вне Facebook, следим за популярными OSS-проектами и помогаем им исправлять устаревший код. +Если мы уверены, что изменение не слишком большое и для всех случаев использования возможна миграция, то предупреждение об устаревании публикуется перед OSS-сообществом. Мы тесно общаемся со многими React-пользователями вне Facebook, следим за популярными OSS-проектами и помогаем им исправлять устаревший код. Учитывая огромный размер кодовой базы React в Facebook, успешная внутренняя миграция часто является хорошим индикатором того, что в других компаниях также не будет проблем. Тем не менее, люди иногда указывают на неучтенные варианты использования и мы добавляем лазейки или пересматриваем подход. From 6c1f4a54cee3020a0070dd6d146008a68564e2a7 Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:46:44 +0300 Subject: [PATCH 48/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index d3e43fe82..92ff5f9d2 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -55,7 +55,7 @@ React прагматичен. Это обусловлено потребност Учитывая огромный размер кодовой базы React в Facebook, успешная внутренняя миграция часто является хорошим индикатором того, что в других компаниях также не будет проблем. Тем не менее, люди иногда указывают на неучтенные варианты использования и мы добавляем лазейки или пересматриваем подход. -Ничего не исключается без веской причины. Мы понимаем, что иногда предупреждения об исключениях разочаровывают. Но они добавляются, так как исключения открывают дорогу для улучшений и новых возможностей, которые мы и сообщество считаем важными. +Ничто не объявляется устаревшим без веской причины. Мы понимаем, что иногда предупреждения об устаревании разочаровывают. Но они вводятся, так как это открывает дорогу улучшениям и новым возможностям, которые мы и сообщество считаем важными. Например, мы добавили [предупреждение о неизвестных DOM-свойствах](/warnings/unknown-prop.html) в React 15.2.0. Этим мы затронули многие проекты. Однако, исправление этого предупреждения важно для добавления в React поддержки [пользовательских атрибутов](https://github.com/facebook/react/issues/140). Подобная причина стоит за каждым исключением, которое мы добавляем. From 274e91eb4e12305c62bd8de041457ceb7595ffc7 Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:48:32 +0300 Subject: [PATCH 49/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 92ff5f9d2..0e09fac6e 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -59,7 +59,7 @@ React прагматичен. Это обусловлено потребност Например, мы добавили [предупреждение о неизвестных DOM-свойствах](/warnings/unknown-prop.html) в React 15.2.0. Этим мы затронули многие проекты. Однако, исправление этого предупреждения важно для добавления в React поддержки [пользовательских атрибутов](https://github.com/facebook/react/issues/140). Подобная причина стоит за каждым исключением, которое мы добавляем. -При добавлении предупреждения об исключении, мы не удаляем его пока текущая мажорная версия не устарела, [изменяя поведение только в следующей мажорной версии](/blog/2016/02/19/new-versioning-scheme.html). Если исключение создаёт много повторяющейся ручной работы, мы публикуем [codemod-скрипт](https://www.youtube.com/watch?v=d0pOgY8__JM), который автоматизирует большую часть изменений. Codemod-скрипты дают нам возможность двигаться вперёд, не закапываясь в куче кода. Рекомендуем вам тоже их использовать. +При добавлении предупреждения об устаревании, мы оставляем его пока актуальна текущая мажорная версия, [изменяя поведение только в следующей мажорной версии](/blog/2016/02/19/new-versioning-scheme.html). Если изменение создаёт много повторяющейся ручной работы, мы публикуем [codemod-скрипт](https://www.youtube.com/watch?v=d0pOgY8__JM), который автоматизирует большую часть изменений. Codemod-скрипты дают нам возможность двигаться вперёд, не закапываясь в куче кода. Рекомендуем вам тоже их использовать. Вы можете найти уже вышедшие codemod-скрипты в [react-codemod](https://github.com/reactjs/react-codemod) репозитории. From f9ee6f9a8f175e9a236358a6df8b40249981dba4 Mon Sep 17 00:00:00 2001 From: ANOTHER GUY Date: Wed, 13 Mar 2019 20:48:59 +0300 Subject: [PATCH 50/51] Update content/docs/design-principles.md Co-Authored-By: echobrain --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 0e09fac6e..74ec57cc2 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -61,7 +61,7 @@ React прагматичен. Это обусловлено потребност При добавлении предупреждения об устаревании, мы оставляем его пока актуальна текущая мажорная версия, [изменяя поведение только в следующей мажорной версии](/blog/2016/02/19/new-versioning-scheme.html). Если изменение создаёт много повторяющейся ручной работы, мы публикуем [codemod-скрипт](https://www.youtube.com/watch?v=d0pOgY8__JM), который автоматизирует большую часть изменений. Codemod-скрипты дают нам возможность двигаться вперёд, не закапываясь в куче кода. Рекомендуем вам тоже их использовать. -Вы можете найти уже вышедшие codemod-скрипты в [react-codemod](https://github.com/reactjs/react-codemod) репозитории. +Вы можете найти ранее опубликованные codemod-скрипты в [react-codemod](https://github.com/reactjs/react-codemod) репозитории. ### Совместимость {#interoperability} From 1985f42017497528a3ba4a06202aa92a5f1da981 Mon Sep 17 00:00:00 2001 From: echobrain Date: Wed, 13 Mar 2019 20:51:58 +0300 Subject: [PATCH 51/51] fixed translation of stability --- content/docs/design-principles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/design-principles.md b/content/docs/design-principles.md index 74ec57cc2..553096b3b 100644 --- a/content/docs/design-principles.md +++ b/content/docs/design-principles.md @@ -57,7 +57,7 @@ React прагматичен. Это обусловлено потребност Ничто не объявляется устаревшим без веской причины. Мы понимаем, что иногда предупреждения об устаревании разочаровывают. Но они вводятся, так как это открывает дорогу улучшениям и новым возможностям, которые мы и сообщество считаем важными. -Например, мы добавили [предупреждение о неизвестных DOM-свойствах](/warnings/unknown-prop.html) в React 15.2.0. Этим мы затронули многие проекты. Однако, исправление этого предупреждения важно для добавления в React поддержки [пользовательских атрибутов](https://github.com/facebook/react/issues/140). Подобная причина стоит за каждым исключением, которое мы добавляем. +Например, мы добавили [предупреждение о неизвестных DOM-свойствах](/warnings/unknown-prop.html) в React 15.2.0. Этим мы затронули многие проекты. Однако, исправление этого предупреждения важно для добавления в React поддержки [пользовательских атрибутов](https://github.com/facebook/react/issues/140). Подобная причина стоит за каждым объявлением об устаревании, которое мы добавляем. При добавлении предупреждения об устаревании, мы оставляем его пока актуальна текущая мажорная версия, [изменяя поведение только в следующей мажорной версии](/blog/2016/02/19/new-versioning-scheme.html). Если изменение создаёт много повторяющейся ручной работы, мы публикуем [codemod-скрипт](https://www.youtube.com/watch?v=d0pOgY8__JM), который автоматизирует большую часть изменений. Codemod-скрипты дают нам возможность двигаться вперёд, не закапываясь в куче кода. Рекомендуем вам тоже их использовать.