ну и сам setState https://github.com/facebook/react/blob/master/src/isomorphic/modern/class/ReactBaseClasses.js#L59

а, не, вот

https://github.com/facebook/react/blob/b1768b5a48d1f82e4ef4150e0036c5f846d3758a/src/renderers/shared/stack/reconciler/ReactUpdateQueue.js#L208

короче чет на ночь глядя сложно

https://github.com/facebook/react/blob/b1768b5a48d1f82e4ef4150e0036c5f846d3758a/src/renderers/shared/stack/reconciler/ReactUpdateQueue.js#L208

дохуя сложно там уходит в ReactUpdates

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

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

ну вот в этом я и хотел убедится. завтра с утра почитаю еще сорцы для пущей уверенности

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

ну вот в этом я и хотел убедится. завтра с утра почитаю еще сорцы для пущей уверенности

читай файбер сразу)

читай файбер сразу)

нннну, файбер это другое я подозреваю

там одна из фишек в этом, сейчас попробую найти обзор

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

нет он обновляет ещё вложенные компоненты собирает апдейты и прочее там дофига чего под капотом

нннну, файбер это другое я подозреваю

файбер это 16 реакт который вот вот выйдет

ну я знаю что такое файбер

файбер это 16 реакт который вот вот выйдет

вот-вот и всё никак

ну я знаю что такое файбер

я думал никто не знает)

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

а нас интересует теперешний

я думал никто не знает)

ну я хз как он изнутри, знаю что рендер разбивает на мелкие кусочки хитро, а что, как, хз. пока не интересно

у кого много свободного времени можно читать там https://github.com/facebook/react/issues/7942

у кого много свободного времени можно читать там https://github.com/facebook/react/issues/7942

?

кстати насчет асинхронности setState https://facebook.github.io/react/contributing/design-principles.html#scheduling

To be clear, we are not taking advantage of this right now. However the freedom to do something like this is why we prefer to have control over scheduling, and why setState() is asynchronous. Conceptually, we think of it as "scheduling an update".

redux-act vs redux-actions. И почему?

redux-act vs redux-actions. И почему?

.

redux-act vs redux-actions. И почему?

я бы ничего не выбрал

но на твоем месте на звезды на гитхабе бы смотрел

Астарожнааа. Я Вас, сударь, принял за спамера.

:(

а стоит ли вообще такие приблуды использовать?

Ну, лично мне надоело писать тонны боилерплейт-кода. Редъюсеры итак довольно жирные. И иногда они тупо отличаются названием экшнов (даже наборы экшнов однотипны). А то, что я ещё и Flow юзаю, добавляет рутины.

Ну, лично мне надоело писать тонны боилерплейт-кода. Редъюсеры итак довольно жирные. И иногда они тупо отличаются названием экшнов (даже наборы экшнов однотипны). А то, что я ещё и Flow юзаю, добавляет рутины.

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

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

сага в этом деле спасла

А чего сага даёт помимо удобной работы с асинхронными экшнами?

А чего сага даёт помимо удобной работы с асинхронными экшнами?

сага не дает ничего для удобной работы с асинхронными экшенами

async/await — вот это удобная работа с асинхронными экшнами

А чего сага даёт помимо удобной работы с асинхронными экшнами?

она позволяет строить так называемые потоки выполнения. то есть что-то типо сценраиев, я хз как назвать. в итоге количество экшенов/редьюсеров сокращается в разы

async/await — вот это удобная работа с асинхронными экшнами

Чёт ты снова поспешил с выводами.

Я её ковырял когда-то. Не хватило времени перейти на неё.

А чего сага даёт помимо удобной работы с асинхронными экшнами?

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

Да и не нужно особо было.

Я её ковырял когда-то. Не хватило времени перейти на неё.

типо на каждый фетч - вешается сага предположим

Сейчас смотрю доку. takeLatest — это вещь. =)

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

Разве сага не чисто для сайд эффектов?

Разве сага не чисто для сайд эффектов?

ну так а чем тебе не сайд эффект?

Кстати, зачем редъюсерам сайд-эффекты?

Сейчас смотрю доку. takeLatest — это вещь. =)

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

ну так а чем тебе не сайд эффект?

Оно же чистое? Не?

Оно же чистое? Не?

так а причем тут редьюсеры?

Выворот мозгов, мать его.

намерение фетча чего либо - а там уже сага запукается нужная

редьюсер тут не примем совсем

Я ваще хотел rxjs осваивать и всё на redux-observable пилить.

Я считаю, что сага нужна, когда есть сложный флоу

В остальном санк и асинков хватит

Я считаю, что сага нужна, когда есть сложный флоу

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

Короче, вопросов стало только больше.

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

Если просто по очереди делать запросы — сага не нужна

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

без саги бы мы заебались бы собирать всю эту муку в нужное состояние

без саги бы мы заебались бы собирать всю эту муку в нужное состояние

ну там не по очереди

ну там не по очереди

А как

Пример приведи

ERROR: S client not available

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

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

Пример приведи

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

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

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

ну прицнип да, такой

ну прицнип да, такой

Вот это очень круто. Я пиздец как против того, чтобы экшн криейтор знал, что ему нужно куда-то отправлять http-запрос.

Вот это очень круто. Я пиздец как против того, чтобы экшн криейтор знал, что ему нужно куда-то отправлять http-запрос.

так он и не должен

Вот-вот.

А санк подталкивает к такому.

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

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

Тоже так делал. Но отказался. ~ 6 мс жрет на каждом диспатче

Ну, хотя от реализации можно абстрагироватья. Мы так и делали с санком. Просто каррировали экшн-криейторы и привязывали к ним реализацию все побочной фигни. Но это всё равно было каким-то компромиссом. А вот связь экшнов через миддлвари — это хорошо.

Тоже так делал. Но отказался. ~ 6 мс жрет на каждом диспатче

а чем заменил?

Как вы любите неочевидный код. Кошмар

Ладно. Тогда redux-saga vs redux-observable. И почему? =)

Как вы любите неочевидный код. Кошмар

вай?

Как вы любите неочевидный код. Кошмар

Да хорош. Вовсе не неочевидный.

а чем заменил?

Ванилой. Да гиморнее. Да код получается местами не такой красивый. Но 60 фпс сами себя ненарендерят )

Ванилой. Да гиморнее. Да код получается местами не такой красивый. Но 60 фпс сами себя ненарендерят )

ну у нас по поводу перфоманса вопрос не стоит :)

Да хорош. Вовсе не неочевидный.

Миддлвары это не очевидность же

Миддлвары это не очевидность же

ну миддлвары чистые - это пиздец

ну у нас по поводу перфоманса вопрос не стоит :)

Я как начал воевать с анимацией вопрос перфоманса встал. Очень.

ну миддлвары чистые - это пиздец

я помню такой ад из этого говна видел. что-то щелкает, пукает, прыгает, экшены эти от миддлвари до миддлвари летают

Я как начал воевать с анимацией вопрос перфоманса встал. Очень.

типо сагавские каналы сами по себе медленные?

типо сагавские каналы сами по себе медленные?

Ну как медленные. На десктопе ты этого и не заметишь. У меня на самом слабом девайсе регулярно матч по имени экшена занимал до 6 мс. А 6 мс очень много

Ну как медленные. На десктопе ты этого и не заметишь. У меня на самом слабом девайсе регулярно матч по имени экшена занимал до 6 мс. А 6 мс очень много

возьму на заметку

Миддлвары это не очевидность же

Так ты только подумай. Экшны и редьюсеры в идеале тоже должны быть переносимы (ничоси? ну, это я так решил) и быть абстрагированы от всех особенностей текущего проекта (не только куда отправлять и какие запросы, но ещё и каким образом). Офигенно выглядит код, когда у тебя есть набор событий. Тогда у тебя стейт как ветвистый... нет, не ветвистый, а одного уровня вложенности евент-эмиттер, это более низкий уровень, CRUD. А БЛ над ним ты выстраиваешь, формируя связи между экшнами, создавая поведение приложения над этим CRUD. Это более высокий уровень.

Так ты только подумай. Экшны и редьюсеры в идеале тоже должны быть переносимы (ничоси? ну, это я так решил) и быть абстрагированы от всех особенностей текущего проекта (не только куда отправлять и какие запросы, но ещё и каким образом). Офигенно выглядит код, когда у тебя есть набор событий. Тогда у тебя стейт как ветвистый... нет, не ветвистый, а одного уровня вложенности евент-эмиттер, это более низкий уровень, CRUD. А БЛ над ним ты выстраиваешь, формируя связи между экшнами, создавая поведение приложения над этим CRUD. Это более высокий уровень.

Mind: Syntax error: Parsing failed

Поэтому экшн-криейтор никуда ничего не должен отправлять. Он должен только принимать аргументы и возвращать экшн.

Так ты только подумай. Экшны и редьюсеры в идеале тоже должны быть переносимы (ничоси? ну, это я так решил) и быть абстрагированы от всех особенностей текущего проекта (не только куда отправлять и какие запросы, но ещё и каким образом). Офигенно выглядит код, когда у тебя есть набор событий. Тогда у тебя стейт как ветвистый... нет, не ветвистый, а одного уровня вложенности евент-эмиттер, это более низкий уровень, CRUD. А БЛ над ним ты выстраиваешь, формируя связи между экшнами, создавая поведение приложения над этим CRUD. Это более высокий уровень.

чет я нихуя не понял