кто тут не прав?

кстати, а почему бы для проблемы с SSR не юзать middleware для редакса, которая будет собирать все промисы, которые возвращаются из dispatch?

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

кстати, а почему бы для проблемы с SSR не юзать middleware для редакса, которая будет собирать все промисы, которые возвращаются из dispatch?

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

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

пододжать всех, отрендерить ещё раз, отдать клиенту полученный html

пододжать всех, отрендерить ещё раз, отдать клиенту полученный html

а если там нужны ещё данные?

не каждый промис, а все сразу

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

типа запросить список проектов, после запроса списка прав

это как бы должно лежать в одном thunk экшене

это как бы должно лежать в одном thunk экшене

ну как бэ нет

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

список прав, глобален для всего проекта а вот список проектов, категорий и пр. это чисто для конкретного роута

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

я делал так, ещё на 0.13 реакте

говно получается

это как бы должно лежать в одном thunk экшене

Не всю логику вообще реально уместить в одну функцию

говно получается

ну других решений я не вижу

ну других решений я не вижу

не размазывать запрос данных по всему приложению

я рассказывал про свое решение, а ты про то что оно херовое и не работает

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

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

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

тут где-то есть табличка о том что можно рассказывать, а что нет?

тут где-то есть табличка о том что можно рассказывать, а что нет?

в голове должна быть

короче отвали

запарил

не размазывать запрос данных по всему приложению

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

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

согласен. Но оно решает проблему прелоада данных в SSR, при определенном подходе в работе с данными. Который, как мне кажется, очевиден — не размазывать запросы данных по всему приложению

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

для этого есть тимлид и ревью. Да и этот коллега, увидит diff error от реакта, что разница между hydrate и SSR markup есть

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

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

тебе это не нужно. меняй входные данные (пропс) компонента

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

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

А то это ад и мракобесие

Ну вот есть панелька, которой нужны данные, и которая приконнекчена к редаксу и дёргает экшены при маунте и между корнем виртуального дома и элементом этой панельки 100500 компонентов И Сова мне тут говорит, что верхние компоненты ПРОСТО ОБЯЗАНЫ знать о существовании этой панельки и сами вызывать экшены для получения данных по апи, так как в противном случае, вызовы апи получаются размазанными, что не является Совоугодно

Ну вот есть панелька, которой нужны данные, и которая приконнекчена к редаксу и дёргает экшены при маунте и между корнем виртуального дома и элементом этой панельки 100500 компонентов И Сова мне тут говорит, что верхние компоненты ПРОСТО ОБЯЗАНЫ знать о существовании этой панельки и сами вызывать экшены для получения данных по апи, так как в противном случае, вызовы апи получаются размазанными, что не является Совоугодно

блэд

у тебя весь проект на этих панельках построен?

или может эта панелька лежит в App который вставлен в роутер?

и больше нигде

как эта панелька может лежать в App, если она должна рендерится где-то в глубине дерева компонент?

как эта панелька может лежать в App, если она должна рендерится где-то в глубине дерева компонент?

чувак. Ну сочувствую

у тебя весь проект на этих панельках построен?

нет, но теоретически (и практически) число этих панелек лежит в диапазоне [0, Infinity)

нет, но теоретически (и практически) число этих панелек лежит в диапазоне [0, Infinity)

ты не находишь, что это несколько не нормально?

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

ты не находишь, что это несколько не нормально?

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

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

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

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

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

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

Костылями?

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

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

зачем-то 100500 одинаковых панелек, со 100500 одинаковыми запросами

ну я нигде не говорил, что их 100500 и они одинаковые

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

я говорил лишь то, что над панелькой 100500 всяких других компонент

ну я нигде не говорил, что их 100500 и они одинаковые

Вобще - запросы лучше делать в одном месте

вот у нас есть виджет, который встроен в разные части сайта, и еще в iframe встраивается

что мы делаем не так запрашивая в нем данные?

Вобще - запросы лучше делать в одном месте

а там не запросы могут идти, а вызовы редакс экшенов при маунте, которые уже делают (или не делают) запросы к апи

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

но их вызов - нет

нет, но теоретически (и практически) число этих панелек лежит в диапазоне [0, Infinity)

говорил

ну я нигде не говорил, что их 100500 и они одинаковые

лол

а

вот у нас есть виджет, который встроен в разные части сайта, и еще в iframe встраивается

редкий кейс

я говорил не о числе инстансов панелек на одной странице

а о числе подобных компонент

вообще

вот снова

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

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

редкий кейс

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

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

а вобще именно этот кейс решается хоком

ребята, таокй вопрос, а почему я в mapStateToProps Делаю свойсвто (выбираю поле), и потом когда например меняю это поле (диспатчу экшен), то при вызове этого свойтсва из мапСтейтТуПропс в нем лежит старое не обновленное значение, как можно получить обновленное значение этого свойства ?

а вобще именно этот кейс решается хоком

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

это по версии Совы всё

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

я так делал

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

и коротким

это конечно всё хорошо

проброс через пропы через всё приложение?

вот только можно запросто забыть вызвать какой-нибудь апи

вот только можно запросто забыть вызвать какой-нибудь апи

у меня это делают компоненты сами

или добавить компонент и не написать вызов апи

у меня это делают компоненты сами

как?

или добавить компонент и не написать вызов апи

ну собственно лол это невозможно данных то нет

ты будешь пробрасывать пропсы и увидишь

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

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

серьезно?

серьезно?

начинается

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

https://m.youtube.com/watch?v=xsSnOQynTHs

проброс через пропы через всё приложение?

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

ты будешь пробрасывать пропсы и увидишь

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

ну если с коннектами к стору, то ещё норм

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

шутка не просто так появилась

https://m.youtube.com/watch?v=xsSnOQynTHs

спс

шутка не просто так появилась

я всё понял, можете не продолжать

я всё понял, можете не продолжать

??

ребята, как отлавливать вверх и вниз события onWheel?

ребята, как отлавливать вверх и вниз события onWheel?

Рассчитать разницу текущего скрола с прошлым?

Рассчитать разницу текущего скрола с прошлым?

спасибо) через event.deltaY решил

спасибо) через event.deltaY решил

?

там же scrollTop есть