Cтрого типизированная надстройка для JavaScript
Зачастую обычные веб-приложения не покрывают E2E тестами, однако, когда разговор заходит об административных панелях, формах биллинга и разнообразных конструкторах, то данная потребность быстро возникает.
В этой статье мы рассмотрим, как правильно организовать селекторы для тестирования веб-приложений.
Я починил плохой перевод силами ИИ, написав расширение при помощи ИИ. И я удивлён, что до сих пор такого не сделали.
WebRTC - это технология, которая позволяет браузерам и мобильным приложениям обмениваться аудио и видео в реальном времени без необходимости использования промежуточных серверов. Это делает WebRTC идеальным выбором для приложений, которым необходим функционал видеозвонков, стриминга, и аудиовызовов.
В реактивных системах существуют специальные функции, такие как watchEffect во Vue или autorun в MobX, которые умеют автоматически отслеживать зависимости и перезапускать «эффект» при их изменении. Принцип их работы следующий:
В Angular любое изменение в компоненте, которое отображается на экране, является результатом работы механизма отслеживания изменений (Change Detection, CD). За этим процессом стоит Zone.js, который можно представить в роли дирижера, сообщающего компонентам о необходимости обновить DOM.
Zone.js не запускает CD сам. Он лишь создает контекст, в котором Angular потом может его запустить. Его задача только уведомлять Angular о завершении асинхронных операций, после чего Angular решает, нужно ли проверять изменения.
Чтобы понять важность такого подхода, нужно учитывать особенности JavaScript. В JavaScript асинхронные операции, такие как setTimeout или fetch, разрывают стек вызовов. Это значит, что callback-функция, выполняемая после завершения асинхронной операции, не имеет информации о контексте, в котором она была вызвана. Для фреймворка, который отслеживает изменения, это создает определенные трудности: как узнать, что асинхронная операция завершилась и, возможно, изменила данные?
ClientOnly в Nuxt - это не просто костыль для исправления SSR-ошибок, а многофункциональный инструмент с неожиданными преимуществами. Разбираемся, как этот компонент может ускорить загрузку приложения, улучшить пользовательский опыт и даже создать дополнительный уровень защиты от ботов.
Серьёзно о несерьёзном и с юмором о технологиях — обо всех секретных суперспособностях вашего любимого компонента-невидимки.
Нам важно, чтобы поддержка пользователей была на высоком уровне, поэтому у нас есть десятки сервисов для организации обучения специалистов поддержки. Я работаю над одним из таких проектов. Он активно развивается: ежемесячно добавляем более 10 новых страниц — сейчас в проекте их больше 120.
В статье расскажу, как мы поэтапно организовали хранение путей роутера и связали параметры страниц с компонентами их вёрстки. Такой подход помогает повысить читаемость кода, сокращает его дублирование и упрощает поддержку.
Если вы занимаетесь фронтенд-разработкой, то наверняка работали со Storybook — удобной витриной компонентов, на которой красиво лежат компоненты и примеры их использования. Его любят за интерактивную документацию, возможность визуального контроля и изолированной разработки. Но замечали ли вы, сколько действий приходится делать, чтобы взять компонент из Storybook и вставить его в реальный проект?
Наверняка вы сталкивались с ситуацией: нашли компонент в Storybook, затем переключились обратно в IDE, скопировали код, вставили, адаптировали, проверили, и повторили снова. Кажется, многовато действий для простой вставки компонента, правда? Постоянные переключения между браузером и IDE, ручной копипаст и отсутствие связи с уже написанным кодом делают этот процесс неудобным и медленным.
Storybook Studio: всё в одном месте...
Сегодня в нашем CI ежедневно запускается более 5 000 автотестов, которые проверяют всё: от корректности скриншотов панели до скорости отклика API. Это не просто тулза в пайплайне, а часть инженерной культуры команды, которая помогает нам выпускать изменения быстро и с уверенностью.
Привет! Меня зовут Михаил Шпаков, я руковожу разработкой Timeweb Cloud.
Мы вышли на рынок четыре года назад, в условиях, когда уже сформировалась сильная конкуренция, и облачные платформы были далеко не новинкой. Поэтому с самого начала для нас критичной стала скорость доставки изменений — чтобы не отставать, а опережать. Но когда твой продукт — чья-то продовая инфраструктура, нельзя позволить себе нестабильность.
Чтобы не выбирать между скоростью и стабильностью, мы сразу сделали ставку на автоматизацию и автотесты. Это позволило команде быстро выпускать новые фичи, не боясь сломать что-то важное, и при этом держать контроль над качеством на каждом уровне.
В этой статье расскажу, как устроена наша система, какие типы тестов мы используем, как выстроен процесс, и какие уроки мы из этого извлекли.
В классическом исполнении, списки включают в себя все элементы из коллекции. Другими словами, те элементы, которые не видны пользователю (находятся за пределами вьюпорта) все равно присутствуют в DOM дереве. А теперь представим, если список состоит допустим из 1 000 000 элементов, как это повлияет на производительность и ресурсоемкось? Ответ очевиден, пропорционально объёму коллекции будет расти ресурсопотребление и снижаться общая производительность.
Но к счастью для нас есть методы и алгоритмы позволяющие существенно ускорить работу таких «исполинских» списков.
HTML Builder — визуальный конструктор HTML-структур с drag-and-drop интерфейсом для библиотеки @vue-dnd-kit/components!
🔹 HTML Builder позволяет создавать HTML-структуры без написания кода
🔹 Включает рабочую область, палитру компонентов, дерево элементов и панель настроек
🔹 Сейчас это ранняя бета с минимальным функционалом, но уже можно оценить концепцию
Идеально подходит для создания прототипов и визуальных редакторов CMS.
🔗 Демо: https://zizigy.github.io/html-builder/
🔗 GitHub: https://github.com/ZiZIGY/html-builder
Ищу обратную связь по UI/UX и функциональности. Какие фичи хотели бы видеть? Что можно улучшить в интерфейсе? И тд тп.
Всем привет! Сегодня хочу разобрать кейс, с которым сталкивается почти каждый Angular-разработчик на существующем проекте.
Часто в компонентах можно встретить такой код:
Привет, Хабр! Сегодня хочу поделиться опытом создания универсальной системы для работы с пользовательским контентом, которая позволила нам избежать дублирования кода и создать масштабируемое решение.
История о том, как мы с командой сделали умный подбор картинок, а в процессе затестили русскоязычную модель RuCLIP и обсудили маникюр.
В данной статье мы подробно рассмотрим процесс настройки среды unit-тестирования веб-приложений на базе React и Next.js с использованием Jest и React Testing Library. Мы расскажем об установке необходимых зависимостей, создании конфигурационных файлов, настройке Babel и TypeScript, подключении SCSS и SVG, а также организации структуры проекта. Особое внимание уделено специфике настройки Jest в среде Next.js. Материал будет полезен для frontend-разработчиков и команд разработки, которые работают с React или Next.js проектами и хотят внедрить качественное unit-тестирование.
Тут я расскажу о том, как я впервые с нуля поднимал проект на React, используя связку FSD, TanStack Router, TanStack Query и Effector — и как мы всё это далее подружили подружили или нет 🙂.
Сразу оговорюсь:
Проектом занимается команда, но архитектурный старт, выбор технологий и базовая структура — легли на меня. Это был мой первый опыт в такой роли: отвечать не просто за компоненты или страницы, а за фундамент проекта.
А так же, это моя первая статья. Не претендую на истину в последней инстанции, но надеюсь, кому‑то мой опыт будет полезен и палками бить сильно не будете.
🧠 Русскоязычные LLM для вызова инструментов, переводов и финансовой аналитики
Подборка моделей, которые действительно позволяют отказаться от OpenAI и вести разработку в закрытом контуре без подключения к интернету 🔌
Всем привет! Сразу хочу сказать, что это не гайд, и я не рассказываю, как нужно кодить — просто хочу поделиться тем, что у меня получилось, и что я использовал в процессе разработки.
Я не эксперт, и всё, о чём я пишу — это то, что сам прочитал и попробовал на практике. Моей основной задачей было сгенерировать сеточную карту и заставить персонажа искать кратчайший путь до точки, на которую я нажал, и двигаться к ней.
Позже я добавил NPC с простым AI: они могут преследовать игрока, если тот находится рядом. В этой статье речь пойдёт только о построении пути.
Для решения такой задачи мне понадобился алгоритм, как и для всех задач где есть работа с поиском чего либо. В моём случает мне не нужно было диагональное перемещение поэтому я использовал алгоритм A*.
Привет, Хабр! Меня зовут Дима, я фронтенд‑разработчик Яндекса. В этой статье я расскажу о том, как мы переписали наш ридер для электронных книг, создав универсальное решение для веба и нативных приложений.
Статья будет интересна фронтенд‑разработчикам. Из неё вы узнаете, как создать универсальное ядро для веба и натива, получить вместо запутанных асинхронных вызовов чёткие последовательности действий и убрать визуальные артефакты при одновременных пользовательских действиях.
