Изучаю react + redux. У меня возник вопрос: если я создам 10 редьюсеров, вызову createStore() с этими редьюсерами, затем в каком-нибудь react компоненте вызову dispatch, как Redux определяет какой редьюсер вызвать для конкретного action?

по action.type

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

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

Разве это эффективно? Вызывать все редьюсеры? А если из 100 редьюсеров нужен лишь 1, зачем вызывать остальные 99?

Разве это эффективно? Вызывать все редьюсеры? А если из 100 редьюсеров нужен лишь 1, зачем вызывать остальные 99?

Ничего плохого не случится

Ничего плохого не случится

Слишком пространное заявление

Слишком пространное заявление

Нормальное

Нормальное

Нормальное то нормальное. Но пространное)

проблема высосаная из пальца

проблема высосаная из пальца

какая проблема?

ну, что ты пытаешься понять)

ну, что ты пытаешься понять)

я пытаюсь понять, как работает react c redux. Это не проблема

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

вот тебе всё ден абрамов написал))) https://redux.js.org/basics/reducers

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

Я конкретный вопрос задал: Как redux определяет, какую функцию вызвать. В сигнатуре функции action type не указывается, следовательно, вызываются все редьюсеры. Чувак выше это уже подтвердил

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

"диспатчишь экшн, у него есть тип" - у экшна то есть тип, а у редьюсеров нет типов

"диспатчишь экшн, у него есть тип" - у экшна то есть тип, а у редьюсеров нет типов

Как это нет?

Как это нет?

А где они есть?

В кейсах свича

Разве это эффективно? Вызывать все редьюсеры? А если из 100 редьюсеров нужен лишь 1, зачем вызывать остальные 99?

Это 99 вызовов функций, которые почти сразу завершаются, для браузера это не проблема

В кейсах свича

В кейсах свича, то есть внутри редьсера, чтобы до этого кейса добраться, надо сначала выполнить эту функцию. Что тут непонятного?

Это 99 вызовов функций, которые почти сразу завершаются, для браузера это не проблема

То есть редьюсеры не бывают "сложными"?

А где они есть?

я бы рад тебе помочь, ну что-то нихуя не понимаю, что ты хочешь понять

Смотри

В кейсах свича, то есть внутри редьсера, чтобы до этого кейса добраться, надо сначала выполнить эту функцию. Что тут непонятного?

Непонятна твоя проблема)

У тебя есть n редюсеров

В начале редьюсера - проверка на тип экшена

Диспетчится действие, пролетает все редюсеры

Находит совпадение - выполняет

Не находит - не выполняет

И какой бы тяжёлый редьюсер не был, он дальше условия не выполнится, если экшн не тот

+

Не находит - не выполняет

Пролетает все редьюсеры... что значит пролетает? Вызывает редьюсеры ты хотел сказать

Я так и сказал)

Ща, сек

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

И какой бы тяжёлый редьюсер не был, он дальше условия не выполнится, если экшн не тот

А сами вызовы функций разве не "дорогостоящая" операция?

Да камон, давно все поняли же, и ты вроде понял

А сами вызовы функций разве не "дорогостоящая" операция?

Нет

Я то уже понял. Я только не понимаю, почему другие не понимают, чего я не понимаю, точнее не понимал. ?

Вот так должен выглядеть твой редюсер

Я то уже понял. Я только не понимаю, почему другие не понимают, чего я не понимаю, точнее не понимал. ?

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

Разве это эффективно? Вызывать все редьюсеры? А если из 100 редьюсеров нужен лишь 1, зачем вызывать остальные 99?

Нет конечно, это жесть

Чем меньшая часть стейта обновляется - тем лучше

Вот так должен выглядеть твой редюсер

Да я эту концепцию понял. Просто меня не покидает чувство, что можно было как-то обойтись без "холостых" вызовов редьюсеров.

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

Да я эту концепцию понял. Просто меня не покидает чувство, что можно было как-то обойтись без "холостых" вызовов редьюсеров.

Помни, что редукс состоит из 100 строк кода

Ничто не мешает написать тебе его самому)

Больше, из-за доки

Ничто не мешает написать тебе его самому)

Есть пара нюансов

Больше, из-за доки

Та то не важно уже)

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

Йеп

Поэтому лучше не пилить велосипеды и юзать готовое

Нет конечно, это жесть

Разве оно не так сейчас работает?

Так

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

Самое весёлое, что предела у сложности нет

финальной точкой становится одна из нерешённых проблем computer science

Люди не видят проблемы, ведь для браузера расплюнуть, вызвать 99 функций, чтобы найти сотую, ту самую, которая повлияет на стейт. Повезло вам, жить во времена мощных вычислительных машин. А пару десятков лет назад, это было бы проблемой.

Подскажите есть ли смысл держать фронтэнд (реакт) на одном порту, а бекэнд (нода) на другом? Испрользуется такое в продакшене? Если используется, то как избежать разрешения cors?

JWT

Нет конечно, это жесть

Почему жесть, больше в call stack операций, но наверняка и преимущества есть перед решениями, которые бы точечно редьюсеры вызывали

ERROR: S client not available

:)

ну и плюс настройка корсов

Подскажите есть ли смысл держать фронтэнд (реакт) на одном порту, а бекэнд (нода) на другом? Испрользуется такое в продакшене? Если используется, то как избежать разрешения cors?

Ставишь пакетом cors и разрешаешь все - не подтйдет?

Ставишь пакетом cors и разрешаешь все - не подтйдет?

А в таком случае 304 не обработать без запроса

Подскажите есть ли смысл держать фронтэнд (реакт) на одном порту, а бекэнд (нода) на другом? Испрользуется такое в продакшене? Если используется, то как избежать разрешения cors?

Ставишь за общий прокси выносишь апи на site.com/api/

я как-то привык на api.site.com выносить

А в таком случае 304 не обработать без запроса

А проверки на статускод?

Люди не видят проблемы, ведь для браузера расплюнуть, вызвать 99 функций, чтобы найти сотую, ту самую, которая повлияет на стейт. Повезло вам, жить во времена мощных вычислительных машин. А пару десятков лет назад, это было бы проблемой.

ты нас тупостью что ли затроллить решил?)))

Ставишь за общий прокси выносишь апи на site.com/api/

Прокси писать в прожект.джон? Если да, то не получается приконектить к домену... делаю по инструкции, но пишет хост инвалид)

ты нас тупостью что ли затроллить решил?)))

Нет, я на твоей тупости спекулирую :)

Люди не видят проблемы, ведь для браузера расплюнуть, вызвать 99 функций, чтобы найти сотую, ту самую, которая повлияет на стейт. Повезло вам, жить во времена мощных вычислительных машин. А пару десятков лет назад, это было бы проблемой.

Ну так собери команду и напиши либу более оптимизированную, в чем проблема?

Прокси писать в прожект.джон? Если да, то не получается приконектить к домену... делаю по инструкции, но пишет хост инвалид)

На проде в сервер, типо нжинкса

ты нас тупостью что ли затроллить решил?)))

даю РО, в следующий раз бан

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

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

То есть ты понимаешь, о чем я?

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

У тебя много проектов с 1к редюсеров?

Да

Подскажите, какой примерно размер бандла реакта+реакт.дом минифицированный?

Да

Ну хоть кто-то

нет возможности загуглить

Подскажите, какой примерно размер бандла реакта+реакт.дом минифицированный?

30кб

30кб

спасибо

Люди не видят проблемы, ведь для браузера расплюнуть, вызвать 99 функций, чтобы найти сотую, ту самую, которая повлияет на стейт. Повезло вам, жить во времена мощных вычислительных машин. А пару десятков лет назад, это было бы проблемой.

Меня гораздо больше волнует over 99 вызовов mapStateToProps и shallowEqual, когда все коннекты на изменение стора реагируют

Всем привет. Я собираюсь писать объект в стейт редакса на mouseMove(), будет ли это медленно работать?

да

У тебя много проектов с 1к редюсеров?

Практически во всех проектах частота создания эвентов достигает десятков в секунду

Ну так собери команду и напиши либу более оптимизированную, в чем проблема?

Я хочу, чтобы ты это сделал. Вместо меня

Всем привет. Я собираюсь писать объект в стейт редакса на mouseMove(), будет ли это медленно работать?

Да, это самодидос настоящий, сделай debounce

Да, это самодидос настоящий, сделай debounce

тротл скорее

Практически во всех проектах частота создания эвентов достигает десятков в секунду

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

Да, это самодидос настоящий, сделай debounce

Мне нужно двигать обьект по странице, максимум смогу 16 милисек сделать