немного не понял, причём здесь то, откуда и чем управлять. я всего лишь утверждаю, что с современными инструментами, какой-нибудь PostsStore не будет являться property объекта window, а будет переменной, расшаренной только компонентам, которые этот store require-нули внутри анонимной функции.
вы правы, по сути, это я к словам придираюсь, что с современными возможностями (говорю про browserify и любой другой dep manager) store не обязательно будет в глобальной переменной. всё приложение чаще всего внутри анонимной функции :) но сути вопроса это не меняет, да.
забавное решение, но одна из догм react это реиспользование компонентов. а это позволительно только в ситуации когда дочерние компоненты ничего не знают о родительских (i.e. не имеют зависимостей кроме props). flux придуман не просто так.
Реакт сам исходя из состояния компонента (state) определяет, нужно ли ре-рендериться, вам не нужно форсить ре-рендер. Всё, что вам нужно — лишь описать зависимость конечного dom дерева компонента от его state. При изменении state (вызов this.setState) реакт будет смотреть, поменялось ли конечное dom дерево и, если поменялось, то найдёт минимально необходимые изменения в dom и произведёт их.
хороший способ композиции, но надо соблюдать какие-нибудь name conventions чтобы одна примесь не помешала другой (не перезаписала) что-либо выполнить в рамках контекста this. js в данном случае не плюнет никаким exception'ом.
в идеале не должно быть таких функций. функция должна возвращать только один тип данных и кидать exception в случае какого-то сбоя. прошу прощения, что не ответил на ваш вопрос — самому интересно :)
X-Cezurity-Installed: 1
Реакт сам исходя из состояния компонента (state) определяет, нужно ли ре-рендериться, вам не нужно форсить ре-рендер. Всё, что вам нужно — лишь описать зависимость конечного dom дерева компонента от его state. При изменении state (вызов this.setState) реакт будет смотреть, поменялось ли конечное dom дерево и, если поменялось, то найдёт минимально необходимые изменения в dom и произведёт их.