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
- 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
- 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
- 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
Editor's Notes
- #3: Talk here about things like: Hiring top talent is difficult on an old framework Updates on the framework are limited Deep knowledge of the frameworks in and outs are limited in candidates (even you hire them) Tooling is sub-par by comparison with React. Developer productivity is suffering.
- #4: Talk here about things like: Transferwise autonomous teams and what that means in decisions The role of the frontend guild in coordinating these decisions Talent
- #6: Well, not so fast. Unless your AngularJS app is one small page or almost a static website then it's not a good idea. There will be dragons. Think of the user. While you rewrite to the new framework you will stop adding features and supporting your old codebase. That's a big negative. It can't be happening for too long. You need to make sure you maintain all the existing functionality. Don't introduce new bugs.
- #13: Regarding the update to 1.7. You donโt need to do that if you plan to do the replatform fast. 1.5 should be sufficient. The benefit of moving to 1.7 is the LTS from Angular and the security updates youโll get. Regarding the move to components. You can make directives work but Angular2React requires components: https://github.com/coatue-oss/angular2react
- #14: Regarding tests: Mention that we chose to move away from Karma and Jasmine to Jest and Enzyme. We did it for future reuse in React. Seriously. If you donโt write more tests the entire thing will not be as robust as youโd like to.
- #15: Mention here that Legacy Angular Module is an npm package that all Angular apps can use Mention why it was bad. Because changes were happening to 2 different code bases and we ended up missing features in both. It was terrible.
- #16: Mention: Your sub-apps should be visible in your package.json
- #19: Here give an example of TransferWise Activity page. Our complexity is in the leafs of the component tree. Regarding state, talk about different options like prop drilling, redux or hooks. Whatever you choose you can change it later.
- #20: Speak
- #21: About Angular2React: This tool will take one Angular component and it will turn it to React component. The caveat is that it only deals with one way data bindings (`<`). So now the refactoring we did in section one pays dividends. It's super easy to wrap your Angular components and drop them in React. If you chose to go Bottom-Up there is react2angular too. Does the opposite thing. About the tests: Mention that to make the tests pass you should simply change all the Angular specific things to React. Using Enzyme and Jest helps. Make sure you donโt delete any tests. You need all the discipline of the world at this point.
- #23: For SSR AngularJS: Mention the window object where Angular attaches itself. Also mention the window.config that TransferWise used to save configuration elements for the different components.
- #24: Regarding the window: Mention that you need to be generally defensive in your code. You need to add checks whether window is available or not in certain cases. Mention an example from TW where we saved config to window.
- #26: * If you reach this point you did it! You have an app in production. A hybrid. Your next steps are now to keep unappealing the onion further. * Take the next component, rewrite that in React, wrap its children with Angular2React * Move tests * Release * Repeat.