User
Кажется, уже сложно представить себе веб-приложение, которое не использует микрофронтендную архитектуру для возможности реализовать гибкое и функциональное приложение. И как в любом архитектурном подходе, в микрофронтенде необходимо обеспечивать качественное тестирование разрабатываемых компонентов.
Но с чего стоит начать и что ждет каждого, кто вступит на путь автоматизации микрофронтенда, когда многие привыкли тестировать уже собранные из кусочков приложения?
Всем привет! Если вы считаете Storybook лишним инструментом, эта статья для вас. Раньше я и сам мог присоединиться к такому мнению, но попробовал Storybook в деле, когда участвовал в разработке сервиса рассрочки для одного из крупнейших маркетплейсов. Разработкой этого проекта занимались две команды, состоящие из 15 человек.
Меня зовут Александр, я frontend-разработчик в Simbirsoft. Хочу поделиться, как этот инструмент может сократить время на разработку и тестирование, улучшить качество конечного продукта, а также сэкономить бюджет на больших проектах.
Советую к прочтению фронтенд-разработчикам и тимлидам, которые хотят упростить процесс тестирования и отладки компонентов интерфейса веб-приложений. Также материал может помочь менеджерам проектов и владельцам бизнеса в поиске новых подходов для ускорения и оптимизации процесса разработки. И даже если вы новичок во frontend-разработке и хотите узнать о новых инструментах и технологиях в этой области — welcome.
Мы рассмотрим такие возможности, как создание документации, тестирование, тестирование доступности, работу с моками, аддоны для имитации API и контекста. Я поделюсь, какие проектные задачи мне удалось решить, и чем может быть полезен Storybook для вас.
Зачастую, когда я наталкиваюсь на информацию о работе с DOM в Angular, в них присутствуют упоминания об одном или нескольких из этих классов: ElementRef, TemplateRef, ViewContainerRef. Именно упоминания, ведь общее представление достаточно сложно сложить, даже тщательно изучив документацию Angular. Поэтому я решил подробно сформулировать, как это работает и для чего нужно.
В последнее время все больше компаний сталкиваются с необходимостью создания нескольких брендов на одном сайте или приложении. Такая задача может быть связана с различными целевыми аудиториями пользователей, регионами или продуктами. Реализация мультибрендинга может быть непростой задачей, особенно если у вас уже есть готовый проект.
В этой статье я расскажу, как на проекте с Angular добавить несколько брендов, как добавить разную для них логику, о преимуществах NX для этой задачи и важности архитектуры.
Эта статья будет полезна для всех, кто работает со сложным приложением или задумывается о его масштабировании.
Сегодня мы с вами рассмотрим свойства CSS Grid (далее также — Грид), позволяющие создавать адаптивные или отзывчивые макеты веб-страниц. Я постараюсь кратко, но полно объяснить, как работает каждое свойство.
CSS Grid?
Грид — это макет для сайта (его схема, проект).
Грид-модель позволяет размещать контент сайта (располагать его определенным образом, позиционировать). Она позволяет создавать структуры, необходимые для обеспечения отзывчивости сайтов на различных устройствах. Это означает, что сайт будет одинаково хорошо смотреться на компьютере, телефоне и планшете.
Вот простой пример макета сайта, созданного с помощью Грида.
Привет! Меня зовут Даниил, я фронтенд-разработчик в Тинькофф Бизнесе. Мы строим удобные интерфейсы, чтобы клиенты могли быстро зарегистрировать бизнес.
Сегодня я хочу рассказать, почему мы используем Nx для всех наших Angular-проектов, какие проблемы решает этот инструмент и чем он лучше Angular CLI.
В середине марта 2023 года Майкрософт анонсировала релиз TypeScript версии 5.0. Разработчики ожидают от нее 10-20% прироста производительности, но так как всё зависит от кодовой базы и характеристик оборудования, они настоятельно рекомендуют опробовать эти изменения.
В этой статье мы разберём некоторые изменения в TypeScript 4.9 и 5.0 и сравним нововведения с предыдущими версиями. На примерах кода постараемся понять, для чего они были добавлены и как они упрощают нашу жизнь. Статья будет полезна опытным разработчикам, которые часто применяют TypeScript в работе, и начинающим, так как мы подробно разберем решения некоторых проблем.
Увы, typescript не идеален. Его ругают, но любят. Кто-то даже не может представить свою жизнь без него так же, как не может представить жизнь без комфортного автомобиля. Тем не менее, у этого "автомобиля" в базовой комплектации есть существенные недостатки, которые каждый "автолюбитель" "чинит" по своему.
Один мой знакомый сравнил тайпскрипт с css браузеров, которому необходим свой собственный аналог css reset. И оказалось, что такой действительно есть. Речь идет о пакете, название которого говорит само за себя - ts-reset. За полгода своего существования на github ts-reset набрал 6 тысяч звезд, и мне показалось странным, что на хабре я не нашел ни одной статьи, посвященной этому пакету. И если интересно, добро пожаловать под кат...
Всем привет! Я Александр Бухтатый, frontend-разработчик в Тинькофф, специализируюсь на Angular. Наша команда работает в монорепозитории с четырьмя проектами. В каждом проекте много форм, нужно сопровождать их и создавать новые.
В статье покажу один из способов работы с формами в Angular-проектах, который упрощает создание новых форм и изолирует зависимость от внешней UI-библиотеки. Будет мало текста и много кода, пристегните ремни, мы начинаем.
Работая с монорепозиторием, ты наверняка слышал о наборе инструментов Nrwl Nx. Если вкратце, то Nx ускоряет и упрощает работу с монорепой, снабжает полезными утилитами. Держи документацию.
Часто работа с Nx заканчивается на имеющихся дефолтных настройках. Все остальное остается черным ящиком. Время сборки проектов начинает расти, а причины так и остаются неизвестными. Может, есть что-то, что способно улучшить работоспособность монорепы и хотя бы частично решить проблемы?
Предлагаю отправиться на изучение официальной документации и поискать лайфхаки вместе со мной. Ниже приведу список полезных инструментов и механизмов, вкратце расскажу о них и дам ссылки для детального изучения.
Итак, что же ты мог упустить при работе с Nx:
• nx run-many
• dependency graph + nx affected
• nx-enforce-module-boundaries es-linting
• computation cache
• nx cloud
• buildable libs
В Angular принято писать декларативный код. Это значит, что нам не стоит руками запрашивать нужные нам сущности. Во фреймворке есть инструменты для работы с элементами шаблона, которые помогут нам. О них сегодня и поговорим.
Наверное, большинство фронтенд-разработчиков в какой-то момент сталкивались с задачей внедрения TypeScript на проект. Обычно это задача выполняется не сразу, а постепенно. Сначала просто переименовываются все файлы из .js в .ts с проставлением везде типа "any", просто чтобы проект запустился, и только потом постепенно разработчики начинают заниматься планомерным переводом.
Если разработчики к тому времени не имеют серьезного опыта работы с TypeScript и изучают его по ходу дела, то очень часто перевод заканчивается на этапе создания модели данных, то есть внедрения типов и интерфейсов для всех основных сущностей, типизации API.
Зачастую, при создании типов и интерфейсов, описывая какое-то свойство, которое может принимать определенное, конечное количество строковых значений, разработчики указывают тип поля string или в крайнем случае перечисляют эти значения через "или".
Так, при создании интерфейса какого-либо сотрудника, у которого есть имя, возраст и должность в компании наиболее простой и быстрый вариант представлен ниже:
interface Person {
name: string;
age: number;
position: string;
}
Ошибок нет. Вроде бы все работает, однако какие проблемы это может создать? Если имя - это строка, которая может принимать любое значение, то должность в компании - это тоже строка, но принимать она может только вполне определенное и конечное количество строковых значений. Например, в нашей компании есть только директор и продавец. В случае, если мы попытаемся создать объект с должностью "бухгалтер", такой тип ошибки не выдаст:
Всем привет, на связи dev.family. Хотим рассказать про интересный проект, над которым мы трудимся почти полгода, и до сих пор продолжаем. За это время в нем многое произошло, многое поменялось. Мы открыли для себя что-то интересное, успели набить шишек.
Привет, Хабр!
За последние несколько лет работы с командами тестировщиков ПО в России и США мне довелось столкнуться с различными подходами к организации тестирования, разнообразными паттернами построения тестовых сценариев и разработки автоматических тестов. При этом нередко случалось, что приходя на проект и анализируя имеющуюся тестовую базу выяснялось, что существующие автотесты нуждались в серьезной доработке или вовсе переработке в целях обеспечения их надежности и сокращения времени на их выполнение. Преимущественно это касалось этапа сквозного (e2e) тестирования, и по моим наблюдениям очень часто причиной тому было не столько незнание тестировщиками встроенных команд тестового фреймворка, сколько неумение применить в тестах базовые возможности используемого языка программирования.
Это подтолкнуло меня к написанию пары статей, в которых я делюсь некоторыми наработками по оптимизации автотестов Cypress, основываясь на простых и в основном известных возможностях JavaScript. Изначально статьи были опубликованы на английском языке в моем блоге "Testing with Cypress" на Medium.
Привет! Я Дима, разработчик онлайн-бухгалтерии. Предлагаю на примере простой задачи разобрать два подхода к созданию модальных окон, связанных с url: императивный и декларативный.
Часто на фронтенде нужно открывать модальные окна по определенному пути. Из коробки ангуляр не предоставляет такой возможности, так же как и популярные ui-kit-библиотеки. И разработчики каждый раз ищут способ, как это сделать.
По мере изучения RxJS разработчик рано или поздно сталкивается с такими понятиями, как cold и hot observable. А на технических собеседованиях в команды, которые используют RxJS, можно услышать вопросы по этой теме.
Например, чем горячий поток отличается от холодного? Можно ли холодный поток превратить в горячий и наоборот? И если да, то как это сделать?
В статье попробуем разобраться в теме и найти ответы.
Один античный оратор говорил, что всем людям свойственно ошибаться. Прошло много веков, а человек продолжает совершать ошибки каждый день. Даже беглое заполнение формы на сайте не обходится без опечаток.
Хороший UI/UX помогает пользователю избежать большинства таких проблем. Инструментов контроля огромное количество, сегодня расскажу про один их них — создание маски для поля ввода силами Javascript.
Hello, world!
Представляю вашему вниманию перевод второй части этой замечательной статьи, посвященной возможностям JS и TS последних трех лет, которые вы могли пропустить.
В первой части мы говорили о возможностях JS, во второй поговорим о возможностях TS.
Это вторая часть.
Обратите внимание: названия многих возможностей — это также ссылки на соответствующие разделы документации TypeScript.
