@z0s0O Есть решение, но оно всязано только с node

пробрасываеться от туда HTML

Вот это не решение? https://github.com/markfinger/python-react?files=1

тут же через node

reactRender(req.body, все дела

Ну, у вас на сервере в любом случае нода должна стоять

Ну, не в любом, но в частом.

но пользоваться django шаблонизатором будет невозможно ?

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

Почему при обновлении компанента он проподает по этому же адресу, где был до обновления?

react-router

роут обновится если компонент был перерисован

нет

не обновится?

он обновляется не только при перерисовке родительского компонента

но и когда обновляется контекст

<Router> задает контекст. <Route> его получает. NavLink === <Route><Link ...someProps /> Соответственно: <SomePureComponent> <NavLink activeClass="active" to="my_url" /> </SomePureComponent> Обновится, потому что NavLink подписан не только на обновление стейта и пропсов, но еще и на обновление контекста. В таком случае, SomePureComponent не обновляется, а NavLink - да

читайте сорцы

читайте сорцы

вот незадача, а как он узнает что обновился контекст если не будет перерисован?

вот незадача, а как он узнает что обновился контекст если не будет перерисован?

может это следует из механизмов контекста?

NavLink - stateful class component

может это следует из механизмов контекста?

это следует, что контекст не работает сквозь любой блокирующий обновления компонент, в документации даже специальная колонка про это написана

это следует, что контекст не работает сквозь любой блокирующий обновления компонент, в документации даже специальная колонка про это написана

поделитесь

react-router blocked updates

признаю, был не прав

заработало. redux (

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

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

он как скрытый prop, поэтому есть смысл закидывать его в пропы блокирующих компонентов

чтобы те обновлялись если изменился контекст

он как скрытый prop, поэтому есть смысл закидывать его в пропы блокирующих компонентов

да я бы сделал контекст реактивным :)

Ну так сделай)

я вообще считаю что контекст не подходит для роутера

Рекомпозовские методы например спокойно пробивают сквозь контекст

Ну так сделай)

что-то мне подсказывает, что это не очень просто

Очень

Шо поделать)

Рекомпозовские методы например спокойно пробивают сквозь контекст

О, слушай, хотел спросить. Я тут подумывал еффектор заюзать, но что-то зашел в исходники, а там кода больше чем самого реакта. Что это все ?

ну, банально - контекст все-таки обновляется через тот-же setState, а это уже включает в себя последующий процесс реконсиляции

другое дело, что если если тупо дергать forceUpdate у Consumer'ов при вызове setState у Provider'а - проблема будет решена

вопрос только в асинхронном рендере :D

О, слушай, хотел спросить. Я тут подумывал еффектор заюзать, но что-то зашел в исходники, а там кода больше чем самого реакта. Что это все ?

Ищу вариант самого удобного низкоуровнего примитива

Там сборка с роллапом, поэтому бандл всё равно не меняется, если код не юзался

ну мне не за бандл, а за восприятие кода

я зашел, посмотрел папки actor, atom и испугался

yarn add redux-thunk

yarn add redux-thunk

Самое главное, что пути отступления продуманы

На этих выходных разберусь, я вроде просто нашёл, чего не хватало)

https://github.com/rematch/rematch

редукс подпертый костылем

Да, видел конечно

иронично

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

Есть вероятность, что эффекты вообще не требуется никак называть, им вполне норм анонимными функциями

типа они на ивент просто сабскрайбятся ?

Ну да

Другая идея — вообще не предлагать апи. wrap будет принимать асинхронную функцию и возвращать её же

обёрнутую без смены типа

Но при этому уже с возможностью вешать наблюдателей например срабатывать при ошибках

типа такого ?

Нет, без {api}

А, или это просто аргумент в функции?

это контекст

Тогда нет

(

ERROR: S client not available

А как тогда вот такое делаеть с контекстом ?

или не делать вообще ?

Другая идея — вообще не предлагать апи. wrap будет принимать асинхронную функцию и возвращать её же

Я конкретную идею прикидывал) Уже понял, что не так)

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

А как тогда вот такое делаеть с контекстом ?

Из стора забирать

из стора в смысле store.apiClient ?

заасайнить ?

Я кстати не тебе показывал свою организацию реакт-проекта? В виде дерева

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

зачем тебе ссылка на класс

в пропсах

Не, пусть, это норм кейс

потому что я апи клиент через пропсы получаю

ввиду моей екосистемы

и того с чем работаю

ну окей

вот

мб я просто не вижу весь твой проект

ну окей

я бы просто его импортировал где надо

а как я заимпорчу

он мне явно не везде нужен

он приходит в скоупе

функции как аргумент

Я кстати не тебе показывал свою организацию реакт-проекта? В виде дерева

Из организации проекта следует организация данных — каждое поле может быть отдельным стором, ещё более простым чем редакс, но читаются только в виде комбинации

makeApi

Как в combineReducers например

создает инстанс

или как ?

а там просто обычные апи колы

Из организации проекта следует организация данных — каждое поле может быть отдельным стором, ещё более простым чем редакс, но читаются только в виде комбинации

Ввиду чего ты не прикован к виду стора который создал единожды при старте, ты берешь части которые тебе требуются и комбинируешь как надо (мы всё равно это делаем combineReducers, только без возможности собрать по другому)