5 вещей, которые я бы хотел знать, когда начинал использовать Angular

    authors$: Observable<string[]>;
    unreaded$: Observable<number>;

  this.authors$.next(jokes.map(joke => joke.author));
  this.unreaded$.next(jokes.filter(joke => joke.unread).length);

export class JokesListComponent implements OnInit {
    jokes$: this.jokerService.getJokes().pipe(shareReplay());
    authors$ = this.jokes$.pipe(jokes.map(joke => joke.author));
    unread$ = this.jokes$.pipe(jokes.filter(joke => joke.unread).length);

    constructor(private jokerService: JokerService) {}
}

С местом разобрались, перейдем к самому механизму. Если мы просто указали provideIn: root в сервисе, это будет эквивалентно следующей записи в модуле:

@NgModule({
    // ... здесь другие свойства модуля
    providers: [{provide: JokerService, useClass: JokerService}],
})
export class JokesModule {}

Во все приложение — указываем provideIn: ‘root’ в самом декораторе сервиса.

Всего 18 строк со всеми красивыми отступами. А теперь попробуйте переписать этот пример на Vanilla или хотя бы на jQuery. Почти 100% у вас это займет как минимум в два раза больше места и будет не так выразительно. Здесь же вы можете просто идти глазами по строке и читать код как книгу.

private loadUnreadJokes() {
  this.showLoader(); // Ставим лоадер

  document.addEventListener("DOMContentLoaded", async () => {
    try {
      this.jokes = (await axios.get('/api/v1/jokes')).map((jokes) => // Запрашиваем шутки
        jokes.filter((joke) => joke.unread) // Фильтруем непрочитанные
      )
    } catch (e) {
      /* Обработка ошибки */
    }
    this.hideLoader(); // Скрываем лоадер вне зависимости от результата
  });
}

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

В модуль — указываем провайдер в декораторе сервиса как provideIn: JokesModule

А вот так делать почти никогда не надо. Честно говоря, я вообще не знаю, когда это можно (и имеет смысл) безопасно сделать.

Проблема в том, что это приводит к циклическим зависимостям.

Ведь зачем нам сервис? Чтобы использовать в компоненте. Стало быть, компонент будет его импортировать. Далее, сам компонент декларируется в модуле — модуль импортирует компонент. И наконец сервис импортирует этот модуль, чтобы сделать providedIn: Module.
Круг замкнулся.

Спасибо за статью, я бы еще немного зарефакторил метод loadUnreadJokes() для красоты картины

1) цепочка операторов в пайпе без вложенностей, вместо:

.pipe(
     switchMap(
          () =>
              this.http
                  .get('/api/v1/jokes') // Запрашиваем шутки
                  .pipe(map((jokes: any[]) => jokes.filter(joke => joke.unread))), // Фильтруем непрочитанные
    ),
)

это выглядит как then() в then() у промисов:

firstPromise
   .then(() => secondPromise
         .then(() => 'some value')
   );

Поэтому, по бэст практисам лучше делать цепочку без вложенностей (как минимум, меньше текста печатать):

.pipe(
      switchMap( 
          () => this.http.get('/api/v1/jokes') // Запрашиваем шутки 
      ),
      map( 
          // Фильтруем непрочитанные 
          (jokes: any[]) => jokes.filter(joke => joke.unread)
      ),
)

2) не первый раз встречаю в проектах, когда спиннер закрывают на complete() в subscribe(), и есть при этом функция-обработчик ошибок, в которой под капотом тоже происходит закрытие спиннера. С одной стороны это логично, т.к. complete() срабатывает только на успешное выполнение Если же триггерится ошибка, complete() не отрабатывает. Для двух кейсов хорошо работает оператор finalize() https://www.learnrxjs.io/operators/utility/finalize.html

.pipe(
   ... ,
   finalize(() => this.hideLoader())
)

если изменилось значение Input();
если произошло событие внутри компонента или его потомков;
если проверка была запущена вручную.

я бегло просморел и мне это показалось пересказом официальной документации