Научитесь обнаруживать красные флажки в коде React/JavaScript?

1656682450 nauchites obnaruzhivat krasnye flazhki v kode reactjavascript

Донавон Вест

92Mj61KMZCO5TSFOUpW9ncdgNXrklqJGHnsC
Оригинальное нераскрашенное фото Артема Сапегина на Unsplash

Эта уверенная статья объясняет некоторые из красных флажков, на которые следует обратить внимание при просмотре проекта React/JavaScript. Избегание этих шаблонов может сделать ваш код более производительным, надежным и более простым в обслуживании.

? Обратите внимание на let ключевое слово

Еще в дни ES5, var был единственным средством в нашем распоряжении для создания переменных. ES6 представила блочную область видимости let и const ключевые слова.

Из своего опыта я вижу очень мало ситуаций, когда вам следует использовать let. Конечно, он имеет свое место (например, счетчик), но для большинства приложений const лучше подходит. Вскоре вы увидите почему.

Рассмотрим следующий распространенный случай использования. Это делает amount красным, если отрицательный, иначе будет чёрным.

let color;
if (amount < 0) {  color="red";} else {  color="black";}
return (  <span style={{ color }}>    {formatCurrency(amount)}  </span>);

Код использует a let но после инициализации, color переменная никогда не назначается повторно. Это именно тот случай использования для a const!

Мы не можем просто заменить let с const через структуру кода Однако, если мы проводим рефакторинг для использования троичного кода, a const работает идеально.

const color = amount < 0 ? 'red' : 'black';

Мы не только перешли от 6 строк кода к 1, но и с помощью a const вместо a letнаши инструменты выдадут ошибку, если мы ненамеренно переназначим const в другом месте кода

Вот результат ESLint, если я попытаюсь установить color к null после его определения.

/Users/donavon/Projects/my-project/src/index.jsx
43:5  error 'color' is constant

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

Преимущества использования конст.

  • Заставляет вас писать более чистый код
  • Проверка непреднамеренного повторного назначения переменной при компиляции

? Деструктуризация – ваш друг

Согласно MDN:

The задачи деструктуризации синтаксис — это выражение JavaScript, которое позволяет распаковывать значения из массивов или свойства объектов в различные переменные.

Это также значительно упрощает чтение кода. Возьмем, к примеру, этот фрагмент.

render() {  return(    <div className={this.props.className}>      {        this.props.isLoading          ? 'Loading...'          : this.props.children      }    </div>  );}

Есть несколько this.props продолжающиеся операции. Это медленнее в исполнении (ладно, незначительно, но все же нужно выполнить несколько поисков свойств объекта), и снова это добавляет визуальный беспорядок.

render() {  const { className, isLoading, children } = this.props;
  return(    <div className={className}>      {isLoading ? 'Loading...' : children}    </div>  );}

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

Преимущества деструктуризация

  • Потенциально быстрее выполнение
  • Уборщик
  • Менее склонен к скрытым ошибкам, вызванным ошибками печати

? Распространение на Object.assign

Ранее считалось, что необходимо создание поверхностной копии объекта или создание объекта из других объектов Object.assign. Но сегодня, с помощью babel мы можем использовать новый синтаксис распространения ES.

Вот некоторый код использования Object.assign.

const defaults = { foo: 'foo', bar: 'bar' };const obj1 = Object.assign({}, defaults, { bar: 'baz' });// {foo:'foo', bar:'baz'}

Нижеследующий код выводит те же результаты, но использует синтаксис распространения объекта.

const defaults = { foo: 'foo', bar: 'bar' };const obj1 = { ...defaults, bar: 'baz' };// {foo:'foo', bar:'baz'}

Этот «синтаксический сахар» позволяет видеть данные, над которыми вы работаете, без шума и препятствий, вызванных сантехникой ES5. Вы можете прочитать больше о шуме и беспорядках в моей статье.Вокруг нас шум”.

Аксель Раушмайер имеет прекрасное углубленное объяснение спреда против Object.assign в своей статье ES2018: Rest/Spread Properties. Это стоит вашего времени, если вы любите копаться в сантехнике.

Преимущества использования спреда

  • Меньше беспорядка
  • Потенциально эффективнее

? Использование троичного кода вместо использования логического I

Для простого if условий, тернарные не являются правильным инструментом. Я объясняю это подробно в своей статье о тернарном и логическом И в моей статье «Условный рендеринг в React с использованием тернарных и логических и”.

Преимущества использования логического и

? Функция стрелки тела выражение

Функции со стрелками идеально подходят для написания функциональных компонентов без сохранения состояния (SFC) в React и выпускаются в двух формах. Форма тела оператора такова.

const SomeFunction = () =&gt; {  return 'value';};

И форма тела выражения, которая подразумевает return заявление.

const SomeFunction = () =&gt; 'value';

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

const SomeFunction = () =&gt; (  'value');

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

К счастью, ESLint снова может прийти вам на помощь.

/Users/donavon/Projects/my-project/src/index.jsx
  12:17  error Unexpected block statement surrounding arrow body;         move the returned value immediately after the `=>`

Единственное, о чем следует помнить, это то, что для того чтобы вернуть объект в форме выражения, вы должны взять литерал объекта в скобки, вот так.

const SomeFunction = () =&gt; ({  foo: 'foo',  bar: 'bar',});

Достоинства функций Expression Body arrow

? Высушите этот дубликат кода

Вы не думали, что я напишу статью о красных флагах в вашем коде, не упоминая DRY, не правда ли? Вот и мы…

Посмотрите на следующие два SFC.

const Foo = () => (  <;div>    <h2 className="sectionTitle">      Foo Title    </h2>    ...  </div>);
const Bar = () => (  <;div>    <h2 className="sectionTitle">      Bar Title    </h2>    ...  </div>);

Обратите внимание на то, как выделены разделы кода выше Foo и Bar почти идентичны. Очевидно, они оба отображают название в определенном стиле. Что, если бы у вас был тот же код в 4, 5 или более местах? Очень вероятно, что любые изменения, внесенные в будущем, потребуют внесения изменений в нескольких местах.

Вы должны переработать повторяющийся код в свою функцию. Это называется DRYing или не повторяйся.

const Title = text => (  <h2 className="sectionTitle">    {text}  </h2>);
const Foo = () => (  <div>    <Title text="Foo Title" />    ...  </div>);
const Bar = () => (  <div>    <Title text="Bar Title" />    ...  </div>);

Преимущества кода DRY

? Почему вы используете конструктор?

Много раз при написании компонента класса React с сохранением состояния вы создаете конструктор для установки первоначального значения state. Вот распространённый пример.

constructor(props) {  super(props);  this.state = { count: 0 };}

Но знаете ли вы, что это можно сделать с помощью нового предложения свойств класса? Приведенный выше код можно записать просто так.

state = { count: 0 };

Подробнее об этом вы можете прочитать в моей статье.Конструктор умер, да здравствует конструктор”.

Преимущества отказа от использования конструктора

? Вывод

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

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

Строгие правила ESLint помогут вам заметить некоторые из них, или… вы всегда можете пометить меня тегом в своем запросе на получение. ?

Я хотел бы извиниться, если эта статья показалась ретроспективным эпизодом вашего любимого ситкома (я ненавижу их), но я хотел разоблачить тех из вас, кто никогда не читал мои другие статьи, возможность погрузиться глубже.

Я тоже пишу для инженерного блога American Express. Просмотрите другие мои работы и работы моих талантливых коллег на AmericanExpress.io. Вы также можете следить за мной в Twitter.

Добавить комментарий

Ваш адрес email не будет опубликован.