Angular *

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

Всем привет! Сегодня я хочу поделиться приемами улучшения производительности фронтенда путем оптимизации RxJS стримов.

В прошлом месяце исполнилось 13 лет с момента появления "красного щита" Angular. AngularJS стал отправной точкой для новой волны JavaScript-фреймворков, появившихся для поддержки растущей потребности в богатом веб-опыте. Сегодня с новым внешним видом и набором перспективных функций мы ведем всех в будущее с версией 17, устанавливая новые стандарты производительности и удобства для разработчиков.

В данной статья я расскажу о том как создавать гибкие UI контролы в несколько строк кода, которые легко расширяются, кастомизируются и поддерживаются!

Рассуждения о мудрости разработчиков массовых продуктов. Должно ли ее быть больше чем у обычных людей вроде наc с вами? Чужды ли им понятия «неуместность», «вкусовщина», «неоправданность» и «недальновидность». Слышали ли они о важности обратной совместимости? Мнение скромного Angular‑разработчика.

Управление глобальным состоянием

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

Как настроить общее рабочее пространство для команды без запуска сборки в watch-режиме и ожидания старта dev-сервера, чтобы подхватить изменения? Для этого нужно удобным для всех образом настроить переиспользование кода внутри монорепы.

Нам поможет Андрей Кочеров, старший разработчик интерфейсов в Яндекс Такси и техлид фронтэнд команды партнёрских продуктов. Он расскажет как сделать готовый к работе репозиторий сразу после чекаута, на основе методологии Trunk Based Development.

^{Mortal Kombat - Vs Screen (MKX version) Fan art by LukenStruken CC BY-SA 3.0}

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

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

Как сделать подтверждение почты с помощью Spring Boot & Angular?

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

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

landing page для наглядности

Нет часов. Нет минут. Нет часовых поясов. До свидания.

Данный счёт времени достался нам по наследию от наших предков. Если говорить грубо, то вероятнее всего какой-то один человек решил, что это будет удобно, если каждая более крупная единица будет равняться 60 мелким. Но нет. Так как мы используем десятичную систему счисления, удобнее, чтобы более крупная единица равнялась числу кратному десяти. Например, как это сделано во всех остальных единицах - по 1000. И даже приставки каждой единицы уже придуманы кило-, мега-, гига-, тера и т.д. Каждая более крупная единица содержит 1000 мелких. Как вариант, это очень удобно и уже давно стандартизировано.

https://vue-faq.org - попытка охватить наиболее часто задаваемые в профильных чатах и конференциях вопросы о фронтенде в целом и Vue.js фреймворке в частности.

Taiga UI — огромная библиотека UI-компонентов для Angular, на которую стоит взглянуть. Но она только вершина айсберга. Мы разрабатывали ее более пяти лет, начав еще на Angular 4. И, будучи любителями декомпозиции, мы создали несколько отдельных независимых проектов, которые помогают нам писать крутые Angular-приложения. 

Вам может быть неинтересна Taiga UI, но эти небольшие библиотеки будут полезны и непременно улучшат DX. В этой статье рассмотрим всех членов семьи Taiga UI и разберемся, что делает их достойными внимания.

Всем привет! В июне 2022 года наша фронтенд команда наконец-то дождалась строго типизированных форм от разработчиков Angular! Через какое-то время мы заметили что не все работает так, как интуитивно ожидаешь. Позже я создал небольшой внутренний документ с “фишками”, которые явно не описаны в официальных доках. И подумал: “А почему бы мне не выложить наш небольшой гайд на Хабр?”. И вот, выкладываю.

Когда мне прилетела задача реализовать перевод для уже немаленького проекта, честно, я немного потерялась. Есть несколько вариантов библиотек, помогающих с данной задачей, но остановилась я на i18n для Angular и вот почему. На мой субъективный взгляд библиотека замечательно справляется с локализацией уже готового проекта. Но даже так, придется немного повозиться, без этого никуда.

Уточню, что данная статья описывает процессы для Angular v.9 и выше. Надеюсь информация будет вам полезна.

Уже сложно представить наши приложения без такой оптимизации, как tree shaking.
Tree-shaking — «встряхивание дерева», удаление неиспользуемого кода из бандла приложения.

А причем тут standalone компоненты в названии статьи?

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

Если вы работали с Angular, то наверняка встречались с RxJS. Потоки, развесистые конструкции, много аргументов у метода pipe, а каждый аргумент возвращают разные функции с разным количеством аргументов. Есть интуитивно понятные функции типа filter или map. Первый явно фильтрует значения в потоке, а второй эти значения меняет. Такие функции называют операторами. И чем глубже вы проваливаетесь в RxJS, тем больше самых разных операторов вы узнаете. И со временем добираетесь до потоков потоков. То есть вместо обычных значений такой поток эмитит другие потоки. Такие потоки называют Higher Order Observables. И для работы с такими потоками существуют специальные операторы. Возможно, вы слышали, что такие операторы называют Higher Order Operators (HOO). Они могут выравнивать потоки или, другими словами, делать их обычным.

В этой статье я покажу, что в HOO нет ничего мифического, и расскажу в каких случаях вам нужно использовать операторы высшего порядка. Сейчас вы подумаете, что это скучный лонгрид, но не торопитесь. Мы рассмотрим всего 4 оператора: switchMap, exhaustMap, concatMap и mergeMap.

Это визуальная шпаргалка по Angular. Если нужно что-то вспомнить, то достаточно глянуть на нарисованную схему, вместо поиска этой информации в документации. Картинки не просто упрощают сложные вещи — они обогащают ваши воспоминания посредством ассоциативной памяти, позволяя вам уловить больше. Думаю, что эта публикация будет в первую очередь полезна тем, кто уже изучал Angular, но что-то забыл. Так же она должна быть полезна экспертам из схожих платформ разработки, если вдруг им придется столкнутся с Angular. И конечно же картинки помогут новичкам, послужив некой отправной точкой в изучении этой платформы.

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

Рисовал я все это в PowerPoint.

Я давно слежу за развитием веб-технологий и каждый раз, натыкаясь на очередной холивар в интернете про злой и страшный JavaScript, залезающий на чужую территорию, инстинктивно хочу побыть его адвокатом. Обычно все мои доводы сводятся к банальному “не мы такие, жизнь такая” или “ничего личного, просто бизнес”, но в этот раз захотелось развернуто обосновать причины популярности веб-технологий.

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