Migrate Client side code from AngularJS to Angular
Issue #754
on hold
@ghachey you mentioned this in Pohnpei so let’s use this issue as a place to hold thinking about this.
Let’s split to a few topics:
- PROS and CONS of doing this migration
- how to go about it
- specific identified difficulties
Comments (11)
-
reporter
-
reporter
Hybrid application
There has been significant tooling support for upgrading from AngularJS to Angular - not surprising considering how widespread this issue must be.
See https://angular.io/guide/upgrade
As well, ui-router offers support for hybrid applications:
https://github.com/ui-router/angular-hybrid
-
reporter
3rd Party Component support
We rely to varying degrees on a number of third party components in AngularJS. We must consider how the functionality provided by these components will be accessible in Angular. It’s likely that in some cases, even when there is an Angular version available, there will be some minor differences that will have to be systematically addressed.
Here’s a quick list:
ui-grid
No Angular version This is probably the biggest challenge , since we have significant investment in ui-grid specific logic (view modes, pagination, in-grid editing, routes from cells etc.
We need to find anoather virtualising grid that is Open source.
angular material data-table ? https://material.angular.io/components/table/overview
AngularJs Material
There are detailed migration instructions here:
https://material.angularjs.org/latest/migration
This task looks relatively straightforward , but time consuming?
Restangular
There is an angular version of restangular, apparently functionally equivalent,
Recently I have been reducing the dependence on restangular - shifting calls that do not need to be “restangularized” back to $http service. This should probably be worked through as a refactoring prior to migration.
ui-router
Angular version with parallel functionality. Although we have a lot of infrastructure built on ui-router (routing via links, navigation system), may be worth looking at the other routing options in the Angular suite before committing to ui-router.
Angular Permissions
Doesn't seem to be an Angular version of angular-permission. There is ngx-permission - different author but apparently similar interface and functionality. However ngx-permission does not play nicely with ui-router??
File Upload
we use 3rd [arty angular-file-upload currently in Exams, Workbook upload etc.
opinion seems to be a 3rd party component is not required in Angular:
https://stackoverflow.com/questions/40214772/file-upload-in-angular
So we face some rework on this to remove the component.
other….
maps
to do - explore google maps support and compatibility with current code
angular-google-maps seems to be the standard.
Investigate how to use the addons markerclusterer and lassoo selection.
Charts
Charting is currently a mish-mash of dc ( sitting on crossfilter) and our customised version of plottable; the customised plottable uses d3 version 3; dc has moved on to d3 version 4 so we are kept a version behind in dc.js.
We have built various wrapper components based on these two frameworks.
This is all pretty integral to the app as the dashboarding components are the “icing on the cake”
Once again we need to re-evaluate the charting landscape
- there is probably some significant work facing us here.This chart library does look promising:
https://swimlane.gitbook.io/ngx-charts
Demos look good, simple interface svg (d3) based rather than canvas based (this allows a lot of opportunity for css styling etc) works in the angular world with angular callbacks ( ( plottable only provides this in our customised version)
Open source, but largely the product of a single company who could - like palantir (plottable) and novus partners (nvd3) before them - lose interest.
-
reporter
Cleanup / Convergence
Prior to migration, we should clean up configuration and in particular identify and remove things that aren;t used.
There is probably a few in the bower.
We are ahead of the game in that our AngularJs is now almost entirley typescript, and very largely component based.
We should push ahead with componetising everything.
– In particular, the recent design change introducing the render-frame / render-list / supergrid model (compare SchoolAccreditations routes to schools routes) should get pushed through everywhere. This is better separation of concerns.
Bootstrap
If we move to a hybrid model, we will have only material on the angular side, so we ought to get rid of bootstrap entirely from the angularJs side .
Note that bootstrap involves not only the Css but “bootstrap” ui-object, which are wrapped in angular-ui-bootstrap” as driectives.
Removing these bootstrap directives and replacing angularjs-material equivalents seems logical, but this probably means some double-hanlding in the medium term, as ui widgets go from ui-bootstrap => angularjs-material => angular material
Bower?
Should we be working with npm esp for types, going forward? Note that our devops does have some dependencies on bower; ie parsing the bower file to generate the list of distributables
-
@Brian Lewis thanks for this information. It’s really useful. My only comment at this moment is that if the amount of work is similar I would rather reduce the amount of dependencies (e.g. use Angular’s routing and file management instead of the dependencies).
One thing you seem to imply that both AngularJS and Angular can coexist? I’m a bit surprised at this? Maybe I misunderstood.I now see this is possible though now sure exactly how much is involved in taking this approach early rather than later.But definitely it’s a bit frustrating to have all future efforts done twice in such a small amount of time. There are things to consider here outside just the actual software development required. We can discuss this over skype in next call.
-
reporter
- changed status to open
-
reporter
Of interest, a worked example of using ui-router in a hybrid app:
https://itnext.io/sharing-the-ui-router-between-angularjs-and-angular-6-84f6370ec557
-
- marked as minor
Lowering priority a little as focus needs to change for a while.
-
If time permit
At least setting up as discussed a framework to start using both AngularJS and latest Angular 11 in their seperate projects. Look at tooling and go as far as possible with a upgrade to latest angular. This would need to be in a seperate new branch and only pushed to production if the whole thing can be upgraded within the next two years.
-
Another task that can be considered step in the right direction for a possible future upgrade I suppose could be any other tooling simplifications that could be made (reducing number of dependencies, simplifying build process using only npm, etc.)
-
- changed status to on hold
For now
- Log in to comment
Timelines
AngularJS Long Term Support period ends on 30 June 2021.
No new functionality will be added before then, but fixes to any breaking changes in new browser versions will be made.
After 30 June 2021 this will not be the case so there is a risk that AngularJS may become incompatible with future browser versions.
So we have at time of writing 18 months.
Probably, tooling and assistance ans well as the availability of 3rd party components etc will only get better, so we should not rush into this.
I’d propose some milestones (assuming we go down the “hybrid” path
Oct 2019 - begin thinking and documenting the issues and considering possible appraoches
June 2020 - have a migration strategy finalised.
Dec 2020 - code cleanup on AngularJs side completed, to make the migration target as small as possible.
March 2021 - have a hybrid application architecture developed and in place to allow new components to be built in Angular. Some components migrated as “proof of concept”.
New development from this point all in Angular
June 2021 ff - “Refactor on demand” as existing components are changed, move them to Angular.
Dec 2021 ??? Final cleanup of any remaining AngularJs code??
That said, the downside of a long horizon for migration is that we may find ourselves “digging the same hole deeper”; ie, wiring angularjs code that we know will in the medium term need to be reworked / rewritten. We need to be aware of what code will look like when migrated to the Angular side, to minimise this. (Sticking to the Component model is one obvious strategy)