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

Иногда это сам запрос к серверу не шлет в ответ никакие данные, иногда мы делаем это намеренно, вручную возвращая из какого-то метода оператор of().

Тут и кроется одна неприятная особенность.

Неважно в рабочем ли коде или в тестах, когда мы возвращаем результат of(), то внезапно получаем зависший намертво тест. Несмотря на то что коллбэк done() вызывается в правильном месте.

Например, вот такой фрагмент из юнит-теста:

fakeDependency.registerShipment.and.returnValue(of());

service.registerShipment().subscribe(() => {
   expect(clearSpy).toHaveBeenCalled();
   done();
});

Здесь метод registerShipment, изнутри возвращает метод зависимости fakeDependency.registerShipment с возвращаемым типом Observable<void>.

И этот тест повиснет на выполнении, а в конечном итоге отвалится с ошибкой таймаута. Потому что observable ничего не пришлет и соответственно не завершится.

А все потому, что оператор of() делает следующее:

Emit variable amount of values in a sequence and then emits a complete notification.

документация RxJS

То есть, оператор отправляет переменное количество значений, а затем завершается.

Но мы не передаем ничего внутри of(), соответственно, никаких значений не отправляется, Observable не завершается, и подписка на него в тесте зависает.

Поправить все это очень легко, достаточно указать undefined в скобках of() и проблема решена:

fakeDependency.registerShipment.and.returnValue(of(undefined));

service.registerShipment().subscribe(() => {
    expect(clearSpy).toHaveBeenCalled();
    done();
});

Будте аккуратны с возвращаемыми вручную значениями Observable и обязательно пишите юнит-тесты на этот код.

На этом все. А теперь пойдемте переписывать все пустые операторы of() там, где должен был быть Observable<void>.

Продолжительность: 46 минут Уровень: middle, senior

Тестовое приложение из видео – https://github.com/dreamhelg/jasmine-unit-test-async

Продолжительность: 55 минут.
Уроверь: junior, middle

Тестовое приложение из видео — https://github.com/dreamhelg/angular-components-unit-test

Проблема

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

В чем тут сложность? Конечно же с путями к ассетам. Например, если у нас в компоненте подключена картинка в качестве background-image, то, когда мы собираем приложение в тестовом режиме локально, путь к ней вполне можно указать от корня сайта:

.image {
   background-image: url(/assets/img/my-image.png);
}

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

А теперь представим, что наше фронтовое приложение в проде лежит в папке my-app. Тогда, чтобы в проде эта картинка отобразилась, путь к ней должен учитывать еще и эту папку, то есть он должен быть таким:

.image {
   background-image: url(/my-app/assets/img/my-image.png);
}

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

BaseHref to rescue

baseHref – это опция angular.json, которая позволяет указать различные пути размещения приложения, локально и на продакшене.

Следвательно, для нашего гипотетического приложения, в секции: architect –> build -> configurations -> production -> baseHref – мы указываем значение «my-app».

...
"architect": {
  "build": {
     "configurations": {
         "production": {
              "baseHref": "/my-app/",
...

А в секции serve, оставляем дефолтное значение: «/»

...
"architect": {
   "serve": {
     "options": {
          "baseHref": "/"
...    

Что же фактически происходило, когда мы указывали подобные настройки и выполняли билд приложения для публикации?

Ко всем путям в CSS добавлялось то значение, которое мы указали в опции baseHref. Если сделать билд приложения с указанными настройками (Angular <= 8), то где-то в недрах файла main.js, вы обнаружите измененные пути:

["src","/my-app/assets/my-image.png" alt=""]

При этом, локально все по-прежнему работало с путями от корня:

["src","/assets/my-image.png" alt=""]

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

Breaking changes и временное решение

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

К счастью дело было не вполне безнадежное, и если в том же angular.json опцию: architect –> build -> configurations -> production -> rebaseRootRelativeCssUrls установить в true – проблема решалась.

...
 "architect": {
   "build": {
     "configurations": {
        "production": {
           "rebaseRootRelativeCssUrls": true,
...

Опять беда

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

«Change root relative URLs in stylesheets to include base HREF and deploy URL. Use only for compatibility and transition. The behavior of this option is non-standard and will be removed in the next major release.»

Или проще говоря, праздник на вашей улице ненадолго, опцию удалят в следующем мажорном релизе. Сказано – сделано, в версии 11 опцию выпилили, ничего не оставив взамен.

Точнее так: взамен оставили рекомендацию всегда и везде в CSS использовать относительные пути.  Что конечно хорошо и правильно, если б не одна проблема.

Относительные пути нельзя использовать во вложенных компонентах, в режиме serve, приложение просто не соберется, выдав ошибку:

Failed to compile.
./src/app/inner/inner.component.less
Module Error (from ./node_modules/postcss-loader/src/index.js):
(Emitted value instead of an instance of Error) CssSyntaxError: \projects\path-fix\src\app\inner\inner.component.less:2:18: Can't resolve 'assets/my-image.png' in 'I:\projects\path-fix\src\app\inner'
  1 | .someclass {
> 2 |   background: url("assets/my-image.png");

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

А вложенные компоненты в angular, это все, кроме родительского. Ну, то есть можно конечно писать нечто в CSS  «/../../../../../assest/my-image.png», но кому в здравом уме, это понравится делать?

Особенно, когда у вас давно написанное приложение, с матрешкой из овер 9000 компонентов, которые раньше прекрасно работали с коротким путем /assets.

Решение

К счастью есть решение, максимально простое и удобное, работающее с LESS. Достаточно в пути к ассетам, указать карет ^

backgorund-image: url("^assets/my-image.png")

Теперь в режиме serve – приложение соберется без проблем, потому что при билде приложения, postCSS-плагин этот символ просто игнорирует, возвращая указанный путь.

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

Проверено на Angular 11.1.1
Источник решения

Проблема

Прежде чем кидаться решать проблему – ее нужно осознать. С чего бы начать? Все зависит от поставленной вам задачи. Например: если требуется, чтобы инпут расширялся в ширину – это одна проблема. Если нужно чтобы он рос в высоту – это проблема другая. А если нужно чтобы сразу во все стороны, тут можно начинать страдать, дело-то непростое.

Главная проблема состоит в том, что элементы ввода не умеют растягиваться по своему содержимому. Это очень досадно и конечно мир был бы лучше, если бы они умели, но увы. Более того, однострочное текстовое поле – input вообще бессмысленно растягивать в высоту, содержимое все равно не ляжет в несколько строк, так уж он устроен. Поэтому дальше начинаются любимые фронтендерами лайфхаки.

Варианты решения

Самый первый, приходящий в топ выдачи гугла – это просто взять и заменить инпут на div с атрибутом contenteditable  – и вот оно, проблема решена! Вот вам адаптивный по высоте/ширине див и редактируемое содержимое. Но если для вас (как и для меня) это не вариант, то смотрим дальше.

Следующий вариант не назовешь слишком изящным, но работающий вот что важно. Основан на том, что где-то позади самого текстового поля мы прячем невидимый блок, куда дублируем содержимое текстового поля при любом изменении. Блок изменяет свои размеры по содержимому, мы вычисляем их с помощью ява-скрипта и присваиваем текстовому полю. Если вас не смущает дополнительный мусор на странице в виде такого вот костыля – смело можно брать на вооружение.

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

Выбираем правильный инпут

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

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

Тут следует обратить внимание на три обязательных параметра, без которых ничего не сработает: box-sizing, height, min-height.

box-sizing: border-box

В обязательном порядке box-sizing должен быть в значении border-box, чтобы когда вы добавите паддинг в текстовом поле, а вы его обязательно добавите, он не увеличивал дополнительно высоту или ширину текстового поля, а откладывался бы вовнутрь.

height и min-height (width и min-width)

Тут все просто: height – чтобы изначально textarea выглядела бы как input. min-height – чтобы при сбросе значения высоты текстовое поле не прыгало, а оставалось минимально необходимого размера. Все это справедливо и для свойств width и min-width.

Немного теории

Принцип действия очень простой. У каждого DOM-элемента, который может содержать контент, есть readonly-свойство scrollHeight (scrollWidth) которое и содержит так нужную нам, истинную высоту элемента, такую, при которой все содержимое этого элемента будет видно пользователю. Все, что нам требуется – при изменении текстового поля, вычислять значение scrollHeight/scrollWidth и присваивать его текстовому полю.

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

Немного vanilla JS-практики

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

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

Ну и давайте для ширины тоже сделаем. Все то же самое, только тут уже берем input, и высоту меняем на ширину.

Результат

Вот такие поля получились. Несложно и недолго.

Адаптивный инпут, растущий в высоту:

Адаптивный инпут, растущий в ширину:

Angular Директива

Для тех, кто дочитал аж до сюда – бонус. Если лень самостоятельно упаковать все это в директиву, я уже все сделала за вас, смотрите:

Здесь используется уже знакомый вам декоратор @HostListener. А если еще не знакомый, то обязательно почитайте статью об этом.

Пример использования:

Да, можно обойтись одним элементом – textarea. Просто, если нужна адаптивность в ширину – добавим CSS-свойство white-space: nowrap – запрет на перенос строк.

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

Посмотреть как работает на stackblitz.com

Приходилось вам сталкиваться с подобной задачей? Как решали?

Продолжительность: 27 минут
Уровень: Middle, Senior

Тестовое приложение из видео

Пользоваться просто и легко, если вы хотя бы раз видели функции-декораторы в Angular. Если не видели, тоже ничего сложного:

@HostListener('eventName', [args])

Первый строковый аргумент – название события DOM, которое мы собираемся слушать и как-то реагировать на его появление. Давно знакомые и родные: click, focus, blur, keypress и т.д.
Второе – необязательный массив аргументов, которые можно передать функции-обработчику, при возникновении события.

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

Например, мы хотим обрабатывать событие click у компонента, выводя алерт с сообщением. Пример учебный и выполнен профессионалами, пожалуйста не повторяйте его на живых людях!

@HostListener('click')
onClick(): void {
  alert('хуяк!');
}

Как видите, максимально просто и быстро. Стоит упомянуть, что текущее событие будет срабатывать только по клику внутри компонента. И если компонент у вас небольшой по размеру, клик за его пределами обработан не будет.

Что если, внутри компонента нам нужно повесить обработчик события, который будет срабатывать глобально, а не только в текущем компоненте? Тоже достаточно просто. Перед названием события, добавляете: “window:” или “document:” и вуаля! Событие слушается глобально по всей странице:

@HostListener('document:click')
onClick(): void {
alert('хуяк!');
}

Давайте представим другую ситуацию, у нас есть компонент бокового меню, которое должно закрываться по клику снаружи компонента. Для этого как раз и понадобится параметр $event.target, в качестве второго аргумента.

  @HostListener("document:click", ["$event.target"])
  onClick(element: Element): void {
    if (!element.closest(".user-menu")) this.isOpen = false;
  }

1. Вешаем глобальный обработчик события клик на документ внутри компонента – document:click
2. Вводим параметр $event.target – содержащий dom-элемент, по которому случился клик
3. Определяем родителя этого элемента – и если это не наш компонент меню – закрываем меню
4. Профит!

Если нужно обрабатывать нажатие определенной клавиши – нет ничего проще. Забудьте про проверку keyCode, она в прошлом.

@HostListener('keydown.enter')
onEnterClick(): void {
  alert('нажата клавиша Enter!');
}

Да, вам не показалось. Просто точка и название клавиши.

А если нужна обработка комбинации клавиш? Ни слова больше!

@HostListener('document:keydown.control.r', ['$event'])
onControlPClick(event: KeyboardEvent): void {
event.preventDefault();
alert('Не пытайтесь перезагрузить страницу!');
}

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

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

Что еще нужно знать? Обработчик, навешенный через @HostListener будет жить, пока жив его компонент. Способа его корректно удалить не задекларировано, поэтому вы сильно-то не увлекайтесь. И в случае чего, используете контролируемый способ – старый добрый addEventListener.

Спасибо за внимание – лайк, шер, репост.

Учебный пример с работающими событиями.

Тестовое приложение из видео на гитхабе

Соответственно, если мы получаем с сервера дату/время в UTC, мы должны конвертировать ее с учетом нашего локального часового пояса.
Для этого в яваскрипте есть разные способы.

Самый простой, это создать объект даты из полученной строки, а затем вызвать метод toString()

const date = new Date('2020-09-13T21:11:32+0000');
date.toString(); // выведет Mon Sep 14 2020 00:11:32 GMT+0300 (Moscow Standard Time)

Или можно вот так, например, получив разницу во времени:

const date = new Date('2020-09-13T21:11:32+0000');
const difference = date.getTimezoneOffset();
const localDate = new Date(date.getTime() + difference).toString(); // так же выведет Mon Sep 14 2020 00:11:32 GMT+0300 (Moscow Standard Time)

Но прежде, чем начинать что-то куда-то конвертировать, присмотритесь внимательно к дате, которая пришла с сервера. Вполне может оказаться, что дата возвращается в формате ISO 8601 – что есть международный формат форматирования даты и времени. Он, в том числе, указывает часовой сдвиг либо говорит нам о том, что дата в UTC.

Как это выглядит?

1994-11-05T08:15:30-05:00 // -5 часов по Гринвичу
1994-11-05T13:15:30Z // буква Z в конце означает 0 часов по Гринвичу

И вот если в вашей дате, пришедшей с сервера, обнаруживается буква Z на конце или часовой сдвиг, как в примере выше, никакая конвертация даты на клиенте не нужна!

Достаточно создать объект даты из полученной строки:

const localDate = new Date('2020-08-31T12:27:43Z'); //Mon Aug 31 2020 15:27:43 GMT+0300 (Moscow Standard Time)

localDate уже и будет содержать верную дату, с учетом вашего часового пояса. Создание new Date() из строки формата ISO 8601 все сделает за вас.

Возможно это сэкономит вам немного времени.

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

В package.json, в списке пакетов, следующий синтаксис:

~ только патч-версия пакета.
То есть, если указано “~1.5.0”, это значит можно обновиться например до “1.5.1”, но до “1.6.0” уже нельзя.

^ только минорные версии и патчи.
Пишем: “^1.5.0”, можем обновиться до “1.5.1” или “1.6.0”. До “2.0.0” уже нельзя.

* любые апдейты пакета: мажор, минор и патч

>, >= любые апдейты пакета, выше или такой же версии

<, <= любые апдейты пакета, ниже или указанной версии

latest – самую свежую версию пакета

Просто номер версии пакета – в точности указанную версию пакета и никакую другую