I’m currently doing the reverse, using rails assets in webpack, with angular-patternfly in the PR. If this is possible, we can try something like this. Would that be a way of avoiding the need to duplicate? Perhaps the Rails engine could be modified in a way to import from webpack instead of the assets pipeline as a compatibility layer. Let me know what you think!Īnother thing that the UI team might be more qualified to answer is that you can export things from webpack to be used by the classic rails assets pipeline. I would love to hear from everyone, especially and Please share any questions, concerns, and/or thoughts on this proposal. We will have to ensure translations still work correctly, as this is a very important part of our app.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. What changes is the importing and exporting the angular components/services/directives/etc.
Bastion main not switching code#
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. OPTION 2 - Move to a namespaced URL, e.g xui/content-credentials. The rails page will no longer be available, and the webpack page will be loaded when the route is used. OPTION 1 - Remove the old page and redirect the top-level page to use the new webpack page. When a page is moved over, we could do one of two things (afaict): The only concern I can think of is duplicating Javascript as I mentioned above. This will allow everything to co-exist and not blocked a release or be tied to a time period. 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. The page isn’t completely functional yet, but is looking more like the original one. In the PR, I’ve moved over the main content credential page, this is to ensure Bastion is working correctly. Ideally, we move Bastion completely over and then work on moving the pages over. The POC PR moves much of Bastion over to webpack. (I’m not 100% sure about this, but worth mentioning) 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.Moving this much code makes cherry-picking for releases more difficult.
Bastion main not switching upgrade#
Simplify js package management to only use NPM (bastion uses bower), more easily upgrade packages.Be able to use ES6+ syntax and modern tooling like npm with our angular code.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.Upgrading and optimizing webpack will benefit the angular pages as well.Gain any benefits that webpack offers to minify and reduce the amount of code send to the browser.Having one javascript bundler, webpack, handle the majority of our front-end code.Since Bastion was meant to be a reusable component, it is a Rails engine. We load bastion and the angular pages completely through the Rails pipeline. 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. 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. For those unfamiliar, this is the majority of Katello’s pages. This includes bastion, our library of modular UI components, and the actual katello pages written in angularJS. Move all the angularJS code in Katello into webpack. We have had some discussions around this and I’ve come up with a working POC so we can discuss further.
0 kommentar(er)
