Demian Smith

TBody в таком случае должен стать дженериком.

type TUserInfo = {
   id: num,
   readonly fname: string,
   readonly lname: string
}

type TBody<T> = {
   success: boolean,
   user?: T
}

И далее по ходу

const fechUserInfo = (): Promise<TBody<TUserInfo>> => {
  return fetch().then(response => response.json()).then((user: TUserInfo) => ({success: true, user}));
}

В таком случае вам понадобится создать *.d.ts файл самостоятельно и подключить его в tsconfig.json

Вот тут подробнее https://www.typescriptlang.org/docs/handbook/2/typ...

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

Я бы на вашем месте сделал так называемую type guard функцию, в которой убеждался бы что таргет действительно элемент дом. Все элементы дом наследуются от объекта HTMLElement. Это можно использовать для проверки:

const isHtmlElement = (v: any): v is HTMLElement => v instanceof HTMLElement;

далее мы можем использовать эту функцию для проверки нашего таргета:

const eventHandler = (e: Event) => {
  if (!isHtmlElement(e.target)) {
    return;
  }
  // Вот здесь мы можем смело работать с таргетом как с ДОМ Элементом
  e.target.classList.toggle('active');
}

УПД

Еще информация к размышлению.

Финальный код, сгенерированный тайпскриптом, не содержит информации о типах. В рантайме нельзя узнать тип интерфейса, выполнив, например `peremennaya instanceof VashInterfeis`. Но всегда можно создать type guard функию, которая будет определять что объект именно нужного типа по каким-то косвенным признакам (например по наличию определённых полей в объекте). Так как код guard функции невозможно провертить статическим анализватором, тайпскрипт не может гарантировать того что ваша guard фунция верна и не пропускает всё подряд. Поэтому, хорошим тоном является писать такой код, который не нуждается в подобных проверках. Это возможно. Код при таком подходе становится стройнее и легче для осмысления.

Переменные в сервисах мало чем отличаются от глобальных переменных. По сути - это и есть глобальные переменные со всеми вытекающими последствиями. Например, переменная сервиса может быть неожиданно изменена во время какого-нибудь асинхронного действия. Что приведёт к неожиданным/нежелательным сайд-эффектам. Современные ООП парадигмы (например, ДДД), напрямую говорят о том что сервисы не должны хранить состояние.

Обзёрвер не выполняет никакой работы до тех пор пока не была вызвана функция subscribe. Сам процесс вызова subscribe называется "подписка". Как только функция subscribe была вызвана (т.е. на обзёрвер подписались) - дело пошло и обзёрвер начал свою работу. До тех пор пока subscribe не вызван, обзёрвер - это просто рецепт того что нужно делать когда прийдут данные.

Сама функция subscribe возвращает деструктор. Деструктор - это что-то что нужно выполнить, если вдруг понадобилось остановить обсёрвер (например прервать HttpConnection).

Код ниже возвращает функцию-деструктор

let get = () => {
    return this.http.get(url)
        .subscribe((response: ResponseObject) => {...});
}

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

Поэтому, универсальный рецепт - это никогда не подписываться в самих сервисах. Если вам нужно что-то проделать с данными из обзёрвера в самом сервисе, то можно воcпользоваться оператором tap:

let get = () => {
    return this.http.get(url)
        .pipe(
          tap((response: ResponseObject) => {...})
        );
}

// а дальше где-то в коде сделать

service.get().subscribe((response: ResponseObject) => {...})

Более того, вы можете делать tap (и любой друго pipe оператор) пока у вас есть обзёрвбл:

service.get()
  .pipe(
    tap(...),
    map(...),
    whatever(...),
  ).subscribe((response: ResponseObject) => {...})

Вам будет проще понять механизм работы обзёрвблов, если вы будите рассматривать обзёрвбл как функцию, а метод subscribe как способ выполнить эту функцию.

Учитывая вышесказанное:

const observable = service.get();
observable.subscribe((result) => {...}); //выполнит запрос к серверу
observable.subscribe((result) => {...}); //выполнит запрос к серверу еще раз
// запрос к серверу будет инициироваться каждый раз когда будет выполняться функция subscribe

Как-то так:

this.httpClient.request(...).pipe(
  repeatWhen(complete => complete.pipe(delay(20000))
).subscribe(result => console.log(result))

Потому что this.request(id) возвращает или faceProductList[][] или faceProductList[].

А array.filter(({title}) => title.includes(valueSearch)) однозначно обрабатывает данные как faceProductList[] и не учитывает faceProductList[][].

Можно сделать

public async handler(id: string, valueSearch: string) { 
        await this.request(id)
          .then((array: faceProductList[]) => { 
            ...

для того чтоб ошибка ушла.

Но проблема неоднозначности останется и однажды вылезет в виде бага.

На вашем месте я бы сделал как-то так:

public async request(id: string): Promise<faceProductList[][]> {
  const res = await fetch(`${this.url}${id}`);
  const resArr: faceProductList[] | faceProductList[][]  = await res.json();
  if (resArr.length === 0) {
    return resArr;
  }

  if (Array.isArray(resArr[0])) {
    return resArr;
  }

  return [resArr];
}

не могу гарантировать что это заработает сразу, возможно прийдётся подпилить. Но направление мысли должно быть понятным.

Плюс этого подхода - вы будете избавлены от проверки на "а что именно вернула request, faceProductList[] или faceProductList[][] ?" при каждом чихе.

Все эти знания принесут пользу несомненно, но они не критичны. Ангуляр весьма органично дружит с тайпскриптом и не требует никакой экзотики. С перечисленными темами можно ознакомиться по ходу пьесы если будет интересно. К вашему списку можно добавтьб дженерики (Generics), они часто используются в ангуляре и желательно понимать что это такое.

Что нереально важно для комфортной работы с ангуляром, так это RxJS. Rx представляет декларативный подход к программированию и на первых парах полностью выносит мозг. Правда потом не знаешь как без него жить дальше. Непонимание RxJS - это гарантия провала и обиды на фреймворк. Вот это видео может немного пролить свет https://www.youtube.com/watch?v=3LKMwkuK0ZE . Не теряйте времени зря и разберитесь в теме заранее, чтоб потом не жалеть о напрасно написанном коде.

Еще, как и большинство фреймворков, ангуляр не поставляет менеджер состояния по умолчанию. Неокрепшие умы хранят глобальное состояние прямо в сервисах. Что мало чем отличается от использования глобальных переменных. Но для глобальных состояний существует NgRx. Это Redux на стероидах. Опять же, прийдётся с этим разобраться для того чтоб через год не оказаться у разбитого корыта.

Можно. Добавьте в конфиг tslint'a `"defaultSeverity": "warning"`.

// Да, сначала мы делаем map, потому что он делается полюбому:

let doSomething$ = this.myApi.getSomething(id).pipe(
  map(tags => ({ ...updatedShop, tags }))
)

// А затем мы делаем mergeMap если понадобится:

if (shop.isNew) {
  doSomething$ = doSomething$.pipe(
    mergeMap(() =>
                  this.myApi.addTags(updatedShop.id, shop.tags).pipe(
                      map(() => {
                          return {
                              ...updatedShop,
                              tags: shop.tags
                          };
                      })
                  )
              )
  )
}

// ну и затем подписываемся на это дело чтоб оно начало работать:

doSomething$.subscribe();

Вам будет значительно легче понять RxJS после просмотра вот этого видео: https://www.youtube.com/watch?v=3LKMwkuK0ZE Оно слега отстало от времени (операторы к обозревателю теперь добавляются через функцию pipe()), но сами принципы, описанные в видео, никуда не делись.

UPD

Если код выше повергает вас в тоску, то можно сделать так:

this.myApi.getSomething(id).pipe(
  map(tags => ({ ...updatedShop, tags })),
  mergeMap((tags) => {
    if (!shop.isNew) {
      return of(tags);
    }
   return this.myApi.addTags(updatedShop.id, shop.tags).pipe(
                      map(() => {
                          return {
                              ...updatedShop,
                              tags: shop.tags
                          };
                      })
                  )
  }),
)

Имеется ввиду, что можно иф вынести в сам mergeMap. И если магаз не новый, то возвращать обзёрвбл от магаза, а если новый, то сделать что-то там еще.

Не нужно result.json()

Данные уже там.

result.data достаточно.

(при условии что вы используете Angular > 4.3)