Всегда интересно наблюдать когда лозунги из телевизора настолько застревают у людей в мозгу что они заменяют ими нормальную человеческую коммуникацию.

Предложу ещё пару вариантов:
- а ты уже используешь эфектор?
- эффектор-мать зовёт тебя!

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

Ваш дед только что обнаружил что если на youtube зажать левую кнопку мыши то видео будет воспроизводиться на x2 скорости

Есть такая фича на фронте - возобновляемая загрузка (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 куска)

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