а может ктонить пояснить базовую вещь, вот в реакте есть shouldComponentUpdate и два типа компонентов Component и PureComponent, второго в shouldComponentUpdate используется shallow сравнение statе и props, для первого всегда возвращается true по дефалту, а как вообще определятся поменялся ли стейт? тоесть как сравнивается стейт до вызова shouldComponentUpdate

чет в доке не смог найти быстро

дак ты же сам вызываешь setState setProps, поэтому первый раз реакт и понимает когда чо произошло. Или я не понял вопроса

погоди, тоесть каждый раз когда setState происходит ререндер?

он не сравнивает стате на equals?

ну вот будет ли рендер как раз определяет реализация shoudComponentUpdate

ааа

тоесть подефолу если я вызову setState и передам идентичный стейт то все равно будет ререндер?

дак ты попробуй - репл сила 🙂

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

это я уже понял

чуваки, а как вы хэндлите случай когда надо много последовательных http-запросов сделать? типо 6 штук, каждый на основе результата предыдущего? ну и с ретраями и эррор хэндлингом?

колбэки или корасинк

@misha дефалтное решение для component это всегда true, даже если стейт по сути не изменился, так?

просто уточняю)

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

@andfadeev не знаю, за меня @tonsky в роме порешал всё иногда только специально дописываю rum/static, где точно знаю, что выхлоп зависит только от аргументов (и то это теперь якобы по-дефолту так)

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

и понял что не совсем понимаю как оно там работает

а в доках реакта чо пишут?

shouldComponentUpdate(nextProps, nextState) Use shouldComponentUpdate() to let React know if a component's output is not affected by the current change in state or props. The default behavior is to re-render on every state change, and in the vast majority of cases you should rely on the default behavior.

но я не понимаю как определяется every state change

по вызову setState?

@artemyarulin ^ help)

Когда меняются пропсы еще компонент рендерится

>state change поменять стейт можно только через вызов setState

https://facebook.github.io/react/docs/react-component.html#shouldcomponentupdate >shouldComponentUpdate() is invoked before rendering when new props or state are being received.

@olegakbarov еще можно промисы, всякие future ну и вообще руками написать асинхронный фор/loop не очень сложно. кор.асинк ради одного раза тащить не надо, он сложный по началу и не имеет встроенной поддержки ошибок. https://github.com/funcool/promesa очень хороша

НАШЕЛ

https://github.com/facebook/react/blob/5881371b61648c70b61b869c3234fc6c4c304409/src/renderers/shared/fiber/ReactFiberClassComponent.js#L97-L128

но это файбер

- если метод заоверайдили - его вызвать - если пур компонент (пур=тру) - поверхностно сравнить - по-умолчанию вернуть тру.

не могу найти, где и кто именно вызывает shouldComponentUpdate

@olegakbarov: promesa

упс 😄

спс, сейчас гляну

а я вообще нативные промисы юзаю, без promesa)

а где посмотреть какие-то референсы?

просто лесенка из 6 колбэков это такое

(-> (fetch 'some/api')
      (.then #(fetch 'another/api'))
      (.then #(fetch 'another/one/api')))

это cljs?

да

я в контексте jvm сейчас интересовался

надо было пояснить 😅

Thread.new 😄

мож future которое создает 6 других feature и ждет их последовательно)

not sounds like a plan)

not sounds? 😕

ну я рассчитывал, что есть более элегантные решения

@olegakbarov ну можно сделать функу, которая будет результат хттп запроса в канал и тогда будет

(-> data1
      (mk-req url1)
      (async/<!)
      transform-results1
      (mk-req url2)
       ...
)

о, да я вот что-то в таком жанре ожидал