Новые фичи JS, о которых стоит знать

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

JS развивается каждый год, но многие продолжают писать код, как привыкли, не используя свежие возможности языка. Я стараюсь бороться с этим и внедрять новшества в свою повседневную работу и недавно пошел посмотреть что там нового подвезли в ECMAScript 2024 (ES15). А там оказалось довольно много интересного.

Например, новые методы массивов. Раньше методы вроде .sort() и .reverse() изменяли исходный массив, что могло привести к неожиданным багам.

const arr = [4,1,6,5]
const sortedArr = arr.sort()
console.log(sortedArr) //[1,4,5,6]
console.log(arr) // [1,4,5,6] оригинал также изменился

В ECMAScript2024 (ES15) были добавлены новые методы, которые позволяют работать с копиями массивов не трогая оригинал без дополнительного кода:

const nums = [1, 2, 3];
const reversedNums = nums.toReversed();
console.log(reversedNums); // [3, 2, 1]
console.log(nums); // [1, 2, 3] оригинал не изменился

Точно так же работают новые методы .toSorted() и .toSpliced(). Они делают код более предсказуемым и чистым.

Также, я с огромным восхищением прочитал про Temporal - новый объект для работы с датами и временем. Например, меня всегда поражало , что в Date месяцы индексируются с 0 (январь – это 0), а вот дни месяца начинаются с 1. Temporal фиксит эти проблемы и теперь можно:
✅ Создавать объекты только с датой или только со временем
✅ Удобно складывать и вычитать даты
✅ Работать с часовыми поясами без боли
В общем делать все, для чего мы раньше тащили в проекты всякие moment и day.js.

К огромному сожалению Temporal пока не поддерживается в браузерах, но когда выйдет – работа с датами в JS станет в разы удобнее.

Если вам интересны такие обновления подписывайтесь на мой Telegram-канал!

🔗 t.me/+qbK9ZPuAocI2MWUy

Там делюсь продакшн-опытом,новостями из мира веб-разработки и разбираю реальные кейсы. Подписывайтесь! 🚀

flushSync в React – костыль или спасение?

Вчера впервые попробовал flushSyncб который подвезли в React еще в 18 версии.
Классное решение для определенных моментов! Выглядит так, будто React выдал нам костыль, но сразу предупредил: пользоваться с осторожностью.

❓ Почему это вообще нужно? (Для тех, кто не совсем в теме)
В React изменения в useState или в useEffect выглядят синхронными, но на самом деле они асинхронны.

Простой пример:

...

const [count, setCount] = useState(0);

console.log(count); // 0

setCount(1); console.log(count); // Всё ещё 0! 😲

...

Кажется, что setCount(1) сразу меняет count, но на самом деле новое значение попадёт в консоль только при следующем ререндере.

То же самое в useEffect:

...

useEffect(() => { console.log("Эффект сработал!"); }, [count]);

setCount(1); console.log("А это после setCount");

...

Лог "А это после setCount" появится в консоли раньше, чем "Эффект сработал!", потому что useEffect выполняется уже после рендера.

Как flushSync меняет поведение?

Обычно React группирует обновления (batching) и откладывает ререндер до конца текущего цикла. flushSync ломает это поведение и заставляет React сразу выполнить ререндер.

function Example() { 
    const [count, setCount] = React.useState(0); 
    const ref = React.useRef(null);
    const handleClick = () => { 
        flushSync(() => setCount(count + 1)); 
        console.log("Высота элемента:", 
            ref.current?.offsetHeight); 
        };

    return (<button onClick={handleClick}>
        Добавить  {count}
    </button>); 
} 

Что тут происходит?
Без flushSync React подождал бы до конца текущего вызова и только потом обновил DOM.
С flushSync обновление происходит немедленно, и console.log видит уже новый DOM.

React нас предупреждает
В документации прямо сказано:

"flushSync – это низкоуровневый API. Используйте его только тогда, когда вам действительно нужно измерить DOM сразу после обновления состояния."

Когда не стоит использовать flushSync?
Если можно обойтись обычными useEffect или useLayoutEffect.
Если batching работает нормально и не мешает.
Если нет необходимости немедленного ререндера (иначе можно уронить производительность).

Итог
flushSync – мощный инструмент, но использовать его нужно осознанно. Он нужен в случаях, когда важно немедленно обновить стейт и тут же прочитать DOM (например, для анимаций).

Если понравился пост присоединяйтесь к моему каналу в Telegram по ссылке https://t.me/+qbK9ZPuAocI2MWUy.
Там я делюсь своим опытом и пишу материалы которые будут полезны как новичкам, так и матерым разработчикам.

Буквально на днях со мной произошла интересная история, которой я хочу поделится с Вами.

Я состою в одном чатике, где собрались энтузиасты Telegram Mini Apps. Там фаундеры, разработчики и просто интересующиеся обсуждают идеи, делятся опытом и помогают друг другу. Мне очень интересна эта тема, и я планирую запустить что-то своё на базе Telegram.

Но ближе к делу. 2 января в чат зашёл человек в поисках разработчика для своего проекта. Он выглядел весьма взволнованным и объяснил, что помимо долгосрочного сотрудничества ему срочно нужен фикс для его мини-приложения. Это небольшое приложение с игровой механикой, у которого Monthly Active Users (MAU) — около 30 тысяч. Впечатляет, согласитесь! Проблема заключалась в том, что текущие разработчики ушли на праздники и не выходили на связь.

Я решил попробовать помочь просто ради интереса. Сидел за компьютером, пытаясь дописать свою дипломную работу, а мозг требовал смены деятельности. Когда мне дали доступ к репозиториям, я увидел следующее:

• Проект довольно крупный: около 10k строк кода на фронтенде и 5k строк на бэкенде.

• Фронтенд написан на React с использованием Jotai для управления состоянием. Интерфейс реализован с помощью Tailwind CSS.

• Бэкенд — Express.js, взаимодействующий с MongoDB.

Весь проект написан на чистом JavaScript, и вот что меня поразило:

• Полное отсутствие типов. Никакого TypeScript, PropTypes или хотя бы JSDoc. После нескольких лет работы с TS мне было трудно принять, что я не могу быстро понять, какие аргументы ожидаются в функциях. Я думал что все крутые проекты используют TS, а JS только для маленьких проектов, обучения и чего-то не совсем серьезного.

• Полное отсутствие безопасности. Захардкоженные ключи для подключения к телеграм боту и базе данных. Сервер обрабатывает запросы с любого origin. Это буквально учебник по тому, как не надо делать.

• Нарушение принципов DRY. Например, в коде вручную прописывались заголовки для fetch-запросов — везде, где только можно.

• Неоптимальный код. Неправильный вызов хуков, отсутствие lazy loading, дублирование логики и так далее. Я могу продолжать список почти бесконечно.

В общем, код был ужасен. Даже мои студенты, которые только начинают изучать программирование, иногда пишут лучше. Но! Несмотря на всё это, продукт работал, пользователи были довольны, и проект приносил прибыль.

Я быстро разобрался с багом, исправил его и в итоге получил предложение помочь улучшить проект. В ближайшие пару недель как раз займусь этим — заработаю сыну на шоколадки и, надеюсь, сделаю код немного лучше. А теперь — к выводам, которые я сделал (а точнее получил подтверждение в очередной раз):

Выводы:

• Работа и подработка всегда найдутся. Если у вас есть знания и навыки, найти проект даже в текущее время— не проблема. Главное — свободное время и скилл. Я получил подтверждение этого тезиса в очередной раз и последние несколько лет я понимаю, что возможность зарабатывания денег ограничивается только наличием свободного времени для этого. Ну и осознав это я пытаюсь найти варианты, которые напрямую не связаны с обменом моего времени на деньги. Во многом моя попытка раскачать телеграмм канал именно об этом.

• JS жив и приносит прибыль. Люди продолжают писать серьёзные проекты на JavaScript. Да, TypeScript стал стандартом в моей работе, но это не мешает другим писать на чистом JS и чувствовать себя отлично.

• Маркетинг побеждает. Код, который я видел, был ужасен. Но приложение успешно благодаря сильному маркетингу. Это очередное подтверждение фразы: “Best products never win. But best sales & marketing always win.” Как программисты, мы должны стремиться к чистому коду и хорошей архитектуре, но успех продукта в конечном счёте определяется вовсе не этим.

А что вы думаете о роли маркетинга? Согласны ли вы, что он может перевесить техническую сторону?

Если вам интересны темы веб-разработки, тимлидства, управления проектами и вы хотите получать больше полезного контента, присоединяйтесь к моему Telegram-каналу.