artalog

Короткое годное введение в полезность AbortController, рекомендую: https://kettanaito.com/blog/dont-sleep-on-abort-controller Со своей стороны добавлю, абортить надо не просто со строкой с описанием причины, а хорошо бы с полноценной ошибкой (Error) для наличия колстака и упрощения дебага. Проблема в том что AbortController стандартизировали, AbortSignal стандартизировали и затащили оба и во все браузеры и в серверные среды исполнения. Но AbortError не стандартизировали, потому что нет такого. Исторически сложилось, что ошибки отмены браузер выбрасывает как new DOMException(message, "AbortError"). И при стандартизации менять это на новый AbortError не хотели из-за обратной совместимости. И серверные среды не хотели к себе тащить DOMException по понятной причине (хотя в ноде DOMException доступен, лол, но это костыли). С DOMException еще проблема в том что он вторым аргументом принимает свойство "name", тогда как недавний апдейт спеки подарил нам error cause и теперь все этоо наследние не совместимо. Я в реатоме использую такой хелпер, и всегда аборт вызываю так: controller.abort(toAbortError('unmount')) (кстати, можете импортировать себе, все тришейкается)

В новой версии @reatom/[email protected] в reatomComponent появилась поддержка use и useAtomPromise. В теории выглядит круто - данные от эффектов не надо сохранять в отдельный стейт. Но типов для use пока не подвезли, да и вообще он пока доступен только в canary версии реакта.

Опять дико подгорает от реакта. Есть общепринятый контракт саспенса - throw promise. Начал тыкать 19 версию для поддержки use - так оно выбрасывает Error! Причем, у них есть симбол Suspens для внутренних нужд, но в эту ошибку они его не асайнят, поэтому сейчас проверка на саспенс выглядит так:

const isSuspense = (thing: unknown) =>
  thing instanceof Promise || (thing instanceof Error && thing.message.startsWith('Suspense Exception'))

Для меня этот код выглядит не надежным. Особенно тревожит то что алгебраические эффекты статически никак не типизируются, в отличии от окамла из которого они были взяты. И если проверка в кетче на Promise ещё достаточно однозначна, то парсит message (а они даже name не меняют) - просто надежда на все хорошее. Если кто-то знает детали и способы лучше - поделитесь, пожалуйста. Текущее решение очень не удобно для авторов библиотек, реакт опять вставляет нам сваи в колёса ☹️

🧐 Когда я все успеваю? В недавнем совместном с Соером эфире, я рассказывал, что развитие своих образовательных проектов и ведение блога является разумным продолжением карьеры разработчика. Это может приносить как непосредственно материальные блага, так и косвенно привести к карьерному продвижению на основной работе. И в комментариях к эфиру был один саркастический вопрос, который меня весьма задел: "Как так он все успевает, мы, увы, не узнали. Видимо, в Яндексе какой-то особый режим работы.". Почему задел? Ну, просто количество времени в сутках реально ограниченно и секрет "успевания" в том, что я вынужден от многоного отказываться. Например, от выходных. Поэтому я решил написать пост, в котором примерно расписать "своё рабочее расписание". Итак, у меня есть 3 работы: работа в Яндексе, ведение образовательного курса и ведение блога. Давайте распишем сколько времени на что уходит. 1. Работа программистом: 5 дней в неделю; рабочее время с 12 до 19, но код пишу в среднем 5 часов в день, а остальное на ревью, созвоны и т.д. 2. Ведение образовательного курса: у меня на неделе либо 2, либо 3 лекции (третья лекция идет по субботам каждую вторую неделю); лекция длиться в среднем 2 часа, а по субботам 3; две лекции идут в будни в 19.00, т.е. я читаю лекцию СРАЗУ ЖЕ после работы без перерывов на ужин и прочего. Кроме того, к лекциям надо подготовить презентацию, а к субботней лекции подготовить разбор ДЗ (фактически, решить ДЗ). Тут конечно зависит от того какой это поток курса, ведь для новой программы времени на разработку нужно куда больше: разработка новой презентации в среднем занимает 10-12 часов, а доработка старой 1-3 часа. Прорешивание ДЗ может занимать от часа до 10 часов (бывают оч сложные ДЗ). Где брать это время? По утрам перед работой (вечером делать такое уже не хватает ментальных сил) и по выходным. Но для меня архи важно, чтобы работа программистом не страдала от моей образовательной деятельности. 2.1. Extra активности. Параллельно с чтением курса я записываю интенсивы. Но из-за критически малого времени и усталости этот процесс сильно размазан по времени. Например, последний мини-курс по командной строке я делал в активной фазе более 6 месяцев. 3. Ведение блога. Признаюсь, что раньше просто тут сдавался и блог вел по остаточному принципу, но проблема такого подхода, что и рост аудитории идет по такому же принципу. Последние несколько месяцев я поставил себе цель писать минимум один полноценный образовательный пост, а в идеале - 2. Это занимает в среднем 3-4 часа в неделю. Работаю по выходным и утрам. А еще у меня жена и маленький ребенок, которым тоже нужно внимание мужа и папы. На все остальное - у меня нет времени. К примеру, за год я прочитываю порядка 1-3 книг, так как совершенно нет на это времени, но раньше я очень любил читать. Тяжело ли жить с таким графиком? Безумно. Кажется я никогда не болел так часто, как за последние годы. Но у меня есть определенные обязанности, которые я должен выполнять. Я не буду сейчас про это расписывать. Как же я не выгораю? Возможно, я давно выгорел и просто уголь дважды сгореть не может. А, возможно, я просто люблю свою работу и это позволяет мне делать больше. Несмотря на сложившиеся сложности, я все равно получаю удовольствие от программирования. К чему я все это написал? Секрет моего успеха в постоянном труде. Нет ни сверх талантов, ни сверх связей или чего-то еще. Есть только постоянная работа на протяжении всей моей карьеры. Другого пути я не знаю. И только про него и рассказываю.

Новости #x за неделю. https://youtu.be/ELz7spMI4Nw?si=-8yj1o5FQHTjsLcS (простите что так поздно в этот раз) Подписывайтесь, ставьте лайки =D state of ai twitter bubble (new Mistral model) - https://x.com/airesearch12/status/1833762791578091677 Новый сайт JPEG XL (поделился https://x.com/jonsneyers) - jpegxl.info The new 3D models at Apple's website - https://x.com/hybridherbst/status/1833281592351166901 A wonderful Electron standalone alternative weighting only 96.5KB to bootstrap - https://github.com/WebReflection/workerful#readme Вот есть популярная шутка, что во фронтенде якобы каждый день новый фреймворк - https://x.com/andrey_sitnik/status/1824040266812076420 A sneak peak of what's coming to tan_stack Start Devtools - https://x.com/aryan__deora/status/1833661460347822381 is this the downfall of the internet? - https://x.com/Steve8708/status/1833318435394318690 I am happy to announce that @documenso is moving from Next.js to Laravel - https://x.com/catalinmpit/status/1833392217093795856 Bench Node vs Bun - https://x.com/manast/status/1834178089573605821 JSX without React - astro.build Solid Trello clone - https://strello.netlify.app

Always prefer using Locators and web assertions over ElementHandles because latter are inherently racy.

ДА ТЫЧТО??? Речь о Playwrite. Вот вам кейс, когда происходит в точности наоборот. Важно понимать, что локатор - это как css селектор, при каждом обращении к нему вызывается заного. Лично я это каждый раз забываю... Если вы накидали какой-то локатор - вы описали селектор который будет потом использоваться при вызове соответствующих операций, но вы не получили элемент! Извините что звучу как Кэп, но я постоянно об этом забываю, да и утренний тред в чате намекает, что люди тоже не особо наровят это помнить и проверять. Так вот, кейс когда это может выстрелить в ногу. Есть список элементов, вам нужно удалить их все по очереди. Вы селектите карточку элемента и получаете все элементы, берете first или last, не важно, получаете targetLocator и прокликиваете на нем удаление. А дальше, я полагаю логично, вы хотите targetLocator.waitFor({state: 'detached'}). И получаете плавующую багу, если элементов много - ожидаение падает с таймаутом, а если в списке всего один элемент - все идет нормально. Уже поняли проблему? Локатор при проверке видимости элемента каждый раз заного ищет целевой элемент в списке и после удаления одного, простоо находит другой, если их несколько. Я долго тупил над этим🥲 В данном кейсе вместо локатора лучше использовать реальный элемент (через elementHandle). Я для себя понял что так надо делать когда работа предстоит с динамическим набором элементов (для меня частый кейс). Жаль только, у него апишка не консистентная с локатором. Например, вместо targetLocator.waitFor({state: 'detached'}) нужно будет написать targetElement.waitForElementState('hidden').

Книжки по жаваскрипту - это какой-то мем. Пример "мы засунули аргументы не туда и добавили Observable - слава реактивности!". Дальше идёт код с так и не принятым bind operator. Боюсь читать дальше.

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