Отгадка.

Разница в том, какой именно результат обслуживает 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МБ в несжатом виде уже стоит серьезно задуматься.

Держите Вам новогодный мульт про программистов

У Вас все дома? А?
ну и ладно.

https://www.youtube.com/watch?v=9hDjp0C79-c

Мурыч записался на собеседование, которое назначено на середину января.

Под запись.

Google, SEO и индексация

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

Например:
Наш веб проект, Google воспринимает как тот, который рассказывает прекрасную информацию про черешню.
Однако, если пользователь заходит читать про ту самую черешню, он видит массу информации о каком-либо порнографическом сайте.

Google - старатеся дифференцировать подобные проекты.
Клоакинг - это когда мы сркыли от поискового алгоритма нашу истинную цель.



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

Позднее Google полностью изменил парадигму, и даже опубликовал официалдьный гайд, который говорит о том, что для индексации можно отдавать одно, показывать другое И ГЛАВНОЕ чтобы оно по смыслу отвечало друг другу.

Чем и стали пользоваться практически все современные проекты. Которые на индексацию Google отдают разметку не отвечающей той которую видит пользователь. НО отвечающей ей с точки зрения контента.


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



Отдельный разговор про контент, который можно визуализировать и нельзя индексировать

Например при помощи CSS content