The document discusses the challenges of managing nested data structures in React with Redux, particularly stemming from MongoDB data prejoining and aggregation, which leads to performance issues. It presents solutions such as store normalization and composable selectors that help create thin actions and improve performance by reducing data processing in components. Key recommendations include normalizing the store, utilizing composable selectors, and implementing memoization to enhance scalability and efficiency.

1. React + Redux: scalability & performance
Vitaliy Redko
Ezetech

2. THE PROBLEM
We mostly get nested data structure
from backend like this:

3. PROBLEM REASONS
● Data prejoining on MongoDB document level
● Data aggregation on MongoDB query level

4. THE PROBLEM
BUT it leads us to the headache while
dealing with nested data structures in
Redux actions or React components

5. THE PROBLEM
And we start (to do stupid things):
● to write FAT ACTIONS;
or / and
● to POLLUTE REACT COMPONENTS with heavy
data processing calls

6. THE PROBLEM
PERFORMANCE LEAKS:
● data processing in React components on
each render()
● nested data manipulation in actions

7. SOLUTION?

8. SOLUTION
● Store normalization
● Composable selectors

9. STORE NORMALIZATION

10. STORE NORMALIZATION
When STORE is NORMALIZED
that gives us the possibility to write
thin actions & pure reducers
with no logic for nested data processing.

11. COMPOSABLE SELECTORS
SELECTORS are the functions we use to fetch data from
store as props for React component:

12. SELECTORS SCHEMA
NORMALIZED
STORE
SELECTORS
REACT
COMPONENTS
ACTIONS

13. COMPOSABLE SELECTORS
Don’t treat selectors as getters for store slices
Treat selectors as props composition layer

14. COMPOSABLE SELECTORS
BENEFITS:
● We save less data in store
● We get rid of data processing in React

15. COMPOSABLE SELECTORS
reselect killer features:
● selectors memoization
● selectors composition (nesting)

16. COMPOSABLE SELECTORS: RESELECT

17. COMPOSABLE SELECTORS

18. COMPOSABLE SELECTORS

19. MULTIPLE COMPONENTS (!)

20. MULTIPLE COMPONENTS (!)
To prevent memoization lose with multiple components:
1. Wrap your mapStateToProps():

21. MULTIPLE COMPONENTS (!)
To prevent memoization lose with multiple components:
2. Wrap your selectors:

22. TESTING: UPDATE EVERY (WS)
nested reducers flat store & composable selectors
20,7% faster
94.1% faster

23. TESTING: PAGE RELOAD
nested reducers flat store & composable selectors
16.2% faster
33.2% slover

24. TESTING: ALL CONTENT UPDATE
nested reducers flat store & composable selectors
48.8% faster
62.1% faster

25. REACT PERFORMANCE TIPS
Don’t use this.state within setState()

26. REACT PERFORMANCE TIPS
Get rid of unnecessary rerendering
(shouldComponentUpdate):

27. REACT PERFORMANCE TIPS
Get rid of unnecessary rerendering
(lodash memoization):

28. REACT PERFORMANCE TIPS
Get rid of unnecessary rerendering
(fast-memoize memoization):

29. REACT PERFORMANCE TIPS
Get rid of unnecessary rerendering
(don’t create props within render() - use defaultProps):

30. SUMMARY TIPS
SELECTORS
● Place your selectors close to reducers
● Wrap selectors and mapStateToProps()
into function to use with multiple
component instances
● Reuse selectors as input to high order
selectors

31. SUMMARY TIPS
STORE
● Normalize your store
● Split your store on simplest slices
● Separate your filters as store slices
● Don’t put derived data into store

32. BENEFITS
● Scalability
● Performance gain
● Ability to use derived data from selectors
and save less data in store

33. TOOLS
STORE NORMALIZATION:
● normalizr
https://github.com/paularmstrong
/normalizr
● redux-orm
COMPOSABLE SELECTORS
● reselect
https://github.com/reactjs/reselect
● fast-memoize
● ramda
● redux-orm

34. ABOUT ME
Vitaliy Redko
email: vitaliy.redko@gmail.com