TypeScript *

Создание user-friendly документации для Angular проектов при помощи NgDoc.

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

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

В этой небольшой заметке я расскажу, как обнаружить прожорливые библиотеки и ускорить компиляцию.

Я давно пишу код, а React использую более пяти лет.

За это время у меня возникло несколько идей о том, как можно было бы улучшить React.

К реализации этих идей я приступил около трех лет назад. Сначала проверил концепцию, потом решил оформить всё в виде библиотеки.

А о том, что из этого вышло, я бы хотел рассказать в этой статье.

localStorage для авторизации в React приложении.

Пишем drag-and-drop загрузчик файлов для React приложения с помощью Context, подхода Compound components и нескольких кастомных хуков

Прикручиваем react-dnd за 5 минут

Пишем систему валидации форм для React приложений

Привет, Хабр!

Несколько дней назад в одном из обсуждений в сообществе Cypress на Discord мельком был затронут вопрос о том, как проверить данные из файла Excel с помощью Cypress. Это подтолкнуло меня сделать несколько полезных заметок, ставших основой для данной статьи.

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

Оригинал статьи на английском языке был включен в 136th Coding Jag от LambdaTest, а также в Issue #82 Software Testing Notes.

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

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

За два года создания Squadus мы столкнулись с массой непростых технических задач. О том, как решали их при разработке фронтенда, читайте под катом.

Привет, Хабр!

За последние несколько лет работы с командами тестировщиков ПО в России и США мне довелось столкнуться с различными подходами к организации тестирования, разнообразными паттернами построения тестовых сценариев и разработки автоматических тестов. При этом нередко случалось, что приходя на проект и анализируя имеющуюся тестовую базу выяснялось, что существующие автотесты нуждались в серьезной доработке или вовсе переработке в целях обеспечения их надежности и сокращения времени на их выполнение. Преимущественно это касалось этапа сквозного (e2e) тестирования, и по моим наблюдениям очень часто причиной тому было не столько незнание тестировщиками встроенных команд тестового фреймворка, сколько неумение применить в тестах базовые возможности используемого языка программирования.

Это подтолкнуло меня к написанию пары статей, в которых я делюсь некоторыми наработками по оптимизации автотестов Cypress, основываясь на простых и в основном известных возможностях JavaScript. Изначально статьи были опубликованы на английском языке в моем блоге "Testing with Cypress" на Medium.

В данной публикации рассмотрим как можно сократить количество типов/интерфейсов в Typescript, сделать их более лаконичными и сэкономить время себе и своей команде. Все это будем делать с помощью Util Types - специальных типов, которые предоставляет Typescript.

Всем привет, на связи dev.family. Хотим рассказать про интересный проект, над которым мы трудимся почти полгода, и до сих пор продолжаем. За это время в нем многое произошло, многое поменялось. Мы открыли для себя что-то интересное, успели набить шишек.

В этой статье я хотел бы рассказать как решил создать свой первый проект.

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

Но японский язык (также как и китайский и, частично, корейский) имеют довольно высокий входной барьер для чтения, потому что нужно не только выучить два алфавита, но и запомнить как минимум несколько сотен кандзи (300-500).

Данная статья написана с уклоном на практическое применение регулярных выражений в проектах. Изначально написана для начинающих разработчиков в моей компании. Статья включает в себя примеры использования на JavaScript (TypeScript).

По мере изучения RxJS разработчик рано или поздно сталкивается с такими понятиями, как cold и hot observable. А на технических собеседованиях в команды, которые используют RxJS, можно услышать вопросы по этой теме.

Например, чем горячий поток отличается от холодного? Можно ли холодный поток превратить в горячий и наоборот? И если да, то как это сделать?

В статье попробуем разобраться в теме и найти ответы.

В пятницу можно смешивать всё и со всем!

Мы смешаем пифагоровы тройки и библиотеку RxJS.

Пифагоровой тройкой называют три натуральных числа, из которых можно составить прямоугольный треугольник.

Такие числа известны людям с очень древних времён. Например, их использовали ещё в Египте, откуда до нас дошла самая известная пифагорова тройка — это числа 3, 4 и 5.

RxJS — это библиотека для реактивного программирования. Она поможет сделать генерацию троек красивой и простой.

Сразу замечу, что статья претендует только на развлекающую роль

Привет, Хабр! Как-то раз после работы мне захотелось взять и написать небольшую компьютерную игру. А почему бы и нет? Играть я люблю, программировать — тоже. Захотелось проверить, можно ли сделать что-то прикольное на уровне современных AAA-игр, не изучая дополнительных языков программирования, а также избежать банального повторения тех же «велосипедов», которые уже 100500 раз выложены на различных стримах и, конечно, не раз разбирались на Хабре. В этом посте я хотел бы поделиться с вами своим небольшим экспериментом в области GameDev на базе JS и обсудить возможности, которые есть у любознательного программиста с бэкграундом в сфере JavaScript.

Наверное, большинство фронтенд-разработчиков в какой-то момент сталкивались с задачей внедрения TypeScript на проект. Обычно это задача выполняется не сразу, а постепенно. Сначала просто переименовываются все файлы из .js в .ts с проставлением везде типа "any", просто чтобы проект запустился, и только потом постепенно разработчики начинают заниматься планомерным переводом.

Если разработчики к тому времени не имеют серьезного опыта работы с TypeScript и изучают его по ходу дела, то очень часто перевод заканчивается на этапе создания модели данных, то есть внедрения типов и интерфейсов для всех основных сущностей, типизации API.

Зачастую, при создании типов и интерфейсов, описывая какое-то свойство, которое может принимать определенное, конечное количество строковых значений, разработчики указывают тип поля string или в крайнем случае перечисляют эти значения через "или".

Так, при создании интерфейса какого-либо сотрудника, у которого есть имя, возраст и должность в компании наиболее простой и быстрый вариант представлен ниже:

  interface Person {

name: string;

age: number;

position: string;

}

Ошибок нет. Вроде бы все работает, однако какие проблемы это может создать? Если имя - это строка, которая может принимать любое значение, то должность в компании - это тоже строка, но принимать она может только вполне определенное и конечное количество строковых значений. Например, в нашей компании есть только директор и продавец. В случае, если мы попытаемся создать объект с должностью "бухгалтер", такой тип ошибки не выдаст:

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

Хороший UI/UX помогает пользователю избежать большинства таких проблем. Инструментов контроля огромное количество, сегодня расскажу про один их них — создание маски для поля ввода силами Javascript.

Hello, world!

В этом туториале мы разработаем простое типобезопасное (typesafe) клиент-серверное (fullstack) приложение с помощью tRPC, React и Express.

tRPC позволяет разрабатывать полностью безопасные с точки зрения типов API для клиент-серверных приложений (предпочтительной является архитектура монорепозитория). Это посредник между сервером и клиентом, позволяющий им использовать один маршрутизатор (роутер) для обработки запросов HTTP. Использование одного роутера, в свою очередь, обуславливает возможность автоматического вывода типов (type inference) входящих и исходящих данных (input/output), что особенно актуально для клиента и позволяет избежать дублирования типов или использования общих (shared) типов.

Руководство по tRPC находится в процессе подготовки — следите за обновлениями ?

Для тех, кого интересует только код, вот ссылка на соответствующий репозиторий.

Интересно? Тогда прошу под кат.