В умелых руках с redux не должно произойти проблем с производительностью. Ну а в неумелых, возможны проблемы и с mobx. А еще стоит помнить что redux весит 7кб, в то время как mobx 55кб (ну если быть честным то связка react-redux + redux весит 21, что все равно в 2 раза меньше). Я не сторонник не mobx, не redux, но на мой взгляд можно выявить недостатки и преимущества в обоих случаях.
Тут стоит уточнить, что мемоизация (реселектом или нет не важно) для mapStateToProps нужна всегда, когда вы генерируете что-нибудь новое. Даже если это что-нибудь новое это просто создание простого объекта.
Согласен, но я бы даже сказал, что только с новыми объектами в mapStateToProps она и нужна. Разработчики react-redux позаботились о базовых принципах производительности и в случае когда mapStateToProps возвращает примитивы, лишних рендеров не произойдет, потому что будет произведена проверка с целью предотвращения ненужных рендеров. Подробнее из доки react-redux.
Так же, стоить помнить что вызов mapStateToProps происходит очень много раз (любой вызванный action вызывает mapStateToProps подключенных компонентов, подробнее), и стоит хорошенько подумать перед тем как наделять его какой-то логикой. Возможно в момент работы action/reducer имеет смысл передать в store уже максимально готовую структуру данных подготовленную для рендера, а возможно имеет смысл перенести эту логику в сам компонент. Во многих случаях достаточно просто избегать создания новых массивов и объектов в mapStateToProps что бы не создавать потенциально проблемных компонентов.
P.S. Думаю вы это и так понимаете, но на всякий случай проясню эти моменты для тех кто забредет в ветку комментариев.
Совет 2 Используйте reselect там, где происходят многократные вычисления.
Совет 3 Не используйте reselect там, где не происходит вычислений.
Как же я рад это слышать, как хорошо что это наконец подмечено. На мой взгляд это важно не только из-за засорения памяти, но и из-за серьезного удара по читабельности кода. Чем больше и сложнее структура селекторов, тем труднее будет разобраться в этом лабиринте в будущем. На мой взгляд многие разработчики слишком увлечены селекторами и создают очень сложные структуры, которые очень сложно расширять и поддерживать, и на деле оказывается, то больше половины селекторов фактически никакого прироста производительности не приносят, но вот код усложняют значительно.
В умелых руках с redux не должно произойти проблем с производительностью. Ну а в неумелых, возможны проблемы и с mobx. А еще стоит помнить что redux весит 7кб, в то время как mobx 55кб (ну если быть честным то связка react-redux + redux весит 21, что все равно в 2 раза меньше). Я не сторонник не mobx, не redux, но на мой взгляд можно выявить недостатки и преимущества в обоих случаях.
Согласен, но я бы даже сказал, что только с новыми объектами в mapStateToProps она и нужна. Разработчики react-redux позаботились о базовых принципах производительности и в случае когда mapStateToProps возвращает примитивы, лишних рендеров не произойдет, потому что будет произведена проверка с целью предотвращения ненужных рендеров. Подробнее из доки react-redux.
Так же, стоить помнить что вызов mapStateToProps происходит очень много раз (любой вызванный action вызывает mapStateToProps подключенных компонентов, подробнее), и стоит хорошенько подумать перед тем как наделять его какой-то логикой. Возможно в момент работы action/reducer имеет смысл передать в store уже максимально готовую структуру данных подготовленную для рендера, а возможно имеет смысл перенести эту логику в сам компонент. Во многих случаях достаточно просто избегать создания новых массивов и объектов в mapStateToProps что бы не создавать потенциально проблемных компонентов.
P.S. Думаю вы это и так понимаете, но на всякий случай проясню эти моменты для тех кто забредет в ветку комментариев.
Как же я рад это слышать, как хорошо что это наконец подмечено. На мой взгляд это важно не только из-за засорения памяти, но и из-за серьезного удара по читабельности кода. Чем больше и сложнее структура селекторов, тем труднее будет разобраться в этом лабиринте в будущем. На мой взгляд многие разработчики слишком увлечены селекторами и создают очень сложные структуры, которые очень сложно расширять и поддерживать, и на деле оказывается, то больше половины селекторов фактически никакого прироста производительности не приносят, но вот код усложняют значительно.