Хорошие практики стрелочных функций в JavaScript

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

Фреймворки для тестирования

Обычно тестовые примеры пишутся дольше, чем порог тайм-аута Testing Framework, поэтому Testing Frameworks позволяют указать тайм-аут для тестов; Mocha, например, дает вам гибкость, чтобы указать собственный тайм-аут для каждого теста.

Поместите себя в следующий упрощенный сценарий:

Этот тест вернет: Error: Timeout of 2000ms exceeded., Mocha позволяет вам установить this.timeout для управления порогом тайм-аута тестового примера, например:

Таким образом, тест проходит:

TypeError: this.timeout is not a functionПодождите, что?

Фреймворки тестирования, такие как Mocha, полагаются на привязку, передавая конфигурации через this, то есть: this.skip this.timeout(1000), но выражения функций со стрелками не могут быть привязаны, что означает, что нам нужно написать выражение функции.

Это настолько распространенная проблема, что в документации Mocha есть раздел, чтобы отговорить вас от использования стрелочных функций.

Не рекомендуется передавать в Mocha стрелочные функции (также известные как лямбды). Лямбды лексически связывают this и не могут получить доступ к контексту Mocha.

Давайте попробуем еще раз с ключевым словом function:

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

Моя рекомендация для вас: напишите все функции тестовых примеров с помощью Function Expressions, ключевого слова function, если вы находитесь в аналогичной ситуации, это дает три основных преимущества:

  1. Вы забываете об этом случае, черт возьми, у вас уже слишком много пограничных случаев домена, зачем добавлять дополнительный пограничный случай программирования?
  2. Ваш код более единообразен, все тестовые примеры будут написаны как выражения функций, а не только те, которым требуется this; Преимущества единообразия превышают выгоду от написания на 4 символа меньше.
  3. Вы избегаете изменения синтаксиса, когда вам нужны эти функции, а затем учитываете пункт 2.

Где ожидается подъем

Вы, вероятно, использовали этот шаблон, который, кстати, прекрасен:

Это хорошо, не правда ли? Это позволяет вам назвать все эти однострочные и придать больше смысла вашему коду, +1 к чистому коду, у вас все отлично, и я серьезно.

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

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

Подъем - это стандартное поведение, при котором все объявления перемещаются наверх области видимости перед выполнением кода.

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

Взгляните на следующий сценарий:

Функции, объявленные с помощью этого шаблона, хороши для однострочников, но они теряют часть динамизма JavaScript.

Бывает, что переменные, объявленные с ключевым словом theconst, действительно поднимаются, но они не инициализируются, они будут инициализированы, когда их лексическая привязка будет оценена во время выполнения, английский язык:

Механизм JavaScript должен оценить правую часть оператора присваивания (=) и назначить ее левой стороне, чтобы ссылка считалась инициализированной и могла быть использована. Это происходит только во время выполнения, последовательно, в конечном итоге вынуждая вас использовать переменные, объявленные с ключевым словом const после их объявления, в противном случае вы получите справочную ошибку, потому что вы обращаетесь к неинициализированной переменной.

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

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

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

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

Бонус

О теле выражений функций стрелок

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

Маджестик, не правда ли? Код, который работает. Пока этого не произойдет. Хуже всего то, что на самом деле он, вероятно, выйдет из строя, мы говорим здесь о JavaScript, все может потерпеть неудачу.

Когда что-то не складывается (это каламбур), вам нужно будет поместить инструментарий в тело функции, она становится такой:

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

После того, как вы закончите отладку и окончательно исправите ошибку, вы удалите тело и снова сделаете однострочник. Этот процесс часто повторяется. Это может быть даже постоянная разница в вашем репо, когда кто-то забывает вернуться к однострочному.

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

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

Идеальное место для выражений функций стрелок

Идеальное место для выражений функций стрелок - это специальные функции, которые нельзя использовать повторно, например, предикаты для array.map array.filter.

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

Бесстыдная пробка

Надеюсь, мое путешествие вам немного поможет. Если вам понравилась эта статья, возможно, вам понравятся и другие:

  1. Рассказано тестовыми случаями: Redux Action Retry.
  2. 6 инструментов, которые изменили для меня JavaScript.
  3. Как менеджмент ограничивает ваш потенциал как разработчика.

Если вам нравится эта статья, пожалуйста, подпишитесь на мою рассылку, подписывайтесь на меня в Instagram @codingedgar, где я публикую красивые картинки о концепциях программирования, и Twitter @codingedgar, где я говорю о… вещах. Протестируйте свой код, почистите зубы и оставьте несколько аплодисментов и приятный комментарий 💬

Примечание из JavaScript In Plain English

Мы запустили три новых издания! Проявите любовь к нашим новым публикациям, подписавшись на них: AI на простом английском, UX на простом английском, Python на простом английском - спасибо и продолжайте учиться!

Мы также всегда заинтересованы в содействии продвижению качественного контента. Если у вас есть статья, которую вы хотите отправить в какую-либо из наших публикаций, отправьте нам электронное письмо по адресу [email protected] с вашим именем пользователя Medium, и мы добавим вас в качестве автора. Также сообщите нам, к каким публикациям вы хотите быть добавлены.