не используй jquery не делай запросы в компонентах

ЭТО JQUERY? O_O

Вот это пушка

не используй jquery не делай запросы в компонентах

> не делай запросы в компонентах Но запрос-то так или иначе инициирует компонент :)

Джейвери в реакте

> не делай запросы в компонентах Но запрос-то так или иначе инициирует компонент :)

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

> не делай запросы в компонентах Но запрос-то так или иначе инициирует компонент :)

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

не используй jquery не делай запросы в компонентах

не делай запросы в компонентах?

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

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

не делай запросы в компонентах?

я так и написал

я так и написал

иммелось виду, почему так?

почему вне компонента надо?

почему вне компонента надо?

а с чего за запрос к апи должен компонент отвечать?

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

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

а с чего за запрос к апи должен компонент отвечать?

можно пример кто должен отвечать?

почему вне компонента надо?

как минимум потому что компонент может пропасть к моменту, когда придёт ответ

можно пример кто должен отвечать?

выше ниже

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

ну. я считаю, что компонент вообще не должен знать, что он производит выполнение запроса. Я думаю, что компонент должен производить событие “открыт компонент” или “пользователь хочет получить данные” это событие ловится неким слоем и слой решает, надо ли вообще делать запрос, или же данные уже есть и можно ничего не делать, или обновить состояние, чтобы открылся popup

как минимум потому что компонент может пропасть к моменту, когда придёт ответ

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

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

ага вот выше примерно о том же написал

выше ниже

кодом пример желательно

не совсем понимаю куда это выносить нужно

ага вот выше примерно о том же написал

ой не туда ответил, я про t.me/react_js/462718

точнее куда можно

точнее куда можно

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

не совсем понимаю куда это выносить нужно

совсем примитивно так: componentDidMount() { myRequestMakingModule.request('descriptionOfNeededData'); }

Куда дальше попадают данные?

Куда дальше попадают данные?

в стейт менеджер и дальше в пропсы компоненту

Господа а если в рендере указываешь вот так: onClick={(e) => this.handleClick(e)} то это ведь плохо и каждый раз создается новая функция? поправьте, а то я что-то засомневался

Я правильно понимаю, что в такой ситуации надо делать редакс-экшены на каждое состояние запроса? То есть process => (error/success)? То есть их 3 на запрос получается

Господа а если в рендере указываешь вот так: onClick={(e) => this.handleClick(e)} то это ведь плохо и каждый раз создается новая функция? поправьте, а то я что-то засомневался

плохо

Господа а если в рендере указываешь вот так: onClick={(e) => this.handleClick(e)} то это ведь плохо и каждый раз создается новая функция? поправьте, а то я что-то засомневался

каждый раз создаётся новая, да не обязательно плохо

Господа а если в рендере указываешь вот так: onClick={(e) => this.handleClick(e)} то это ведь плохо и каждый раз создается новая функция? поправьте, а то я что-то засомневался

Не проблема в новой функции

каждый раз создаётся новая, да не обязательно плохо

почему необязательно? ну т.е. НЕПРИЯТНО

Делаю запросы в component DidMont обычно

Проблема когда новая функция каждый раз в проп попадет

И вызывает не нужный ререндер

каждый раз создаётся новая, да не обязательно плохо

нет, всегда плохо. другое дело, что чаще всего можно этим пренебречь

почему необязательно? ну т.е. НЕПРИЯТНО

А че плохого? <SomeComponent style={{ color: 'red' }} /> а здесь каждый раз создаётся объект. О НЕТ!

Господа а если в рендере указываешь вот так: onClick={(e) => this.handleClick(e)} то это ведь плохо и каждый раз создается новая функция? поправьте, а то я что-то засомневался

onClick={this.handleClick}

А че плохого? <SomeComponent style={{ color: 'red' }} /> а здесь каждый раз создаётся объект. О НЕТ!

а то, что PureComponent ломается

нет, всегда плохо. другое дело, что чаще всего можно этим пренебречь

это ты другими же словами ту же мысль сказал)

onClick={this.handleClick}

ну там типа с параметрами немножно есть затык) но я в курсе да

а то, что PureComponent ломается

ну не все компоненты pure знаете ли )

спасибо

в нативных компонентах, вообще пофигу

а <button /> так вообще

в нативных компонентах, вообще пофигу

вот-вот

в нативных да но у меня не нативные)

в нативных да но у меня не нативные)

вот потому и "не всегда"

ну там типа с параметрами немножно есть затык) но я в курсе да

параметры можно прибиндить биндом

в стейт менеджер и дальше в пропсы компоненту

redux/mobx? По факту сейчас приложение имеет 10 страниц и всего пару запросов которые повторяются. И ради этого класть все данные в глобальный стейт как то не хочется...

ну там типа с параметрами немножно есть затык) но я в курсе да

в смысле с параметрами затык?

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

redux/mobx? По факту сейчас приложение имеет 10 страниц и всего пару запросов которые повторяются. И ради этого класть все данные в глобальный стейт как то не хочется...

если есть данные, которые шарятся между страницами, то state-manager must have!

redux/mobx? По факту сейчас приложение имеет 10 страниц и всего пару запросов которые повторяются. И ради этого класть все данные в глобальный стейт как то не хочется...

не хочется — не надо :) все ж давно говорят

если есть данные, которые шарятся между страницами, то state-manager must have!

90% стейт данных не шарятся между страницами

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

Очевидно не надо делать то, что будет бесполезным )

параметры можно прибиндить биндом

короче суть проблемки: компонента используется много где и пробрасывает в родительский колбек на клик name но есть место, где name не нужно, а нужен объект event вот т.е. либо я руками в одном месте делаю ненужный мне первый параметр и передаю везде (name, event) либо создаю новую функцию каждый раз и руками прокидываю только эвент

вот как бы тут получше

Очевидно не надо делать то, что будет бесполезным )

однако тут ругаются на то что запросы делает компонент (тоже понимаю почему)

короче суть проблемки: компонента используется много где и пробрасывает в родительский колбек на клик name но есть место, где name не нужно, а нужен объект event вот т.е. либо я руками в одном месте делаю ненужный мне первый параметр и передаю везде (name, event) либо создаю новую функцию каждый раз и руками прокидываю только эвент

КОМПОНЕНТ — мужского рода

КОМПОНЕНТ — мужского рода

это правда

если это бесполезно, то что делать то тогда

ERROR: S client not available

вот как бы тут получше

у Function.prototype.bind есть 2 и последующие параметры

короче суть проблемки: компонента используется много где и пробрасывает в родительский колбек на клик name но есть место, где name не нужно, а нужен объект event вот т.е. либо я руками в одном месте делаю ненужный мне первый параметр и передаю везде (name, event) либо создаю новую функцию каждый раз и руками прокидываю только эвент

так сделай другую функцию и её прокинь, а она будет как надо вызывать

так сделай другую функцию и её прокинь, а она будет как надо вызывать

тогда тоже новая будет каждый раз

у Function.prototype.bind есть 2 и последующие параметры

у нас по кодстайлу бинды не используются не я придумал

у нас по кодстайлу бинды не используются не я придумал

омг

тогда тоже новая будет каждый раз

почему это) вопрос как прокинуть

пропустим этот вопрос что плохо написаны компоненты и юзабилити

onClick={this.sendCorrectArguments} в чём проблема

Господа а если в рендере указываешь вот так: onClick={(e) => this.handleClick(e)} то это ведь плохо и каждый раз создается новая функция? поправьте, а то я что-то засомневался

Ивент и без этого придет, если что

Ребят, как правильно и более профессионально: 1) В редакс для каждого списка сущностей в сторе делать еще свойство "состояние запроса" (process/success/error) + свойство, где хранить ошибки, которые сервер вернет. То есть в функциях, которые дергают апи сервера будут диспатчиться экшены для состояний запроса 2) Сделать отдельные функции для апи-запросов, возвращающие промисы, и дергать их в componentDidMount (например, или по нажатию кнопки - в зависимости от задачи). Обрабатывать состояние запроса в таком случае надо через then и catch. Диспатчить экшены функции, обращающиеся к апи, не будут. Как лучше и правильнее: первый вариант или второй?

Ивент и без этого придет, если что

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

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

а каким)

а каким)

первым name идет там же не нативная, говорю же)

первым name идет там же не нативная, говорю же)

не надо так ((

первым name идет там же не нативная, говорю же)

пффф

я уже Lego наюзался. боль

о, лего жесть

я уже Lego наюзался. боль

че за он

Кто-нибудь может ответить на мой вопрос?) Пожалуйста

люди, подскажите как можно и HOC, и обернутый в него компонент подключить к store redux'а?

Ребят, как правильно и более профессионально: 1) В редакс для каждого списка сущностей в сторе делать еще свойство "состояние запроса" (process/success/error) + свойство, где хранить ошибки, которые сервер вернет. То есть в функциях, которые дергают апи сервера будут диспатчиться экшены для состояний запроса 2) Сделать отдельные функции для апи-запросов, возвращающие промисы, и дергать их в componentDidMount (например, или по нажатию кнопки - в зависимости от задачи). Обрабатывать состояние запроса в таком случае надо через then и catch. Диспатчить экшены функции, обращающиеся к апи, не будут. Как лучше и правильнее: первый вариант или второй?

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

люди, подскажите как можно и HOC, и обернутый в него компонент подключить к store redux'а?

обернуть в ещё один хок connect

не понял честно. можно плиз пример?

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

Все равно не понимаю) Как правильно? Я выбрал второй вариант - логика вроде упростилась. Проблема в том, что если юзать первый вариант, то я не очень понимаю, как в react-final-form пробросить ошибки с сервера (смотрю по этому примеру - https://github.com/final-form/react-final-form#submission-errors)

кстати, кто-нибудь пробовал И formik, И final-form? интересно сравнение

Все равно не понимаю) Как правильно? Я выбрал второй вариант - логика вроде упростилась. Проблема в том, что если юзать первый вариант, то я не очень понимаю, как в react-final-form пробросить ошибки с сервера (смотрю по этому примеру - https://github.com/final-form/react-final-form#submission-errors)

Там же есть ERROR_FORM вроде

кстати, кто-нибудь пробовал И formik, И final-form? интересно сравнение

Пробовал

не понял честно. можно плиз пример?

ConnectedComponent = connect()(myHoc(Component))

rff для велосипедистов

rff для велосипедистов

в каком смысле?

Все равно не понимаю) Как правильно? Я выбрал второй вариант - логика вроде упростилась. Проблема в том, что если юзать первый вариант, то я не очень понимаю, как в react-final-form пробросить ошибки с сервера (смотрю по этому примеру - https://github.com/final-form/react-final-form#submission-errors)

ошибку из стора брать как и другие ответы