Как в современном мире обрабатывать ошибки в Javascript?

Уже все норм https://devblogs.microsoft.com/typescript/announcing-typescript-4-6/#cfa-destructured-discriminated-unions

Как в современном мире обрабатывать ошибки в Javascript?

Тут может помочь TS: пока не будет проверен тип err, тип users будет Users | null Например

Не читай это

Спасибо за статью и наглядные шаги!

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

Чтобы научить нашу версию метода React.createElement работать с компонентами, добавим следующую проверку:

Это может произойти синхронно или асинхронно, но уже внутри реакта.

Собственно, благодаря тому, что вызов компонентов выносится из стек фрейма, в котором происходит render, и становятся возможны все основные фичи: от частичных апдейтов, до Suspense и Transitions.

React-three-fiber: повышаем производительность приложений

https://docs.pmnd.rs/react-three-fiber/advanced/scaling-performance#enable-concurrency

Удобный дешевый шедулинг всего приложения включая и webgl и DOM

Пожалуйста, начните использовать pnpm

Ок, согласен. Но тогда уж проще устроить для CI такой же локальный репо с кешом пакетов и монтировать его в каждый агент. Так еще стабильнее, чем ходить куда то по сети :)

Пожалуйста, начните использовать pnpm

А зачем хранить кеш в репозитории?

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

Пожалуйста, начните использовать pnpm

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

Пожалуйста, начните использовать pnpm

Ну а вам шашечки или ехать?

Пожалуйста, начните использовать pnpm

Можно монтировать volume с локальным хранилищем

Пожалуйста, начните использовать pnpm

Yarn PnP делает то же самое + еще ускоряет запуск ноды за счет экономии на чтениях с диска.

Одна задача с собеса

Ну на самом деле же там не 0. Если мерять через Performance API, а не Date.now(), все видно.

Одна задача с собеса

На throttle функции хорошо бы вызывать `cancel()` в cleanup callback.

useEffect(() => {
    fetchRandomNumber().then(setNumber);
}, []);

лучше переписать так

useEffect(() => {
    let mounted = true
    fetchRandomNumber().then(value => {
        if (mounted) {
            setNumber(value)
        }
    });
    return () => mounted = false
}, []);

Пока там просто асинхронный запрос чего-то, самое худшее, что может случиться — warning в консоли. Но вот если там происходит, например, отправление формы и по успеху делается роутинг типа такого

submitForm().then(() => router.push('/success'))

то можно поломать UX.

Old Skull — фронтенд-фреймворк из альтернативной вселенной

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

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

По моему, если задаваться целью ускорения современного фронтенда и уменьшения объема кода, то лучше копать в сторону AOT компиляции, как уже делают Svelte и Angular. В реакте похожий проект отложили до лучших времен. Но у них другая киллер фича в приортете: параллелизация отрисовки с помощью коопертивного планировщика (это если почти на русский перевести :) )

Лучшие инструменты для совместной работы творческих команд в 2021 году

Не хватает Miro

Ошибку Rockstar может совершить каждый (и я тоже)

Каждый раз вызов strlen() для одной и той же константной строки

А компилятор не умеет такое оптимизировать? Или он не знает, что strlen чистая функция?

Провайдер CDN Fastly пояснил причину масштабного сбоя

Fastly пояснил причину масштабного сбоя

из-за не обнаруженной ранее ошибки в программном обеспечении сервиса.

изменения в настройках, которые вызывали проблему

пояснил?

Нарушает ли React DOM-стандарты?

Вспомнил случай на работе (ровно год назад): хочу отдебажить вебвью в старом андроиде, подключаю телефон к ноуту, иду в remote devices в хроме (80), выбираю свое вебвью и… вижу белый экран вместо девтулзов. Быстрое расследование показало, страничка девтулзов сама падает с ошибкой document.registerElement is not a function
Пытливому читателю предлагается угадать, на какой технологии сделаны девтулзы андроидного вебвью и какую технологию выпилили под 0 в свежем хроме.
https://www.chromestatus.com/feature/4642138092470272

Кроссплатформенная мобильная разработка: история вопроса

Видимо, нет
https://www.npmtrends.com/nativescript-vs-react-native-vs-ionic-vs-cordova

Что лучше: дистрибутив Linux в яблочном стиле или нормальный хакинтош?

Смысл сравнивать есть, потому что там, где macOS запустится, она будет работать стабильно, а вот там, где запустится linux, не известно, как он будет работать.

Первое погружение в исходники хуков (задел на будущие статьи)

Но еще из любопытного, можно вставлять и совсем не props, например ref или же вообще какой-нибудь window.location.pathname:

Не делайте так, если не хотите долгого неочевидного дебага!
Чтение чего либо, кроме props, state и context в теле компонента — это сайдэффект и должно происходить в use(Layout)Effect.

Во первых, ваш компонент может не знать об изменении значения произвольной рефки (например, если она спускается пропсом глубже) или компонент может не подписываться на событие popState и соответственно не отреагировать на изменение window.location. Это приведет к stalled эффекту — использованию протухших значений из замыкания.
Во вторых, такой код сломается при серверном рендеринге.
Любое чтение из "окружающего мира" (ref.current это тоже зачастую кусочек окружающего мира) надо делать в эффектах.