Demian Smith

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

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

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

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

UPD

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

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

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

return ++currentCount

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

Грузить файл во временную папку и при этом задавать файлу рандомное уникальное имя. Во время поста передавать связку действительное_имя - рандомное_имя.

Рандомное уникальное имя должен задавать сервер и возвращать его как ответ поста.

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

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

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

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

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

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

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

<BrowserRouter basename="/book-store">...

По классике такое делается фильтром, а не ng-repeat. Потому что с ng-repeat обработка ситуаций "пустой массив", "массив с одним элементом" и "массив с двумя элементами" (про массив с двумя элементами объяснено ниже) будут выглядеть по-уродски в шаблоне.

Вот как это выглядет

// human-friendly-concat.js
angular.module('yourModule', [])
.filter('humanFriendlyConcat', function() {
  return function(input) {
    input = input || [];
    if (input.length === 0) {
        return 'does not exist';
    }

    if (input.length === 1) {
        return input[0];
    }

   if (input.length === 2) {
        return input.join(' and ');
    }

    return input.slice(0, -1).join(', ') + ', and ' + input.slice(-1);
  };
})

// template.html
<p>
  This name <span ng-bind="name | humanFriendlyConcat"></span>.
</p>

Разница между массивом из двух элементов и массивом из больше чем двух элементов в так называемой "гарвардской запятой". Она ставится перед "and" в перечислении. Например, перечисляя страны мы напишем "Russia and Spain" для двух, но "Russia, Jamaica, and Spain" для трёх. Такие дела. https://en.wikipedia.org/wiki/Serial_comma

Чтобы было проще понять почему так происходит, попробуйте разобраться с понятием "присвоение по ссылке". Это базовая концепция многих языков. Без этого знания, использовать 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.

Такие дела.