Вступление

При написании Single Page Application разработчики в большинстве случаев сталкиваются с одной очень распространенной проблемой, а именно — создание lazyLoad модулей и их последующая загрузка на сторону клиента. Т.е. по какому-то действию или по переходу по URL (в большинстве случаев) мы должны загрузить определенный набор зависимостей — JavaScript, CSS, HTML и т.д. В реалиях современной Front-End разработки это будет большущий JavaScript файл. В этой статье я хочу поделиться своим опытом и показать как реализовать lazyLoad модули для AngularJS и тем самым уменьшить общий объем кода при первой загрузке приложения.

⬝ 11 библиотек (наборов компонентов) для Angular, о которых стоит знать в 2018-м
⬝ 11 библиотек (наборов компонентов) для Vue, о которых стоит знать в 2018-м
⬝ 11 библиотек (наборов компонентов) для React, о которых стоит знать в 2018-м

Перед вами третий материал из серии, посвящённой обзору библиотек для популярных веб-фреймворков. В прошлые разы мы говорили о React и Vue. Сегодня наша тема — Angular. В этом материале, помимо традиционных 11-ти библиотек, мы упомянем ещё несколько наборов инструментов, достойных внимания.

Введение

Одним из достоинств Angular является широкий набор инструментов “из коробки”, которые позволяют быстро создавать формы любой сложности.

В Angular существует 2 подхода к созданию форм:

Template-driven forms — подход, в котором ключевую роль играет шаблон компонента, и все описание производится в нем — этот подход является развитием работы с формами в AngularJS;

Reactive forms — новый подход для работы с формами в реактивном стиле. Описание формы происходит в компоненте в виде дерева объектов, после чего это дерево связывается с шаблоном. Все манипуляции (проверка валидности, подписка на изменение значения и прочее) производятся в компоненте, что делает работу более гибкой, удобной и предсказуемой.

В данной статье мы разберем, как начать работать с reactive forms на примере простой формы с валидацией и сообщениями об ошибках. Код примера.

Реактивные формы. Часть 2.

TypeScript — это надмножество JavaScript, то есть, любой код на JS является правильным с точки зрения TypeScript. Однако, TypeScript обладает некоторыми дополнительными возможностями, которые не входят в JavaScript. Среди них — строгая типизация (то есть, указание типа переменной при её объявлении, что позволяет сделать поведение кода более предсказуемым и упростить отладку), механизмы объектно-ориентированного программирования и многое другое. Браузеры не поддерживают TypeScript напрямую, поэтому код на TS надо транспилировать в JavaScript.



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

Недавно на sitepen.com вышла серия статей, посвящённая фреймворкам для разработки веб-приложений. А именно, в этих материалах исследованы платформы Angular 2+, React + Redux, Vue.js, Dojo 2, Ember и Aurelia.

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

На прошлой неделе вышло большое обновление WebStorm. Мы хотим рассказать о том, какие улучшения ждут JavaScript-разработчиков в WebStorm 2017.3 и в других IDE от JetBrains с поддержкой JavaScript.

Вы можете скачать WebStorm 2017.3 на нашем сайте.

Улучшения в поддержке Vue.js

В новой версии WebStorm мы улучшили поддержку Vue.js. В template-части .vue-файла теперь есть автодополнение и навигация к определению для props, свойств в data-объектах, computed свойств и имен методов, объявленных в script части.

Для обычного пользователя программы, которые мы пишем — это магия. Фронт, бэк — неважно. Человек нажимает на кнопку в браузере, и вдруг случается чудо. Но мы-то знаем, что это не чудо, а результат упорной работы.

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

Это происходит само собой, просто по статистике? Если набрать достаточное количество докладов, всё получится автомагически? Как бы не так. Всё подстроено. Как программу на JS проектируют архитекторы, так и за каждой конференцией стоит команда отличных инженеров, которые проектируют её специальным образом. Они проектируют не только структуру, но и вместе с докладчиками «отлаживают» каждый доклад, строчка за строчкой, раз за разом. Проводят кросс-ревью, оценку, починку багов. Пишутся специальные инструменты и выкладываются на GitHub. И так до тех пор, пока не скомпилируется хорошо работающая, безбажная конференция.

Наверное, каждый иногда хотел пообщаться с разработчиками тех инструментов, которыми мы все пользуемся. К примеру, кто хотел бы сказать пару ласковых создателям React или Node.js? А кто хотел бы узнать от них парочку тайн о внутренней кухне проекта?

Это интервью — с разработчиками конференции HolyJS 2017 Moscow, с её Программным комитетом. Мы будем обсуждать:

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

В мире современных веб-технологий все стремительно развивается и меняется. Пару лет назад совершенно нормальным было по запросу клиента рендерить DOM структуру на сервере (например, при помощи PHP) и отдавать уже полностью сформированную страницу. Сейчас все чаще появляются сайты c полным отделением фронтенда (Angular, React, Vue.js...) от бэкенда (некие API эндпоинты), где на фронтенде почти весь контент формируется посредством скриптов, а сервер отдает только данные по запросу. Тут можно было бы упомянуть SSR (Server Side Rendering), но не об этом данное произведение.

В любые времена перед разработчиками и владельцами сайтов стояла непростая задача: доставить контент как можно быстрее, как можно большему количеству клиентов. Одно из самых правильных решений — использовать CDN (Content Delivery Network) для раздачи статичных файлов. В случае с динамическим рендером страниц на сервере мы должны были ограничиваться небольшим списком объектов, которые можно было разместить в CDN: таблицы стилей, файлы скриптов, изображения. Однако, фронтенд, написанный на Angular (React, Vue.js...), статичен целиком, включая индексную страницу. Вот тут и возникает мысль: а почему бы не организовать раздачу через CDN всего фронтенда?

В данной статье пойдет речь о настройке комплексного решения для разработки, контроля версий, автоматической сборки и доставки статического сайта с использованием Gitlab CI, Amazon S3 и Amazon CloudFront. Также речь пойдет о настройке сопутствующих вещей: git, безопасное соединение по протоколу HTTPS, доменная почта, DNS хостинг, бэкенд сервер…

Если вас заинтересовала эта тема, добро пожаловать под кат. Осторожно! Много скриншотов.

Собрал в кучу свои впечатления от конференции, которая прошла 7-8 ноября.

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

Введение

1 ноября 2017 года Google анонсировали мажорную версию Angular 5.0.0 под кодовым названием «пятиугольный пончик». Новая версия включает в себя новые функции и исправления ошибок, и в тоже время основной упор был снова сделан на то, чтобы уменьшить размер Angular, сделать его быстрым и простым в использовании. Полное описание всех изменений, включая критические, можно посмотреть в changelog файле официального репозитория Angular.

От переводчиков

Всем привет, с вами Максим Иванов и Дмитрий Сергиенков, и сегодня мы поговорим о вышедшей новой версии, кратко рассмотрим некоторые из наиболее важных изменений и вспомним историю Angular. Также для тех кто только начинает изучать этот фреймворк, мы рассмотрим примеры того, как быстро разворачивать приложение на Angular. Хотелось бы отметить, что вы можете присоединиться к отечественному сообществу Angular в Telegram, а также посещать Angular Meetup в Москве.

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

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

Два наиболее популярных решения это ngrx/store, вдохновленной по большей части Redux, и Observable сервисы данных.

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

Поэтому я решил поведать вам, как может пригодится Mobx, в решении проблемы управления состоянием. Идея заключается в том, чтобы объединить два мира, Redux и Mobx.

Выжмите из Angular — ведущего фреймворка для динамических приложений JavaScript — всё. Адам Фримен начинает с описания MVC и его преимуществ, затем показывает, как эффективно использовать Angular, охватывая все этапы, начиная с основ и до самых передовых возможностей, которые кроются в глубинах этого фреймворка.

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

Практически каждый человек сталкивается с ведением какого-либо учета, сбором и анализом данных: от использования таблиц в экселе до работы с данными в клиент-банковском приложении. Повсеместно для такого учета используются различные системы управления базами данных (СУБД).

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

Представляю вашему вниманию типичные варианты использования Observable объектов в компонентах и сервисах Angular 4.

Подписка на параметр роутера и мапинг на другой Observable

Задача: При открытии страницы example.com/#/users/42, по userId получить данные пользователя.

Решение: При инициализации компоненты UserDetailsComponent мы подписываемся на параметры роутера. То есть если userId будет меняться — будер срабатывать наша подписка. Используя полученный userId, мы из сервиса userService получаем Observable с данными пользователя.

// UserDetailsComponent

ngOnInit() {
  this.route.params
    .pluck('userId') // получаем userId из параметров
    .switchMap(userId => this.userService.getData(userId))
    .subscribe(user => this.user = user);
}

Вступление

Много лет я работал с AngularJS и по сей день использую его в продакшене. Несмотря на то, что идеальным, в силу своей исторически сложившейся архитектуры, его назвать нельзя — никто не станет спорить с тем, что он стал просто вехой в процессе эволюции не только JS фреймворков, но и веба в целом.

На дворе 2017ый год и для каждого нового продукта/проекта встает вопрос выбора фреймворка для разработки. Долгое время я был уверен, что новый Angular 2/4 (далее просто Angular) станет главным трендом enterprise разработки еще на несколько лет вперед и даже не сомневался что буду работать только с ним.

Сегодня я сам отказываюсь использовать его в своем следующем проекте.

Дисклеймер: данная статья строго субъективна, но таков мой личный взгляд на происходящее и касается разработки enterprise-level приложений.

Всем привет!

Современное front-end-приложение на Angular должно включать в себя следующие характеристики:

• Возможность использования типизированного JS — Typescript
• Обеспечение удобства и производительности разработки с помощью HMR (hot module replacement);
• Модульность приложений и возможность отложенной загрузки модулей (Lazy Loading);
• AoT — режим (ahead-of-time), повышающий производительность приложения.

Существует много вариантов сборки, решающих эти задачи (angular cli, A2 seed и т. д.). Обычно они имеют сложную структуру, плохо настраиваются/расширяются и представляют собой монолит, который невозможно изменить.

В статье я расскажу, как совместить Angular 2+ с webpack и разобраться со всеми этапами сборки/разработки.

Вы удивитесь, как это просто.

Самый распространенный способ получить данные из web служб — это через Http. И в этой статье мы посмотрим как это можно сделать Http-запрос в Angular 4.3 через новый HttpClient.

Начиная с версии Angular 4.3 появился новый HttpClient. В этой статье описывается только новый клиент.

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

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

Но это только половина проблемы. Как всем известно, ресурсами еще нужно уметь грамотно управлять, чтобы не случалось коллизий. Ситуации, когда во время встречи с партнерами, в переговорную врывается руководитель соседнего подразделения со словами “И эта занята!?”, недопустимы.

Второй момент – когда под рукой нет инструмента (к примеру, Outlook или его web-интерфейса), чтобы забронировать переговорную комнату, но очень нужно «успеть» захватить ценный ресурс. Для осуществления задуманного, необходимо идти на свое рабочее место и с него осуществлять бронирование. Теперь представим, что у вас нет на это времени, выходя из переговорной комнаты с очередной встречи.

Можно конечно придумать еще различные варианты «почему». Для нас уже этих двух моментов было достаточно, чтобы начать исследования в направлении поиска решения проблемы.

Мы не замечаем, но услуги и продукты, которыми мы пользуемся, постоянно усложняются.

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

Ну и я уже молчу про всякие Tinkoff, Apple Pay, Google Now, умные дома и многое другое.

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

Такие большие команды вынуждены более ответственно подходить к выбору технологий, в том числе и UI-фреймворков. И вот вам вброс: неважно, какой UI-фреймворк выбран. И даже вредно ограничивать себя выбором одного фреймворка. Но абсолютно не вредно и даже необходимо следовать правилам использования этих фреймворков.