не совсем понял, но если у тебя чистый реакт, то грубо говоря у тебя есть компонент верхнего уровня в иерархии компонентов и все манипуляции с данными делаешь в нем, а новые данные "передаешь" дочерним компонентам через проперти

вангую, что у него стейт размазан по нескольким компонентам

хотя конечно на чистом реакте можно и данные и хендлеры пробрасывать в дочерние компоненты из компонента-стейта

Тренд на ООП лет 10 назад закончился

щас бы быть трендоблядью

у меня есть хелпер utils/loginHelper.js и есть компонент в котором в функции onSubmitHandler я передаю значения полей в этот хелпер. когда приходит ответ я через promises в onSubmitHandler уже определял там ошибка пришла из хелпера (response status или timeout) или пришел ответ что бы знать что рисовать на экране. это правильно?

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

при скорее всего не очень правильной архитектуре (а кто ж её с первых трёх раз правильно делает то?)

в общем если вы обнаруживаете, что у вас нет однотипных повторений кода, то всё более-менее в порядке

щас бы быть трендоблядью

Щас бы отвечать на сообщение не прочитав историю даже на 1 сообщение вверх

Существует ли простой способ из сервером отрендеренной разметки ПЛЮС компонентов_в_виде жс получить исходный стейт который мы использовали на сервере для рендеринга? Чтобы не дублировать инитиал стейт который пришёл с сервера)

нет

так много данных?

Существует ли простой способ из сервером отрендеренной разметки ПЛЮС компонентов_в_виде жс получить исходный стейт который мы использовали на сервере для рендеринга? Чтобы не дублировать инитиал стейт который пришёл с сервера)

Редакс для этого создан

Редакс для этого создан

Для чего для этого? Вы вопрос поняли?)

так много данных?

В общем нет. Я просто пытаюсь найти бест-практики

Но Нет так нет

Объясни вопрос

смотря о каком стейте речь идет, стейт компонента или reudx

я так понял вопрос: как из представления получить состояние) нужна ф-ция, обратная state -> view, а компоненты должны рендерить стейт по вью, им приходит jsx, а они должны в render возвращать props (я угараю просто, если что, не в серьез)

да хрен проссышь, что он вообще имел ввиду)

Что является состоянием а что нет?

полуночная философия

В любом случае все что рендерит сервер не из пальца высосано

я тут начал писать wasm-loader. как же все сложно там пока что

Для бабеля?

вебпака

Васм к жс? Или наоборот?

чтобы юзать васм модули из жс

https://github.com/rsms/wasm-loader а вот это видел?

в общем если вы обнаруживаете, что у вас нет однотипных повторений кода, то всё более-менее в порядке

благодарю ) обычно я стараюсь неповторятся с кодом

да хрен проссышь, что он вообще имел ввиду)

Ну когда у нас react/redux приложение с серверным рендерингом, то у нас на клиент приезжает во первых верстка, которая отрендерилась на сервере, а во вторых стейт, который мы сформировали на сервере для рендера в виде чего-то вроде <script>window.__INITIAL_STATE__ = {someProp: 'banana'}</script>, который потом используется для инициализации стора на клиенте. Получается, данные дублируются в верстке и стейте. Человек хочет на клиенте из верстки и компонентов восстановить стейт, чтобы не дублировать данные. Но это сделать невозможно, в стейте могут быть какие-то данные, которые не используются для рендера текущей страницы, но тем не менее важны. На самом деле, тут можно упороться. Мы же серверный рендеринг для людей делаем для визуальной скорости загрузки, пока грузится js, человек уже видит готовую страницу, отрендеренную на сервере. Но если js есть в кэше браузера - в серверном рендеринге нет смысла. Мы можем отдавать для статики заголовки для кэширования, скажем, на сутки, и ставить какую-нибудь куку на сутки. На сервере при обработке запроса, если кука есть - значит js в кэше браузера - не рендерим на сервере, не дублируем данные, не нагружаем лишний раз сервер. Куки нет - рендерим на сервере, ставим куку. Для роботов, конечно, всегда рендерим

https://github.com/rsms/wasm-loader а вот это видел?

нет, чот я даже не подумал погуглить)

Теперь мы делаем не изоморфные, а квазиполиномиальные приложения :) http://people.cs.uchicago.edu/~laci/update.html

Наконец-то прогресс в этой области!

Ну когда у нас react/redux приложение с серверным рендерингом, то у нас на клиент приезжает во первых верстка, которая отрендерилась на сервере, а во вторых стейт, который мы сформировали на сервере для рендера в виде чего-то вроде <script>window.__INITIAL_STATE__ = {someProp: 'banana'}</script>, который потом используется для инициализации стора на клиенте. Получается, данные дублируются в верстке и стейте. Человек хочет на клиенте из верстки и компонентов восстановить стейт, чтобы не дублировать данные. Но это сделать невозможно, в стейте могут быть какие-то данные, которые не используются для рендера текущей страницы, но тем не менее важны. На самом деле, тут можно упороться. Мы же серверный рендеринг для людей делаем для визуальной скорости загрузки, пока грузится js, человек уже видит готовую страницу, отрендеренную на сервере. Но если js есть в кэше браузера - в серверном рендеринге нет смысла. Мы можем отдавать для статики заголовки для кэширования, скажем, на сутки, и ставить какую-нибудь куку на сутки. На сервере при обработке запроса, если кука есть - значит js в кэше браузера - не рендерим на сервере, не дублируем данные, не нагружаем лишний раз сервер. Куки нет - рендерим на сервере, ставим куку. Для роботов, конечно, всегда рендерим

как у вас тут все запущено

как пропс к toUpperCase() присобачить? <strong>{this.props.myprop}!</strong>

как пропс к toUpperCase() присобачить? <strong>{this.props.myprop}!</strong>

перед рендером можно в переменной сделать это

<strong>{this.props.myprop.toUpperCase()}!</strong> так не работает?

Ну когда у нас react/redux приложение с серверным рендерингом, то у нас на клиент приезжает во первых верстка, которая отрендерилась на сервере, а во вторых стейт, который мы сформировали на сервере для рендера в виде чего-то вроде <script>window.__INITIAL_STATE__ = {someProp: 'banana'}</script>, который потом используется для инициализации стора на клиенте. Получается, данные дублируются в верстке и стейте. Человек хочет на клиенте из верстки и компонентов восстановить стейт, чтобы не дублировать данные. Но это сделать невозможно, в стейте могут быть какие-то данные, которые не используются для рендера текущей страницы, но тем не менее важны. На самом деле, тут можно упороться. Мы же серверный рендеринг для людей делаем для визуальной скорости загрузки, пока грузится js, человек уже видит готовую страницу, отрендеренную на сервере. Но если js есть в кэше браузера - в серверном рендеринге нет смысла. Мы можем отдавать для статики заголовки для кэширования, скажем, на сутки, и ставить какую-нибудь куку на сутки. На сервере при обработке запроса, если кука есть - значит js в кэше браузера - не рендерим на сервере, не дублируем данные, не нагружаем лишний раз сервер. Куки нет - рендерим на сервере, ставим куку. Для роботов, конечно, всегда рендерим

Зачем так усложнять. Да и серверный рендеринг нормально работает

Существует ли простой способ из сервером отрендеренной разметки ПЛЮС компонентов_в_виде жс получить исходный стейт который мы использовали на сервере для рендеринга? Чтобы не дублировать инитиал стейт который пришёл с сервера)

Бред

Ну когда у нас react/redux приложение с серверным рендерингом, то у нас на клиент приезжает во первых верстка, которая отрендерилась на сервере, а во вторых стейт, который мы сформировали на сервере для рендера в виде чего-то вроде <script>window.__INITIAL_STATE__ = {someProp: 'banana'}</script>, который потом используется для инициализации стора на клиенте. Получается, данные дублируются в верстке и стейте. Человек хочет на клиенте из верстки и компонентов восстановить стейт, чтобы не дублировать данные. Но это сделать невозможно, в стейте могут быть какие-то данные, которые не используются для рендера текущей страницы, но тем не менее важны. На самом деле, тут можно упороться. Мы же серверный рендеринг для людей делаем для визуальной скорости загрузки, пока грузится js, человек уже видит готовую страницу, отрендеренную на сервере. Но если js есть в кэше браузера - в серверном рендеринге нет смысла. Мы можем отдавать для статики заголовки для кэширования, скажем, на сутки, и ставить какую-нибудь куку на сутки. На сервере при обработке запроса, если кука есть - значит js в кэше браузера - не рендерим на сервере, не дублируем данные, не нагружаем лишний раз сервер. Куки нет - рендерим на сервере, ставим куку. Для роботов, конечно, всегда рендерим

Да. Именно это имел в виду. Спасибо за объяснение этой оптимизации. Звучит круто

Бред

Ну почему бред? Я же ясно написал ниже, что искал бест практики в этой области. )

выглядит сложновато

Совсем некультурно

лучше разделить всю логику в обычном if else ?

Для начала лучше стейт не мутировать

а чем плох этот метод?

ты имеешь ввиду, то что, сначала без setState устанавливаю значения?

Да

а чем это плохо?

https://facebook.github.io/react/docs/state-and-lifecycle.html#using-state-correctly

чет я не увидил там объяснений

чет я не увидил там объяснений

> *Do Not Modify State Directly* For example, this will not re-render a component: this.state.comment = 'Hello';

Иди перечитай

В твоем случае все будет работать

Пока ты последний setState не уберешь

16.0.0-alpha на npm'е, можно пробовать файбер :)

Иди перечитай

там нет объяснений почему плохо мутировать два метода, иди перечитай

Но ведь... Гуру реакта не мутируют стейт...?

ну может у него просто такой стиль, а мутирование на производительности может не как не сказываеться

На самом деле всё дело в производительности. Реакт под капотом сравнивает старый стейт и новый. И когда ты мутируешь старый стейт, то реакт не видит изменений между старым и новым.

Че?)

Ссылку на код в студию

ERROR: S client not available

+

я часто мутирую, проблем еще не было

Ой напали. Я только объяснил как сам понял

На самом деле всё дело в производительности. Реакт под капотом сравнивает старый стейт и новый. И когда ты мутируешь старый стейт, то реакт не видит изменений между старым и новым.

ты про редукс может говоришь

там есть с этим проблемы

Я про реконсулиейшон или как его там..

Дело в том, что есть определенный метод апдейта. В доке написано почему — вызывает lifecycle методы и рендер. В принципе ничто не мешает намутировать стейт напрямую и потом вызвать forceUpdate, например, но это как-то пахнет

это даа

Производительность не пострадает?

Ща читану чо за форсапдейт

ф-ция которая обновляет компонент

Может, ведь при forceUpdate не будет проверки на shouldComponentUpdate

Но дуру не гоните, используйте setState. Реакт может поменять кишки и ваш код сломается или сами сломаете случайно (setState уберете) и потом будете искать. А еще это дети увидеть могут

Calling forceUpdate() will cause render() to be called on the component, skipping shouldComponentUpdate()

Это говнокод короч

Короче, есть общие правила написания кода на реакте, есть смысл им следовать иначе вас будут проклинать либо ваши коллеги, либо программисты которым придется это разгребать

Короче, есть общие правила написания кода на реакте, есть смысл им следовать иначе вас будут проклинать либо ваши коллеги, либо программисты которым придется это разгребать

Еще и пальцы сломать могут!

Я один не понимаю что пишет человек про кишки помененые реактом?

Ребят, стоит переходить на react-route 4? :)

или лучше подождать

Ребят, стоит переходить на react-route 4? :)

А его зарелизили?

Я один не понимаю что пишет человек про кишки помененые реактом?

Что не понятно?

Ребят, стоит переходить на react-route 4? :)

Он же шлак

Потерял нить.

Так вот она, валяется

или лучше подождать

Подожди пятого.)

〰 нить найдена!

@sunify на гитхабе пока 3 официальная, но по 4 уже доки есть и она кардинально отличается от 3

Потерял нить.

Я про то, что в реакте определен API для апдейта стейта, если ты его не используешь или используешь как Сергей, в одной из будущих версий можешь получить доп. ложку говна при апдейте.

@sunify на гитхабе пока 3 официальная, но по 4 уже доки есть и она кардинально отличается от 3

Я знаю, что отличается. Но я бы до релиза ждал, плюс они там собирались слой для обратной совместимости с 3 напилить, вроде (в тви у Джексона проскакивало, вроде)

Что не понятно?

Короч мутирование это плохо. А в кишках реаста я не лазил

Я про то, что в реакте определен API для апдейта стейта, если ты его не используешь или используешь как Сергей, в одной из будущих версий можешь получить доп. ложку говна при апдейте.

можно не обновлять)))