Спасибо, Тимур. Пока не вижу подводных камней и все прекрасно).
Вы писали: "Плохо подходит для вычислений и моделирования". А можете привести пример, насколько сложные вычисления не следует делать на Node JS?
1. Версии последнии
2. Попробовал componentWillReceiveProps, работает приемлемо. Это так задумано или хак? Похоже на костыль. Вот тут (https://github.com/spoike/refluxjs/issues/336) есть рассуждение небольшое на эту тему, но как-то тоже не впечатлило. Не может быть, что такой банальный момент упущен разработчиками - скорее всего я в упор не вижу чего-то совершенно очевидного для всех)
1. так кеш - это оочень ограниченное пространство - 4kb, если не ошибаюсь. Вероятно, вы имеете ввиду LocalStorage, верно?
2. Я, совсем недолго пытался вникнуть в этот "изоморфизм", но так и не понял, зачем он нужен, ведь преимущество реакта как раз и состоит в том, что он очень быстро на клиенте работает. Разве что, это может быть полезно для первоначальной загрузки приложения - где-то попадалась статья, в которой рассказывалось, как можно при первой загрузке передать клиенту html а все приложение тем временем в фоне подгрузить. Еще не успел попробовать. Ну еще, я так полагаю, рендер на сервере может быть полезен для безопасности, но этого я еще не успел коснуться. Можете высказаться по этому поводу? Или ссылку на статью дать, на эту тему. Можно на английском.
Благодарю вас, Дмитрий. Наверное, вы имели ввиду метод serializeArray(). Это приемлемо.
А подскажете вариант с vanilla js?)
Статья в тему habrahabr.ru/post/150594
Fluxxor - интересное решение. Я только не совсем понял, как обстаят дела с dispatcher там и зачем нужны все эти Fluxxor.Flux? фейсбучный flux же без этого живет.
liubko: Спасибо, пробую. А какой жизненный цикл у stores? Они mount'ятся при первичной загрузке приложения и перманентно живут до самого закрытия вкладки браузера? Значит стоит очищать из них ненужные данные, чтобы исключить утечку памяти? Ну и еще один вопрос) Пробовали ли вы увязать store с localStorege, чтобы при открытии новых вкладок, информация передавалась на них?
А как сохранить полученный Parse.Query?
Пример: пользователь совершает поиск по каталогу товаров, получает определенную выдачу (обращение к БД #1). Я хочу, чтобы дальше было так: пользователь жмет на любой товар, обращение к базе уже не происходит, а страница описания товара формируется из уже полученного Parse.Query. Плюс "похожие товары" оттуда же. Плюс при возвращении на прежнюю страницу, обращения к БД отсутствует, а страница формируется из данных полученных при обращении #1.
Посоветуете что нибудь?
Использование ParseReact не принципиально, просто с ним сразу получилось связаться с Parse Data, а вот API Parse напрямую штурмом взять не удалось - отсюда и вопросы
именно так и делаю - запросы через actions) все кашерно) Просто именно это к вопросу не относится, поэтому решил не усложнять.
Вопрос именно об этом - как совмещать flux с parse. ParseReact, как мне кажется, ломает эту архитектуру.
Нашел еще одно решение: https://github.com/Kemcake/React-Parse/blob/master...
Но тут опять store работает не так как задумано в flux - обращение идет напрямую к нему из компонента, никаких вам регистраций в диспетчере. Или я что-то не так понимаю?
Вы писали: "Плохо подходит для вычислений и моделирования". А можете привести пример, насколько сложные вычисления не следует делать на Node JS?