TypeScript *

В процессе написания приложения с более-менее сложной бизнес-логикой на фронтенде возникает необходимость держать всю эту логику на слое предметной области в "толстых" моделях. Например, для работы с формой, которая отображает на пользовательский интерфейс создание или редактирование сущности с большим количеством взаимозависимых свойств. Если "размазать" обработчики изменения состояния этой сущности и входящих в неё подсущностей по слою Application, легко можно потерять целостность модели в разных actions, reducers, валидаторах. Такой код будет трудно читать, отлаживать и поддерживать.

Можно использовать паттерн Aggregate Root для единой точки входа управления моделью, тогда упростится поддержка инварианта такой сущности. Методы доступа к свойствам и методы, меняющие состояние сущности, можно вызывать из одного объекта, а сам объект будет обеспечивать целостность и валидность своих данных. Но здесь появляется ещё одна проблема: сериализация. К примеру, бывает нужно сохранить всю сущность в каком-нибудь хранилище -- localStorage, redux store. Или отправить на бэкэнд для сохранения. Или событием обновить пользовательский интерфейс, а в payload события при этом надо передать часть сущности в виде простого плоского объекта. В этих случаях нам нужна выжимка данных из сущности, которую можно будет восстановить потом при запросе из хранилища для дальнейшей работы. Это особенно актуально, если на проекте используется SSR, там данные, которые собираются для страницы на серверной стороне, должны быть сериализуемыми.

Всем привет!

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

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

Весь код пишется в файле eslint.config.mjs, а не в eslint.json или eslint.config.js, однако вы можете указать свой формат. В доке пишут, что приоритет наивысший у .js и .mjs и имеет смысл их использовать. А .mjs нужен для корректной работы, поэтому не .js, хотя это тоже всё настраивается, если есть желание.

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

Так же добавлена пара новых импортов

Привет Хабр. На связи Даня, Angular-разработчик из команды Т-Бизнеса.

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

Добро пожаловать под кат!

В данной статье хочу рассказать про сервис load-testing-hub, главная задача которого это сбор, агррегация, анализ и визуализация данных о нагрузочном тестировании

Расскажу о том, какие проблемы решает сервис, как он помогает оценивать производительность выпускаемых релизов, а также поделюсь примерами его использования

Рассмотрим основные возможности load-testing-hub, такие как создание наглядных графиков и отчетов, сравнение результатов нагрузочных тестов

В статье мы рассмотрим, как можно значительно улучшить читаемость кода с помощью двух мощных техник: пайплайнинга (pipelining) и композиции функций (composing). Мы будем использовать TypeScript для демонстрации этих подходов.

База данных будет подниматься через Docker Compose.

Миграции пишутся вручную и запускаются через Flyway мигратор.

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

Конфигурации для Docker Compose и Flyway генерируются через запуск NestJS-mod в режиме инфраструктуры.

Всем привет!

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

Меня зовут Федор, занимаюсь JS Fullstack разработкой последние несколько лет. Хочу поделиться своим примером организации backend проекта с использованием Nestjs и Firebase. В этом туториале мы создадим кодовую базу на Nestjs, законфигурируем линтеры и Firebase.

В статье приведены примеры кода, ссылки на коммиты и сам репозиторий. Мы пройдем от генерации проекта, до итогового CRUD примера, который можно использовать при разработке своих пет проектов и не только. Для работы с Firebase может потребоваться иностранная платежная карта.

Создание приложения происходит через nx схематик для Angular.

Адрес сервера задается жестко в коде, в следующих постах адрес будет перенесен в переменные окружения.

Для запуска E2E-тестов используется "Playwright".

Недавнее объявление о блоке @let в Angular вызвало бурное обсуждение в сообществе разработчиков, одни считают его ценным дополнением, другие видят в этом ненужное усложнение.

После многих лет написания различных проектов на NestJS и Angular, я решил переписать группу проектов из репозитория https://github.com/rucken и использовать текущий стиль кодирования, он не сильно поменялся, просто стало меньше однотипного кода.

Разработку основного fullstack-бойлерплейта для фронтенд и бэкэнд без бизнес функционала буду вести в отдельной организации "NestJS-mod" (https://github.com/nestjs-mod).

⚛️ Адаптивная верстка на React Native

При разработке веб-приложений на React, браузер Chrome тратит много оперативной памяти. Это связано с тем, что для эффективного обхода Virtual Dom, используется JIT компилятор, наслаивающий более эффективные реализации скомпилированных JavaScript функций поверх интерпретируемой реализации. Это создает высокую сложность по памяти: нагрузка на GC возрастает кратно.

Избежать просадки производительности может использование движка Hermes из React Native. Однако, React Native не умеет работать с адаптивной версткой: из коробки есть Yoga Layout, реализующий только Flexbox.

Описание проблем, возникших при портировании классического React приложения в React Native можно прочитать в этой статье. Речь идет о поддержке различных форм факторов устройств, в том числе, Galaxy Fold

Эта статья для тех, кто знает, что такое “внедрение зависимостей” и имеет практический опыт его использования. Меня зовут Алекс Гусев и я являюсь автором библиотеки “@teqfw/di”. Цель моей библиотеки - дать возможность использовать функционал “внедрение зависимостей через конструктор” в проектах на JS (фронт и бэк) и TS (бэк). Минимальной единицей внедрения является отдельный экспорт es6-модуля. Поэтому библиотека не может использоваться с модулями CJS или UMD.

В основу внедрения зависимостей заложена идея о том, что вместо статического связывания исходного кода на этапе написания (через import) применяется динамическое связывание объектов программы в режиме выполнения. В моей библиотеке это достигается за счёт размещения в коде конструкторов (или фабричных функций) инструкций по созданию нужных им зависимостей, которые интерпретируются Контейнером Объектов при работе программы и на основании которых загружаются нужные исходники и создаются нужные зависимости.

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

Данная статья рассчитана на тех, кто только начинает писать свои React приложения на TypeScript, а также является памяткой для меня, ведь совсем недавно я путался в типизации children props.

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

Если же чувствуете, что несмотря на то, что в проекте нет сложной логики, но дерево компонентов и количество и вариация передаваемых пропсов внушительные, я бы воспользовался prop-types. Ранее эта фича входила в состав React и использовали её так: React.PropTypes. Но начиная с версии React 15.5 она переехала в отдельную библиотеку, поэтому теперь её необходимо устанавливать как, например, npm/yarn пакет. Она используется для валидации типов props в компонентах React. Это всё из возможностей TS, но для проекта с большим количеством компонентов и пропсов - то, что нужно. Синтаксис описания типов пропсов отличается от TS.

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

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

В первой части предлагаю ознакомиться с предикатами выводимого типа и то как всё это поменялось в TypeScript 5.5 версии, приступим!

Привет. Меня зовут Дмитрий, я фронтенд-разработчик в компании «Цифровая индустриальная платформа». В своей работе мне часто приходится использовать Dependency Injection (DI) в Angular. Это мощный и популярный инструмент, который упрощает работу с зависимостями в наших приложениях. Он позволяет легко интегрировать необходимые сущности в компоненты, упрощает процесс тестирования и поддерживает принцип инверсии зависимостей. Однако часто мы не используем все возможности DI, потому что не знаем, как он работает под капотом. Давайте разберемся, как функционирует DI, что такое иерархия инжекторов и какие изменения принесла версия Angular 14.

Частенько сталкиваются с проблемой поддержания типовой безопасности в React-проекте. Код разрастается, и управление типами становится всё сложнее. Ошибки, вызванные неправильной типизацией, приводят к крашам и длительным отладкам. Тогда приходит время внедрения TypeScript!

В статье рассмотрим как TypeScript может помочь решить проблемы с типизацией и сделать React-код идеально типизированным.

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