Пропсы прям роут кидать пробовал?

Когда его вешаешь?

Практический пример - в лайоуте хедер, в хедере кнопка помощь. Отображать только на страницах /login /signin

Я вот забыл, а не умеет ли роутер в предоставление текущего пути в первый компонент?

Оу, там последний раз были контексты…

Пропсы прям роут кидать пробовал?

Да, <Route component={GeneralLayout} show={false}> - не отработало =(

А <GeneralLayout show={false} /> пробовал?

component={<GeneralLayout show={false} />}

Я вот забыл, а не умеет ли роутер в предоставление текущего пути в первый компонент?

<Route component={GeneralLayout} show={false}> <Route path="/" component={App}/> </Route> разбить на: <Route > <GeneralLayout show={false}> <Route path="/" component={App}/> </GeneralLayout> </Route> ?

Не.

component={<GeneralLayout show={false} />}

А, понял, попробую

И это тоже навскидку, я никогда так не делал в коде.

А про передачу, я говорю, что есть такая фишка, которая позволяет посмотреть текущий путь компоненте, который в <Route component={???} /> идёт.

Но она на контексте(или hoc) сделана.

ТОгда browser.js?9520:40Uncaught Invariant Violation: The root route must render a single element

!

Попробуй сделать там stateless.

(show = false) => <Component show={show} />

Тьфу

А про передачу, я говорю, что есть такая фишка, которая позволяет посмотреть текущий путь компоненте, который в <Route component={???} /> идёт.

Да, но хотелось бы управлять этим из роутера. Я в итоге по пути сейчас смотрю. Но кажется что это неправильно. Компонента не должна отображать инфу в зависимости от пути, не ее зона

(props) => <Component {…props} show />

Во.

О! Вроде работает!

А можешь в двух словах подсказать как эта магия сработала? =)

() => < /> это state-less компоненты.

Которые сделаны как стрелочные функции.

const myStCom = ({ color }) => <div>I’m {color}!</div> myStCom - это та самая функция, ссылка, называй как хочешь. Т.е. ещё не пременена. jsx умеет определять, что у тебя такая функция - это валидный компонент. И применять соответствующие правила.

стрелочные функции - понимаю - анонимная функция с удобным синтаксисом. state-less компоненты - не понятно. У этой GeneralLayout есть state. Или внутри это как обертка над GeneralLayout разворачивается?

Иными словами const myComp (props) => <Comp {…props} />; <Route component={myComp} />

Ты не понял.

Stateless не твой GeneralLayout.

Аааа, кажись дошло

stateless это сама эта функция, которая не имеет стейта, принимает только пропсы и отдаёт любой компонент. Это как React.Component сплющеный до одного render();

Я мог описать в отдельном файле GeneralLayoutComponentWrapper = (props) => ( <GeneralLayout show={false}> ); И в роутере включить его. А так получилось это инлайн. Так?

Соответственно, если ты просто хуячишь такой компонент прямо так, component={() => {}}; реакт получает эту функцию и дёргает её.

Не забудь только развернуть пропсы в <GeneralLayout />

Чтобы не потерять инфу свыше.

Да.

Потому что есть определение функции, нет вызова. Значит реакт вызывает её внури.

Щииикарно! Понял. Про определение функции знал. В единую картинку теперь сложилось

Но в реакт роутере играться с этим особо не стоит.

Есть моё такое мнение.

Доброе утро. Подскажите пожалуйста что не правильно делаю. const essay = nextProps.essay || this.props.essay; ожидаю: если nextProps нет, то присваивать this.props

если нет nextProps - все сдохнет. Если нет nextProps.essay - все будет ок

дак nextProps undefined

от undefined не может взять essay

const essay = (nextProps) ? nextProps.essay : this.props.essay;

cost {essay}=Object.assign({},this.props,nextProps) - железобенный костыль

я думал раз nextProps undefind то должно присвоиться this.props

const essay = (nextProps) ? nextProps.essay : this.props.essay;

Мне больше этот вариант по душе)

мне тоже)

Для одного свойства такая конструкция оптимальна, для кучу - лучше чем assign/extend и так далее. В общем по старинке.

nextProps && nextProps.essay ||this.props.essay

Скорее соглушусь, но я бы не стал работать с кучей свойств в рамках componentWillReceiveProps

const essay = (nextProps || this.props).essay;

Совсем хорошо

(а тут стикеры можно?)

ваще красиво

вишенка на торт: const { essay } = (nextProps || this.props)

@localvoid

да, действительно, прелесть)

всем спасибо)

Доброе утро, уже отвечали но не могу найти где, а сам забыл. Роутинг приложения происходит в реакт-руотере, на бэке PHP, кажется laravel, как сделать чтобы при обновлении страницы не получать 404. Я понимаю что бэк должен подменить любой роут и отдать /index.html Но как это называется как объяснить бэку что нужно сделать?

ERROR: S client not available

через nginx разрулить

должен быть один какой то базовый роут типо начинающийся с /api

и все остальное nginx должен отдавать фронт

если SPA.

либо вообще по доменам разнести что лучше.

api.domain.com

а по domain.com всегда отдавать фронт/пререндер

ого а без nginx нельзя седать, типа как в ноде там как-то просто делается на любой роут (*) => /index.html

ого а без nginx нельзя седать, типа как в ноде там как-то просто делается на любой роут (*) => /index.html

Можно, но зачем?

зачем смешивать бэк и фронт?

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

да, лучше на nginx это сделать)

поэтому мы их разнесли.

самое логичное это по разным доменам разнести.

там будут разные логи обращения к сайту и к апишке тогда, например.

Есть где-то даже конфиг уже написаный.

И сборочка nginx пропатченная под rest-api, я правда не знаю, есть ли от неё особая польза.

@Misaka, есть)

@Misaka, есть)

Ты про сборочку?

Там вроде более удобное обращение с хидерами, и корсы просто устроить.

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

да, про нее

Я юзал её два года назад последний раз, почему-то подумал, что всё это в nginx уже завезли.

самое логичное это по разным доменам разнести.

типа то что нужно фронту на один домен, а все запросы для получения данных из базы на другой домен я правельно понял? и это все делается на ngnix?

Не могу ничего на этот счет сказать

yep

типа то что нужно фронту на один домен, а все запросы для получения данных из базы на другой домен я правельно понял? и это все делается на ngnix?

Запросы на получение из базы? тебя база не волнует, ты дергаешь API и получаешь данные.

Все остальное это заботы этого самого API

Да, просто вынеси api на отдельный домен для собственного удобства.

Я надеюсь у вас фронт и бэк архитектурно не связаны?

Запросы на получение из базы? тебя база не волнует, ты дергаешь API и получаешь данные.

ну да я это и имел в виду

Я надеюсь у вас фронт и бэк архитектурно не связаны?

бэк и фронт общаются через api