Так что не понимаю какая у тебя проблема

Подожди. Санки говно. Саги говно. Обзерваблы говно. Что остаётся?

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

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

Подожди. Санки говно. Саги говно. Обзерваблы говно. Что остаётся?

Санки норм

Подожди. Санки говно. Саги говно. Обзерваблы говно. Что остаётся?

Страдать

Страдать

бдышь печатает 2 минуты и потом спустя это время

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

ну если ключ только на строчку ставить, то все ок...НО в каждой строчке также рендерится select и у каждого option тоже свой ключик, select повторяется в каждой строчке и Реакт выдает warning что в пределах всей таблицы есть неуникальные ключи у селектов...А как они могут быть разные, если это реально один и тот же селект

через пропсы предать этот хендлер

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

Здравствуйте коллеги

привет

бдышь печатает 2 минуты и потом спустя это время

Он хотел написать эффектор, но понял, что не стоит

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

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

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

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

recompact

recompact

есть нюанс у меня был коннект и обычный компонент и когда я добавлю эту штуку у меня енивей добавится один компонент)

если бы он еще коннект функцию сквошил

есть нюанс у меня был коннект и обычный компонент и когда я добавлю эту штуку у меня енивей добавится один компонент)

тебе придется сделать trade-off

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

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

Lifting state up читай

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

инверсия зависимостей

recompact

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

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

Не, они там разошлись во мнениях и появились аналоги рекомпоуза с такой фичей, рекомпакт и ещё один https://github.com/wikiwi/reassemble

а в чем там суть была ?

А я не помню, давно issue читал, там ещё в рекомпоузе решили некоторые фичи депрекейтить и в целом многие были против, лайфсайклы вроде

типа не юзать лайфлайклы ?

типа не юзать лайфлайклы ?

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

Сейчас даже гляну

типа не юзать лайфлайклы ?

https://github.com/acdlite/recompose/pull/182#issuecomment-315214044

О, кстати про флэт дерево

я пока в проекте из всех фич рекомпоуза заюзал defaultProps

>I dont use devtools so this is not a problem for me.

Идеальный ответ

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

я пока в проекте из всех фич рекомпоуза заюзал defaultProps

У совы же в пет проекте юзается на гх,можешь глянуть

и что ?

Ну тип можешь посмотреть как он юзает, хотя там все на хоках вроде

я знаю как пишет мне не оч нрав идея с хоками

которые не реюзаются

У совы же в пет проекте юзается на гх,можешь глянуть

ты про инстакод или про другой какой-то :?

ты про инстакод или про другой какой-то :?

https://github.com/howtocards/frontend

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

https://github.com/zhDmitry/frontend/blob/master/src/features/join/pages/logout.js

https://github.com/howtocards/frontend/blob/master/src/features/join/pages/logout.js

какой приятный вид, что за тема?) про визуализацию в vscode

https://marketplace.visualstudio.com/items?itemName=ionutvmi.spacegray-vscode

которые не реюзаются

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

я вот просто не уверен что вот такой способ описания компонента https://github.com/howtocards/frontend/blob/master/src/features/join/pages/logout.js, лучше чем просто описание в классе

я вот просто не уверен что вот такой способ описания компонента https://github.com/howtocards/frontend/blob/master/src/features/join/pages/logout.js, лучше чем просто описание в классе

У меня на одном проекте было так, что ребята увлеклись рекомпоузом и вот эти компоузы были оче жирные. Их конечно можно было бы раздробить нормально логически, но они писали всё в ОДИН МОЩНЫЙ КОМПОУЗ и это нифига не лучше было описания в классах

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

У меня на одном проекте было так, что ребята увлеклись рекомпоузом и вот эти компоузы были оче жирные. Их конечно можно было бы раздробить нормально логически, но они писали всё в ОДИН МОЩНЫЙ КОМПОУЗ и это нифига не лучше было описания в классах

????

5 хоков это норм в одном compose это норм ?

у меня был проект в котором было 2 хока по 10 хоков

и один в другого вкладывался

А то я тоже увлекаюсь recompose

у меня был проект в котором было 2 хока по 10 хоков

Неплохо

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

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

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

Recompose - модно и молодёжно

вот единственная проблема классов, что они дают слишком много свободы действий

вот единственная проблема классов, что они дают слишком много свободы действий

В смысле? Ты и в классе можешь описать и с рекомпоуз

ERROR: S client not available

в классе больше свободы для наговнячить

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

ну это правильный вопрос, так что тут ответ один — писать как удобно

ну это да, но это слишком размыто что бы кому-то обьяснить

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

Скинуть туториал

И показать основные приемы.

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

Зачем брать такого чувака?

допусти от сервера пришел токен, и объект user. Токен я сохранил в куки, а user записал в стор. Если я обновлю страницу, то куки с токеном останутся, а стор обнулится и user будет null. Вопрос - надо делать какой-то дополнительный экшен "FEATCH_USER", который будет постоянно диспачится при монтировании App компонента, если токен уже есть в куках и отдельным http запросом получать user от сервера заново, без запрашивания логина и пароля ?

допусти от сервера пришел токен, и объект user. Токен я сохранил в куки, а user записал в стор. Если я обновлю страницу, то куки с токеном останутся, а стор обнулится и user будет null. Вопрос - надо делать какой-то дополнительный экшен "FEATCH_USER", который будет постоянно диспачится при монтировании App компонента, если токен уже есть в куках и отдельным http запросом получать user от сервера заново, без запрашивания логина и пароля ?

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

Если мне нужно перед тем как компонент перерендерится посмотреть изменился ли параметр запроса и если изменился то сделать запрос к апи и потом поменять стейт, то как это я могу сделать ? Каким неустаревшим lifecycle методом?

Если мне нужно перед тем как компонент перерендерится посмотреть изменился ли параметр запроса и если изменился то сделать запрос к апи и потом поменять стейт, то как это я могу сделать ? Каким неустаревшим lifecycle методом?

cDU, но вообще лучше сделать запрос к апи до ререндера компонента

cDU, но вообще лучше сделать запрос к апи до ререндера компонента

Почему лучше не делать? Какая разница?

Почему лучше не делать? Какая разница?

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

https://youtu.be/K6oZuB8_dU8

https://youtu.be/K6oZuB8_dU8

неплохо

стоит ли тащить лодаш если нужно чекать на equal два объекта с одним уровнем?

нет

посоветуйте что по реакту почитать

для новичков

посоветуйте что по реакту почитать

Доку и твиттер Абрамова

бля, я все пытаюсь сохранять рефы в функциональных компонентах

с рекомпозом

так рефы хранятся в this, а тут их нужно хранить либо в стейте, а он попадает в пропы и компонент обновляется

а затем ref={el => setRef(el)} вызывается заново на компоненте

а затем ref={el => setRef(el)} вызывается заново на компоненте

forwardRef

forwardRef

хоспаде, первый раз слышу

Кто сделает ревью реакт кода на платной основе (10 usd)? Не получается передавать значение инпутов (компонент) в функцию. Ориентировочно, рассчитываю на 30 минут времени ревьювера. Напишите в лс.

Кто сделает ревью реакт кода на платной основе (10 usd)? Не получается передавать значение инпутов (компонент) в функцию. Ориентировочно, рассчитываю на 30 минут времени ревьювера. Напишите в лс.

Вкинь сюда, тебе и бесплатно ответят по возможности