bromzh

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

Горизонтальное масштабирование в первую очередь предполагает возможность развернуть приложение на N количестве физически удаленных компьютеров. Соответственно вы не можете изменить что-то локально таким образом чтобы при этом оно продублировалось для всех процессов на всех удаленных машинах. Увы, но магии не существует. Чтобы это было возможным, требуется реализовать какой-нибудь механизм межпроцессного взаимодействия. Один из них вы уже назвали - использовать для этих целей redis.

Но ваша проблема в другом. В архитектуре. Её нет. Код выше - это спагетти-код. Поэтому вы думаете, что вам нужно это

если один процесс что-то изменяет в глобальных переменных - то это изменение должно продублироваться

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

Вообще наличие большого количества глобальных переменных - это один из показателей плохого кода.

Вы можете продолжать городить костыли и накапливать технический долг сохраняя глобальное состояние в redis или прокидывать данные из дочерних процессов в мастер-процесс и наоборот (благо в node.js есть для этого инструменты), но все же лучше начать что-то изучать из области архитектурных решений в вебе (и в javascript в частности) и смотреть код других крупных проектов и желательно не только в javascript.

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

Rx.Observable.of(value)
создает поток, который содержит одно событие с value. Это совсем не про изменения.
От шаблона, который вы хотите применить, в Angular2 уходят, в сторону реактивности.

У компонентов в Angular2 есть input-свойства, изменения которых можно отслеживать с помощью life-cycle callback, конкретно интерфейс OnChanges. Выглядеть будет примерно так:

@Component({selector: 'my-component', template: '<span>{{text}}</span>'}}
class MyComponent implements OnChanges {
  public text: string;
  @Input() changeMe: string;
  
  ngOnChanges(changes) {
    this.text = Date.now().toString();
  }
}

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

<my-component [changeMe]="someValue"></my-component>

Изменяя someValue вы изменяете input-атрибут changeMe компонента MyComponent. При каждом изменении будет срабатывать ngOnChanges.
Еще одно замечание - если в качестве значения вы передаете объект, то не надо его мутировать. Создавайте новый объект и присваивайте заново.

this.someValue = {value: 1, anotherValue: 2};
this.someValue = Object.assign({}, this.someValue, {value: 2}); // {value: 2, anotherValue: 2} // Но тут this.someValue это ссылка уже на другой объект.

Как обычно - через event.target
ng-click="testClick($event)"
И в обработчике используем

function testClick(e) {
  console.log(e.target);
}

Проблема в том, что setTimeout вызывает функцию асинхронно, и нужно уведомить ангуляр о том, что данные нужно обновить при помощи метода $scope.$apply().
Чтобы избежать этого можно использовать сервис $timeout(ссылка на доку), вместо стандартного window.setTimeout.

require('es6-promise!./about/about')('About')

что же это за чудо такое?

Попробуем разобраться. Заходим на документацию к вебпаку тык.

Т.е. эта конструкция require('es6-promise!./about/about') является вызовом загрузки модуля с помощью переопределенного лоадера, а не просто лоадера, который прописан в webpack.config.js этой сборки

loaders: [
  // See: https://github.com/s-panferov/awesome-typescript-loader
  {test: /\.ts$/, loader: 'awesome-typescript-loader', exclude: [/\.(spec|e2e)\.ts$/]},

Идем в исходники es6-promise-loader, который как раз у нас является одной из devDependencies сборки. Там можно маленько посмеяться над комментариями).
Смотрим, что тут, ага - это pitch лоадер, который делает обертку es6-promise. А внутри метод из вебпака ensure, который позволяет отделять chunk и загружать его динамически. В итоге получается примерно такой модуль (пути я порезал маленько)



Т.е. require('es6-promise!./about/about') грубо говоря превращается в функцию с параметром namespace. И вобщем когда придет время сдерживать своё обещание и возвращать модуль, то сработает следующее выражение
require("......app\\about\\about.ts")[namespace]
Require вернет нам как раз наш exports объект, который мы возвращаем в about.ts
export class About {
Смотрим на практике

А к свойству объекта мы уж по namespace сможем легко обратиться. Именно поэтому там 'About'.

Если напишете about, то не видать вам

ngOnInit() {
  console.log('hello `About` component');
}

из компонента

Миксины .make-row() и прочие я использую, только чтобы сгенерировать альтернативную сетку. Например, параллельно стандартной 12-колоночной нужно использовать 5-колоночную с увеличенным гуттером.

В остальных случаях пишу классы «row», «col-*» и прочие бутстраповские сразу в вёрстке, мне так удобнее. Потому что нужно сбалансировать сложность в HTML разметке и сложность в CSS коде. Рассмотрим крайности.

1) Если каждому блоку в разметке писать уникальный класс, а потом в CSS миксинами накидывать rows, cols и прочие свойства из фреймворка, то в HTML сложность понижается, ведь у нас на блоке всего один класс, зато в CSS сложность резко вырастает: чтобы исправить баг, верстальщику придется бегать по миксинам, анализировать зависимости, чтобы не поломалось в другом месте. При этом растет размер CSS файлов: стили для модульной сетки повторяются в разных селекторах (дублирование кода), а верстальщику для каждого нового блока приходится придумывать новое уникальное имя класса. Два внешне похожих блока имеют 90% одинакового кода и этот код повторяется два раза. Такая ситуация называется «css bloating» (css наводнение).

2) Противоположная ситуация называется «html bloating»: когда в стилях создают простейшие классы типа .colorred, .fontsize14, fontweightbold, .padding20 и т.д., а в разметку на каждый тег кидают по 10-20 таких классов, пока блок не будет выглядеть как надо. В этом случае в CSS очень низкая сложность, нет никаких конфликтов, размер файла невелик. Но если дизайн хоть чуть-чуть поменяется, верстальщику придется переписывать классы на каждом тэге. Вся сложность из стилей ушла в разметку.

В первом случае (css bloating) у нас 100% отделение внешного вида от разметки. Это вроде бы хорошо, блоки выглядят независимыми, но достигается это высокой ценой: большой риск сломать что-нибудь, внося правки в миксины; повторения в коде и в результате обязательный gzip стилей. В чистом виде можно использовать, когда нет доступа к html-разметке: один и тот же виджет используется на разных сайтах и должен выглядеть по-разному, менять ему html опасно.

Во втором случае (html bloating) внешний вид смешан с разметкой (это лишь чуть-чуть лучше, чем инлайн styles) и даже самое маленькое изменение в дизайне влечет кучу тупой работы по перестановке классов в html, но зато в css конфликтовать нечему. Пожалуй, в чистом виде может встречаться в веб-приложениях, когда верстка генерируется через js-шаблоны (тупая работа автоматизирована). Отлавливать css баги в динамичной верстке приложений очень сложно, поэтому есть смысл увеличить прочность стилей, перенеся сложность в разметку.

Оптимальный вариант — распределить сложность примерно поровну между стилями и разметкой — «multiple classes». На каждый блок вешать 3-5 классов, которые отвечают за модульную сетку, геометрию, скин этого блока. Соответствующие классы можно переиспользовать в других блоках. Классы Bootstrap'а хорошо справляются с модульной сеткой и частично с геометрией, а скины и геометрию собственных компонентов верстальщик дописывает сам.

В БЭМ баланс сложности смещен в сторону css bloating: блоки должны быть независимыми, их нельзя смешивать, можно лишь вкладывать друг в друга, а значит увеличено количество повторений css кода.

В OOCSS баланс смещен в сторону html bloating: пишут больше мелких, но переиспользуемых конструкций, имена классов придумывать сложнее, т.к. они должны быть достаточно абстрактны, но всё ещё показывать, что этот класс делает.

1) не используйте $scope в контроллере. Y031. И тем более не используйте $rootScope. И тем более не используйте и то и то.

2) если мы выполним предыдущий пункт, у нас станет на 2 зависимости контроллера меньше, и проверять нам надо только состояние контроллера. В этом случае для теста достаточно просто взять нашу функцию и подменить зависимости через моки (если используете jasmine то там уже все есть, если используете mocha то тогда рекомендую sinon)

3) Продвинутое владение: Не используйте ngController или контроллеры стэйтов/роутов (максимум для прокидывания данных из ресолверов в скоуп). Дробить все на директивы. Причем данные прокидывайте в них сверху через биндинги а не запрашивайте прямо изнутри через сервисы. Тогда тестировать в нашем UI компоненте вообще ничего не надо будет. Достаточно биндинги проверить. А модель уже покрывать обычными тестами, ну и модель наша будет полностью отделена от angular-а (сервисы типа $http и контейнер зависимостей не в счет).

p.s. примерчик простенького приложения где все три пункта есть: вот.

D3

.btn-block же?