Comments 16
Object.entries — превращает объект в массив вида [[ключ, значение], [ключ, значение]]:
Конечно же, не превращает, объект остается как был:)
Вот так делать тоже не очень хорошо — на каждый вызов создавать новые функции
Если это место не высоко-нагруженное, то так делать можно. Никаких проблем.
Их можно вынести из тела функции
Чаще всего такой подход (матрёшки) встречается ввиду использования замыканий. Поэтому просто так взять и вынести не получится. Нужно будет ещё расширять аргументы, передавая туда всё необходимое из scope. Насколько это резонно — зависит от конкретного участка кода.
Часто мы не знаем где будет использоваться наш код
Очень и очень редко. Почти всегда мы очень отчётливо понимаем где будет использоваться наш код.
вероятность использовать это не в том месте возрастает
Очень надуманный предлог, не находите? Эдак можно пол языка срезать код-стайлом, без объективных на то причин. Важно понимание используемого инструмента, а не прятать голову в песок :)
Этот подход могут начать копировать другие участники проекта
Пускай копируют. Это одна из наиболее нативных вещей в JavaScript. Такими подходами JS и дышит. Это настолько распространённый паттерн… По сути это и есть JavaScript.
сделает функцию более тестируемой
Всё равно эту функцию никто не будет тестировать. Давайте заглянем правде в глаза. Тестировать каждый атом кодового пространства очень редко является разумной идеей. Более того, почти никогда — осуществимой. Вот тестирование её внешней обёртки — там да...
Drag13, важно понимать, что у JavaScript-а несколько иные приоритеты. Это скриптовый слабо-динамически-типизированный язык. Это не Rust, не C++, не C#. Избегая его сильных сторон по надуманным причинам вы не выигрываете ровным счётом ничего, а теряете — почти всё.
Посмотрите, к примеру, реализацию каррирования. Да и вообще исходники с использованием любых FP библиотек. Да даже код с использованием lodash-а, чего уж там. Все эти экономии на спичках, за счёт избегания замыканий и усложнения кодовой базы, просто меркнут на фоне того, что реально творится в сложных JS SPA. Спички экономим, а за окном лес горит.
Т.е. если замыкание оправдано — без проблем
Главным и зачастую единственным аргументом тут (в JS) выступает читаемость кода. И если с анонимкой в замыкании код читается легче, ей быть, если же нет — выносим отдельно. Поэтому я и написал выше, всё зависит от конкретного участка кода. Нет универсальных рецептов.
Нагромождение матрёшек никто не любит. С ними неудобно работать. Так же как и с кодом, который пусть и сделан "плоско", но теперь изобилует лишней сложностью, в виде множества аргументов, которые приходится таскать друг за другом паровозиками. И то и другое понемногу убивает кодовую вазу. Приходится искать компромисы.
Пример с == и === вы зря привели. В большинстве случаев == это зло без явной выгоды. У меня в коде вообще такого нет. А замыкания это сердце языка. Они везде. не надо их бояться. Это не "тоже возможность языка", а по сути центровая возможность языка. Избегать замыканий без объективных на то причин — просто ставить себе палки в колёса. Можно и без них, но чаще хуже, чем лучше. Тут стоит вопрос не "можно ли обойтись без?", тут стоит вопрос "а можно ли здесь упростить, используя замыкание". Это вполне себе желанный инструмент, который используется для упрощения кодовой базы и работы с ней. Это не антипаттерн.
Но как и любой инструмент — использовать надо мудро. Иначе будут нечитаемые уродливые матрёшки. Такой код потом только выкинуть )
В разделе "Работа с функциями" есть два очень опасных совета:
- Использование нестандартного
Function.caller— даже в MDN по ссылке написано, что оптимизатор может заинлайнить вызывающую функцию, и мы получим совсем не то, что имеем в виду. - Парсить регулярками результат
Function.toString— а что будет если кто-то пропустит код через минификатор?
Symbol.species — позволяет получить/изменить ссылку на конструктор, использующийся для создания новых объектов:
Что за arr?
Метапрограммирование в JavaScript