Дмитрий Лузанов

Вы все неправильно поняли. Обращайтесь в такие моменты к спецификациям.
1. Если вы передаете NaN, нативная функция ToNumber возвращает NaN, затем ToInteger заменяет значение на +0.
2. Если вы передаете null, ToNumber заменяет его на +0.
3. Если передаете undefined первым аргументом, его сначала ToNumber заменяет на NaN, затем ToInteger на +0.
4. Если вы передаете undefined вторым аргументом, алгоритм использует вместо него длину массива.

Для этого используется environment файл.

Исчерпывающее руководство

Из перечисленных (через запятую - перечисление, через точку - вещественные числа) выражений в круглых скобках возвращается последнее.
Отсюда и (1, 5-1) === 4

Есть ли причины так не делать?

Уместнее спросить - есть ли причины так делать? Мне таковые не известны. Если хотите повторно выполнить какой-то код из хука в произвольный момент - вынесите его в отдельный метод, и вызывайте этот метод.

А то, что вы показали в качестве примера, при назначении рейтинга дёргаете ngOnInit - это что же, компонент повторно инициализируется при изменении рейтинга? Нет, это не правда. Зачем же тогда вводить в заблуждение себя и тех людей, которые будут читать ваш код? Не просто же так переменным, методам, классам и т.д. дают человекопонятные имена, описывающие их назначение.

Вешаю на него сеттер...

Не-а, не на него. Созданное ранее свойство вы перетёрли вызовом defineProperty, кроме того, вы не определяете геттер - отсюда и undefined.

Можно добавить геттер, само же значение сделать локальной переменной конструктора:

function test(m) {
  let money = m;

  Object.defineProperty(this, 'money', {
    get() {
      return money;
    },
    set(val) {
      alert(`Значение свойства money меняется с ${money} на ${val}`);
      money = val;
    },
  });
}

Или можно воспользоваться Proxy:

function test(m) {
  this.money = m;

  return new Proxy(this, {
    set(target, prop, val) {
      alert(`Значение свойства ${prop} меняется с ${target[prop]} на ${val}`);
      target[prop] = val;
      return true;
    },
  });
}

item - переменная, переданная по значению.
arr - массив, переданный по ссылке.

не знаю зачем вам это безумие, но примерно как-то так

function F() {
  return F;
}
new F() === F // true

Геттеры и сеттеры.
Только если ваша переменная является свойством объекта, тогда вы можете задать свою set-функцию, которая не требует от остальной части скрипта какой-то модификации.
На глобальной переменной my_var делается это так:

Object.defineProperty(window /*- объект, где располагается свойство */, "my_var" /* - свойство, которое нужно опекать */,
{
  get: function() // сторожим чтение значения
  {
    alert('Кто-то прочилал my_var!');
  },
  set: function(newValue) // сторожим запись значения
  {
    alert('Кто-то записал my_var! Новое значение: ' + newValue);
  }
});
my_var = 123456;  // пробуем записать что-то
you_var = my_var; // пробуем извлечь значение

'user.name'.split('.').reduce((obj, key) => obj[key], filter_params)

BabelEdit

Использую vscode+webpack+pug+scss+бэм. Из физических инструментов, основной моник: lg ultrawide 29um69g, рядом прикручен моник от ноутбука повешенный вертикально, подключенный через универсальный скаллер.

0) Запускаю Spotify :-)

1) Произвожу установку всех необходимых модулей для сборки. В моем случае у меня набор конфигураций для webpack (отдельные файлы для pug, scss, static и.т.д., выбираю что нужно).

2) Запускаю avocode, загружаю в него макет. Определяю в нем переменные (в то же время записываю их, чтобы сразу кинуть в scss файл) для цветов, размеров шрифтов и.т.д. чтобы при получении кусочков кода из него, он сразу расставлял переменные.

3) Запускаю VS Code, открываю нужную папку.

4) Пишу размету на Pug. Пишу с БЭМ, если встречаю повторяющийся блок, то открываю файл _mixins.pug, в который пишу миксины для повторяющихся блоков, например товаров, пунктов меню, каких-то блоков и.т.д. Pug умеет делать циклы, это ускоряет сильно.

5) Когда HTML готов, начинаю делать каркас. Если дизайн сделан по сетке, определяю контейнеры, колонки, строки в свои классы (не пишу в html тучи классов аля col-md-6, а пишу в SCSS инклуды в нужные мне блоки, типа @include make-col(2) и.т.д.).

6) Экспортирую картинки из Avocode. Очень делается просто, указываю папку и просто кликаю экспорт и ввожу название файла и расширения. Преимущественно для иконок использую svg, если нет svg, то ищу эту иконку в интернете (дизайнеры редко рисуют иконки сами, но зато любят вставлять их не в векторе). Если иконка простая, могу сам ее в inkscape обвести, ну и если нет, то экспортирую png в 2х размере (благо авокод это позволяет, если конечно дизайнер не вставил в исходном маленьком размере). Когда есть контакт с дизайнером, трясу его, ибо растр это плохо для иконок.

7) Пишу стили блоков из страницы. На этом этапе можно на втором монике параллельно смотреть футураму или
Арчера :-) Но чаще на широком монике слева браузер, справа VS Code, а на втором монике Avocode (может меняться местами с браузером). Мысленно нарезаю страницу на блоки. Для каждого блока (БЭМ) создаю отдельный scss файл (кто-то даже для элемента создает, но мне лень), из него сразу выписываю все селекторы. Иногда могу сначала выписать все селекторы со страницы (но так лучше не делать, т.к. во время работы может потребоваться изменить что-то в разметке), но чаще для одного блока выполняю этот пункт и за ним сразу выполняю пункт 8, потом для нового блока опять 7 и 8 и.т.д.

8) Пишу css код вместе с Avocode, у него беру нужные мне параметры (а он уже подставил в них переменные), и вставляю в мой код. И параллельно сверяю со скрином макета используя вот это расширение https://chrome.google.com/webstore/detail/perfectp...

9) Пишу адаптив. Я не могу привыкнуть к методологии mobile-first, поэтому пишу всегда сначала полную версию сайта. Я понимаю, что это чревато всякими проблемами и это типа не модно, но мне норм.

10) Медиа-запросы пишу прямо в блоках, для каждого блока/элемента/модификатора может быть отдельный медиа-запрос. Но для начала определяю breakpoint'ы для разных экранов (чтобы их не было сотни разных), если использую Bootstrap, то беру его breakpoint'ы.

11) Добавляю анимашки. Даже если заказчик не просил отдельно (и если не указал отдельно, что нельзя), он все равно будет доволен, а с animate.css+onscreen.js это вообще работа 10 минут. Сложные анимации обговариваю отдельно, чтобы не сделать ненужную работу.

11) Все снова сверяю, пишу скрипты где надо. Для слайдеров в 99% случаев подходит slick (с доработками конечно, но там хорошее API), для других случаев могу написать свой.

12) Сдаю заказчику и жду ответа сидя на тостере/пикабу.

Это чисто мой опыт, опыт фрилансера, не знаю, как делают другие и не могу на 100% утверждать что это 100% правильный способ. Я так и не смог заставить свой конфиг webpack правильно вставлять спрайты svg.
Надеюсь чем-то поможет мой ответ.