Hello all,
We have had some discussions around this and I’ve come up with a working POC so we can discuss further.
Proposal
Move all the angularJS code in Katello into webpack. This includes bastion, our library of modular UI components, and the actual katello pages written in angularJS. For those unfamiliar, this is the majority of Katello’s pages. We have converted a couple (subscriptions and RH repositories) to React and plan to convert more, but this is a large effort that will take a long time. It’s safe to say the angularJS pages will live with us for a long time, though will reduce in number as we convert more to react.
What do we currently do?
We load bastion and the angular pages completely through the Rails pipeline. Since Bastion was meant to be a reusable component, it is a Rails engine.
Benefits
- Having one javascript bundler, webpack, handle the majority of our front-end code.
- Gain any benefits that webpack offers to minify and reduce the amount of code send to the browser.
- Upgrading and optimizing webpack will benefit the angular pages as well.
- Since Katello is the only user of Bastion and that is unlikely to change, remove bastion’s code around making it a reusable rails engine
- Be able to use ES6+ syntax and modern tooling like npm with our angular code
- Simplify js package management to only use NPM (bastion uses bower), more easily upgrade packages
- Could potentially make adding React to Angular pages easier, making our transition to React smoother.
Concerns
- Moving this much code makes cherry-picking for releases more difficult
- May require packaging changes
- While the pages are being moved, duplicate javascript could be sent to the browser since the pages loaded by rails will still use bastion provided by the rails engine and the webpack ones will use bastion provided by webpack. (I’m not 100% sure about this, but worth mentioning)
Strategy
The POC PR moves much of Bastion over to webpack. Ideally, we move Bastion completely over and then work on moving the pages over. In the PR, I’ve moved over the main content credential page, this is to ensure Bastion is working correctly. The page isn’t completely functional yet, but is looking more like the original one.
I think we will want to get Bastion completely working and playing nice with webpack, and then move the top-level pages over one-by-one in separate PRs. This will allow everything to co-exist and not blocked a release or be tied to a time period. The only concern I can think of is duplicating Javascript as I mentioned above.
When a page is moved over, we could do one of two things (afaict):
OPTION 1 - Remove the old page and redirect the top-level page to use the new webpack page. The rails page will no longer be available, and the webpack page will be loaded when the route is used.
OPTION 2 - Move to a namespaced URL, e.g xui/content-credentials
. Continue to move all the pages over to this and when they are all fully moved over, remove all old bastion/angular code and switch the routes to load the new webpack pages.
Some other points:
- The business logic of the pages will still be the same. What changes is the importing and exporting the angular components/services/directives/etc. This means if you need to pull in a commit that was done on bastion-in-rails, you should be able to make the same changes easily to bastion-in-webpack.
- We will have to ensure translations still work correctly, as this is a very important part of our app. I plan to handle this in the initial PR.
I would love to hear from everyone, especially @packaging and @ui_ux. Please share any questions, concerns, and/or thoughts on this proposal. Let me know what you think!