Типа ленивый хочешь сказать?)

Ну я профита не вижу))) зачем лишние телодвижения делать

Да вопрос не код писать, а комментарии))

Ну т.е. я пока услышал только аргумент, что бы между контекстами (языка) не переключаться

Индусам и Китайцам потом твои комменты читать будет сложно

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

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

Если бы код писался на русском, имело бы смысл, имхо)

@sergeysova помоги =D Я помню, примерно, прошлым летом, ты ругался на коменты на русском, а сейчас как?

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

+

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

Сверхразум))

Vlad Nechyporchuk: Ребят подскажите. У меня есть запрос в базу данных по ид (graphQl+Apollo). Как мне реализовать так, чтобы при переходе на определенный линк (допустим customer/description/244/adresse(где 244 ид елемента)) загружались данные именно по этому ид? Заранее спасибо

Vlad Nechyporchuk: Ребят подскажите. У меня есть запрос в базу данных по ид (graphQl+Apollo). Как мне реализовать так, чтобы при переходе на определенный линк (допустим customer/description/244/adresse(где 244 ид елемента)) загружались данные именно по этому ид? Заранее спасибо

props.match.params

плюс https://github.com/bkonkle/ignore-styles

Спасибо вам за подсказку, это то что было нужно

Всем привет, вопрос по производительности. Имеет ли смысл в mapStateToProps указывать конкретные свойства из стора? Пример: Обычная реализация: { user: state.user } Конкретные свойства: { userFetching: state.user.isFetching, userFetched: state.user.isFetched, } Есть ли разница в производительности, учитывая, что в state.user еще несколько свойств. В моем понимании, если использовать первый вариант, компонент будет пытаться обновиться, если изменятся другие свойства user, соответственно будут дополнительные вызовы методов из цикла компонента, в котором я уже могу отменить рендер.

Всем привет, вопрос по производительности. Имеет ли смысл в mapStateToProps указывать конкретные свойства из стора? Пример: Обычная реализация: { user: state.user } Конкретные свойства: { userFetching: state.user.isFetching, userFetched: state.user.isFetched, } Есть ли разница в производительности, учитывая, что в state.user еще несколько свойств. В моем понимании, если использовать первый вариант, компонент будет пытаться обновиться, если изменятся другие свойства user, соответственно будут дополнительные вызовы методов из цикла компонента, в котором я уже могу отменить рендер.

Для таких кексов подойдёт мемоизация, а компонент обновляется если меняется пропсы, следовательно пробрасывай isFetching , isFetched в компоненты как пропсы

Для таких кексов подойдёт мемоизация, а компонент обновляется если меняется пропсы, следовательно пробрасывай isFetching , isFetched в компоненты как пропсы

Спс

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

Есть готовый модуль на реакт "Уже уходишь?"?

приветы

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

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

Весь стейт кидаешь ?

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

и как правильно хранить такие данные

Привет. Помогите решить задачу. Есть state.cart.book = [ book, book, book ] При добавлении туда добавляется книга, но не как book.count (то есть, количество купленных), а просто объектами

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

так, а в чем проблема, передавай в state объект

Как структурами данных преобразовать эти повторящиеся объекты ( к тому же, через reselect, каждый раз разные ) в объекты с каунтерами

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

а что у тебя повторяется?

у книги должен быть уникальный id

но вот ты одну книгу в двух экземплярах захотел купить

дважды кликнул на купить

кидаешь объект { id: 123, count: 1}

она добавилась в cart = [ book1, book1 ]

данные с бекенда, допустим, там нет count

при клике проверяешь есть ли такой id в стэйте, если есть, тогда count++, если нет, то вставляешь объект с новым айдишником

О_о

это вопрос не по Реакту, тебе, наверное, лучше в чат по javascript

ребят у когото была такая трабла что если запускать сайт через вебпак а-ля npm start и если залить сбилженые файлы, то в итоге имеем разный роутинг ? https://prnt.sc/jmmqk0

https://prnt.sc/jmmr70

в случае отдельного сервера, будет /build/ а если через вебпак - /build

что за фигня, кто в курсе )

@webpack_ru

что за фигня, кто в курсе )

больше чем сказать очевидное "затесался лишний слеш в конфигах где-то, в basePath" сложновато)

как лучше всего изменять стиль body в зависимости от роута? Пока что ничего лучше чем с помощью React Helmet прокидывать стиль не придумал

public toggle(name) { this.setState({ ...this.state, [name]: !this.state[name], }); }

эта конструкция не имеет смысла если что

как лучше всего изменять стиль body в зависимости от роута? Пока что ничего лучше чем с помощью React Helmet прокидывать стиль не придумал

А оно точно нужно именно так?) ну если да, то почему бы не работать напрямую через document.body...

А оно точно нужно именно так?) ну если да, то почему бы не работать напрямую через document.body...

ну это ведь чат по Реакту а не по JS )

ну это ведь чат по Реакту а не по JS )

Ой, точно, пардонте))

он хотел сказать, что это чат по реакту, а не по реакт-роутеру :))

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

видимо так....

я к тому что может человеку нужно готове решение с описанным АПИ

и он не хочет это решение намеренно на чистом JS писать

А оно точно нужно именно так?) ну если да, то почему бы не работать напрямую через document.body...

ну helmet я и так использую, поэтому и решил через него стили

как лучше всего изменять стиль body в зависимости от роута? Пока что ничего лучше чем с помощью React Helmet прокидывать стиль не придумал

если у тебя router в redux следы оставляет, то тупо можешь в саге повесить yield takeEvery('@@router/LOCATION_CHANGE', router) а далее типа function* router({ payload }) { switch (payload.pathname) { case '/page1': document.body.style.backgroundColor = 'red' ...

это если 4-й роутер

если у тебя router в redux следы оставляет, то тупо можешь в саге повесить yield takeEvery('@@router/LOCATION_CHANGE', router) а далее типа function* router({ payload }) { switch (payload.pathname) { case '/page1': document.body.style.backgroundColor = 'red' ...

да, оставляет. Спасибо

в 3-м можешь <Route path="/page1" onEnter={(state, replace, cb) => ....} />

да, оставляет. Спасибо

вариантов море, если без саги, то через getDerivedStateFromProps можно

зависит от ситуации короче

вариантов море, если без саги, то через getDerivedStateFromProps можно

Он без сайд эффектов если что

Он без сайд эффектов если что

ну ок, это что-то меняет?

ERROR: S client not available

смена бэкграунда, это уже сам по себе сайд эффект

или ты как раз про это? :)

или ты как раз про это? :)

Да

боди можно заменить дивом внутри дерева реакта и вешать туда класс

И нормально прокидывать класс как проп

научи

научи

думаю это будет слишком дорого)

нет ну так то можно вообще сделать по простому

задать для body id

и рендерить в него либо само приложение, либо Portal

браузеры предоставляют много возможностей для извращений

https://css-tricks.com/parent-selectors-in-css/

ты во тэто имел в виду?

Я?

угу

Сначала хочу узнать в чем разница между дивом который оборачивает реакт аппу и боди Вместо #root > App пишешь #root > #wrapper > App С враппером делаешь что угодно

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

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

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

правда до сих пор не знаю правильно это или просто хак

один раз сделал, получилось, теперь всегда так :))

Это react-way хотя бы)

react way это 99% div

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

Сначала хочу узнать в чем разница между дивом который оборачивает реакт аппу и боди Вместо #root > App пишешь #root > #wrapper > App С враппером делаешь что угодно

+1, потому и уточнил действительно ли оно надо ? с body работать

react way это 99% div

Это про flex и т.п. "современности". Так что адекватные верстальщики не должны удивляться)

ну хз.... сразу спрашивают, а где <acritcle ? а почему меню не через <nav> <ul> <li> ... ?

А вопрос справедливый ващет

Семантику по дороге потеряли?

ну хз.... сразу спрашивают, а где <acritcle ? а почему меню не через <nav> <ul> <li> ... ?

семантические теги юзать реакт не мешает, это нужно Но ul > li для меню это маразм

Может просто большинство забивает на это и херачат дивы

семантические теги юзать реакт не мешает, это нужно Но ul > li для меню это маразм

Конечно, меню же <aside role="menu"><dl><dt/><dd/></dl></aside>