Ну, если вы про скобки, обрамляющие Function Expression, то да, они не обязательны. Но я бы не сказал, что это уж сильно большой недочет, возможно чисто косметический. А вот с delete тут не все здорово, так как delete не удаляет переменные, а удаляет ключи в объекте.
Ну, мне кажется, вы слишком прискребаетесь к формулировке вопросов в подобном "собеседовании". Как бы, наверное, еще правильнее было бы спросить: "объясните разницу спецификаций Function Declaration, Function Expression и Arrow Function Expression", но, как мне кажется, это уже вопрос человеческого понимания и soft skills, нежели самой темы вопроса.
Ну смотрите, я тогда объясню. Сематика лямбд особенная — именно поэтому использовать их абсолютно везде неправильно. Дело в том, что они были созданы именно как функции-помощники, которые не должны полностью представлять все качества функции обычной:
1) Они всегда анонимные.
2) У них нет своего this — и поэтому вы можете смело их использовать/вызывать внутри функций нормальных и не бояться, что контекст этой главной функции подменится контекстом лямбды.
3) У них нет своего arguments — по той же причине, чтобы был прямой и простой доступ к arguments родительской "полноценной" функции.
4) У них более сокращенный синтаксис.
Можно показать это на примере полифила к bind:
// Нам нужно сохранить ссылку на оригинальную функцию, так как если я буду юзать this позже напрямую - то это уже будет this возвращаемой функции - коллбека.
Function.prototype.bind = Function.prototype.bind || function(ctx, ...args) {
const fn = this
return function(...restArgs) {
return fn.apply(ctx, [...args, ...restArgs])
}
}
// Тут this берется от первой "полноценной" функций - можно не переживать, что он подменится на this лямбды.
Function.prototype.bind = Function.prototype.bind || function(ctx, ...args) {
return (...restArgs) => {
return this.apply(ctx, [...args, ...restArgs])
}
}
На самом деле довольно ожидаемый вопрос — так как многие не понимают зачем эти генераторы вообще нужны. На самом деле в большинстве случаев достаточно вместо генератора использовать классический кложур — он так же способен симулировать сохранение состояния в том или ином виде:
function* genNumbersFromOneToTen() {
for (let i = 1; i <= 10; i++) {
yield i
}
}
// По-сути достижимо и просто через
function genNumbersFromOneToTen() {
let i = 1;
const iterator = {
next: function() {
return {
done: i > 10,
value: i++
}
}
}
iterator[Symbol.iterator] = () => iterator
return iterator
}
Но генератор располагает более удобным для этого интерфейсом. Следующие качества, которые делают из генератора совсем не бесполезную фичу:
1) Возможность использовать spread (...) и for-of (по скольку итератор инстанции генератора это он же и есть).
2) Возможность lazy-вычислений — пожалуй это и есть самый главный козырь генераторов — вы можете засунуть туда сложный синхронный алгоритм, который можете спокойно ставить на паузу где вам угодно и "заводить" опять по мере необходимости. Более того, с помощью next() вы можете прокидывать новые данные внутрь уже работающего генератора.
3) Около-асинхронные трюки: по скольку генератор эффективно останавливает даже синхронный код в любой его точке исполнения — вы можете смело делать обертки-генераторы вокруг более сложных и времязатратных синхронных операций — и с помощью того же yield выходить на определенное время из работы — дабы дать остальным таскам, ожидающим в event-queue запуститься. То есть, иными словами, вы относительно безболезненно можете разбить сложную синхронную операцию на более мелкие — и эти мелкие запускать асинхронно — для того, чтобы браузер, например, не фризанул при каком-то сложном алгоритме.
По-скольку ruvds скорее всего все равно до качества статей, то всем новичкам, читающим статью хочу сказать, что здесь есть достаточное количество вредных советов, чтобы к этой статье относиться несерьезно.
Использовать "когда хочу" — это значит не понимать зачем вообще лямбды были придуманы. Отличий от обычной функции более, чем достаточно. И да — существуют вполне ясные и понятные причины почему в том или ином случае нужно использовать именно то или другое.
Больше 10 лет в вебе, даже и не понял что за аббревиатура такая. Лучше писать нормальное название, тогда все сразу понятно.
Это общепринятное сокращение, которое используется уже много-много лет. Либо вы не особо в JS, либо вы не читаете материал, третьего представить не могу.
За такие вопросы я готов убивать.
Воу-воу, попридержите коней. Вполне нормальная постановка вопроса.
Ну, пожалуй, определенную поверхностную картину такие бенчмарки, конечно, могут дать. Но надо держать в голове всегда, что это достаточно не точные тесты.
Все гораздо проще, чем вы думаете. Не надо юзать бенчмарки на jsperf, надо смотреть проблемные места конкретного приложения. В конкретном месте с конкретными условиями — и сразу все становится понятно, где и что надо оптимизировать. Профайлер в devtools показывает все очень наглядно.
Насчет benchmark.js, я, если честно, не помню, но там, на сколько я помню, суть не только в тестировщике, а скорее в самих тестах.
Прислушиваться к определенным техникам есть смысл, но не очень большой, если честно. Так как от релиза к релизу (v8) все это оптимизируется и выполняется по разному.
Автор, у вас из поста в пост какой-то негатив и полное отчаяние. Может быть вам просто не стоит программировать? В этой профессии есть столько всего интересного и крутого, а у вас — в одном посте про выгорание на неинтересном аджайле, в другом — про то как кто-то там умнее.
Как-то это все навевает скорее художественный роман с личными переживаниями и муками. Не понимаю зачем эти статьи.
И вам спасибо за продукт. Я хоть и вряд-ли его буду использовать (впрочем как и выше указанный yo) — но, как мне кажется, создание велосипедов должно поощряться. Тем более, если вы говорите, что даже есть определенные отличия в подходах.
Я буду оценивать то, что я вижу. А вижу я то, что мне суют в нос какое-то решение. Мало того, что они сомнительное технически, так это еще и писал какой-то чувак панк, который даже продавая свою штуку не может слюну свою не выплескивать. Так что не надо тут говорить кому и что нужно оценивать. Хотите оценивать однобоко — я вам не мешаю, я выразил субъективную точку зрения.
Ну, если вы про скобки, обрамляющие Function Expression, то да, они не обязательны. Но я бы не сказал, что это уж сильно большой недочет, возможно чисто косметический. А вот с delete тут не все здорово, так как delete не удаляет переменные, а удаляет ключи в объекте.
А что тут не так со скобками? Скорее здесь оператор delete неправильно используется.
Ну, мне кажется, вы слишком прискребаетесь к формулировке вопросов в подобном "собеседовании". Как бы, наверное, еще правильнее было бы спросить: "объясните разницу спецификаций Function Declaration, Function Expression и Arrow Function Expression", но, как мне кажется, это уже вопрос человеческого понимания и soft skills, нежели самой темы вопроса.
Ну смотрите, я тогда объясню. Сематика лямбд особенная — именно поэтому использовать их абсолютно везде неправильно. Дело в том, что они были созданы именно как функции-помощники, которые не должны полностью представлять все качества функции обычной:
1) Они всегда анонимные.
2) У них нет своего this — и поэтому вы можете смело их использовать/вызывать внутри функций нормальных и не бояться, что контекст этой главной функции подменится контекстом лямбды.
3) У них нет своего arguments — по той же причине, чтобы был прямой и простой доступ к arguments родительской "полноценной" функции.
4) У них более сокращенный синтаксис.
Можно показать это на примере полифила к bind:
На самом деле довольно ожидаемый вопрос — так как многие не понимают зачем эти генераторы вообще нужны. На самом деле в большинстве случаев достаточно вместо генератора использовать классический кложур — он так же способен симулировать сохранение состояния в том или ином виде:
Но генератор располагает более удобным для этого интерфейсом. Следующие качества, которые делают из генератора совсем не бесполезную фичу:
1) Возможность использовать spread (...) и for-of (по скольку итератор инстанции генератора это он же и есть).
2) Возможность lazy-вычислений — пожалуй это и есть самый главный козырь генераторов — вы можете засунуть туда сложный синхронный алгоритм, который можете спокойно ставить на паузу где вам угодно и "заводить" опять по мере необходимости. Более того, с помощью next() вы можете прокидывать новые данные внутрь уже работающего генератора.
3) Около-асинхронные трюки: по скольку генератор эффективно останавливает даже синхронный код в любой его точке исполнения — вы можете смело делать обертки-генераторы вокруг более сложных и времязатратных синхронных операций — и с помощью того же yield выходить на определенное время из работы — дабы дать остальным таскам, ожидающим в event-queue запуститься. То есть, иными словами, вы относительно безболезненно можете разбить сложную синхронную операцию на более мелкие — и эти мелкие запускать асинхронно — для того, чтобы браузер, например, не фризанул при каком-то сложном алгоритме.
По-скольку ruvds скорее всего все равно до качества статей, то всем новичкам, читающим статью хочу сказать, что здесь есть достаточное количество вредных советов, чтобы к этой статье относиться несерьезно.
Использовать "когда хочу" — это значит не понимать зачем вообще лямбды были придуманы. Отличий от обычной функции более, чем достаточно. И да — существуют вполне ясные и понятные причины почему в том или ином случае нужно использовать именно то или другое.
Это общепринятное сокращение, которое используется уже много-много лет. Либо вы не особо в JS, либо вы не читаете материал, третьего представить не могу.
Воу-воу, попридержите коней. Вполне нормальная постановка вопроса.
Причем тут Y-комбинатор?
Ну, пожалуй, определенную поверхностную картину такие бенчмарки, конечно, могут дать. Но надо держать в голове всегда, что это достаточно не точные тесты.
Все гораздо проще, чем вы думаете. Не надо юзать бенчмарки на jsperf, надо смотреть проблемные места конкретного приложения. В конкретном месте с конкретными условиями — и сразу все становится понятно, где и что надо оптимизировать. Профайлер в devtools показывает все очень наглядно.
Насчет benchmark.js, я, если честно, не помню, но там, на сколько я помню, суть не только в тестировщике, а скорее в самих тестах.
Прислушиваться к определенным техникам есть смысл, но не очень большой, если честно. Так как от релиза к релизу (v8) все это оптимизируется и выполняется по разному.
Ну, например, https://www.youtube.com/watch?v=HPFARivHJRY
JSPerf уже давно не считает бенчмарки правильно.
Автор, у вас из поста в пост какой-то негатив и полное отчаяние. Может быть вам просто не стоит программировать? В этой профессии есть столько всего интересного и крутого, а у вас — в одном посте про выгорание на неинтересном аджайле, в другом — про то как кто-то там умнее.
Как-то это все навевает скорее художественный роман с личными переживаниями и муками. Не понимаю зачем эти статьи.
Браво, хорошее, я бы даже сказал крутое расследование! Таким и должен быть айтишник.
Я — учитель в универе. У меня таких приколов каждый семестр хоть отбавляй. Но им, более менее, простительно. Вот из последних, который запомнился:
И вам спасибо за продукт. Я хоть и вряд-ли его буду использовать (впрочем как и выше указанный yo) — но, как мне кажется, создание велосипедов должно поощряться. Тем более, если вы говорите, что даже есть определенные отличия в подходах.
Читал по диагонали, это как-то отличается от https://github.com/yeoman/yo?
Я буду оценивать то, что я вижу. А вижу я то, что мне суют в нос какое-то решение. Мало того, что они сомнительное технически, так это еще и писал какой-то чувак панк, который даже продавая свою штуку не может слюну свою не выплескивать. Так что не надо тут говорить кому и что нужно оценивать. Хотите оценивать однобоко — я вам не мешаю, я выразил субъективную точку зрения.
Вы не на приеме, я на приеме. Бизнес так не работает. Может в России и привыкли к такой подаче, но я есть говно не хочу.
Ага, но, тем не менее, если ты представляешь людям свой продукт, который что-то решает лучше — изволь выразить мысль корректно, а не как обиженка.