When writing large scale react native app it’s always fun to blame rn for everything that is wrong in our lives. However, what we keep finding, again and again, is that for most of the cases. Writing better performant react code can fix our performance issues. In the last couple of years our team built a huge production app in react native. In this talk I’ll go over some of our lessons learned in regards of react native performance and how to improve your app’s performance subsequently.

1. Ofir Dagan, R&D Manager @Wix - 22/03/2019
medium.com/@ofirdagan twitter@ofirdagan2 linkedin/ofir-dagan github.com/ofirdagan
(Don’t)
Blame it on React Native

2. We are many developers from
different groups working on
one app
My Background For This Talk
I’ve been writing React Native
for a while now
Our lessons learned are
useful for anyone who writes
in React Native
I work on a huge app

3. When I think about
React Native
I want to...

4. But
eventuall
y I just...

5. I’m not gonna lie

6. writing React Native
is no walk in the park

7. because
…
IT ADDS AN
ABSTRACTION
OVER NATIVE
…
PERFORMANCE
SUCKS
…
IT’S SINGLE
THREADED
…
IT’S A CHALLENGE TO
DO THINGS THAT
SHOULD BE EASY IN
REGULAR NATIVE
APPS
…
MORE
writing React Native
is no walk in the park

8. but you already know this by now

9. Our only option
for truly performant apps
is to write
pure native apps.
- Any react native app developer

10. It is an option,
but not the only one.

11. What if I told you
We can solve 90% of the problems in JavaScript

12. The Send button

13. It turned out
we rendered
the entire chat
rooms list, even
when we were
inside the chat
room screen.

14. All because of
one “new” word
in a selector*
* Selectors are helper functions that we use in mapStateToProps

15. Messages
arrive in
delay

16. before

17. after

18. componentWillReceiveProps
was called too many times
and each time
it triggered a new render
due to a call to setState.

19. Typing animation

20. We tried JavaScript.

21. We tried JavaScript. It sucked.
* You can’t use native
driver if you want to
change the height of
the object. More
about it

22. We went native!

23. We went native! It sucked*.
* Integrating native
components into a
react controlled
screen has its
problems

24. Turns out
we could achieve
the same slickness
using LayoutAnimations

25. Module load time

26. Turns out that
using lazy require
can save a lot of
time.

28. And the list
goes on
Top level comp prop change
Duplicate network requests
I'm sure you can think of
examples of your own

29. It’s not React Native’s fault!
That’s just how
React and Javascript work.
It’s just a lot easier to see
the consequences in RN.

30. GOOD CARD
CardHeader
Input
GrandChild
Card
CardContent
CardFooter
https://github.com/ofirdagan/good-card-bad-card

31. It’s up to us.
We must be much more
careful and responsible react developers

32. It’s up to us.
Know your crucial app flows
and monitor them
Never write anonymous
functions as props
Know your components*
*Don’t just use “PureComponent” and forget about it
Know your reducers
Know your components’
lifecycle methods*
* Each component is different

33. ReducerDB
Many writes to one field
Many reads to another field
→ Any write locks the table
and delays the read
Separate to two tables
A lot of actions that change a
field in the state
Not many reads for this field
→ Any state change triggers
the rendering cycle
Separate to two reducers
Problem
Solution

34. F*** this!
This is too hard

35. Help is just around the corner
* Make sure to include only your components

36. RN FWT
Thank You
medium.com/@ofirdagan twitter@ofirdagan2 linkedin/ofir-dagan github.com/ofirdagan
This talk in depth on medium: https://hackernoon.com/dont-blame-it-on-react-
native-2eb0be3000b6