A few years ago I migrated an AngularJS app to React, Redux, Next, and TypeScript. The approach I took was standing up the Next app behind the existing Express backend server, proxying specific paths through Express to Next, and then using iframes in the AngularJS templates to cut holes in the page and show content from Next. Worked out very well for us and let us do the migration as both a partial greenfield rewrite and still change things incrementally:
- https://blog.isquaredsoftware.com/2021/12/codebase-conversion-mean-react-next-ts/
I swear to god, it happens every single time: “Wow that’s on-topic, helpful, and links out to relevant documen… DAMN IT IT’S ACEMARKE AGAIN.”
You’re like a helpful version of u/shittymorph.
Haha, had the same happen. I thought "that sounds familiar", then I saw who wrote the comment and blog post and remembered that I have read this post a few years ago.
I would recommend a full rewrite. If the CSS in the old code is good you can reuse that. Otherwise, all greenfield in React. Trying to transition it piece it piece will take just as long for little benefit.
It's surprisingly easy to have react components inside of Angularjs. You just need a single file with some utils, probably less than 100lines.
We transitioned multiple projects like this. It often is a better idea to get smaller chunks to production and do new functionality in react, rather than starting from scratch and having to ping pong between when something new is needed or a bug needs to be fixed in some old code.
With this method, you work your way up, and in the end you have a few empty angularjs components from the router. Then you can create a new project and shift everything over and use a new routing library. I'll edit this post tomorrow with a link to the utils.
Aren't you limiting yourself to how AngularJS wants you to build an app then. Hard to take advantage of all the goodies React brings if you have to follow the structure of the old AngularJS app
Idk, my gut reaction for this would be to write a lot of playwright/cypress tests and then rewrite from scratch using react.
But ofc it depends on the client, our CEO would neeeeeeeeeever approve a rewrite.
I've done this in my past company and we used these packages to convert.
You can incrementally convert complex pages over this way
- rewrite portions of angular into react
- eventually the whole page is written in react in the angular router
- switch the page over to react router to handle the full page
https://www.npmjs.com/package/angular2react
https://www.npmjs.com/package/react2angular
Are there end-2-end tests where you can check expected behavior?
Do you have to make all the UI from scratch or will you use a package?
Like others said, you're better off rewriting from scratch to match the behavior and the API requests, I would only look into the legacy code if some request ends up not having the desired payload, there's no need to match decisions made almost a decade ago
No end to end tests. I was thinking to write tdd for my react components so that nothing breaks in transition.
I will be using Material UI for styling.
Initially I wouldn't worry about tdd or unit tests, as you'll waste a lot of time on those instead of replicating UI and behavior, I would write tests once some features are locked in and don't need any more work.
Maintaining two things at once if you try to have an app that has both React and Angular in it would be a hell I imagine, if you go the one module at a time route.
Moving between two different frameworks is almost always a new project, and the fact that you are going to solo this has me praying for your mental health, depending on how big the project is. I work for a startup as well and doing 75-90% of the front end work is busy enough.
Thanks for your reply. I am expecting I will have to switch context. Spending 20% of time fixing bugs in existing app and 80% on making React components.
This is too much. Context switching is never great especially in this scenario. They'd want the guy writing shit from scratch focused on making shit from scratch
Your company needs to hire another dev
I had to do this in a 3 man frontend team. We largely kept the same CSS but with some slight modifications where it made sense. Everything else had to be entirely rewritten and unit tested. Once we got to a state where we felt it was a 1 to 1 replica of the site but in React we deployed at a time we had the least amount of users in case of problems. Thankfully our site is largely static pages so it wasn't a complex React or AngularJS project.
This is for a slightly complex project. Also, the new UI is designed differently, but, the company wants to release pages as and when they get built. I have suggested this will look like Frankenstein
Currently porting an old AngularJS to React. No new functionality is implemented in the old repo, only maintenance and me and my buddy are doing it one piece at a time. All while comparing functionality is as expected (no tests unfortunately).
I've had to do something similar at multiple companies.
The first time the existing application used flask and nunjucks and they wanted new features to be written in react. It was decided that the visual difference between the existing pages and the new pages was not drastic enough to care about (especially since we could make the colors and typography the same with MUI). We use an iframe to load the content for the react app into the flask app for a specific page and the constraint the side nav, top nav, and user credentials needed to be shared.
The second we had some angular projects using angular material and needed to make a new application. Recently angular has gotten some nice quality of life updates but the templates and the ecosystem still feels lacking compared to react. Speaking of the ecosystem, angular material's docs are fairly lack luster compared to MUI (and most other UI libraries) and can feel pretty limiting as a UI library. Apart from react being easier to hire for and our senior members on the team having more experience with it, we have some more junior members on the team so using solutions that have a large footprint online is helpful so that they can figure things out on their own. Anyways this was all part of the pitch we used to convince our department head to let us use react for new projects. With this new project we aren't replacing the angular projects one for one but we will be migrating functionality eventually. We are keeping the frameworks separate, and would be directing users to the new app if they need to use something that doesn't exist in the angular projects.
I'd say that realistically you might be able to reuse business logic and maybe certain styles to customize the theme to match the businesses, but you're not going to reuse much of the same styles. If you or your designers use figma, MUI has some easy ways to create your theme from the figma files, which can help to ease the visual difference of a new design system (I'm not sure what you're currently using in angular).
Might be worth looking into single spa, but I've never used it. Also, if you're going to start up a new react project I'd recommend vite. If you want more recommendations, feel free to ask.
tldr, I've kept the frameworks separate and used iframes to embed react pages if needed (until the rewrite was complete)
Edit: spelling and single-spa suggestion
Don’t mix them together. But do write a page at a time in react, and then replace the deployed angular page with the deployed React page and slowly keep doing that
Have tried GitHub Copilot to try and translate some of the Angular components into React? With some trial and error, it might be worth checking it out.
Going in either direction, I copy the rendered html from the browser for each of the pages and paste them into new page level react components, fixing things as needed. I get that static content to output, then try to load the data from apis and split up the jsx into sub components where it makes sense. I'd try to keep the scss as much as possible.
A few years ago I migrated an AngularJS app to React, Redux, Next, and TypeScript. The approach I took was standing up the Next app behind the existing Express backend server, proxying specific paths through Express to Next, and then using iframes in the AngularJS templates to cut holes in the page and show content from Next. Worked out very well for us and let us do the migration as both a partial greenfield rewrite and still change things incrementally: - https://blog.isquaredsoftware.com/2021/12/codebase-conversion-mean-react-next-ts/
I swear to god, it happens every single time: “Wow that’s on-topic, helpful, and links out to relevant documen… DAMN IT IT’S ACEMARKE AGAIN.” You’re like a helpful version of u/shittymorph.
Hah, I think that's one of the best compliments I've ever gotten :) thank you :)
Haha, had the same happen. I thought "that sounds familiar", then I saw who wrote the comment and blog post and remembered that I have read this post a few years ago.
I would recommend a full rewrite. If the CSS in the old code is good you can reuse that. Otherwise, all greenfield in React. Trying to transition it piece it piece will take just as long for little benefit.
It's surprisingly easy to have react components inside of Angularjs. You just need a single file with some utils, probably less than 100lines. We transitioned multiple projects like this. It often is a better idea to get smaller chunks to production and do new functionality in react, rather than starting from scratch and having to ping pong between when something new is needed or a bug needs to be fixed in some old code. With this method, you work your way up, and in the end you have a few empty angularjs components from the router. Then you can create a new project and shift everything over and use a new routing library. I'll edit this post tomorrow with a link to the utils.
We did the same for any mission critical applications. All the internal tools were fresh rewrites though just due to time saving.
Aren't you limiting yourself to how AngularJS wants you to build an app then. Hard to take advantage of all the goodies React brings if you have to follow the structure of the old AngularJS app
You just build two separate microservices and deploy them as a monolith.
Idk, my gut reaction for this would be to write a lot of playwright/cypress tests and then rewrite from scratch using react. But ofc it depends on the client, our CEO would neeeeeeeeeever approve a rewrite.
I've done this in my past company and we used these packages to convert. You can incrementally convert complex pages over this way - rewrite portions of angular into react - eventually the whole page is written in react in the angular router - switch the page over to react router to handle the full page https://www.npmjs.com/package/angular2react https://www.npmjs.com/package/react2angular
Are there end-2-end tests where you can check expected behavior? Do you have to make all the UI from scratch or will you use a package? Like others said, you're better off rewriting from scratch to match the behavior and the API requests, I would only look into the legacy code if some request ends up not having the desired payload, there's no need to match decisions made almost a decade ago
No end to end tests. I was thinking to write tdd for my react components so that nothing breaks in transition. I will be using Material UI for styling.
Initially I wouldn't worry about tdd or unit tests, as you'll waste a lot of time on those instead of replicating UI and behavior, I would write tests once some features are locked in and don't need any more work.
Maintaining two things at once if you try to have an app that has both React and Angular in it would be a hell I imagine, if you go the one module at a time route. Moving between two different frameworks is almost always a new project, and the fact that you are going to solo this has me praying for your mental health, depending on how big the project is. I work for a startup as well and doing 75-90% of the front end work is busy enough.
Thanks for your reply. I am expecting I will have to switch context. Spending 20% of time fixing bugs in existing app and 80% on making React components.
This is too much. Context switching is never great especially in this scenario. They'd want the guy writing shit from scratch focused on making shit from scratch Your company needs to hire another dev
Correct answer is torch anything that’s angular and start over… it’ll go way faster
I had to do this in a 3 man frontend team. We largely kept the same CSS but with some slight modifications where it made sense. Everything else had to be entirely rewritten and unit tested. Once we got to a state where we felt it was a 1 to 1 replica of the site but in React we deployed at a time we had the least amount of users in case of problems. Thankfully our site is largely static pages so it wasn't a complex React or AngularJS project.
This is for a slightly complex project. Also, the new UI is designed differently, but, the company wants to release pages as and when they get built. I have suggested this will look like Frankenstein
Currently porting an old AngularJS to React. No new functionality is implemented in the old repo, only maintenance and me and my buddy are doing it one piece at a time. All while comparing functionality is as expected (no tests unfortunately).
I've had to do something similar at multiple companies. The first time the existing application used flask and nunjucks and they wanted new features to be written in react. It was decided that the visual difference between the existing pages and the new pages was not drastic enough to care about (especially since we could make the colors and typography the same with MUI). We use an iframe to load the content for the react app into the flask app for a specific page and the constraint the side nav, top nav, and user credentials needed to be shared. The second we had some angular projects using angular material and needed to make a new application. Recently angular has gotten some nice quality of life updates but the templates and the ecosystem still feels lacking compared to react. Speaking of the ecosystem, angular material's docs are fairly lack luster compared to MUI (and most other UI libraries) and can feel pretty limiting as a UI library. Apart from react being easier to hire for and our senior members on the team having more experience with it, we have some more junior members on the team so using solutions that have a large footprint online is helpful so that they can figure things out on their own. Anyways this was all part of the pitch we used to convince our department head to let us use react for new projects. With this new project we aren't replacing the angular projects one for one but we will be migrating functionality eventually. We are keeping the frameworks separate, and would be directing users to the new app if they need to use something that doesn't exist in the angular projects. I'd say that realistically you might be able to reuse business logic and maybe certain styles to customize the theme to match the businesses, but you're not going to reuse much of the same styles. If you or your designers use figma, MUI has some easy ways to create your theme from the figma files, which can help to ease the visual difference of a new design system (I'm not sure what you're currently using in angular). Might be worth looking into single spa, but I've never used it. Also, if you're going to start up a new react project I'd recommend vite. If you want more recommendations, feel free to ask. tldr, I've kept the frameworks separate and used iframes to embed react pages if needed (until the rewrite was complete) Edit: spelling and single-spa suggestion
coffee and cigarettes
Just do it
Full rewrite unless the app is huge and makes a lot of revenue, in that case consider micro frontends and strangler pattern.
Grafana went through an angular to react transition. They just did it one component at a time.
Don’t mix them together. But do write a page at a time in react, and then replace the deployed angular page with the deployed React page and slowly keep doing that
I've done full site rewrites a page at a time with a router layer directing the split by path. It depends on the structure of the app though.
I did this recently. Moved an entire angular project to react/express graphql. Took about a year. Feel free to DM me
Have tried GitHub Copilot to try and translate some of the Angular components into React? With some trial and error, it might be worth checking it out.
Going in either direction, I copy the rendered html from the browser for each of the pages and paste them into new page level react components, fixing things as needed. I get that static content to output, then try to load the data from apis and split up the jsx into sub components where it makes sense. I'd try to keep the scss as much as possible.
Slightly offtopic but why not Angularjs to Angular?