Антон Швец

Причем тут вообще Angular? action это аттрибут хтмл-тэга form.
action+method видит браузер и отправляет содержимое формы по указанному адресу. У вас был указан только method, поэтому браузер ничего никуда не слал, т.к. не знал адреса.

ng-pristine ng-valid это классы накладываемые Ангуляром при проверке формы. Т.к. форма у вас никак ангуляром не обрабатывается, проверки пустые и всегда пройденны, форма типа валидна. Эти классы ни на что не влияют и ничего тут не значат.

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

А почему бы не сделать так, зачем эти токены строкой?

class ScreenMediaDevicesService extends MediaDevicesService {}
class CameraMediaDevicesService extends MediaDevicesService {}

providers: [ScreenMediaDevicesService, CameraMediaDevicesService ]

export class CharacterDetailsComponent implements OnInit {
  readonly id$ = this.route.paramMap.pipe(map(paramMap => paramMap.get('id'));
  ....

Все

function filterList() {
  return filter(list=> list!= null && list.length > 0)
}

можно использовать в пайпе.
Остальное - подписка и тейкантил - не нужно

В принципе можно скостылить какого-нибудь уродца, но смысла большого не вижу.
Предпочтительней два пути.
1. Отказаться от tippy в пользу основанной на ангуляре либы.
2. Взять готовую обертку, вот angular-tippy нагуглилось. Может еще что есть, надо смотреть.

switchMap не отменяет никаких запросов. Он отписывается от потока.
А уже HttpClient так устроен, что отменяет запрос при отписке. Т.е. вызывает XMLHttpRequest.abort() когда срабатывает TearDown logic.

Если вы используете fetch, а не xhr, то его тоже можно завернуть в обсервабл. Что-то типа такого

function request(url) {
  return new Observable(observer => {
    const controller = new AbortController()
    const signal = controller.signal
    signal.addEventListener("abort", () => observer.complete());

    fetch(url, { signal  })
            .then(res => {
                observer.next(res);
                observer.complete();
              })
           .catch((err) => {
                observer.error(err);
                observer.complete();
            });

      return () => controller.abort();
  });
}

Писал по памяти, возможно это даже работает :)
При создании Observable переданный ему коллбэк возвращает логику, которая будет выполнена при отписке от него, т.е. teardown

source.pipe(
  switchMap( value => myBooleanSubject.pipe(filter(Boolean), mapTo(value)))
)
  .subscribe(value => ...)

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

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

Так же di предоставляет больше гибкости, инжектор это своего рода внешняя переменная, которую можно подменить. Что удобно при тестировании или при использовании в контексте.

ниче не понятно, чего куда.
Возможно вам поможет понимание того, как работает прокси.

При запуске дев сервера мы запускаем сервер на ноде который умеет слушать сеть по указанному порту и отдавать статические файлы, собранные вебпаком.
Далее в браузере мы отправляемся по ссылке типа "/api" которая пойдет на тот же самый хост и порт, на котором работает страничка. Этот запрос придет туда же, откуда страница взята, т.е. на наш nodejs сервер.
И там включается разбор запросов, который говорит "ага, вот адрес /api у нас должен проксироваться вот сюда" и сервер на ноде делает самостоятельно запрос по указанному в proxy конфиге адресу, передавая туда же все данные из запроса. Получив ответ, он отправит его под видом ответа от ноде-сервера, который попадет в браузер.

Зачем вообще нам прокси? Чтобы браузер считал что он никуда далеко не ходит, и OPTIONS не слал. И для того чтобы лишние пути во фронте не прописывать, изменить адреса бэкендов для разработки можно подсунув другой конфиг.

А теперь какие такие другие url? Если пойти из браузера по другому url в запущенный прокси он не попадет никогда, если не совпадет айпи адрес хоста и порт.

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

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