БАЯН

Не у кого не было желания запилить connect (Redux) так чтобы там не использовался context.store?

+1

Нормально ли делать редирект на страницу со стора, после запроса?

типо запрос не сработал и перекинуть юзера на другую страницу

ктонить может сказать , что вот тут происходит ? внутри <main>

детям

передаются пропсы из app

эта штука передаётся в роуте

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

вот и возвращаем массив из детей, к которым добавляем пропсы

app

а. а дети по умолчанию в роутах это что ? https://i.imgur.com/QLBEygR.png

вот это компонент который выше

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

не через location это же делать:D

жа

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

а из роута какие чилдрены могут там лететь ?

а из роута какие чилдрены могут там лететь ?

дочерние роуты какие-нибудь?

хм. но ведь https://i.imgur.com/QLBEygR.png здесь нет никаких дочерних

хм. но ведь https://i.imgur.com/QLBEygR.png здесь нет никаких дочерних

может были) может app где-то вызывается не как корневой компонент, а как вложенный

а... пардон я перепутал

сорян. всё верно

тут роут с вложенностямми

допёр

спс!

https://i.imgur.com/rqbgLQx.png

все равно странно

что передаются пропсы из App

хотя вложенные роуты сами передадут те же пропсы

в компоненты

а вложенные компоненты не передадут

думаю поэтому App внутри передаёт своим детям эти же пропсы

Ребята, а как вы поплулейтите стейт для серверного рендеринга? Руками или у вас какой-то изоморфный фетч?

А то просто во всех примерах этот момент упускается почему-то.

вы поплулейтите стейт что это значит?))

по русски дико звучит

Ну типа наполняете state redux.

Запихать туда юзера, какие-нибудь начальные данные для рендера странички.

window["scope"].yourAppState = jsonFromApiInjectedBySSR

Проосто на клиенте этим занимается компонент, который хочет что-то от сервера. А на сервере как эти ручки подёргать я пока не знаю. Можно, конечно, прикинутся что мы такие же как и все остальные и просто через http запросы у себя всё спрашивать, но это как-то странно.

window["scope"].yourAppState = jsonFromApiInjectedBySSR

Не, ну это-то понятно. А как этот самый стейт сформировать?

Ты же сам сказал, что умеешь дергать ручки

Может быть можно через редакс стор со всеми редьюсерами формировать initialState

Думаю можно

Если вопрос про то, как работать и получать async state, то: 1. react-router-redux 2. Isomorphic Relay 3. redux-catch-promise

А редьюсеры изоморфны

Если вопрос про то, как работать и получать async state, то: 1. react-router-redux 2. Isomorphic Relay 3. redux-catch-promise

О, точно, с релейм, пожалуй, понятно как сделать.

У меня была идея делать какие-то ручки, которые отдают данные как бы не зная про HTTP. Этакий изоморфный CRUD.

@hgenru const finishStore = configureStore(merge.recursive(store.getState(), твои данные так мы соединяем initial state с твоими данными. merge это просто https://www.npmjs.com/package/merge можно и руками

это и рендеришь на сервере <Provider store={finishStore}>

Что лучше реактовые chartjs или victoryjs?

это и рендеришь на сервере <Provider store={finishStore}>

Блин, я, видимо, плохо объяснил свой вопрос. Тут проблема не в том, как эти данные запихнуть в провайдер. Тут скорее проблема в том, как эти данные сформировать.

сформировать initial state или те, которые берутся в зависимости от роута?

Если второе, то либо костыли, либо вариант описанный Денисом выше. Если первое, то два раза configureStore сделать. Первый чтобы узнать initial state, второй, чтобы смержить

кстати, а с mobx как этот вопрос решают?

сформировать initial state или те, которые берутся в зависимости от роута?

Ну так это одни и те же данные. Просто для каждого роута хотелось бы чтобы стейт был разный. Тут два варианта есть: либо самому "руками" этот стейт создавать, а потом мёржить. Но тогда могут быть проблемы с логикой компонентов (возможно). Второй, более хороший вариант — это полностью отдать логику наполнения стейта компонентам (ну они там сами типа запросили что им нужно), но тогда нужно чтобы на сервере был какой-то изоморфный иструмент получения данных (тот же релей)

Глянь как у Кости сделано

А ещё, наверное, можно сделать такой фетч, который полностью эмулирует http-запрос к себе же, но работает не через сеть.

https://github.com/kriasoft/react-app

У меня была идея делать какие-то ручки, которые отдают данные как бы не зная про HTTP. Этакий изоморфный CRUD.

Мы сделали два подхода: 1. fetch с сервера себя же, местами с ключом для доступа к данным с ограниченным доступом. 2. Функцию-wrapper, которая на сервере делает запрос к данным, а на клиенте (разумеется с DCI) шлет запрос на сервер.

ERROR: S client not available

решит твои проблемы, но я не юзал

Ага, всем спасибо. Так и думал, что какого-то магического решения нет.

Пока, наверное, поживу без серверного рендеринга. Заморочусь на другом проекте с этим.

А ещё, наверное, можно сделать такой фетч, который полностью эмулирует http-запрос к себе же, но работает не через сеть.

rum?

rum?

Это библиотека какая-то? Можно линк?

Это библиотека какая-то? Можно линк?

https://github.com/tonsky/rum

@tonsky хорошо писал про такую идею

http://tonsky.me/blog/the-web-after-tomorrow/

Только я перепутал и это datomic

Статья хорошая, потом дочитаю. Спасибо.

внезапно сегодня внеплановый БирЖС в Craft Republic в 20:00

В Мск?

Пора в Киеве делать, а то чет скучно

https://twitter.com/chicoxyzzy/status/746000050527027200

Пора в Киеве делать, а то чет скучно

сделаем обязательно

Ребят, подскажите нубу, как правильно подружить oauth и реакт?

точнее даже oauth, react и аутентификацию на апи сервере?

Ребят, подскажите нубу, как правильно подружить oauth и реакт?

А при чём тут реакт вообще? Сходил на сервер, получил куку или Beaer и хмаляешь запросами.

Что лучше реактовые chartjs или victoryjs?

recharts

Я просто в голове процесс уместить не могу весь: 1) Юзер на фронтэнде кликает на ссылку /auth/twitter 2) Сервер переадресует на твитор, твитор переадресует обратно, но с uid пользователя. 3) Сервер находит пользователя, генерирует токен А вот дальше то что? как токен обратно реакту отдать?

А при чём тут реакт вообще? Сходил на сервер, получил куку или Beaer и хмаляешь запросами.

Я просто в голове процесс уместить не могу весь: 1) Юзер на фронтэнде кликает на ссылку /auth/twitter 2) Сервер переадресует на твитор, твитор переадресует обратно, но с uid пользователя. 3) Сервер находит пользователя, генерирует токен А вот дальше то что? как токен обратно реакту отдать?

А, ты про сторонний oauth. Сервер переадресует на стринчку твиттера -> твиттер спрашивает -> если всё ок тебя переадресует на /auth/twitter/callback (или на другой урл, который ты обозначил). На сервере ты запоминаешь токен, а клиента, например, переадресуешь на главную страничку, на которой он уже кликает на "загрузить твитты" (или оно автоматом делается). Ты со свежим токеном идёшь к твиттеру и спрашиваешь у него данные.

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

Сервер отдаёт свой jwt токен, токен твиттера на клиент не уходит

Да, верно.

Если у тебя long-live токен, то, в теории, ты на твиттер больше никогда и не пойдёшь. А клиент сможет логинится через какие-нибудь другие сервисы (почта, другие соцсети)

Так делают привязку всяких аккаунтов в сервисах.

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

А куки тебе на что?

Логично, забыл про них. Спасибо