Using the OpenAI platform to analyse automated test failures

С появлением нейронок появляются все новые и новые интеграции в существующие инструменты. Некоторые идеи лежат прям на поверхности и вот, статья как раз об одной из них. Существует проблема, что ошибки от инструментов не очень информативные. Например, упал пайплайн в CI. Средний разработчик может зайти в упавшую джобу и ничего не понять и тогда ему приходится гуглить. Почему бы это не автоматизировать с помощью gpt нейронки?

Вот автор задался тем же вопросом и написал кастомный reporter для nightwatch - фреймворк для браузерного тестирования. Репортер, при получении ошибки в тесте, идет в специальное API для уточнения, что же с этой ошибкой делать. Сервер, предоставляющий API, представляет собой expressjs, который ходит в openai со специальным шаблоном, в который подставляется текст ошибки.

Итого, репортер видит ошибку -> идет на expressjs сервер за информацией -> expressjs идет в openai -> пользователь вместо непонятной ошибки видит предложения от gpt о том, что случилось и как это исправить

Выглядит интересно. Вдохновляет тоже запилить что-то эдакое.

https://labs.pineview.io/using-openai-platform-to-analyse-automated-test-failures/

#development #javascript #chatgpt #autotests

Moving back to React

Сайт daily.dev переходит с Preact на React. Долгое время команда писала на Next.js + Preact. Не смотря на то, что Preact поддерживает основные фичи React, команда столкнулась с проблемами:
- Медленный Hot Reload
- Медленная работа сборки в dev-режиме (включая фризы вкладки)

Этих проблем нет при использовании Next + React, поэтому было решено переходить на react.

Плюсы от потенциального перехода на React:
- React совместим с текущим Next.js и со всеми будущими фичами
- Меньше возни с конфигами
- Меньше зависимостей
- React более стабилен и в нем больше уверенности. Preact же старается быть как React, но также тащит фичи из других миров

Минусы:
- Размер бандла увеличится
- Нужно поменять много кода

Размер бандла
Увеличение размера бандла оказалось ожидаемым - ровно на разницу между React и Preact. Влияние можно минимизировать, выделив react в отдельный чанк с отдельным кешированием. Также, во время замеров, были обнаружены возможности для оптимизации размера бандла в приложении, решение которых позволит еще сильнее минимизировать влияние перехода на React на пользователей

План миграции
Команда решила сделать миграцию в рамках внутреннего хакатона, который решили проводить во время общего недельного сбора в Польше (команда разработки сайта - распределенная). Перед началом хакатона определили несколько основных зон для изменений:
- Нужно убрать и заменить все что связано с Preact (зависимости и все такое)
- Все автотесты должны быть зелеными (но потребуется поднять версию Jest)

Т.к. Preact поддерживает подмножество функционала React, то переезд на React не должен быть в целом сложным. Но при этом проблемы, естественно, возникнут. Эти проблемы решили поделить на 2 категории: ошибки и предупреждения (errors and warnings). Предупреждения - это все то, что не влияет на работу приложения или на пользователя. Ошибки же - все, что может привести к неправильной работе сайта (в том числе утечки памяти)

Миграция
В первый день сделали изменения в ядре проекта и отсортировали все ошибки и предупреждения. Во второй и третий день исправляли флакующие тесты, ререндеры и утечки памяти. В завершающий день много внимания уделили code review и тестированию приложения. В целом, команда готова была вливать изменения в мастер и выкатываться на прод, но не стали этого делать т.к. пятница и все разлетались по домам. На следующей неделе новую версию сайта выложили в прод и не возникло никаких проблем.

Итоги
После перехода на React исчезли проблемы с DX, которые очень сильно замедляли разработку, а также открылась возможность использовать свежую версии библиотек и Next.js

Сама история достаточно интересна в плане организации: организовали недельный хакатон, при этом не забывали замерять изменения размера приложения и следить за тестовой инфраструктурой. Этот опыт можно перенять для других миграций или больших изменений в кодовой базе.

https://daily.dev/blog/moving-back-to-react

#development #javascript #react #migration

Microservices aren't the problem. Incompetent people are

Какое-то время назад все только и говорили о микросервисах. Затем, стали говорить, что микросервисы не нужны - слишком сложно и много накладных расходов. Дмитрий Нон возвращается к этой теме, но рассматривает её под другим углом - проблема не в подходе микросервисах, а в недостаточной компетенции разработчиков.

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

Статья начинается с того, что нет проблемы в конкретной технологии, будь то микросервисы или Kafka или еще что-то. С технологиями все хорошо, это с инженерами, которые применяют инструменты не к месту, все плохо. Вся наша индустрия построена на принципе hype-driven development. Мы постоянно меняем подходы, технологии и инструменты, но не отказываемся от старых привычек. Это как всю жизнь работать с молотком, потом получить отвертку, но все равно работать ей как молотком

Часто слышно, что разработчику нужно постоянно что-то изучать, большинство людей этим не занимается и просто пишет код по ТЗ от звонка до звонка на текущем рабочем месте. Проблема не только в написании кода, но это в целом проблема культуры компаний, которая влияет и на принятые решения, на найм и так далее.

Инженеры считают себя умными, но, как правило, большинство из них такими не являются. Автор называет это smart-ass complex. Если переводить грубо, то "комплекс умной задницы", хотя мне в последнее время для обозначения этой проблемы нравится классика - "Горе от ума".

smart-ass инженер:
- Переусложняет решения. Там где можно было сделать что-то в лоб, умный инженер сделает микросервисную масштабируемую систему с наиболее подходящим тех. стеком
- Использует разные имена для одной концепции, говоря, что в разных контекстах названия должны быть разные (например фасад, адаптер, мост и тд для обозначения врапера)
- Борется с несуществующими проблемами. Наиболее яркий пример - взять практики гугла, имея на сервис менее 1 RPS, зато получив запас прочности при масштабировании на десятилетия вперед
- И так далее

Не быть умным нормально, главное осознавать этом и не считать, что принятые решения - самые лучшие. Вместо этого полезнее считать себя неумным (но не тупым) и стараться делать решения простыми.

Как быть компетентным? Автор предлагает свое видение принципов, которым следуют компетентные инженеры:
- Применять SOLID на разных уровнях: код, сервисы, команды, организация (в оригинале расписано очень подробно, но я переводить не стал. Если вам интересно - окунитесь в оригинал)
- В чем отличие монолита от микросервиса? В коде приложения разнцы особой нет т.к. вся суть в том, что единственная разница - это механика коммуникации. В монолите мы просто вызываем нужную функцию, в микросервисе же используем сетевое взаимодействие для той же цели. Следует применять сервисную архитектуры. Т.е. писать такие сервисы, которые не микро, но и не монолит. Каждый сервис принадлежит конкретной команде, которая за него ответственна
- Думайте о Developer Experience
- KISS
- Откиньте подход "все или ничего". Не следует ультимативно следовать каким-то практикам т.к. в большинстве случаев это непрактично. Например, не случится ничего страшного, если вы добавите функционал в существующий микросервис сбоку, вместо написания нового. Написанный сбоку функционал всегда можно вынести позже.
- Ownership - у каждого сервиса есть свой owner и только он туда может вносить правки. Это позволяет быть уверенным что владелец знает все о том, как работает сервис и что он поддерживает его качество на высшем уровне.

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

https://nondv.wtf/blog/posts/microservices-arent-the-problem-incompetent-people-are.html

#development #microservices #architecture #softwareEngineering

Advent of TypeScript

Набор заданий type challenge для TypeScript, который будет открывать по одной задаче в день с 1-ого по 25-ого декабря и может послужить отличным поводом или дополнительно попрактиковаться, или изучить работу типов в языке.

Дайджест за 2023-11-27 - 2023-12-01

Announcing TypeScript 5.3
Команда Typescript анонсировала релиз 5.3. Основные изменения, за которые зацепился мой глаз - оптимизация перформанса и размера и улучшение уточнения типов

Начну с уточнения типов: завезли корректное уточнение типов для паттерна switch (true)

⭐Promises Training
Очень интересный репозиторий, который содержит в себе задачки по работе с Promise'ами. Они разделены на уровни сложности. К каждой задачке есть четкое описание, что нужно сделать и на все задачки написаны тесты. Если все тесты проходят - вы решили задачку правильно.

Это что-то типа сайтов с алгоритмическими задачами (типа литкода), но только механика задача+тесты используется для интерактивного обучения. Выглядит очень интересно.

Using the OpenAI platform to analyse automated test failures
С появлением нейронок появляются все новые и новые интеграции в существующие инструменты. Некоторые идеи лежат прям на поверхности и вот, статья как раз об одной из них. Существует проблема, что ошибки от инструментов не очень информативные. Например, упал пайплайн в CI. Средний разработчик может зайти в упавшую джобу и ничего не понять и тогда ему приходится гуглить. Почему бы это не автоматизировать с помощью gpt нейронки?

Вот автор задался тем же вопросом и написал кастомный reporter для nightwatch - фреймворк для браузерного тестирования. Репортер, при получении ошибки в тесте, идет в специальное API для уточнения, что же с этой ошибкой делать. Сервер, предоставляющий API, представляет собой expressjs, который ходит в openai со специальным шаблоном, в который подставляется текст ошибки.

Moving back to React
Сайт daily.dev переходит с Preact на React. Долгое время команда писала на Next.js + Preact. Не смотря на то, что Preact поддерживает основные фичи React, команда столкнулась с проблемами:
- Медленный Hot Reload
- Медленная работа сборки в dev-режиме (включая фризы вкладки)

Microservices aren't the problem. Incompetent people are
Какое-то время назад все только и говорили о микросервисах. Затем, стали говорить, что микросервисы не нужны - слишком сложно и много накладных расходов. Дмитрий Нон возвращается к этой теме, но рассматривает её под другим углом - проблема не в подходе микросервисах, а в недостаточной компетенции разработчиков.

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

——————————————

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

67 Weird Debugging Tricks Your Browser Doesn't Want You to Know

Список из 67 трюков для дебага кода в браузере. Причем, это не те простые трюки, которые часто описывают в туториалах, здесь описаны прям хорошие приёмы. Описаны применение API-браузеров и продвинутой использование breakpoint'ов с условием по выражению.


Например, вы знали, что в GoogleChrome есть функция, навесив которую на другую функцию, вы будете получать в консоль все её вызовы?

function test() {}
monitor(test);
test('lol', 'kek')
// в консоли будет function test called with arguments: lol, kek

Сталкивались ли вы с таким, что вам нужно понять, кто меняет какое-то css свойство элемента? Т.к. css-стили - каскадные, это может быть сложно сделать. Но ведь можно повесить breakpoint, который срабатывает на JS выражении, которое будет проверять итоговые стили. Например, мы хотим остановить исполнение кода, когда backbround-color станет красным:

window.getComputedStyle(document.body).backgroundColor === "rgb(255,0,0)"

Или другой кейс. У вас есть какое-то поведение на элементе при наведении на него и оно реализовано через JS, а не css :hover. Как быть? Автор предлагает следующий хак: вызвать debugger в setTimeout, затем навести мышку на нужный элемент и дождаться вызова debugger. Работа браузера остановиться и можно дебажить элемент сколько угодно

setTimeout(() => { debugger; }, 5000)

В общем, очень крутой список. Рекомендую к ознакомлению

https://alan.norbauer.com/articles/browser-debugging-tricks

#development #googleChrome #debug #recommended #javascript

Node.js CLI Apps Best Practices

Список бест-практисов для CLI приложения на node.js. Разделены на группы:
- Опыт использования
- Публикация
- Встраиваемость (Interoperability)
- Доступность
- Тестирования
- Работа с ошибками
- Разработка
- Аналитика
- Версионирование

https://github.com/lirantal/nodejs-cli-apps-best-practices

#development #nodejs #cli #recommended

Secure Code Review Tips to Defend Against Vulnerable Node.js Code

Короткая статья про обеспечение безопасности в node.js приложениях. Данная статья, я так понял, является первой в цикле и рассказывает о небезопасных паттернах кода (на самом деле паттерн 1, но почему-то разбит на 4 части).

В целом, один из способов уменьшения риска получить проблемы из-за недостаточной безопасности - это качественное проведение Code Review.

Паттерн, рассматриваемый в данной статье в разных вариациях - это склеивание строк для вызова команд без предварительной валидации

const userInput = req.query.input;
const command = `echo ${userInput}`;
exec(command, (error, stdout, stderr) => {
  // Handle the command execution
});

Если мы используем пользовательский ввод для получения итоговой команды, то у пользователя появляется возможность запускать команды на нашем железе. Причем это может быть как пользовательский ввод, так и данные из БД или от другого сервиса. При склеивании команды для командной строки всегда нужно быть максимально параноидальным, проверяя всё, что приходит на вход.

https://www.nodejs-security.com/blog/secure-code-review-tips-to-defend-against-vulnerable-nodejs-code

#development #nodejs #security

Event Loop в деталях

Неплохая статья, объясняющая для новичков, как работает Event Loop в Javascript. Статья делает это не совсем точно (собственно один из комментариев на хабре посвящен именно этому аспекту статьи), но достаточно доступно и понятно для тех, кто не знает как работает Event Loop. В целом, как начальная статья для джунов вполне ок.


https://habr.com/ru/articles/762618/

#development #javascript #eventLoop #tutorial

Leading Successful Product Teams

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

Лично я согласен не со всеми правилами (хотя некоторые из них сложно назвать правилами), но список интересный. Возможно, вы найдете что-то для себя.

- Избегайте встреч и созвонов. Вместо этого используйте асинхронные коммуникации (чаты, рабочие инструменты и тд)
- Предоставьте по-крайней мере 3 дня фокусированный работы в неделю для дизайнеров и разработчиков.
- Доверяйте команде самой принимать решения. Ваша задача, чтобы команда понимала, что делает, устранять препятствия и защищать от внешних воздействий.
- Будьте открытыми. Команда должна создавать продукт, не закрываясь от других команд и людей. Это неизбежно повысит качество создаваемого продукта
- Держите количество процессных активностей (дейли, груминги и тд) в таком количестве, чтобы это уже помогало работать, но еще не мешало
- Не проводите синки по задачам на всю команду ежедневно, достаточно собраться раз в неделю, замотивировать команду и подсветить блокеры
- Используйте как можно меньше инструментов для реализации задачи
- Автоматизируйте все, что возможно автоматизировать. Команда должна проводить ценное время с коллегами, пользователями, а не заниматься рутиной
- Заботьтесь о своих пользователях.
- Большинство актов общения и совместной работы должны быть асинхронными.
- Позвольте участникам команды решать проблемы сообща, если это полезно. Но не забудьте задокументировать все принятые решения.
- Предоставляйте еженедельные отчеты для всех заинтересованных о прогрессе в работе
- Создайте публичный родмап
- Сфокусируйтесь на регулярных итерациях вместо ярких запусков
- Не бойтесь выбрасывать сделанную работу
- Поставленное пользователю лучше, чем идеальное, но не поставленное
- Будьте добрыми

https://arie.ls/2023/leading-successful-product-teams/

#managment #team

Дайджест за 2023-12-04- 2023-12-08

⭐67 Weird Debugging Tricks Your Browser Doesn't Want You to Know
Список из 67 трюков для дебага кода в браузере. Причем, это не те простые трюки, которые часто описывают в туториалах, здесь описаны прям хорошие приёмы. Описаны применение API-браузеров и продвинутой использование breakpoint'ов с условием по выражению.


⭐Node.js CLI Apps Best Practices
Список бест-практисов для CLI приложения на node.js. Разделены на группы:
- Опыт использования
- Публикация

Secure Code Review Tips to Defend Against Vulnerable Node.js Code
Короткая статья про обеспечение безопасности в node.js приложениях. Данная статья, я так понял, является первой в цикле и рассказывает о небезопасных паттернах кода (на самом деле паттерн 1, но почему-то разбит на 4 части).

В целом, один из способов уменьшения риска получить проблемы из-за недостаточной безопасности - это качественное проведение Code Review.

Event Loop в деталях
Неплохая статья, объясняющая для новичков, как работает Event Loop в Javascript. Статья делает это не совсем точно (собственно один из комментариев на хабре посвящен именно этому аспекту статьи), но достаточно доступно и понятно для тех, кто не знает как работает Event Loop. В целом, как начальная статья для джунов вполне ок.



Leading Successful Product Teams
Набор правил успешной команды от лида команд дизайн-систем. Дизайн-системы отличаются от традиционных продуктовых команд, но, тем не менее, имеют много пересечений.

Лично я согласен не со всеми правилами (хотя некоторые из них сложно назвать правилами), но список интересный. Возможно, вы найдете что-то для себя.

——————————————

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

Web Components Eliminate JavaScript Framework Lock-in

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

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

Автор делает TodoList с использованием React, Vue, Svelte и Solid. Все созданные компоненты оборачиваются в кастомные элементы и используют друг друга как кастомные элементы. При этом автор также обращает внимание на гибкость веб-компонентов, организации взаимодействия и хранении стейта.

Если у вас есть подобная задача, ну, например, у вас есть система на каком-нибудь старом angular, а вам надо поставлять туда фичи, а вы - React-разработчиков, то вам может подойти подобный подход с интеграцией через веб-компоненты

https://jakelazaroff.com/words/web-components-eliminate-javascript-framework-lock-in/

#development #javascript #webcomponents

Track Frontend JavaScript exceptions with Playwright fixtures

Достаточно интересная статья про использование API playwright для расширения функционала тестов на примере слежения за неперехваченными глобальными ошибками.

В чем проблема: браузерные автотесты весьма полезны т.к. позволяют быть уверенными, что система работает end-to-end или близка к этому. Но тесты проверяют только конкретный функционал. А бывает так, что конкретный функционал работает, но что-то другое падает и в консоли видна ошибка. При ручном тестировании это заметно, но автотесты это не отлавливают. Но автотесты можно научить проверять глобальные ошибки. Именно этим автор и занимается в статье с помощью Playwright

Механически, добавить проверку на глобальные ошибки достаточно просто - подписываемся на ошибки и если в конце теста случилась хотя бы одна - тест падает

test("Checkly blog lazy loading", async ({ page }) => {
  // set up a new Array to collect thrown errors
  const errors: Array<Error> = []

  // listen to exceptions during the test sessions
  page.on("pageerror", (error) => {
    errors.push(error)
  })
  
  // All your test code…
  // …

  // assert that there haven’t been any errors
  expect(errors).toHaveLength(0)
})

Но писать такое в каждом тесте непродуктивно. У Playwright есть API для расширения метода test - фикстуры. Фикстуры это такие объекты или функции, которые доступны в тесте и они создаются новые для каждого теста.

const myTest = test.extend<{
 testUser: { name: String }
 loggedInPage: Page
}>({
  testUser: {
    name: "Jenny Fish",
  },
  async loggedInPage({ page }, use) {
    await page.goto("/login")
    /* code */
    await use(page)
    // clean up steps after the test
  },
})

// Теперь testUser и loggedInPage доступы в тесте
myTest("Your custom Playwright setup", async ({ testUser, loggedInPage }) => {
  // …
})

Фикстуры устроены так, что у них есть 3 этапа:
- подготовка
- передача в тест - await use(fixture) передает фикстуру в тест и дожидается завершения теста
- действия после завершения теста

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

// extend the test object and assign it to a new `myTest` variable
const myTest = test.extend<{ page: void }>({
  // override and use Playwright’s base `page` fixture 
  page: async ({ page }, use) => {
    const errors: Array<Error> = []

    page.addListener("pageerror", (error) => {
      errors.push(error)
    })

    // pass the `page` object to tests using it
    await use(page)

    expect(errors).toHaveLength(0)
  },
})

Чтобы не использовать во всех тестах myTest, можно создать свои модуль с экспортируемым test и использовать его во всех тестах.

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

https://www.checklyhq.com/blog/track-frontend-javascript-exceptions-with-playwright/

#development #javascript #playwright #testing

console ninja: console log output right next to your code

Интересный тулинг по типу wallaby и quokka, который связывает код в IDE и консоль в приложении. Т.е. например, вы поставили console.log(myVariable) и вывод консоли отобразится у вас прямо в IDE. Кроме этого инструмент умеет связывать ошибки с кодом, создавать лог-поинты (это как брекпоинты, только вместо остановки мы просим вывести значение переменной в лог) и еще всякое.

Есть платная и бесплатная версии. Посмотрите, возможно вам понравится.

https://console-ninja.com

#development #javascript #tool

Keep that cursor still!

Веб-разработчики делятся на 2 типа - познавшие боль от работы с курсором в input'ах и тех, кому это только предстоит.

Данная статья подробно разбирает популярную проблему прыгающего курсора в инпуте - если программно менять значение инпута, то велика вероятность что курсор улетит в конец инпута, даже если редактирование было по-середине. Например, вы делаете инпут, в котором происходит замена некоторых символов (например, имена автоматически пишутся с большой буквы, или же вы делаете транслитерацию). Если в этом инпуте пользователь начнет что-то писать в середине инпута, то есть шанс что курсор, после ввода, улетит в конец инпута.

В статье разбирается, почему оно так работает. Если коротко, то в спеке HTML четко написано, что если значение инпута программно изменяется и новое значение отличается от того, что было до этого - то курсор перемещается в конец.

В целом, это поведение мы можем видеть в двух кейсах:
- Преобразование значения в onChange
- Асинхронный обработчик. Здесь не обойтись без примера: в инпуте было значение авг, пользователь вводит б между а и в. Но у нас так устроена архитектура, что значение в инпут ставится из какого-нибудь redux, а туда новое значение попадает через несколько тиков в эвент-лупе. С точки зрения браузера это означает, что мы сначала поменяли значение абвг на авг, а через пару тиков на абвг. Оба раза курсор улетел в конец

По второму кейсу статья не дает подробных советов т.к. это вопрос архитектуры решения.
По первому же кейсу решение следующее - браузер предоставляет нам позицию курсора на момент обработки события и API для установки курсора. С помощью этих данных мы можем синхронизировать новое значение и положение курсора. Для реализации автор предлагает 2 решения:

Первое: устанавливать положение курсора сразу после рендера с помощью useLayoutEffect

export default function App() {
 const position = useRef({
  beforeStart: 0,
  beforeEnd: 0
 });

 const [val, setVal] = useState("hello");
 const inputRef = useRef<HTMLInputElement>(null);
 useLayoutEffect(() => {
  inputRef.current.setSelectionRange(
   position.current.beforeStart,
   position.current.beforeEnd
  )
 }, [val]);

 const onChange = (e: ChangeEvent<HTMLInputElement>) => {
  const beforeStart = e.target.selectionStart;
  const beforeEnd = e.target.selectionEnd;
  position.current = {
   beforeStart,
   beforeEnd
  };

  setVal(e.currentTarget.value.toUpperCase());
 };
 return (
  <input ref={inputRef} value={val} onChange={onChange} />
 );
}

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

export default function App() {
  const position = useRef({
    beforeStart: 0,
    beforeEnd: 0
  });

  const [val, setVal] = useState("hello");

  const inputRef = useRef<HTMLInputElement>(null);

  const onChange = (e: ChangeEvent<HTMLInputElement>) => {
    const beforeStart = e.target.selectionStart;
    const beforeEnd = e.target.selectionEnd;

    position.current = {
      beforeStart,
      beforeEnd
    };

    flushSync(() => {
      setVal(e.currentTarget.value.toUpperCase());
    });

    inputRef.current.setSelectionRange(beforeStart, beforeEnd);
  };

  return <input ref={inputRef} onChange={onChange} value={val} />
}

В общем, очень крутая статья, в ней крутые sandbox'ы с примерами проблемы и примерами решений, в которой очень подробно разбирается почему происходит эта проблема (включая разбор внутренностей React). Рекомендую к прочтению

https://giacomocerquone.com/keep-input-cursor-still/

#development #javascript #react #input #cursor #recommended

Хороший обзор погружения в solid - борьба со сборщиком и реактивностью. У меня всплывают воспоминания об использовании Vue когда еще весь тулинг необходимо было настраивать руками 🙃

Я уже написал на solid.js аж целых два маленьких приложения.
Поделюсь опытом в сравнении с реактом, раз уж они под реакт мимикрируют.

День первый.
Я полистал документацию, посмотрел ролики, впечатлился качеством материалов.
Нашел необходимый плагин для vite, шаблон конфгиа по ts, запилил hello world, все круто!
Надо было сразу выбросить реакт и взять солид, чего ждал - не понятно. Счас хуяк хуяк и в продакшен супер быстрый апп, с маленьким бандлом, бешеным перфом, гранулярными апдейтами, ууухххх

День второй.
Плагин оказался со странностями. Почему он перетирает часть конфига моего vite, и принудительно заменет happydom на jsdom???

pnpm орет на меня что у меня vite 4, а плагин только до 3 ей версии. К тому же после изменений в стилях у меня появляется копия всего приложения на странице. Одна по другой. +1 копия приложения после каждого обновления.
Потратил время на изучение проблемы
- нашел ишьюс в котором проблемы с happydom известна пол года. И даже вроде мр есть. Но всем плеват. Решается откатом на старую версию. Наконец замерижили фикс.
- по поводу дублирования приложения - оказывается надо плагину hrm комментариями подсказать что index.tsx где я маунчу апп в дом дерево перевызывать не надо /* @refresh skip */
в целом очень странно видеть что фреймворк так сильно завязаный на сбороку - так слабо поддерживает единственный официальнаый плагин для vite который счас мейнстрим сборщик.

День третий.
Два часа пытался понять почему у меня не ренедериться вьюшка.
Если на реакте заработает почти любой говнокод, ужасно, с кучей лишних перерендоров - но заработает, то в solid - малейшая оплошность приводит к тому что рендера не будет.
Без ошибок в рантайме или иде. Я просто смотрю в дэбагере как мой ресурс скачался, обновитлся сигнал, но ничего не происходит - в вьюшке все так же висит ...loading
дэбагер не помогает - надо слишком много знать о внутрянке солида чтоб в этом был толк.
В итоге оказалось что дело в тернарке.
Тернарки в jsx использовать можно, но только один раз. Как с ядовитыми грибами, ага.
Только специальный компонент <Show>, запомните.
про Optional chaining тоже лучше забыть. Один раз ваше выражение foo?.bar() вернет undefined вместо сигнала и больше вы ререндеров не увидите здесь.

День четвертый.
ClassList как будто бы должен был заменить clsx но на самом деле это пятая нога. Не заменяет, а только лишная апи мешается и создает избыточность.
Typescript, и так бывает больно писать, а с solid это будет еще веселее.
Подводных камней столько что есть отдельный раздел документации который я почему-то не замeтил когда знакомился с солидом первый раз

Вобщем итого -
если ваше приложение на солиде работает - оно будет работать быстро. Это в реакте можно открыть код и сказать "божеш ты, как это го-но работает то, кто это, какой return первой строкой, кто правила хуков будет соблюдать - и тп"
реакт приложение как то накоряканое будет работать хоть и плохо.
В солиде готовтесь превозмогать, без ошибок и подсказок, девтулзов и т.п. выезжать на опыте, внимательном прочтении доки, знать где тонко и писать jsx с минимум логики.
Я вам вобще не рекомендую по началу в солидовском jsx писать выражения js как бы абсурдно это не звучало.
Но, если вам нужен перф, у вас все обновляется например по сокетам и мигает как новгодняя елка каждая панелкьа отдельно - да, это для солида.
Касательно похожести на реакт - ваш код смогут читать (но не писать) реактеры, на этом все

Как появились веб-пуши Apple в Тинькофф

Возможность использовать пуши в браузерах появилась довольно давно, но в safari с этим были сложности, что останавливало внедрение этой технологии. Но, начиная с ios 16.4 safari поддерживает веб-пуши. Статья рассказывает, как в компании Тинькофф начали применять веб-пуши, с какими проблемами столкнулись и как их решали. Также вкратце рассказывается про особенности работы пушей: необходимость шлюза, 2 варианта использования, проблемы с отписками и переподписками и доставляемостью.

Хорошая ознакомительная статья про возможность веб-платформы и её практическое применение большой компанией.

https://habr.com/ru/companies/tinkoff/articles/776658/

#development #javascript #habr #webPush #pwa

Дайджест за 2023-12-11 - 2023-12-15

Web Components Eliminate JavaScript Framework Lock-in
Очередная статья про то, что веб-компоненты позволят нам создавать сайты, используя разные технологии. Сами же веб-компоненты могут использоваться как клей между этими технологиями.

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

Track Frontend JavaScript exceptions with Playwright fixtures
Достаточно интересная статья про использование API playwright для расширения функционала тестов на примере слежения за неперехваченными глобальными ошибками.

В чем проблема: браузерные автотесты весьма полезны т.к. позволяют быть уверенными, что система работает end-to-end или близка к этому. Но тесты проверяют только конкретный функционал. А бывает так, что конкретный функционал работает, но что-то другое падает и в консоли видна ошибка. При ручном тестировании это заметно, но автотесты это не отлавливают. Но автотесты можно научить проверять глобальные ошибки. Именно этим автор и занимается в статье с помощью Playwright

console ninja: console log output right next to your code
Интересный тулинг по типу wallaby и quokka, который связывает код в IDE и консоль в приложении. Т.е. например, вы поставили console.log(myVariable) и вывод консоли отобразится у вас прямо в IDE. Кроме этого инструмент умеет связывать ошибки с кодом, создавать лог-поинты (это как брекпоинты, только вместо остановки мы просим вывести значение переменной в лог) и еще всякое.

Есть платная и бесплатная версии. Посмотрите, возможно вам понравится.

⭐Keep that cursor still!
Веб-разработчики делятся на 2 типа - познавшие боль от работы с курсором в input'ах и тех, кому это только предстоит.

Данная статья подробно разбирает популярную проблему прыгающего курсора в инпуте - если программно менять значение инпута, то велика вероятность что курсор улетит в конец инпута, даже если редактирование было по-середине. Например, вы делаете инпут, в котором происходит замена некоторых символов (например, имена автоматически пишутся с большой буквы, или же вы делаете транслитерацию). Если в этом инпуте пользователь начнет что-то писать в середине инпута, то есть шанс что курсор, после ввода, улетит в конец инпута.

Как появились веб-пуши Apple в Тинькофф
Возможность использовать пуши в браузерах появилась довольно давно, но в safari с этим были сложности, что останавливало внедрение этой технологии. Но, начиная с ios 16.4 safari поддерживает веб-пуши. Статья рассказывает, как в компании Тинькофф начали применять веб-пуши, с какими проблемами столкнулись и как их решали. Также вкратце рассказывается про особенности работы пушей: необходимость шлюза, 2 варианта использования, проблемы с отписками и переподписками и доставляемостью.

Хорошая ознакомительная статья про возможность веб-платформы и её практическое применение большой компанией.

——————————————

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

Доклады секции Frontend на Codefest13

В открытом доступе появились записи доклады с секции Frontend на Codefest13. Лично я посмотрел не все доклады с этой секции прошедшего Codefest, но горячо рекомендую, конечно же, свой доклад про использование ChatGPT и доклад Никиты Сидорова про прогрессивный рендеринг (или что-то в этом роде) в Яндекс.Маркете.


https://www.youtube.com/playlist?list=PL8761XQAJnrZtx3JvX50duslRe_mU7_Zl

#development #youtube #codefest

UX Core - Cognitive biases in product management and HR

Каталог из 210 когнитивных искажений, которые сгруппированы по типам и имеют хорошее описания действия этих искажений в разработке продукта и HR-вопросах, а также как с ними работать. Доступно на русском и английском языке.

Рекомендую к изучению или хотя бы к беглому просмотру

https://keepsimple.io/uxcore

#managment #cognitiveBiases #product #recommended