Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Mistakes We Fixed

Kashish
February 01, 2019

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.

Kashish

February 01, 2019
Tweet

Other Decks in Programming

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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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.”
  20. About Overdraws • The fixes can be too easy to

    be true • High return of investment • Mostly it’s just background colour
  21. 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
  22. • 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
  23. 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
  24. 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
  25. My codebase is like my room It gets dirty I

    clean it It gets dirty again But I love it anyway
  26. 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
  27. 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
  28. 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