Demian Smith

Это делается через switchMap:

this.httpClient.get('/check-email').pipe(
  switchMap(emailResult => {
    if (emailResult !== exists) {
      return of(dataForNonExistingEmail);
    }
    
    return forkJoin(
      this.httpClient.get('/user-data1'),
      this.httpClient.get('/user-data2')
    );
  })
)

Как-то так:

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

В super() нужно передать суперимя и суперфамилию: super(name, surname);

Тогда всё будет супер.

В начале функции сделайте

str = str.toString()

Чтоб переданные значения приводились к строке.

Сейчас функция не работает потому что 123 - это число, а не строка.

Выучите наизусть принципы SOLID. Серьёзно. Юнит тесты пойдут как по маслу. Еще разузнайте поподробнее про separation of concerns - это тоже про разбивку на модули. В общем-то если принимать решения руководствуясь правилами SOLID и постоянно думать о separation of concerns, то дела пойдут на поправку. Только не ждите скорого озарения, пожалуйста. Придётся целенаправленно попрактиковать это годик-другой. Сужу по личному опыту, но признаюсь честно, я слегка туповат. Может у вас есть шанс осилить это дело быстрее.

Еще можно ознакомиться с тем что такое temporal coupling. Да и вообще coupling. Это про то как делать не нужно.

Еще можно наизусть выучить мантру "low in coupling and high in cohesion".

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

UPD

Забыл сказать, попробуйте писать такой код, который не стыдно выложить в npm. Если у вас получилось написать модуль, который можно подключить к любому проекту через npm, то это хороший признак того что модуль был написан по всем правилам. Да и вобще open source сильно помогает в прокачке "модульного мышления".

// Да, сначала мы делаем 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. И если магаз не новый, то возвращать обзёрвбл от магаза, а если новый, то сделать что-то там еще.

Если хотите чтоб функция counter() увеличила currentCount перед выводом, то можно делать

return ++currentCount

Хозяйке на заметку: оператор ++ считается антипаттерном и на уважающих себя проектах отключён на уровне линтера.

Тег cut - это кастомный тег. В HTML спецификации такого нет.

Возможно вас заинтересует вот эта либа https://dollarshaveclub.github.io/shave/ . Она как раз про обрезку текста и html.

Или ищите по сочетанию js truncate html

Чтобы было проще понять почему так происходит, попробуйте разобраться с понятием "присвоение по ссылке". Это базовая концепция многих языков. Без этого знания, использовать JS очень непросто.

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

$scope.manufacturers = angular.copy(manufacturers);
$scope.datadilers = angular.copy(datadiler);

Вот эти переменные в своём php.ini подкрутите по своему усмотрению

; Maximum allowed size for uploaded files.
upload_max_filesize = 40M

; Must be greater than or equal to upload_max_filesize
post_max_size = 40M

Отрицание (!) перед выражением приводит значение выражения к boolean, а затем инвертирует его. Это часто встречающаяся конструкция в JS. Это документированное и однозначное поведение.

Часто можно встретить так же двойное отрицание !! перед выражением. Двойное отрицание направлено на приведение выражения к чистому Boolean.

Отрицание (!) так же можно заменить на конструкцию типа (выражение) != true или (выражение) == false. Все эти конструкции приводят проверяемое выражение к Boolean. Такое поведение языка называется "неявное приведение".

Ниже идёт небольшое исследование (провёл только что для себя из интереса) и тема для холивара.

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

Но "хорошо" или "плохо" ли использовать отрицание перед выражение - это непростой вопрос, на который не существует однозначного ответа. Есть "эталонная" книга по лучшим практикам в JS: Javascript: The Good Parts Дугласа Крокфорда. Несмотря на многие спорные утверждения в ней, на эту книгу принято ссылаться как на истину в последней инстанции. Так вот, Крокфорд однозначно требует использование строгого равенства (операторы "===" и "!==") в пользу нестрого (операторы "==" и "!="). И многие компании с удовольствием его поддерживают и даже вводят ограничение на использование нестрогого равенства на уровне линтера. Но, к сожалению, Крокфорд ничего не сказал про оператор отрицания, который, по сути, тоже является нестрогим неравенством, явно запрещенным лучшими практиками. Раз ни Крокфорд, ни какой-либо другой влиятельный гуру ничего не сказали про отрицание, его продолжают использовать, радоваться простоте и страдать от неявных ошибок.

Лично для себя выбрал такую тактику: использую отрицание там где явно имею дело с логическими выражениями (пример привести не могу) и строгое равенство когда имею дело с функциями. В вашем случае, скорее всего, запись имела бы вид return /^[ \\t]*$/s.test(r) === false; . Почему так? Потому что функции регулярных выражений имеют свойство возвращать чёрт знает что и хочется пожалеть девелопера, который почти наверняка споткнётся читая return ! /^[ \\t]*$/s.test(r); и полезет в документацию выяснять что именно возвращает функция test.

Такие дела.

if (["Andy", "Vasjya", "Petya"].includes(name))

Полезность итераторов в том что это открытый интерфейс для любой структуры данных. Как вы уже поняли, любой класс/объект в JS может обладать интерфейсом итератора. Идея итератора в том чтобы скрыть внутреннее представление структуры данных от потребителя этих данных. Например, если вы работаете с какими-либо замысловатыми структурами данных, типа бинарных деревьев. Пользователю совсем не обязательно знать как ваш класс/объект хранит бинарное дерево. Пользователь просто его получает и проходит по всем его элементам в цикле. В дальнейшем, вы можете, при необходимости, заменить одну структуру данных на другую, не меняя самого пользователя. Например, вы можете заменить бинарное дерево на б-дерево прозрачно для самого пользователя (пользователь не будет знать что вы подменили структуры, он по прежнему получает что-то что можно проитерировать и ему этого достаточно).

Для того чтоб глубже понять суть вопроса, можно погуглить про инкапсуляцию и SOLID (в вашем случае, принцип Open/closed).