Будни разработчика: блог лид JS

#такое дня Как выбесить коллег одной строкой? А сейчас я покажу вам... Автор #бородач #js

#новость дня В HTTP появился (точнее, вот-вот появится, только RFC приняли) новый метод QUERY. Примерно такой: QUERY /search Content-Type: application/json { "q": "foo", "limit": 10, "sort": "-published" } И самое интересное тут даже не то, что теперь можно отправлять сложный поисковый запрос в теле HTTP-запроса. Самый интересный вопрос: а разве мы не могли делать это через GET? Могли. Иногда даже делали. GET /search Content-Type: application/json { "q": "foo", "limit": 10, "sort": "-published" } На уровне HTTP-сообщения тело у GET возможно. Протокол не развалится только потому, что после заголовков пришёл body. Проблема в другом: у тела GET нет нормальной общей семантики. Стандарт не говорит: «тело GET — это параметры запроса». Сервер и клиент могут между собой так договориться, но для остальной инфраструктуры это будет частная магия. Прокси, CDN, кэши, балансировщики, библиотеки и браузерные API не обязаны понимать такой договор. Поэтому GET с body — это поведение из серии “может работать в нашей связке”. Где-то пройдёт, где-то тело проигнорируют, где-то запрос завернут, а где-то его вообще нельзя будет отправить. Например, браузерный fetch не разрешает body у GET и HEAD. QUERY как раз стандартизирует этот сценарий. QUERY /search Content-Type: application/json { "q": "foo", "limit": 10, "sort": "-published" } Смысл метода: это запрос на чтение, но параметры запроса лежат в теле. То есть больше не нужно притворяться, что сложный фильтр — это короткая строка query-параметров, и не нужно использовать POST там, где состояние на сервере не меняется. От POST отличие тоже важное. POST для HTTP-инфраструктуры выглядит как метод с возможными побочными эффектами. QUERY, наоборот, описан как safe и idempotent: его можно повторить, не ожидая, что повтор сам по себе что-то создаст или изменит. Получается, QUERY — это не «GET с body», а нормальный стандартный способ сказать: тело запроса важно, оно описывает выборку, и сам запрос при этом остаётся запросом на чтение. #http

Как правильно работать с резервным копированием в облаке? 25 июня приглашаем на бесплатный вебинар от MWS Cloud Platform всех, кто работает с облаками. Развеем мифы, разберём лучшие современные подходы и инструменты. Обсудим интеграцию в процессы, консистентность, точечное восстановление и безопасность. Поговорим о плюсах нативных облачных инструментов. Проведём демо в MWS Cloud Platform и ответим на ваши вопросы. Зарегистрируйтесь, чтобы не пропустить! ⏰ 25 июня в 14:00 (мск) Зарегистрироваться

#статья дня Команда Chrome предложила довольно необычное API для частичного обновления HTML. В разметке можно оставить специальный маркер:

Проект от подписчика! Напоминаю, что я выкачу любую статью или проект от вас, не стесняйтесь писать. Презентация? Выступили на митапе? Хотите поделиться интересной статьёй — добро пожаловать! Всем привет! Меня зовут Роман, я фуллстек-разработчик, 5+ лет в вебе — фриланс и работа в команде, в основном фронтенд. Давно читаю «Будни разработчика», так что вдвойне приятно оказаться здесь уже со своим материалом. Хочу рассказать про инструмент, который сделал под собственную боль и которым теперь пользуюсь сам каждый день. Когда верстаешь адаптив, постоянно скачешь между десктопом и мобильной версией: то DevTools в режиме устройства, то ресайз окна, то открыть на телефоне. Десктоп и мобайл при этом никогда не видны вместе — один прячется, когда смотришь на другой. А показывать заказчику «узкое окно браузера» по видеосвязи — так себе демонстрация. Готовые симуляторы есть (Mobile First, U-eyes и другие — со своей задачей справляются). Но почти все открывают превью в отдельном окне или своей области. Мне же нужно было другое: рамка телефона прямо поверх десктопной страницы, на той же вкладке, одновременно с ней. Не нашёл такого — сделал сам. 🟣 Как устроено (коротко по технике) Страница внутри себя. Очевидный путь — iframe с тем же URL, сужённый до ширины телефона. Но большинство сайтов отдают X-Frame-Options и CSP: frame-ancestors, и iframe просто не грузится. Через declarativeNetRequest (MV3) динамически срезаю X-Frame-Options, вырезаю только директиву frame-ancestors из CSP (остальной CSP не трогаю) и подменяю User-Agent на мобильный. Правило живёт только пока открыто превью, привязано к конкретной вкладке, ничего не блокируется и не отправляется — меняются лишь заголовки ответа. Изоляция стилей. Весь UI оверлея (рамка, панель, кнопки) — в Shadow DOM, чтобы CSS сайта и расширения не ломали друг друга. Синхронизация. Скролл, клики и ввод проксируются между десктопом и превью — заполняешь форму на десктопе, видишь, как она заполняется в телефоне. Самое муторное — маппинг элементов и защита от бесконечных циклов событий. 🟣 Скриншоты снимаются и обрезаются локально, сохраняются файлом — ничего никуда не грузится. 🟣 Запись экрана. Честно про текущее состояние: в опубликованной версии работает штатным путём — через диалог захвата экрана браузера, видео кодируется локально (WebM и MP4, MP4 пока тестово). Параллельно допиливаю бесшовный вариант без промпта на расшаривание (chrome.tabCapture + getUserMedia в offscreen, перекодирование через WebCodecs + mp4/webm-muxer) — но это пока в разработке. 🟣 Приватность как ограничение архитектуры. Нет бэкенда, аналитики и удалённого кода. Настройки — в chrome.storage.local, не покидают устройство. Разрешения в манифесте — ровно под задачу. Итог: Mobile View — десктоп и мобайл одновременно на вкладке, синхронизация, скриншоты, запись. Бесплатно, лежит в Chrome Web Store. Буду рад любому фидбэку. И если найдёте баги на своей ОС/версии браузера — напишите подробно, по возможности со скрином или записью: веду проект в одиночку, так баги фиксятся куда быстрее. Chrome Web Store: Ссылка скрыта Сайт: Ссылка скрыта Статья на Хабре: Ссылка скрыта

#фишка дня Таблица до сих пор превосходит все попытки её имитировать по очень простой причине: если скопировать её из браузера, она спокойно вставится в Excel или Google Sheets как нормальный диапазон. Но вот обратное направление не работает. Скопировал диапазон из Sheets — а в браузере всё рассыпалось в текст, будто ничего и не было. Иногда это мешает: есть форма с табличкой на сайте, есть данные в Google Sheets, и единственное желание — просто вставить их туда, не перепечатывая по ячейке. Чтобы привычный Ctrl+V вёл себя так же естественно, как в Excel. Для таких случаев можно сделать маленькую, но удобную вещь — ловить событие вставки и парсить табличные данные из буфера, распределяя их по нужным полям: document.addEventListener("paste", function (e) { const text = e.clipboardData.getData("text"); const rows = text.trim().split(/\r?\n/).map(r => r.split("\t")); const inputs = [...document.querySelectorAll("input")]; let index = 0; for (const row of rows) { for (const cell of row) { if (inputs[index]) { inputs[index].value = cell; index++; } } } e.preventDefault(); }); Так можно взять диапазон в Google Sheets, нажать Ctrl+V в браузере — и данные разложатся по ячейкам формы, словно это штатная функция. Я пример забыл, а вы и молчите: Ссылка скрыта #js #table #бородач

#статья дня Вы когда-нибудь пытались анимировать смену цвета и сталкивались с тем, что в какой-то момент всё превращается в уныло-серое? Джош Комо как раз разбирает эту проблему. Дело в том, что даже если мы задаём разные цвета через разные цветовые модели, браузер всё равно интерполирует их в RGB-пространстве. А оно ограниченное, и на кривой перехода иногда выпадает серый — как с градиентами (Ссылка скрыта только теперь в анимации. Казалось бы, решение простое: крутим hue в HSL, и серого не будет. Но на практике CSS-анимации всё равно сводятся к RGB, и мы снова получаем неожиданный результат. И более того, анимация от 0 до 360 (полный оборот) вообще не будет анимирована. Оптимизация! Есть два способа это обойти: 1. Использовать filter: hue-rotate(), чтобы прокручивать оттенки напрямую. 2. Хранить угол оттенка в CSS-переменной и анимировать именно её, а не цвет в целом. В итоге получается ровная и предсказуемая смена цвета без серых провалов. Статья: Ссылка скрыта #css #color #animation #бородач

#заметка дня Итак, на работе выдали новые ноутбуки тем, чьи машины в лизинге уже три года и более. Вот только есть нюанс. Мой побитый M2 Pro нём на борту 32 Гб оперативной памяти, а новенький M5 Pro — только 24. Как-то нехорошо. У компании, конечно, свои интересы в ограничении максимальной конфигурации, но получили что получили. Людям, работающим с тяжёлыми задачами выдали модели на 48 Гб, то есть, возможность что-то доказать имеется. Но я сюда не ныть пришёл, хотя очень хочется. Любые ограничения это повод пересмотреть работу. И одним из таких пересмотров, конечно же, стала сборка Webpack, которая в пике сжирает 11 гигабайт. Планирую заменить на Rspack, хоть там есть и свои нюансы. Самый главный нюанс — продать это стафф-инженеру. Но поговорить я даже не об этом хотел. У коллеги новый такой же ноутбук резко начал выть кулерами, и причина была не очень ясна. Потребление памяти в пике всё ещё не упирается в лимит, свопится не очень сильно. А воет. А воет, потому что процесс rg — знаменитый инструмент поиска ripgrep — забивал 8 ядер процессора под завязку и останавливаться не собирался. Попросил коллегу показать мне её расширения для Cursor (VS Code). И там, конечно, было очень красиво. 34 расширения с её учебных дней, от разных иконок и сниппетов до подсветки классов. Запустили Extensions Bisect — я писал об этой встроенной в VS Code утилите не так давно, она позволяет найти расширение, которое вызывает глюки редактора или прочие странные эффекты — вот вроде пожирания ресурсов ripgrep-ом. И такое расширение нашлось! Им оказалось популярное IntelliSense for CSS class names in HTML. Что заставило его сожрать все ресурсы и почему это не проявлялось на предыдущей машине — вопрос остаётся открытым. Да и не нужно оно в большинстве случаев. В общем, я рад тишине в офисе, наконец. #rg #vscode

#такое дня GDPR помните? В РФ его аналог 152-ФЗ, правда, реализация чуть другая. Ну, короче, это та штука, которая заставляет бедных-несчастных бизнесменов просить у вас разрешение на сбор ваших данных путём демонстрации убогих куки-банеров. Мы сейчас опустим тот факт, что это даже не всегда нужно, что простые куки авторизации и даже анонимной аналитики и мониторинга не всегда означают слежение и, стало быть, баннеры не нужны. Но мало кто хочет разбираться в нюансах, а штрафы большие. А вот следить за вами — хотят. Вот такой вот метод (на иллюстрации) отложенного принятия решения по сбору преддложила некая девушка, пост которой попался мне в ленте линкедина. Классический JS-шаблон: указываем тип скрипта как text/template или text/plain и он не выполняется браузером, но текстовое содержимое ноды доступно и легко можно запустить в нужный момент. Красиво? Не то слово, вот только... Вот только Google Tag Manager это буквально оркестратор! С его помощью и можно было бы показать баннер, принять решение по включению аналитики и так далее и тому подобное. И вся эта обвязка вокруг шаблона с кастомным кодом была бы не нужна. Но некоторые люди почему-то не любят искать простые решения. Штош. #gdpr #cookie #gtm