A journey of moving the TransferWise activities page from AngularJS to React.

1. From AngularJS to React.
A journey of moving the TransferWise activities page to React.

2. A little bit of history
● Transferwise started as a big Grails app
The frontend was written inside gsp files. 😱
● When I joined we moved the frontend to AngularJS
That was 2016 and everyone was using AngularJS. 🤔
● Cue 3 years later...
It’s 2019. No one uses AngularJS. No one wants to work on it. 😳
2/25

3. Why React? Why not X.
● Things happened organically.
Apps start appearing next our main AngularJS app. It was only natural.
● Framework design patterns.
While AngularJS design patterns was very good, these days React is
giving teams a lot more modern options.
● Tooling
With tools like React dev tools, frameworks like redux, hooks, NextJS etc
teams are way more productive than they used to be.
● AngularJS is not being actively developed
Current LTS version is 1.7. Not likely to see more versions or fundamental
updates coming anytime soon.
3/25

4. Let’s rewrite everything!
4/25

5. Avoid full blown rewrites.
We want to do this iteratively.
We need to maintain the existing functionality.
5/25

6. “The goal of refactoring is to modernize
a system while retaining and extending
the value of the legacy investment.”
https://en.wikipedia.org/wiki/Software_mode
rnization
6/25

7. The big paradox.
7

8. You are doing this because you want to get
your customers off the old codebase.
8/25

9. You want to work less on the old. You want
the productivity gains of the new.
9/25

10. You can’t yet.
10/25

11. An example of a big Angular app
11/25

12. The big refactoring
● Old codebase maintenance
The reality is that most codebases that need replatforming have a fair bit of entropy
in them. So you need one last big refactor.
● Upgrade AngularJS version
Upgrade to at least version 1.5 onwards that introduces Components. Ideally you will
go to 1.7*
● Get rid of old Angular patterns
Things like Directives should be replaced by components.
● Two way data bindings are evil
All your bindings in the components have to be one way data binds. That way you
make sure you are compatible with modern frameworks logic
12/25

13. More refactoring!!
● TESTS!!!!
You might think you have enough tests. You don’t! Focus mostly on unit
tests. Cover all the functionality if you can. Without them you will
introduce new bugs and you will lose existing functionality.
● Split down the app.
If it's too big start extracting the individual sub-apps, move them to their
own repositories and host them in a private npm, or just Github
packages.
● Create a package for your app
Whether you decide to go with npm or Github it doesn’t matter. Create a
package from your app that you can consume.
13/25

14. Learnings on copying code
● Code that tightly couples the apps.
In the case of the Activity page we had a bunch of modules reused across
all our apps.
● Violating DRY.
We decided to violate DRY, copy the code to our new extracted app and
move on. That made things more complicated.
● Extract and reuse.
If I were to do this again I wouldn’t copy the code. I would have spent the
time extract it and reuse it. It feels like it slows you down but it doesn’t.
● Legacy Angular Modules
We ended up doing the above. Legacy angular modules repo was born.
14/25

15. Final stretch
● Making the original big app a skeleton.
Ideally you want to be in a place where your original app is a simple
skeleton that consumes packages you’ve extracted.
● Getting rid of things like Grunt/Gulp.
Gulp/Grunt were awesome. They moved us forward. We chose to remove
them so we can do tree shaking with webpack and use webpack-dev-
server for our demo page.
● Create a fully functional, mocked demo page
Using webpack dev-server create a demo page. This will multiply your
productivity. The target should be doing doing npm start will start a
operational page of your app.
15/25

16. Example of your webpack config.
16/25

17. First glimpses of hope.
17

18. We can now start rewriting! 😃
● Top-Bottom or Bottom-Up.
You can start rewriting components from the bottom or from the top.
The decision depends from where your complexity is. Start from the
simplest.
● We started from the top.
Most of our business logic wasn’t in the root. It was in the leaves of the
component tree.
● Rewrite the root.
What used to me your main controller now can be a React component.
You also need to decide where to keep your state.
18/25

19. Don't optimise for performance yet,
optimise for correctness.
19

20. Bringing it all together.
● Dropping the rest of the Angular application in the new base React
component.
Thankfully Boris Cherny, a Facebook developer wrote a super handy tool
called Angular2React
● Remember the tests?
This is the moment where the future you should thank past you. Make
sure all the existing tests are passing. When done you know you didn’t
lose any functionality during the move.
● Making sure the demo page still works.
Keep the demo page operational. It’s a key element to verify that our app
is still functional.
20/25

21. Gotchas
● You can implement SSR now.
You won’t be able to SSR a lot at this point.
● Careful of the window!
AngularJS depends on the presence of the window. It attaches there all
the global scope. When using NextJS this doesn’t exist. Use next/dynamic
to dynamically load your AngularJS parts.
● Angular2React + React2Angular
We had trouble when in the middle of our component tree we had a
React component wrapped with React2Angular. Things didn’t work.
21/25

22. Server Side Rendering
● This is totally optional but it has huge benefits
Server side rendering can massively improve your experience. For us we
SSR the main page, the navigation elements and a shimer loading effect.
The UX was greatly improved
● It totally has drawbacks too.
While there are a lot of benefits it also makes things more complicated.
AngularJS requires hacks to render.
● Using NextJS and CRAB.
As a frontend guild we decided to SSR our apps using NextJS. We also use
a NodeJS backend middleware to provide our app with TransferWise
related configs and tools. The new Activity page uses that.
22/25

23. Releasing.
● This is emotional.
The above is a big undertaking. You now have a React app. It's big, it's
bloated, it has at least 2 frameworks in it but you have started an iterative
process.
● Dockerize it!
● Deploy!
23/25

24. DONE!
24/25

25. Or is it?
25/25

26. 26