The Mistakes We Fixed

We at Treebo love React Native, and over the past 2 years of us using it, we made a lot of mistakes. Some we fixed, and some we continue to fix. In this talk, we want to share with the community our experience and journey of building a React Native App for scale.

Transcript

1. The Mistakes We Fixed A Retrospective of the Treebo Mobile App Kashish Grover App Developer, Treebo
2. About me • Building with React Native for about 2 years • Active speaker in the React Bangalore community • Also like to play drums , drink beer , and cook @_kingofnull @kashishgrover
3. About me at Treebo • 1 year experience here • Senior Software Engineer • Responsible for our consumer app • Joined after the app was orphaned • Made it my aim to fix it and bring it up to standards @_kingofnull @kashishgrover
4. React Native at Treebo • We ❤ React Native • Using it for about 2 years • Consumer app is fully React Native • Have made mistakes, and fixed some • Have learned a lot
6. I want to share our experience with you
7. Our 8 mistakes 1. Library Stupidity 2. Chaotic Rules 3. Bad Debugging Experience 4. No CI/CD or Test Automations 5. Unsystematic Components 6. Janky Performance 7. Poor Production Performance Monitoring 8. Engineering Baggage
8. But now,
9. Let’s begin
10. Mistake #1
11. Library Stupidity • Chose libraries poorly • Bugs, crashes & performance issues • All that unused 80% of some component library • Introduced engineering baggage • Some we chose back then haven’t been updated since • Got stuck with some for a long time // TODO
13. Library Wisdom • Some had to be fixed • Some had to be removed • Some had to be updated • Some are still there • We built abstractions (Components, Utils, Services) // DONE
14. Mistake #2
15. Chaotic Rules • Used to be in a separate repo • Did not follow same linting guidelines as other projects • Made it difficult for rest of the frontend to work on app • Improper guidelines around app versioning • Commits weren’t tagged // TODO
16. Orderly Rules • Migrated the app to our frontend monorepo • Follows same linting guidelines as all our other frontend projects • Shares utils and services with other frontend projects. • Possibility of shared business logic! • Follow simple semantic versioning of Major.Minor.Patch • Commitizen for git to properly tag each commit • Still update app versions manually. Aim to automate this using commitizen tags. // WIP
17. Version Patch Number Version Minor Number
18. Mistake #3
19. Bad Debugging Experience • Local debugging was done using Chrome Dev Tools and console statements • Crashlytics reports were paralysed. Uploading sourcemaps didn't help • Didn’t know how to reproduce crashes • Crashlytics would point to obfuscated code • Luckily for us we were using testID and accessibilityLabel // TODO
20. Open bundle Copy line to new file Pray for something familiar Find reported obfuscated line number Spend more hours trying to reproduce crash Old Production Debugging Method
23. Good Debugging Experience • Locally we use React Native Debugger and Reactotron • In production we use Bugsnag and we love it • Proper slack alerts for crashes and crash spikes • Crashlytics gives correct line numbers • Sourcemaps work now!
 
 Clean builds deserve clean bundles & sourcemaps
 
 Sourcemaps are uploaded right after the build by our CI/CD setup // DONE
25. Mistake #4
26. No CI/CD or Test Automation • Certain crashes were device specific • Used to release from my work laptop • All production builds had to be manually tested • Certain test flows would get missed • Uncertainty was bad for business // TODO
27. Yes CI/CD and Test Automation • Found Bitrise • Built Test Automation workflows using Appium and Amazon Device Farm • Nightly builds - daily test reports • Slack alerts for everything • High predictability = trust = good business • QA resources freed up for better work // DONE
28. Beautiful Bitrise
29. Amazon Device Farm Nightly Regression Test Report
30. Mistake #5
31. Unsystematic Components • Project structure was confusing • No single pattern of writing pages (screens) • A heavy mix of third party and local components • Really big components - bad readability • No ground rules • Few common basic components between pages // TODO
32. The right project structure that worked for us Before (By Type) Now (By Feature)
33. Systematic Components • Built our own component library • Leaf UI - Our Design System • Ground rules were set • All basic components go to Leaf UI • No direct use of styles, unless absolutely necessary • All styles should be applied via Leaf UI “enhancers” • Third party component libraries were slowly removed, or used through Leaf UI • Could achieve UI scaling through our design system • Continuous Refactoring // ALWAYS WIP
34. Leaf UI at play Passing down styles using enhancers Numbers are multiples of 8
35. We are ALWAYS refactoring
36. Mistake #6
37. Janky Performance • Highly janky scroll on Home Page and Search Page • Visible Factors • Library rendering SVGs using WebView • Lazy loading • Animations • Proper use of Flex • Invisible Factors • Overdraws! // TODO
38. Better Performance • Got rid of WebViews (Huge gain) • Optimised lazy loading in FlatList - render components onEndReached • Optimised onEndReached by using Flex properly • Overdraws were cause by excessive use of backgroundColor in parent components • Animations were optimised - can be improved further // WIP
39. About Overdraws True Colour: No overdraw Blue: Overdrawn once Green: Overdrawn twice Pink: Overdrawn three times Red: Overdrawn four or more time “Overdraw refers to the system’s drawing a pixel on the screen multiple times in a single frame of rendering. For example, if we have a bunch of stacked UI cards, each card hides a portion of the one below it.”
40. About Overdraws • The fixes can be too easy to be true • High return of investment • Mostly it’s just background colour
41. Android Overdraws - Before
42. Android Overdraws - Now
43. Demo - Results in Treebo App
44. Mistake #7
45. Poor Production Performance Monitoring • Didn’t use any statistics to measure performance in production • Difficult to convince product to allow improvements without stats • No way to relate performance improvements with conversion improvements • No way to tell connect app performance with API performance • Were already using NewRelic for other platforms // TODO
46. • Integrated NewRelic’s SDK with Native Android and prepared dashboards • Connected Segment Analytics events with NewRelic performance metrics • Now able to connect App Performance with API Performance • TTFI (Time To First Interactive) has become a benchmark • Google Play Console can be incredibly useful Better Production Performance Monitoring // WIP
47. CENSORED
48. CENSORED
49. CENSORED CENSORED
51. Mistake #8
52. Engineering Baggage • Navigation library had to be replaced • Certain old packages prevented React Native upgrade • Old React Native version prevented package updates • Were stuck in a loop • Had to take it slow // TODO
53. Fixing Engineering Baggage • Replaced old navigation library with the latest React Navigation • Slowly got rid of ancient packages • Absorbed what we couldn’t remove but needed • Now upgrading to latest React Native version (0.58.1) // WIP
54. My codebase is like my room It gets dirty I clean it It gets dirty again But I love it anyway
55. Where we are today… • Updated stack • Much less dependency on third party libraries • Great debugging flow • Proper CI/CD setup • Automated regression testing • Codebase thriving in monorepo • A great component library • Easy to read components
56. Where we are today… • Far superior navigation experience • Far superior performance • Animations & interactions can be better • Much better understanding of native code & how RN works • Actively monitoring performance • Continuous improvement
57. Where we wish to see React Native • Not having to look at iOS/Android code • Great performance out of the box • More warnings - Prevent overdraws in Android! • More warnings - Prevent bad practices • An easy to upgrade tech stack • Improved Animated performance • Easy to implement gesture system
58. And…
61. Questions?