From Angular to React

Jack talks about the reasons why he's moving a large scale app from Angular to React and the practicalities of doing so in a less risky, flexible manner that hasn’t left him and his team rebuilding from scratch, but implementing incrementally.

Transcript

1. From Angular to React by @Jack_Franklin
2. From X to Y My experience migrating complex software (Regardless of the tech choices).
4. Music discovery + ticket selling
9. The Store
10. — Started 2 years ago, built on Angular 1 — Primarily used within iframes — Added Redux to be used alongside Angular — 2 main developers no longer with the company — Very heavy on features — Our main source of revenue — Tickets being sold constantly — Used by our flagship clients (Adele, RHCP and others)
11. The store works well.
12. But changing it is very tricky.
13. — Test coverage not bad, but not great. — Unclear which features are actually needed — Many different use cases — Regular general admission tickets — Reserved seating tickets — Queued tickets for big sales — VIP tickets ("meet and greet") — Merchandise addons (Ticket + album = 10% discount) — We have a lot of stores in the wild
14. We want to be in a position to iterate quickly on this product, but with the current codebase we can't.
15. What do we do?
16. 1. Start completely from scratch 2. Stick with Angular 1, and rewrite complex parts. 3. Migrate from Angular 1 to 2/3/4 4. Migrate bit by bit to something else
17. Start completely from scratch ! — We can't afford to not work on bugs, improvements on the existing product — The Angular app began as a big rewrite - business wwouldn't like it to happen again
18. Stick with Angular 1 ! — Angular 1 is reaching its end - focus is now on Angular 2 and beyond. — Not much developer expertise in Angular across Songkick
19. Migrate from Angular 1 to 2 and beyond ! — Not much developer expertise in Angular across Songkick — Not many Angular evangelists at Songkick — Apparently David Moyes likes Angular
20. Migrate bit by bit to something else ! — Allows us to work on bugs in existing code whilst migrating others — Allows us to build new features whilst migrating — We can experiment by moving piece by piece and try different approaches — Current stores continue to function correctly — We can move quickly and release small parts at once - avoiding risky big bang releases — Downside: introduce some migration specific code
21. What to migrate to?
23. ! I and my team are all familiar with React ! Another, newer, product at Songkick was built with React ! React leaves you with less framework specific code ! It's Rafa Benitez's framework of choice
24. Note: I am not saying that Angular is a bad choice, or that you shouldn't use it. Just for us, it wasn't the best fit.
25. So, we've decided to migrate, and what to migrate to.
26. Now for the hard part — 40,000 lines of JavaScript — Most of those lines are tied directly to Angular — Many dependencies outdated due to lack of maintanance over past 6 months — A store that cannot be broken at any point (we sell tickets pretty much continuously)
27. The Theory Components (or directives in Angular)
31. The Plan
35. The theory is easy!
36. But more complicated in practice...
37. Angular and dependency injection
38. Angular 1 was built in a time where we had no module system in JavaScript, so it provided one.
39. // define your Foo object const Foo = {...} angular.service('Foo', Foo) // in another Angular thing function SomeController(Foo) { Foo.bar() ... } Angular will inject the Foo dependency into SomeController at runtime.
40. In ES2015 we have a module system (which Babel transpiles for us) const Foo = {...} export default Foo // in another file import Foo from './foo'
41. ES2015 modules are amazing cool super awesome (Come chat to me if you want boring details)
42. The step by step process of migrating an Angular directive to a React component
43. 1. Find all dependencies that the directive (or a dependency of the directive) injects.
44. 2. Migrate all of those one by one to React
45. But wait! You need to migrate localStorage-service.js away from Angular. angular.service('LocalStorage', function() { ... }) But this service is used in ~15 places in the app. And we want to release the migration in tiny chunks.
46. So, we can first pull the logic into a standalone thing: const localStorage = { ... }
47. And then export it so any non Angular code can just import it: const localStorage = { ... } export default localStorage
48. And then leave the small Angular wrapper: const localStorage = { ... } export default localStorage angular.service('LocalStorage', function() { return localStorage })
50. ! Existing Angular code can still use the local storage code without being aware it's changed ! New React components can import the module without any of the Angular boilerplate " We had to write a small amount of migration specific code
51. Migration specific code Code that you know will be deleted when the migration is finished. A neccessary part of the migration but you should keep it to a minimum.
52. So, we've migrated all dependencies away from Angular
53. But what about Angular's built ins? — $timeout is a wrapper around setTimeout — $window is a wrapper around $window — $q is a wrapper around Promise
54. Now we can migrate listingsButton- directive.js to React
55. import React, { Component } from 'react' class ListingsButton extends Component { render() { return ( <a href="" className="">Buy now!</a> ) } }
56. But how do we embed this within Angular? <li> <h2>Rihanna at The O2</h2> <listings-button url="...">Buy now</listings-button> </li>
58. ngReact lets you embed React components within Angular applications It is the piece of code that enables our entire migration strategy to work. Remember: you can render many React apps on a page in any place you want.
59. With ngReact <li> <h2>Rihanna at The O2</h2> <react-component name="ListingsButton" props="..." /> </li>
60. We can continue this strategy, migrating the other components to React: <li> <react-component name="ListingsTitle" props="..." /> <react-component name="ListingsButton" props="..." /> </li>
62. And now we can migrate this into one big React component! import React, { Component } from 'react' import ListingsTitle from './listings-title' import ListingsButton from './listings-button' class ListingsItem extends Component { render() { return ( <li> <ListingsTitle ... /> <ListingsButton ... /> </li> ) } }
63. And update our template <react-component name="ListingsItem" props="..." />
65. Maintaining functionality — At no point can the store be broken. — Newly migrated code must have exactly the same functionality — Put simply: users must not notice any difference
66. Unit Tests — Existing Angular tests can be migrated as the services move away from Angular — Used as an opportunity to add test coverage
67. React components are very testable import React from 'react' import ListingsDate from './listings-date' import { mount } from 'enzyme' describe('ListingsDateComponent', () => { describe('an event with just a start date', function() { const event = { event_date: { date: '2016-01-01' } } const wrapper = mount(React.createElement(ListingsDate, { event })) it('formats the month correctly', function() { expect(wrapper.find('.date-block__seg--month').text()).toEqual('Jan') }) it('formats the day correctly', function() { expect(wrapper.find('.date-block__seg--day').text()).toEqual('1') }) it('formats the year correctly', function() { expect(wrapper.find('.date-block__seg--year').text()).toEqual('2016') }) }) })
68. Unit tests are good because they provide quick feedback and can test at a very granular level.
69. Unit tests (in our case) are bad because when you migrate code, you migrate tests Therefore, they are not technically proof that everything works as before.
70. Acceptance tests
72. — Automated tests that are run using Protractor & Selenium — ! They test the entire system, with no faked API calls or fake data — ! This means they are entirely independent of the migration — " They can flake sometimes and are slow to run
73. Because they are slow to run, we keep acceptance tests to our core user journeys
74. They run on every single build, and they have to pass to enable us to deploy
75. The pipeline
77. Track user activity to ensure deploys are successful
78. !
79. Unfortunately, fires will happen during this process.
80. To date we've had 3 fires caused by migration: — One was down to bad data in our test environment not matching "real life" — we have now fixed the test data to replicate "real life"
81. To date we've had 3 fires caused by migration: — One was down to a particular journey not being covered by any unit or acceptance tests — it is now covered by tests
82. To date we've had 3 fires caused by migration: — Another was down to timezones ! — we know to check our site on different timezones when making changes that might hit this problem
83. You have to communicate how and why a fire happened, but how you'll prevent it next time Because you can never ever release bug free so!ware.
84. Momentum and prioritisation We knew this migration was going to be at least 6 months, more likely closer to a year.
86. Mix larger, multi-week work with short, 1-2 day work, to keep momentum.
87. <1 day's worth of work
88. 1 week's worth of work
89. Break down large work into small PRs
90. Release early, release often
91. The boy scout rule Always leave things better than when you found them.
92. Mix visual work + "under the hood work"
93. Have some form of tracking or metrics, however rough it is
96. Prioritisation One of the core goals of this migration was to make the code easier to work on, add features to and fix bugs with more confidence.
97. Pick work based on bugs and churn rate, not code quality Churn rates: the amount of times a file is changed
98. Code quality Churn rate Bug rate Priority Bad Low Low Low Good Low Low Lowest Bad Medium High High Good Low High High Bad High High Highest
99. Remember: you can go back and rewrite migrated code Don't aim for perfection when you migrate.
100. Communicate to the business Specifically: Why?
101. "Right now when you ask us for a new feature, or bug fix, it's hard and takes a long time to fix and have confidence that we've not inadvertently broken anything else" "This migration will enable us to have a leaner, stable codebase which we will have more confidence in and be able to build features and fix bugs more quickly" "It will enable us to onboard new developers to the team easily and have them contributing quicker than with the current codebase"
102. xf buddies
103. Tooling Because you can't do a JavaScript talk without talking about tools. 1 1 And I don't mean John O'Shea or David Moyes
104. Migrations are a good excuse to reconsider tooling And also provide a break from working on the actual user codebase.
105. From Karma to Jest Our tests were running on Karma, but we wanted to try Jest from Facebook. We had (at the time) ~600 tests across ~130 files. So we started migrating them!
107. From Browserify to Webpack The store was built using a combination of Makefiles, misc command line tools and Browserify. This was hard for us to follow and was very brittle. We moved to Webpack which lead to reduce build times, smaller bundles and got us more inline with the rest of the community.
108. By providing a mix of migration tasks (big, small, visual, "under the hood", tooling), we're able to keep work fun and interesting over a (so far) 6 month period, with probably 6 more months to go.
109. How's it going so far? We estimate to be ~ 35% done. Most of the core visual journey is done. All forms that users interact with are now in React. We've had very few bug reports on any of our new React code, compared to the old Angular code.
111. We've done some stuff well, and I expect to learn we've done some stuff badly.
112. Will you ever be done? Our natural "finish" point is when we've removed Angular from our codebase. But when that happens we'll keep refactoring & revisiting old code as we fix bugs and introduce new features.
113. Takeaways
114. 1. Don't migrate for the sake of it "Framework X is now out of date" is not a valid reason!
115. 2. Plan, plan and plan again
116. 3. Cross business communication is more important than you realise at first
117. 4. Prioritise based on pain points in your current application
118. 5. Mix up tasks based on difficulty + visual/tooling/etc to keep it interesting
119. 6. Have some rough metrics that you can use to track progress internally
120. 7. Don't be surprised if you end up rewriting some migrated code
121. Thank you :) Questions? jack.franklin@songkick.com Want to get involved? We're hiring (in London) jack.franklin@songkick.com