Типа во время вызова этой ф ции самого компонента нет еще

все-равно вызовы и компарации

Сова, не кипишуй, тут парад аутизма, надо уважать такие мероприятия

?

а в чем тогда подводные камни большого кол-ва коннкетов, сова?

Я не сова, но насколько я знаю с точки зрения производительности - connect у вложенных элементов - ЛУЧШЕ, чем передача данных по пропсам из одного центрального. Минус такого подхода - они делаются завязаны на приложение, их тяжелее выделить в отдельный независимый компонент и сложнее тестировать.

PureComponent всего-лишь обеспечивает поверхностное сравнение пропсов

Вы в асинхронных действиях юзаете async await?

Мы там мозги используем, это полезнее

Пиздец тут собрание шутников

Я в ахуе

Сука, задал адекватный вопрос

Бро, а ты почитай бест практис. Потом лезь в комьюнити

В чем проблема

Зачем использовать коммьюнити, вместо гугла?

И тебе больше знаний и мозг не делаешь другим)

Сова, не кипишуй, тут парад аутизма, надо уважать такие мероприятия

ладно пойду работать

Мы там мозги используем, это полезнее

Вспомнил хохму вэч, на какой-то рандомный вопрос по реакту чуваку ответили "Попробуй shouldComponentUpdate". Чувак такой: да спасибо, заработало!

Вы в асинхронных действиях юзаете async await?

Я не сова, но насколько я знаю с точки зрения производительности - connect у вложенных элементов - ЛУЧШЕ, чем передача данных по пропсам из одного центрального. Минус такого подхода - они делаются завязаны на приложение, их тяжелее выделить в отдельный независимый компонент и сложнее тестировать.

лол пропсы тестировать легче чем connect ну если ты не знал

лол пропсы тестировать легче чем connect ну если ты не знал

ээ. я это и написал

ну так в этом то всё и дело

Сова, не кипишуй, тут парад аутизма, надо уважать такие мероприятия

два кипятка этому господину

Вы в асинхронных действиях юзаете async await?

ды че хочешь используй, как удобнее тебе

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

ну используй

в чем проблема?

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

если не нравится - используй

у мамы спроси в конце концов, может она разрешит

Воу воу шуточки про мам

Дак я спрашивал используете ли вы

используем)

кто-то использует, кто-то нет

ответ на этот вопрос тебе ничего не даст абсолютно

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

async await - нормальный подход. промисы - нормальный подход. генераторы - нормальный подход.

Пиздец тут коллектив

больше компонентов получают componentWillReceiveProps, а затем SCU

recompose onlyUpdateForKeys

и этому тоже 2 кипятка

Один мозги использует

Другому разрешение от мамы нужно

Один мозги использует

это бывает, да

Другому разрешение от мамы нужно

Всё как в жизни.

Один мозги использует

Не он один) И ты не в этом ряду

Ещё один шутник

Дак я спрашивал используете ли вы

мне async/await не очень нравятся. это императивный подход, мне кажется он не очень хорошо ложится. я как то к декларативности уже привык

Я же говорил) Бест практис Гугл

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

А не в телеге писать)

так странно наблюдаьб_

мне async/await не очень нравятся. это императивный подход, мне кажется он не очень хорошо ложится. я как то к декларативности уже привык

лол

мне async/await не очень нравятся. это императивный подход, мне кажется он не очень хорошо ложится. я как то к декларативности уже привык

К миллионам промисов?

вангую хуевую архитектуру раз в одном экшне дохуища запросов к разным апи

мне async/await не очень нравятся. это императивный подход, мне кажется он не очень хорошо ложится. я как то к декларативности уже привык

буквально пару дней назад переписывал на async/await с промисов, сложный флоу переписал, прям порадовался, ещё и пару багов закрыл просто отрефакторив

Бляя

К миллионам промисов?

в чем проблема чейнить промисы? в случае async/await у тебя будет миллионы try/catch

еще и матерится

в чем проблема чейнить промисы? в случае async/await у тебя будет миллионы try/catch

1 try catch

вангую хуевую архитектуру раз в одном экшне дохуища запросов к разным апи

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

Боже

При чем тут архитектура

в чем проблема чейнить промисы? в случае async/await у тебя будет миллионы try/catch

ща туту тебе еше про Maybe monad скажут

ыхыхы

Мне кажется Павел ярый тролль

Ну 2-3 запроса есть

бля перепиши на асинк-авейт

И в промисах это уже длинная цепочка

он просто лидер парада

посмотри как выглядит

в чем проблема?

ERROR: S client not available

там работы на 10 минут

бля перепиши на асинк-авейт

Я сразу на нем пишу

ну заебись

Ну так пиши)

Я сразу на нем пишу

Зачем тогда спрашиваешь?)

возьми с полки пирожок

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

1 try catch

как же один. у тебя куча async/await запросов и ты на них один общий обработчик повесишь?

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

Мне кажется Павел ярый тролль

забанить его штоль?

пишущих на async-await

забанить его штоль?

не надо

забанить его штоль?

Нене)

как же один. у тебя куча async/await запросов и ты на них один общий обработчик повесишь?

и в чем проблема?)

recompose onlyUpdateForKeys

А вот этого я не видел, спасибо:)

и в чем проблема?)

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

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

поставь универсальную. "Yob tvouy matb. Opyatb vsyo slomalos"

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

ты не понимаешь концепта try/catch похоже

в fetch/axios класс ошибки передать можно?

в fetch/axios класс ошибки передать можно?

fetch у меня под оберткой обертка свои ошибки кидает

ну есть же request-specific ошибки

ну есть же request-specific ошибки

meh?

ну есть же request-specific ошибки

пиши для такой фигни метод и обрабатывай в нем

ты не понимаешь концепта try/catch похоже

Он вроде имеет в виду делать под разные типы ошибок разные catch блоки

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

Он вроде имеет в виду делать под разные типы ошибок разные catch блоки

в жс нельзя несколько catch блоков по типам

Я знаю

но можно if else instanceof

но можно инсианс

ну да

Но залётные джависты часто бугуртят

ну напиши бабель - плагин:)