Хорошие практики ReactJS

В этой статье я хочу представить пару хороших практик в ReactJS и подчеркнуть важность сохранения хороших практик в команде для обеспечения стабильного качества.

Но сначала, что является хорошей практикой? Согласно Википедии, хорошая практика:

«Метод или техника, которые общепризнанно превосходят любые альтернативы, потому что они дают результаты, превосходящие результаты, достигнутые другими способами, или потому что они стали стандартным способом выполнения действий, например, стандартным способом соблюдения требований. с юридическими или этическими требованиями ».

Мы используем передовой опыт, потому что с его помощью мы работаем лучше и быстрее добиваемся результатов. Однако определение указывает на один из аспектов передовой практики, который, на мой взгляд, даже более важен, чем улучшение работы. Это факт, что хорошая практика должна стать стандартом. Потому что чаще всего (и вы убедитесь в этом в этой статье) существует несколько лучших способов сделать что-то, и команда должна сделать выбор, какой стандарт использовать.

Используйте передовой опыт своей команды

Прежде всего, не забудьте спросить о передовых методах работы вашей команды! На самом деле цель хороших практик - убедиться, что все им следуют, чтобы мы могли достичь единства и согласованности в команде. Если каждый человек следует своей собственной версии «хороших практик», тогда представление о том, что такое хороший код, ломается внутри команды. Если хороших практик нет, поговорите с командой, чтобы установить их.

Если вы считаете, что передовой опыт вашей команды неэффективен, возможны два сценария:

• Вы думаете, что они нехорошие, потому что они не удобны / не устарели…. В таком случае обязательно поговорите об этом со своей командой и при необходимости договоритесь об изменении.
• Вы думаете, что они плохие, потому что они вам не нравятся или вы к ним не привыкли. Тогда, может быть, вам пора адаптироваться. Помните, что всегда лучше придерживаться общих стандартов внутри команды, чем просто следовать всем остальным.

Помните:

«Если хочешь идти быстро, иди одна. Если хочешь далеко уйти, то иди вместе ».

Без лишних слов, давайте углубимся в код!

Объявление переменной и контекст

В ReactJS вы, скорее всего, будете использовать переменные. Главное, что нужно помнить, - где их объявить. Часто место, в котором объявляется переменная, почти так же важно, как и ее имя (для этого есть еще одна хорошая практика). Таким образом, правило состоит в том, чтобы объявлять переменные в той области действия, в которой они используются, а не в меньшей или большей области. Почему это важно? Потому что область, в которой объявлена ​​переменная, предлагает информацию о том, какой компонент / функция собирается ее использовать и как далеко она должна дойти. Это похоже на инкапсуляцию в том смысле, что вы хотите поместить свою переменную только там, где она будет использоваться. И вы могли бы сказать:

«Да, но это не очень важный момент, это всем известно».

Собственно, не все об этом знают. Причина, по которой я использую этот пример, чтобы начать работу, заключается в том, что это мелкие детали, которые необходимо согласовать команде, чтобы выразить, что «передовой опыт» означает в вашей организации.

Это = это

Сколько раз вы видели этот фрагмент кода? Если вы работаете на JS, я уверен, что вы видите это довольно часто. Принцип прост. Вы находитесь в функции, которая имеет собственный контекст (например, onClick), но вы хотите получить экземпляр компонента, а не событие или что-то еще. Уловка заключается в том, что перед функцией сохраните ссылку на экземпляр в переменной, например:

$(‘#element’).click(function(){
 // that is a reference to the clicked element
 let that = this;
$(‘.elements’).each(function(){
 // this is a reference to the current element in the loop
 // that is still a reference to the clicked element
 });
});

Конечно, вы уже знаете, когда видите переменную с именем «that», что это уловка, позволяющая скрыть «это». Однако давайте представим, что у вас есть несколько уровней функций, каждый из которых имеет свой контекст. Собираетесь ли вы использовать это2? Это? вещь? Даже если есть только одна переменная, такая как «this», я бы предложил назвать ее правильно, просто легче понять, что она делает, без необходимости возвращаться туда, где объявлена ​​переменная, чтобы проверить, что означает «this».

Тогда простой для понимания код будет выглядеть так:

$(‘#element’).click(function(){
 // clickedElement is a reference to the clicked element
 let clickedElement = this;
 $(‘.elements’).each(function(){
 // “this” is a reference to the current element in the loop
 // clickedElement is a reference to the clicked on element
 });
});

С «clickedElement» вы легко понимаете, что это ссылка на элемент, по которому щелкнули, с «что»… .. Что вы получаете?

Убедитесь, что ваши изменения не повлияют отрицательно на другие компоненты

Самое замечательное в React заключается в том, что вы можете создавать несколько компонентов из одного и того же класса, как в ООП. Не очень хорошая вещь, которая связана с этим, заключается в том, что если вы измените что-то в классе, это повлияет на все экземпляры компонентов, которые используют этот класс.

Урок здесь состоит в том, чтобы быть осторожным при изменении компонента, потому что, хотя ваше изменение может быть эффективным для того места, где вы хотите, чтобы оно произошло, оно может сломать что-то еще где-то в другом месте. Так что будьте осторожны, когда делаете такие вещи, как:

• Добавление, удаление, переименование параметров в функциях
• Добавление, удаление, переименование переменных состояния
• Добавление, удаление, переименование свойств по умолчанию
• Переименование функции
• Изменение метода рендеринга
• Изменение классов в HTML
• Изменение CSS, применяемого к компоненту

Делайте компоненты небольшими

Название этой части говорит само за себя. Есть несколько веских причин, по которым вы должны сохранять компоненты относительно небольшими в проекте React:

Во-первых, его легче читать и понимать. В случае, если более крупный компонент состоит из более мелких, еще проще иметь каждую часть кода в отдельном компоненте, чтобы у нас действительно была единственная ответственность за каждый файл, и мы могли лучше и быстрее понять концепцию компонента.

Во-вторых, как мы заявили, важна единоличная ответственность. Это почему? Это один из принципов SOLID, который гарантирует, что код остается чистым и легким для улучшения / работы, он гарантирует, что мы можем легко повторно использовать компонент (потому что вы просто используете основные функции этого компонента, без необходимости перетаскивать другие обязанности, которые вы выиграли. не в конечном итоге использовать).

В-третьих, легче заменить небольшой компонент. Меньше кода, меньше зависимостей, меньше частей, которые должны работать, несмотря на изменения, меньше вещей для тестирования….

В-четвертых, легче тестировать более мелкие компоненты. Чем сложнее компонент, тем больше вам придется имитировать, моделировать и тестировать различные случаи. Если вы сохраните простой компонент, тесты, скорее всего, останутся простыми.

Функциональный компонент без состояния

Эта следующая часть хорошо известна в сообществе и заслуживает внимания. Если ваш класс выглядит так:

class ShoppingList extends React.Component {
  render() {
     return (
         <div className=”shopping-list”>
           <h1>Shopping List for {this.props.name}</h1>
           <ul>
             <li>Instagram</li>
             <li>WhatsApp</li>
             <li>Oculus</li>
          </ul>
        </div>
     );
   }
}

Вы бы что-то заметили ... государства нет! Теперь это нормально, если вы хотите оставить все как есть, код работает, и вы можете легко понять, что происходит. Однако позвольте мне предложить небольшое улучшение - превратить этот класс в функциональный компонент:

const ShoppingList = (props) => (
 <div className=”shopping-list”>
   <h1>Shopping List for {props.name}</h1>
   <ul>
     <li>Instagram</li>
     <li>WhatsApp</li>
     <li>Oculus</li>
   </ul>
 </div>
);

Мы видим два основных преимущества использования этого стиля:

• При использовании в качестве стандарта мы напрямую понимаем, что этот компонент не будет иметь управления состоянием или что жизненный цикл не будет слишком сложным для обработки.
• Код сокращен до самого необходимого, и мы можем выполнить его быстрее

Используйте функции стрелок

Теперь поговорим о стрелочных функциях! Если вы не понимаете, о чем я говорю, напомню:

function doSmth(param){
 // This is a classic function
// Inside a component, we will have to use bind in order to use
// the “this” keyword
}

const doSmth = (param) = ›({
// Теперь вам не нужно связывать эту функцию

// «this» будет относиться к объекту, вызывающему функцию
});

В дополнение к преимуществу в примере кода, стрелочные функции можно использовать в таких функциях, как map, reduce, filter и делать код внутри короче и читабельнее.

Заключение

Повторюсь, самый важный аспект передовой практики - это поддерживать единство всех в вашей команде и делать то, что лучше всего работает в вашем проекте. Для вас и вашей команды важно собраться вместе и определить, каковы эти передовые методы, и убедиться, что все применяют их, даже если некоторые могут предпочесть другие методы.