В чем существенная разница между кодом:

promise.resolve().then( 
    ( theVal ) => { /* якись код */ }
    , (theVal) => { /* якись код */ }
 );

и

promise.resolve().then( 
    ( theVal ) => { /* якись код */ }
 ).catch(
    ( theVal ) => { /* якись код */ }
);

Тучарышника Вам в ленту

Кот в лаваше.
Єто не туча, єто сосед Мася.

Отгадка.

Разница в том, какой именно результат обслуживает catch.
В предложенном коде:

promise.resolve().then( 
    ( theVal ) => { /* якись код */ }
 ).catch(
    ( theVal ) => { /* якись код */ }
);

callback из catch обслуживает то, что вернет callback из предшествующего then. А это может быть что угодно - как resolved так и rejected promise так и pending promise.


В отличии от кода без catch:

promise.resolve().then( 
    ( theVal ) => { /* якись код */ }
    , (theVal) => { /* якись код */ }
 );

где реакция описанного в нем callback на rejected происходит по результату предшествующего ему кода (в нашем примере это результат работы resolve)


Иными словами, чтобы привести оба кода к состоянию когда они были бы эквивалентными по своей логике, следовало бы, для случая catch написать вот так:

var thePromise = promise.resolve();

thePromise.then( 
    ( theVal ) => { /* якись код */ }
 );

thePromise.catch(
    ( theVal ) => { /* якись код */ }
);

Почему это может быть для Вас важно.
1) Всегда следует помнить, что методы связанные с Promise совершают большую работу по формированию нового Object Promise. Эта работа много больше чем формирование обычного обьекта.

2) Методы принимают в качестве аргументов и возвращают в качестве результата ЛЮБЫЕ значения, от типа которых прямо зависит то, что происходит дальше.

Например
В следующем примере:

Promise.resolve().then( 
  ()=>{}
  , ()=>{}
).catch( 
  ()=>console.log('Rejected') 
);

catch будет вызван только в случае если один из callback-ов описанных в then уровнем выше, вернет Promise.reject. Причем совершенно неважно будет это collback для resolved или rejected.

хочу перезаписать видео про топ5 js мифов.

вот сегодня решил что нужно добавить - чейнинг

претенденты:
this - как контекст
event loop - єто js
null - как ошибка
переменные как коробочки


что я забыл?
что важнее?

UPD:
примитивные типы
var устарел

UPD2:
однопоточный JS

UPD3:
HOISTING, хостинг, всплытие

UPD4:
только promise попадает в очередь promise queue

UPD5:
TDZ

UPD6:
порядок приведения типов

UPD7:
передача параметров в функцию по ссылке и по значению
call stack

UPD8:
функциональные методы медленее for
js-классы синтаксический сахар

относительно дополнительных окружений, которые стали создаваться после появления let и const.


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

При єтом, агенту надежнее повторять архитектуру диктуемую спецификацией, так как єто гарантирует что при появлении чего-то нового в ней(спецификации), єто не вступит в противоречие с "особой" реализацией агента.


В случае создания дополнительных окружений, для обеспечения работы let/const на уровне block statement, авторы спецификации упоролись настолько, что єто перешло все допустимые рамки.

И, например, v8 игнорирует єтот аспект, рабоая так же, как он работал до єтого - функция имеет свое окружение все остальное от лукавого.

При єтом v8 предпринимает СВОИ шаги для обеспечения работы безобразия, названного let и const.

То есть v8 в нарушение спецификации никаких доп-окружений для блок стейтмент и случаев let/const не создает. Ибо нефиг.


Как єто делает v8 можно посмотреть в байткоде. Он делает єто просто, костыльно и гениально. Авторам спеки следует поучиться.

Обязательно посмотрите єтот мультфильм.
Оригинальное название Straume
Для европейского рынка Flow

Єто чудо.

перевод неважен - там нет ни одного слова на человеческом.

туча мотивирует меня работать

Ничего особо интересного. Просто теревеньки на тему JS, пара плоских анекдотов, и чуть чуть рокет саенс.
https://youtu.be/jj53cCZ0wFg

Други мои.

Я просмотрел ваши комментарии выше, и я горд тем что они именно в моем недочате.

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

Спасибо Вам.
Вы стали/были крутыми.

Склоняю перед Вами голову.

Бодрое утро

угадайте, почему стол в тапочках

что мы все за котов да за котов,
давайте за подарки

Про Google, SEO, семантику и FORM эелементы.

Моя информация актуальна в этом вопросе на 2022 год.

Работа с FORM элементами и не FORM элементами имеет принципиальную разницу для Google.

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

При условии, что Вы точно знаете что Google ее распознает.


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


ARAEA атрибуты, на 22 год, имели такой же мифический статус, что и FORM html элементы. С одной стороны логично их распознавать, с другой стороны не понятно что с ними делать когда они входят в коллизию с микроразметкой и семнатическими тегами.


В результате был отработан эффективный набор решений - сначала микроразмекта, потом семантика тегами, потом все прочие забавы.


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

Про Google, SEO и CSS

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

А производительность формирования первой области отображения - один из важнейших для Google показателей при ранжировании проекта.

CSS может сильно просадить производительность при условии:

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

2)Использовании сложных каскадов, в том числе условий in и прочих.

Сложный каскад - это когда вы в УЖЕ в правиле CSS используется больше одного селектора:

.class1 .class2 {
  color: red;
}

p .class2 {
  font-size: 14em;
}

#blockID .highLight {
  background-color: blue;
}

ВСЕ эти селекторы и любые более сложные - пиздец производительности.

Безусловно имеет существенное значение уровень вложенности тегов.


Эффективным решением двух выше-обозначенных проблем, является:
Либо минимизация CSS дерева.
Либо использования что-то наподобие БЭМ. Где де факто исключены каскады.



Еще раз подчеркну - это касается больших обьемов CSS правил.
Ну чтобы было понятно, условно - 1МБ в несжатом виде уже стоит серьезно задуматься.