Есть такая фича на фронте - возобновляемая загрузка (Resumable Upload).
Это когда вы закидывайте ваш архив мемов на 5 гигов, а он на фронте распиливается и загружается в бэк кусочками по-меньше (chunks).

Все это для того чтобы:
a) Если соединение оборвется, можно было сделать ретрай не с самого начала, а только с незагруженого кусочка
б) Можно было распаралелить (а следовательно - распределить) загрузку (например грузить по 3 кусочка паралельно)
в) Самое главное - если вы забыли что у вас там идет загрузка и закрыли браузер, выключили ноут, на следующий день можно было прийти и возбновить загрузку с того места где мы остановились
Вобщем все чтобы оградить ваших пользователей от данного опыта.
(технически так же позвоялет продолжить загрузку этого же файла с другого устройства , или даже грузить с нескольких одновременно, но это уже out of scope)

Принцип работы (упрощенно):
1. Создаем "сессию" загрузки
2. Пилим файл на кусочки,
3. Грузим все файлы в любом порядке прикрепив номер кусочка и айди сессси
4. Закрываем сессию когда все кусочки загружены (в этот момент склеиваем их на бэке в один файл).
5. Самое главное - у нас должен быть эндпоинт который скажет нам какие кусочки уже загружены для этой сессии (т.е. - что можно скипать при возбновлении загрузки)

Что у нас есть на фронте для реализации:
- Есть мамонт resumable.js, сегодня интересен только в качестве музейного экспоната
- Есть filepond - имеет навароченую интерактивную часть с приятным дизайном, однако техническая реализация довольно кривая, много багов, почти нет тестов, поверхностыне типы (пытался поправить но чет мейнтейнеру не зашло)
-Есть tus.io - самое здравое решение на сегодняшний момент. И дело тут даже не в качестве кодовой базы. Ниже обьясню.

Как вы уже заметели, это фича не чисто фронтовая, она тесно связана с бэкэндом, на стороне которого должна быть реализована пачка эндпоинтов, которые работают определенным образом.
Так что если делать бэк под фронт под конкретную либу - она протекает в ваш бэкэнд и, вероятно даже в БД.
Tus - это не либа, это протокол. Причем под этот протокол уже написаны реализации под разные ЯП и окружения, как для фронта так для бэка. Вобщем есть из чего выбрать.

Впрочем есть вариант не писать бэк вообще, и взять multipart upload от aws S3, что по сути готовая реализация бэкэнда (на собственном протоколе) для resumable uploads

Ну и наконец, у нас есть uppy.io - это все-включено-мега-комбайн который в том числе включает в себя и поддержку tus протокола, и 3S multipart upload и еще с десяток всяких других сервисов типа дропбокса и гуглдрайва,
(не забудьте завести голден ретривера) и вобще умеет делать разную дичь типа - стриминга вашей вэбки в ваш onedrive (what?)

Постоянно гуглю этот тип, так что решил обронить его тут.
Полезная вещь для дебага, позвоялет "развернуть" сложный тип. Ну то-есть выводит конечный тип после всех дженериков юнионов и тп.
Если совсем просто - вместо SomeGeneric<SomeOtherGeneric, AnotherGeneric<API["some"]>> получаем структуру из js примитивов

/**
 * Debugging type that will display a fully resolved type
 * in Intellisense instead of just the type aliases
 *
 * @type {T} The type to expand out
 */
type ExpandRecursively<T> = T extends (...args: infer A) => infer R
  ? (...args: ExpandRecursively<A>) => ExpandRecursively<R>
  : T extends object
  ? T extends infer O
    ? { [K in keyof O]: ExpandRecursively<O[K]> }
    : never
  : T

type Expand<T> =  T extends (...args: infer A) => infer R
  ? (...args: A) => R
  : T extends object
  ? T extends infer O
    ? { [K in keyof O]: O[K] }
    : never
  : T

Бонус контент:
чтобы тс вам в ошибках не обрезал тип через ... надо включить noErrorTruncation в tsconfig

#typenoscript #ts

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

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

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

Сегодня у нас есть уникальная возможность посмотреть на примере как это работает.

alexgriss поделился своими мыслями о том как он приходит к выбору next.js, в своем посте про выбор стэка для нового проекта.
Речь там не о Proof of Concept или MVP, это имено продуктовый стэк.
Обратите внимание - в листе приоритетов нету ничего что должно волновать иженера:
- Подерживаемость
- Производительность
- Вендорлок
- Куда движется это решение и есть ли у него будущее
и так далее.

Вместо этого вы увидите что
- Мне надо побыстрее

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

На канале mefody_dev появился класный пост про то как сделать модалки с анимациями на нативных апишках.
(codepen демка)

В лисе анимашки не работают, но может через год два уже можно будет тащить в прод

По работе сейчас много работаю с Bazel, и подумал что вам будет интересно узнать с какими челеджами я сталкиваюсь и как оно вообще работает.
Для тех кто не в курсе пару слов о том что это:
monorepo.tools говорит нам что это тул для менеджмента мнорореп, что на самом деле не совсем совсем не так.
По факту он не делает ничего типа авторелизов или трэкинга / подьема версий / генерации ченжлогов и все то что обычно делают монореп тулы фронта.

Если в классическом монорепе возможно сделать так чтобы один пакет зависел от более старой версии пакета из этого монорепа, то bazel такой возможности не предоставляет

Он нужен в монорпе для того чтобы билдить все вот это что вы туда накидали написанное на разных ЯП и связать это между собой (т.е. что после чего надо собрать)
Короче, на языке фронтендеров - bazel это типа webpack, но не для сборки js, а для сборки чего угодно чем угодно*. Только в webpack мы все импортируем в js файлы, и пишем loader-ы, а в bazel мы все импортируем в BUILD.bzl** файл и пишем rules

* В теории, на практике есть нюансы о которых я буду расказывать позже
** Написаны они на языке starlark, который является диалектом Python с ужасной поддержкой в vscode

#bazel

Под каждый билд каждой зависимости Bazel создает отдельную дирректорию куда копирует* все необхожимое для конкретно этой стадии билда.

Так, например, в процессе описания билда приложения в Build.bzl надо перечислить все зависимости что ему нужны для работы (в случае js приложения это будут пакеты из node_modules и например другие пакеты в вашем монорепе, которые Bazel так же предварительно соберет аналогичным образом.)

* На самом деле он их не копирует, а создает симлинки. И на практике это постоянно стреляет в ногу. Сначала вы получаете легкое ранение если попытаетесь это все дело поднять на винде, которая как известно, имеет особые отношения с симлинками, а потом вы получите выстрел из дробовика, когда узнаете что чтобы нода не могла "сбежать" из своей папки "контейнера" bazel патчит ей весь fs пакет чтобы она не могла ходить по симлинкам в принципе (npm link - пока), и наконец ноги отрывает полностью когда оказывается что bazel так же патчит require от чего esm перестает нормально работать ведь import-ы замонкепатчить не получается

По сути это все очень напоминает недо-докер:
- Свой язык для описания билда в специальном файле - в докере есть
- Билды изолироваными "слоями", каждый из которых кэшируется - в докере есть (и реализовано лучше)
- Которые потом заливаются в репозиторий и могут быть скачаны оттуда без потребности их пересобирать - в докере есть

Как работает bazel с точки зрения пользователя (упрощенно):

а) Описываем рул для сборки приложения:
- от каких пакетов зависит (вернее сказать - от каких рулов)
- где взять сорс файлы
- какой бинарник с какими аргументами запустить
- даем ему имя например - build_dev

б) Описываем рул для запуска приложения и даем ему имя, например run_dev
- указываем что он зависит от build_dev
- каким бинарником
- какой файл из build_dev запустить

Теперь если мы хотим запустить приложение - пишем bazel run //путь/к/пакету:run_dev
Bazel составит граф зависимостей, и начнет его билдить с конца (или нет если они уже готовы. Те самые временные директории для билда, о которых я говорил ранее одновременно являютсья кэшем bazel), в конце запустит ваше приложение

Кроме run есть еще build (понятно - только билдит что-то) и test

Я очень внимательно слежу за тем как развивается продукт под названием AR очки.

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

Делает такие очки много разных компаний (в коментарии будет список), и цена у них в диапазоне 400-700$ (а не 3 куска)

Я такие очень хочу, но пока не покупаю, а все потому что я знаю страшную тайну - в них есть одна пока нерешенная техническая проблема (продолжение в следующем посте)

Отзывы о framework от ситника:
https://x.com/andrey_sitnik/status/1751987531158057129

Саммари:
1. First class linux support
2. Регулярное обновление железяк
3. Кастомки от сторонних производителей
4. Собирается за 5 минут
5. AMD по бенчам показал производительность близкую к m2, и энэргоэффектиновсть как у m1
(от себя добавлю что после его поста фреймворк выкатил опцию с новым intel ultra - производиельность уже намного выше чем у m2, при той же энэргоэфективности)
6. Фреймворк холодный и не шумит
7. На момент написания поста на винде работал 12 часов на линухе 9, фиксы энэргосбережения уже вмержены
8. На фреймворке легко быть на cutting edge, потому что он популярен у "различных хакеров", в качестве демо показывает что он уже на wi-fi 7
9. Во время презы его выручило что hdmi разьем можно перекинуть на другую сторону
10. Был косметический изьян по корпусу - выслали детальку на замену
11. 3:2 гораздо удобнее для кодинга чем 19:10
12. Очень хватил кастомную клавиатуру
14. Через пол года использования уже заказал новый экран 120гц 4к (обновления частей на практике - работает)

Я вот все думал что лучше использовать по дефолту interface или type.

Сегодня я определился что по дефолту надо юзать type, потому что interface работает очень странно, не интуитивно, и приведет к ошибкам в вашем коде (см скрин)

Песочница

Интересно что Matt Pocock (кто не в курсе кто это - погуглите) пришел к аналогичному выводу в своем посте

Как проверить доступен ли файл для чтения / записи в nodejs

fs.stat ноды возращает обьект в котором есть поле mode c числом.
Накладывая на него битовые маски можно извлечь необходимю информацию.

Проверяем что файл доступен для чтения (хоть кому-нибудь):

if (mode & (fs.constants.S_IRUSR | fs.constants.S_IRGRP | fs.constants.S_IROTH)) {
  console.log('file has read permissions');
}

аналогично для записи:

if (mode & (fs.constants.S_IWUSR | fs.constants.S_IWGRP | fs.constants.S_IWOTH)) {
  console.log('file has write permissions');
}

Значения констант:

S_ISUID  04000  set-user-ID bit (see execve(2))
S_ISGID  02000  set-group-ID bit (see below)
S_ISVTX  01000  sticky bit (see below)
S_IRWXU  00700  owner has read, write, and execute permission
S_IRUSR  00400  owner has read permission
S_IWUSR  00200  owner has write permission
S_IXUSR  00100  owner has execute permission
S_IRWXG  00070  group has read, write, and execute permission
S_IRGRP  00040  group has read permission
S_IWGRP  00020  group has write permission
S_IXGRP  00010  group has execute permission
S_IRWXO  00007  others (not in group) have read, write, and execute permission
S_IROTH  00004  others have read permission
S_IWOTH  00002  others have write permission
S_IXOTH  00001  others have execute permission

Обновлено:
Мне тут подсказали что есть менее гиковский вариант: fs.access

Google Translate ломает сайты на реакте. После того как я переехал жить в польшу и стал им часто пользоваться я постоянно с этим сталкиваюсь.

Недавно и в лису завезли встроенный переводчик, и там точно такая же проблема (ничему не научились!)

Об этом баге известно очень давно но, в браузерах считают что это проблема реакта (должны учитывать поведение браузера), а в реакте - что это баг браузера (не должны менять вёрстку).

И я даже не знаю кто тут прав.

Codesandox с демкой бага, воркэраунда, случаев которые ломают воркэранэунд и тп.

Случайно набрел на крутую статью о работе с node.js приложением с vite, который сам по себе больше расчитан на сборку под браузер, от автора @liuli-util/vite-plugin-node либы.
Затраигиваемые моменты:
- настройка vite
- настройка vitest
- vite-node для запуска.
- magic-string для совместимости esm - commonjs (require, __filename, __dirname, self)
- rollup-plugin-node-externals для исключения из билда пакетов самой ноды