Migrating the MAAS UI from AngularJS to React



MAAS (metal as a service), is a Canonical product which allows for very fast server provisioning and data centre management. Around 2014, work began to build a rich UI for MAAS, primarily using the AngularJS JavaScript framework from Google. AngularJS today is in long term support (LTS) and due to reach end-of-life in 2021. This year we began the work of transitioning away from AngularJS in anticipation of this impending EOL to more contemporary tooling.
Evaluating Angular vs React
Google’s recommended upgrade path for applications built in AngularJS is to transition to the Angular framework. Despite the similarity in naming, Angular is very different from AngularJS architecturally, and the migration process is non-trivial. While components (allowing for the now ubiquitous uni-directional data architectural pattern) were later backported from Angular to AngularJS, most of MAAS UI predated this and consequently migration to Angular would require significant app-wide refactoring.
Since the inception of the MAAS UI, a number of other products had been built at Canonical using React. As we had developed significant experience using React, and tooling in the surrounding ecosystem, ultimately it made more sense to invest in transitioning the MAAS UI to React rather than Angular. This choice conferred additional benefits, such as standardising our build and testing infrastructure, and allows for component reuse across products. We also just generally enjoy working with React, and feel that the most significant developments in web UI technology are happening within the React ecosystem (hooks, concurrent mode, suspense, CRA).
-
- Login or register to post comments
Printer-friendly version
- 1760 reads
PDF version
More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
today's howtos
| Wine Developers Are Working On A New Linux Kernel Sync API To Succeed ESYNC/FSYNC
While there is the prior "ESYNC" and "FSYNC" work pursued by Wine for the Linux kernel, it appears Wine developers are back to the drawing board in coming up with a Linux kernel implementation for Wine synchronization primitives that will address all their needs and match the Windows behavior well.
CodeWeavers developer Zebediah Figura sent out a lengthy mailing list post on Sunday night outlining the current state and objectives of coming up with kernel-based Wine synchronization primitives. While the ESYNC/FSYNC patches were successful in improving the performance of many Windows games running on Linux, they are still working towards a more all encompassing solution and to match the behavior well for Windows and with optimal speed.
|
Linux Weekly Roundup: Wine 6.0, Fedora i3 Spin, and More
Here’s this week’s (ending Jan 17, 2021) roundup series, curated for you from the Linux and the open-source world on application updates, new releases, distribution updates, major news, and upcoming highlights. Have a look.
| Linux 5.11-rc4
Things continue to look fairly normal for this release: 5.11-rc4 is solidly average in size, and nothing particularly scary stands out. In the diff itself, the new ampere modesetting support shows up fairly clearly - it's one of those hardware enablement things that should be entirely invisible to people who don't have that hardware, but it does end up being about a fifth of the whole rc4 patch. If you ignore that oddity, the rest looks pretty normal, with random patches all over, and a lot of it being quite small. All the usual suspects: drivers (gpu, sound, rdma, md, networking..) arch updates (arm64, risc-v, x86), fiesystems (ext4, nfs, btrfs), core networking, documentation and tooling. And just random fixes. The appended shortlog gives the details as usual.. Linus ![]() |
Recent comments
1 hour 7 min ago
1 hour 33 min ago
1 hour 35 min ago
6 hours 5 min ago
6 hours 8 min ago
12 hours 31 min ago
12 hours 42 min ago
1 day 10 min ago
1 day 1 hour ago
1 day 7 hours ago