TypeScript *

История создания логического симулятора на TypeScript: от «игрушки» на паре до архитектурного движка с DI, event-bus и системой плагинов.

Доброго времени суток, Хабр! Я, как и многие из нас, периодически захожу на тот самый "красный сайт" по поиску работы. В перерывах между задачами скролю ленту вакансий, откликаюсь на интересные и жду отклика. Но с недавних пор всё изменилось.

Если раньше в таком "ленивом" режиме я получал человеческие ответы — иногда даже приглашения на собесы, — то теперь, буквально через секунды после моего отклика, прилетает reject. И не просто "нет", а с шаблонными комплиментами: "Вы отличный специалист, но, к сожалению, не подходите под нашу вакансию". Все как один — сгенерированы роботами.

Раньше было сложно пробиться через HR до технарей, а теперь даже до HR не доберёшься. Добро пожаловать в эпоху нейросетей, где ИИ решает, достоин ли ты собеседования!

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

В нашей компании AnyMaint, которая занимается разработкой софта для управления техническим обслуживанием и ремонтом (CMMS) промышленного оборудования, одной из главных задач является нормализация имён тулов (инструментов). Под «тулом» мы подразумеваем любой промышленный актив: машины, станки, приборы, оборудование и т.д.

Ранее мы говорили о том, как улучшить кэширование наших проектов и правильно загружать поставщиков. А в этой статье мы рассмотрим следующее:
- Как мы можем использовать стратегии предварительной загрузки, включая что такое "магические" комментарии Webpack, и что такое спекулятивная/ручная предварительная загрузка;
- Как мы можем запрашивать данные с сервера, не дожидаясь загрузки наших статических файлов;
- А также какие сторонние или наши собственные решения могут быть использованы для этого.

Ранее мы поговорили о том, как сделать дерево зависимостей нашего проекта максимально чистым и почему это важно для ленивой загрузки. А в этой статье мы расскажем о следующем:
- Как мы должны загружать вендор файлы с точки зрения правильной организации ленивой загрузки.
- Что общего между стратегиями оптимизации "ленивой загрузки" и "кэширования", и как использование одной из них влияет на другую.
- Что такое кэшируемость и как сделать наше приложение максимально кэшируемым.
- А также как правильно настраивать группы кэша в Webpack и не испортить кэшируемость.

Ранее мы обсуждали самые основы ленивой загрузки и то, почему она вообще важна. А в этой статье мы рассмотрим следующее:
- Как бандлеры анализируют файлы исходного кода, строят деревья зависимостей и генерируют файлы для сборки.
- Как они генерируют файлы JavaScript из исходного кода.
- Как браузеры решают, какие сгенерированные файлы следует загружать, чтобы отобразить ленивую страницу/компонент.
- И как мы можем уменьшить размер и количество загружаемых файлов, правильно настроив структуру файлов и корректно используя статический импорт.

Ленивая загрузка - это принцип, который должен быть известен большинству frontend разработчиков. Однако, этот механизм обманчиво прост, и его освоение является гораздо более комплексной задачей, чем кажется многим. Если уже используете Lazy Loading, у вас все равно могут быть серьезные пробелы в знаниях. Но даже если вы считаете, что знаете про ленивую загрузку абсолютно все, освежить память не будет лишним.

В этой статье мы рассмотрим основы ленивой загрузки: что это такое и почему это важно;
как мы можем использовать ленивую загрузку в наших проектах; а также какие части кода следует загружать лениво.

Современный фронтенд напоминает перегруженный интерфейс: мощные возможности, но чтобы начать работать, нужно изучить десятки концепций. React, Vue, Angular — у каждого свой сложный путь изучения.

Мы задались вопросом: что действительно нужно знать, чтобы создавать UI?

Оказалось, всего четыре концепции: компоненты, состояние, эффекты и DOM. Все остальное — синтаксический сахар и edge cases.

Так родился наш эксперимент: упаковать эти основы в максимально простую модель. Не изобретать новое, а отшлифовать существующее.

Иногда прогресс — это не добавление возможностей, а смелость убрать лишнее.

Всем привет! Сегодня я возвращаюсь с новой порцией TypeScript- и React-магии. Вместе разберем полиморфизм в React, а именно — паттерн as. Зачем он нужен, как его прикрутить без багов и почему это сделает ваши компоненты в разы круче. Как обычно — всё под катом.

Привет! Меня зовут Алексей Гомелевский, я frontend-разработчик в Garage Eight. Моя команда занимается улучшением взаимодействия пользователей с продуктом, и недавно мы решили реализовать комментарии. В этой статье расскажу, как выбирали между решением из коробки и собственной разработкой, с какими сложностями столкнулись и как на базе комментариев создали чаты. 

Я построил полноценную образовательную платформу для изучения иврита — с интерактивными тренажерами, умным словарем на 4000+ слов и системой подписок. В статье рассказываю о нетривиальных технических решениях, архитектурных выборах и ошибках, которые пришлось исправлять по ходу.

Продукт: hebrewglot.com

Стек: Next.js 15, TypeScript, PostgreSQL + SQLite, Stripe, NextAuth

Привет, это Костя из Cloud.ru, я вернулся после долгого перерыва, чтобы снова открыть цикл коротких статей про Typescript. В этот раз поговорим о важном — дистрибуции типов. Зачем она вообще нужна, когда и как применяется, а также как работает. Как обычно интересное — под катом.

Hawk — это open-source трекер ошибок, разработанный в России. Позволяет отслеживать ошибки в веб-приложениях, API и мобильных сервисах. В этой статье подробно рассмотрим функциональность, которая сегодня доступна пользователям Хоука — от регистрации до продвинутых SDK-функций и планов на будущее.

Решил мигрировать с WebStorm на VS Code, но обнаружил, что нет поддержки автоимпорта Angular-компонентов. В WebStorm это работало из коробки — начинаешь писать <app-, IDE сразу подсказывает компоненты и автоматически добавляет импорт. В VS Code такого не было.

На первый взгляд задача выглядела несложной — пару регулярок накидать и можно сделать своё решение.

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

Сколько раз вы меняли поле в API, обновляли тип на бэкенде, а потом вспоминали, что надо поправить ещё и фронтенд? А если есть мобилка? А если схемы валидации тоже дублируются? Я устал от этого и создал шаблон монорепозитория, где TypeScript типы, Zod схемы и константы живут в одном месте и используются везде.

Однажды при работе с крупной кодовой базой одного фронтенд-приложения я заметил, что функционал постепенно группируется относительно команд (доменов). Каждая из таких групп функционала постепенно накладывает собственные ограничения на архитектуру. Как оказалось, обработка ошибок при сравнении кода двух разных команд неоднородна. В одном случае разработчики структурировали ошибки стандартным наследованием JS/TS, в другом были использованы перехваты возникающих ошибок и логирование.

Стало ясно, что нам требуется обобщить подход к тому, как мы структурируем (называем, наследуем) и выбрасываем ошибки. Как показала практика, соглашений о кодировании недостаточно.

Что мы хотели получить?

Object-Relational Mapping (ORM) — технология, призванная «поженить» реляционную природу SQL-баз (PostgreSQL, MySQL, SQLite и т.п.) с объектной моделью языков программирования. Она настолько популярна, что её пытаются реализовать даже в необъектных языках — например, в Go или Erlang.

Если в Java без ORM действительно неудобно, то в экосистеме Node.js (и TypeScript в частности) ситуация принципиально иная. И ORM здесь — зачастую избыточная абстракция. В большинстве случаев рациональнее обойтись компактным SQL-билдером который сильно упрощает построение запросов, оставляя над ними полный контроль, и который совсем не занимается управлением объектами. Почему в Node.js ORM почти не даёт преимуществ...

Привет! Я Максим Кузьмин, старший инженер по автоматизации в команде Т-Путешествий. Строю и развиваю процессы автоматизации и разрабатываю инструменты тестирования.

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

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

Да, я его действительно ненавижу. Мне кажется, что команда React'а презирает разработчиков, и я презираю их в ответ. Все их решения направлены на то, чтобы сделать разработку сложнее, медленнее и непредсказуемее. На сегодняшний день они даже умудрились сломать работу JavaScript. Уму непостижимо, почему им это сходит с рук.

Очередной чат, и к тому же на rust?! Да, yet another. И да, в этой статье не будет каких-то новых откровений системного программирования с написанием своего фреймворка для работы со сетью на уровне драйверов или других испытаний. Этот альманах про мой первый опыт в веб-разработке, который может быть полезен для других новичков, ведь тут мы затронем помимо злосчастного rust такие вещи, как devcontainer, REST API, идентификацию-аутентификацию-авторизацию, WebSockets, SSE, юнит и интеграционные тесты, некоторые паттерны, логирование и прочее.