maxcode.dev — мой сайт для изучения JavaScript
Это похоже на литкод/кодварс, но задачи понятнее и полезнее

С чем я могу помочь индвидуально:

✓ Занятия по фронтенду (JavaScript, React)
✓ Занятия по алгоритмам (LeetCode)
✓ Моковые собесесдования (фронтенд или алгоритмы)

🚂 Итераторы в JavaScript

У использования цепочек из методов массива есть одно важное преимущество. Этот код декларативный: мы не создаем переменные и не пишем циклы, а просто описываем последовательность действий: отфильтровали, преобразовали, сложили.

[4, 8, 15, 16, 23, 42]
  .filter(x => x % 2 === 0)
  .map(x => x ** 2)
  .reduce((a, b) => a + b, 0);

Но у декларативности есть цена. Чтобы посчитать сумму квадратов положительных чисел, мы создаем два дополнительных массива и делаем три прохода.

В 2024 году появилась альтернатива, которая не требует дополнительной памяти, работает в два раза быстрее, но при этом сохраняет декларативность. Начиная с Chrome 122 (март) и Node.js 22 (апрель) итераторы обзавелись методами как у массивов.

Итераторы были доступны еще с 2015 года. Почти 10 лет назад можно было вызвать методы keys, values и entries у массива (не путать со статическими методами класса Object) и получить экземляр класса Iterator. Но дальше мы ничего с ними сделать не могли. Теперь можем:

[4, 8, 15, 16, 23, 42]
  .values() // ← создаем итератор
  .filter(x => x % 2 === 0)
  .map(x => x ** 2)
  .reduce((a, b) => a + b, 0);

Этот код не создает новые массивы и делает один проход.

Подробнее об итераторах я рассказываю в видео. Мы посмотрим, сколько памяти занимают лишние массивы, чем отличаются Iterator и iterable, какие методы есть у итераторов и как они работают внутри.

✓ Видео на YouTube
✓ Задачи на итераторы на maxcode.dev

Стек вызовов

На собеседованиях часто дают задачи на рекурсию, а потом просят перерешать без рекурсии. Зачем? 🤦🏻‍♂️

Дело в том, что рекурсивное решение потенциально приводит к переполнению call stack (стека вызовов). Проблема в том, что часто собеседующий сам не понимает, в каком случае этот самый колстек переполняется. Например, некоторые думают, что глубина стека измеряется максимальным количеством рекурсивных вызовов.

Давайте позапускаем код и ответим на следующие вопросы:

✓ В чем измеряется размер кол стека и можно ли его измнить?
✓ Что хранится на стеке?
✓ Сколько раз можно вызвать функцию рекурсивно?
✓ Как переполнить стек без рекурсии и даже без вызова функций вообще?

https://www.youtube.com/watch?v=D6MGnUBSdSU

PS. Видео про то, как решать задачи на рекурсию с помощью рекурсии и без рекурсии, будет отдельно. Напоминаю, что задачи на рекурсию у нас вот здесь: https://maxcode.dev/courses/recursion

🚀 Особенности Promise.race

Продолжаю записывать видео на ютуб. И новое видео про Promise.race:
https://www.youtube.com/watch?v=wJW4UEMBgGY

Вообще из всех четырех методов, позволяющих работать с промисами конкурентно, Promise.race самый простой. Во всех остальных мы собираем какой-то массив, дожидаемся окончания работы всех промисов, а еще нужно не забыть учесть порядок. Тут алгоритм гораздо проще.

Поэтому в новом видео я концентрируюсь на общих для всех методов принципах:

✓ Что принимают race/all/allSettled/any и почему это опять iterable
✓ Как обрабатывается ситуация, когда внутри лежит не промис
✓ Что будет если передать пустой итерабл или вообще не итерабл

Статические методы

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

Но Promise.race отличный пример, где активно используется факт того, что функция race лежит в классе Promise. Разбираю это в конце видео, если что, есть таймкоды 😉

На сайте обновил шпаргалку по промисам.

Многие теряются в нестандартных ситуациях, например, когда мы методом catch подписываемся на fulfilled промис. Или не понимают, как определяется статус промиса, который возвращается из then.

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

Зачем нужен React ⚛️

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

Напомню, что React вышел в паблик в 2013 году, а до этого использовался внутри Фейсбука, где его и разработали. Это, кстати, к вопросу как часто во фронтенде что-то меняется и нужно учить что-то новое. Не часто, 10 лет не меняется.

И я вспомнил про Александра Соловьева, у которого был доклад в 2014 году. Это вам ретроспективно сейчас расскажут, почему реакт стал успешным. Но лучше послушать это от человека из 2014 года. Примеры кода интересные там. Как вы знаете, до функциональных компонентов с хуками были классы. Но классы в джаваскрипте появились в ES2015. Что же было до них? :)

В общем, я пересмотрел доклад (само выступление 18 минут или 9 минут на 2x) и Александр рассказывает всё очень правильно. Вот ссылка: https://www.youtube.com/watch?v=aFUiULAC6zk

А теперь давайте я кратко перескажу две важные вещи, которые нам дал React.

1️⃣ Реакт позволил объединить HTML и CSS, повышая cohesion. Кохижн — это когда штуки, которые об одном, лежат рядом. Ну, типа, есть папка с компонентом, а рядом с ним CSS-модули, картинки для этого компонента, вспомогательные функции и тесты. А 20 лет назад отдельно был целиком HTML всего сайта и отдельно джаваскрипт, который в этом большом файле искал по селекторам нужные куски.

Сюда же идет удобная работа с событиями. Мы особо не разбираем на занятиях работу с событиями браузера напрямую, потому что рыночек порешал и для работы вам это особо не нужно. Но есть много проблем, которые реакт решает, предоставляя вам простой пропс onClick.

Кстати, кохижн — это один из принципов GRASP (wikipedia). По-моему, GRASP в сто раз важнее SOLID, но об этом в другой раз давайте.

2️⃣ Реакт решил проблему комбинаторного взрыва. Когда у вас много кусков системы, которые влияют друг на друга, то при изменении одного из них, нужно учесть это в других. Если у вас 10 модулей, то взаимодействий между ними 10 × 9 = 90 (каждый с каждым). А в случае реакта мы должны для каждого компонета уазать, как он влияет на стейт и в кажом компоненте указать, как он от стейта зависит. Это 10 + 10 = 20 взаимодействий. В первом случае ментальная сложность программы растет квадратично, во втором — линейно.

Из минусов Александр называет отсутвие Model Layer, то есть слоя с данными, грубо говоря. Это та проблема, которую потом будут решать стейт-менеджеры типа редакса. Но редакс будет представлен Даней Абрамовым только через год.

Кстати, примерно в это время Абрамов выступает на митапах в Питере на русском языке, рассказывая про сам React. Есть запись с испорченным звуком (https://www.youtube.com/watch?v=nwtQMSFikUk). Организаторы митапа ее скрыли, потому поиском не найти.

Наконец, еще можно посмотреть доклад от разработчиков реакта 2013 года, где они его представляют, тоже полезно (https://www.youtube.com/watch?v=GW0rj4sNH2w). Но там не так весело, как у Соловьева.