How to become an author
Search
Write a publication
Pull to refresh

Comments 20

> 2. Имитация именованных параметров при деструктурировании объекта
Это уже перебор.

// Pure
options = Object.assign({}, default_options, options);
// jQuery
options = $.extend(true, {}, default_options, options);
Total votes 4: ↑2 and ↓20
Просто неудачный пример. На практике обычно нужно задать дефолтные значение паре критичных параметров, и не трогать остальные. Причём, очень часто, диапазон ожидаемых значений позволяет использовать операцию ||.
Total votes 2: ↑1 and ↓10

Исходя из поста, знание основ любого языка — признак профессионализма.


1. Очистка или усечение массива

А за такое можно сразу гнать из профессии. Мало того, что это, мягко скажем, необычное применение для length, это, предполагаю, может подгадить в плане оптимизации кода JS движком. Не говоря уж о том, что JS не требует ручного управления памятью.


4. Использование диапазонов значений в операторе switch

А почему нельзя было через if/else?

Total votes 6: ↑3 and ↓30
А почему нельзя было через if/else?


На ум только такой сценарий приходит. Вообще для меня этот пункт единственной новостью был…
switch () {
  case (something < 10):
    ...
  case (something < 20):
    ...
    break;
  ...
}
This comment wasn’t rated yet0

Не новость, а хак. Обычный свитч же.

Total votes 1: ↑1 and ↓0+1
Как же необычное? Вполне себе рутинное использование length, это один из лучших способов очистить массив, не создавая новых объектов. Это, кстати, один из популярных вопросов на собеседованиях.

Про усечение массива — вот тут я согласен, что необычно, не уверен, что спецификация однозначно предписывает усекать массив справа.
Total votes 2: ↑1 and ↓10
не уверен, что спецификация однозначно предписывает усекать массив справа.
А с какой стороны его ещё усекать, чтобы нумерация оставшихся элементов сохранялась?
Array.length:
You can set the length property to truncate an array at any time.
Total votes 2: ↑1 and ↓10
Упралвение длинной массива через установку length прописано в спецификации. Все законно и на мой (испорченый) вкус — красиво: )
This comment wasn’t rated yet0

Заметьте, я и не говорил про спецификацию, я сказал про JS движки (V8 / Spider Monkey / etc.) и их оптимизацию такого поведения, что я не уверен, что подобное использование length не деоптимизирует байт код.


Касаемо спеки, да, данное поведение в ней явно прописано.

This comment wasn’t rated yet0
5. Организация ожидания выполнения нескольких асинхронных функций в конструкции async/await

Promise.all(iterable) в случае исключения в каком-либо одном из переданных обещаний отклонится сразу, при этом не будет остановлено выполнение других обещаний. Это обстоятельство не делает код
await Promise.all([anAsyncCall(), thisIsAlsoAsync(), oneMore()])

аналогичным коду
await anAsyncCall();
await thisIsAlsoAsync();
await oneMore();

т.к. во втором случае, если из какого-то метода (допустим thisIsAlsoAsync) вылетит ошибка, то можно гарантированно утверждать, что другие методы из цепочки не выполняются (anAsyncCall уже выполнился, oneMore — не будет вызван)
Total votes 3: ↑1 and ↓2-1
Это обстоятельство не делает код
await Promise.all([anAsyncCall(), thisIsAlsoAsync(), oneMore()])


аналогичным коду
await anAsyncCall();
await thisIsAlsoAsync();
await oneMore();


А разве, кто-то утверждал, что делает?
Total votes 3: ↑2 and ↓1+1
Да, я не правильно выразил мысль.
Имел так же в виду, что такая конструкция не ожидает выполнения всех трех функций, в случае, если одна из них выбросила ошибку.
Total votes 1: ↑0 and ↓1-1
Однако, второй вариант ждёт пока завершится предыдущий промис, прежде чем вызвать следующий метод, даже если в этом нет необходимости.
Я к тому, что у этих двух вариантов кода — разная область применения.
Total votes 2: ↑1 and ↓10
1. Припоминаю, что у меня был практический случай, заставляющий относиться к такому приёму с недоверием. Не помню уже детали, то ли это был массив объектов, который криво обрезался, то ли что…
3. Я ведь правильно понимаю, что это работает только при инициализации переменной, а значит — не всегда дружит с let?
4. Вот это для меня новость, хоть и не могу с ходу придумать вменяемый случай, где это уместно.
7. Интересно, есть ли хоть один человек, который работал с JSON.stringify и не знает этой возможности?..

В общем, статья, конечно, интересная, и мне, как разработчику, прямо скажем, не слишком ещё пока высокого уровня, даже полезная, но — именно с поправкой на уровень. Так-то конечно, спасибо, и автору, и переводчику.
Total votes 2: ↑0 and ↓2-2
1. У Мутулз так реализована очистка массива. Сомневаюсь, что они бы использовали этот трюк, если бы он имел какое-то неожиданное поведение
3. Почему нет? Какие проблемы вы ожидаете?
4. Да потому что таких случаев и нет. Тот же if всегда будет значительно более читаемым:
function getWaterState(tempInCelsius) {
  let state;
  
  switch (true) {
    case (tempInCelsius <= 0): 
      state = 'Solid';
      break;
    case (tempInCelsius > 0 && tempInCelsius < 100): 
      state = 'Liquid';
      break;
    default: 
      state = 'Gas';
  }
  return state;
}

/////////// vs ///////////

function getWaterState (tempInCelsius) {
  if (tempInCelsius <= 0) {
    return 'Solid';
  }
  if (tempInCelsius < 100) {
    return 'Liquid';
  }
  return 'Gas';
}


7. Ага. Я узнал буквально пару недель назад
Total votes 4: ↑1 and ↓3-2
3. Банально: ситуации, когда присваивание переменной должно происходить в блоке (try, например), а чтение — после него (допустим, что в catch мы всегда выходим из функции, соответственно, после try/catch значение в переменную записано успешно). Примерно так:
function () {
  let variable
  try {
     variable = someFunc()
  } catch(e) {
    throw new Error('someFunc errored: ' + e.message)
  }
  return someLongProcedure(variable)
}
В этом случае, если переместить let variable внутрь блока try, переменная будет недоступна для someLongProcedure.

4. Конкретно в Вашем примере есть одно возражение — общая vs множественная точка выхода. Неоднократно встречал утверждение, что второе — антипаттерн, поскольку усложняет, к примеру, добавление операций перед выходом (скажем, если требуется логировать возвращаемое значение). Хотя с общим посылом, пожалуй, согласен.
Total votes 1: ↑0 and ↓1-1
Благодаря следующему приёму, в котором используется Promise.all, можно организовать ожидание выполнения нескольких асинхронных функций

Ну совершенно не очевидный приём. Кто бы мог подумать, что Promise.all может быть использован для такого?
Total votes 3: ↑2 and ↓1+1

Параметры по умолчанию — это паттерн. Вот это язык, шёл 2018 год

Total votes 1: ↑1 and ↓0+1
Я, конечно, не сторонник ярких высказываний «за такое гнать из профессии», но в корпоративном чатике джунам порекомендовал эту статью как «прочитайте, и запомните, за что я могу вас побить».
По факту, почти все эти «лайфхаки» не требуют костылирования и велосипедирования при подключении одной из популярных библиотек вроде LoDash или (для консерватистов вроде меня) Underscore. Много их. И делают они всё вышеописанное явно, и джуны потом не будут хвататься за голову «я такой тупой, я не понимаю что тут написано!!!».

Я, разумеется, рад, что вы знаете всякие там тонкости работы языка, щёлкаете вопросы с подвохом как семечки и всё такое… Но пусть лучше это останется «академическими» знаниями, которые просто позволяют смотреть на язык, как на родную лужайку, а не как на черный ящик. Применять их я однозначно не рекомендую.
This comment wasn’t rated yet0
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr