As identified in Shimon_Shtein’s post, our current UI infrastructure suffers from significant fragmentation:
Diverse Technology Stacks: We simultaneously use ERB, jQuery, Angular (in Katello), React, PatternFly 3, PatternFly 5.
This multi-stack approach results in:
A steeper learning curve for new and existing developers.
Complications in feature addition and maintenance.
A non-unified, inconsistent visual experience for users.
Relying on extra npm packages increases application bundle size and complicates long-term maintenance by requiring constant updates to address security vulnerabilities and breaking changes.
UI Coding Standard
To address these issues, all new UI development must adhere to the following guidelines, as mentioned in our Handbook and Developer Docs:
Technology: All new UI code must use React pages and PatternFly (PF) components, and be tested with React Testing Library and/or Capybara.
Component Reuse:
Always prioritize reusing existing components from PatternFly.
If a new component is universal, consider contributing it directly to PatternFly instead of creating a project-specific component.
The Roadmap To Patternfly 6
Enzyme removal: PatternFly v6 does not support React 16, and Enzyme does not run on React 17+.
Therefore, we will need a testing update: We are working on updating all Enzyme library tests to the more comprehensive React Testing Library (RTL).
Reminder: we have simplified JS tests to be run out of the Foreman dir directly, more details here: Testing plugins from foreman core
PF3 to PF5 Migration: Update all PatternFly v3 (PF3) uses to PatternFly v5 (PF5). During this migration, we also aim to simplify code by removing unnecessary Redux usage (Where React state or context should be used instead) and updating associated tests to RTL.
We are actively working on this, for most components it’s just a code refactor, and in some specific cases the whole component will be redesigned.
React Version Upgrade: Once all Enzyme usage is removed, we will update React to version 17+, as Patternfly 6 Only supports React 17+.
PF5 to PF6 Migration: Following the React 17+ upgrade, and PF3 removal, we will update to PF6.
Note: We anticipate this being a single, large step, similar to the PF4 to PF5 update, leveraging PatternFly’s provided automation.
Legacy Technology Removal
Angular: We will refactor or redesign Angular pages to use React with PF5, with the ultimate goal of removing all Angular usage from the project.
Server-Side Rendered Pages (.html.erb): All server-side rendered pages will be migrated to a React-based implementation using PatternFly (PF5 or PF6, depending on timing).
A concrete plan for the full migration is pending, as we are focused on the PF3 removal. Some pages will just need a code refactor while others will need a redesign, for example the Host Creation Form is already identified as candidates for a full redesign (see: RFC - Host Creation Form, Dependency Map).
Thanks for this! It lays out our plan clearly and I am 100% on-board.
I think it’s worth calling out here that this means removal of JS snapshot tests.
It’s nice to say this, but in my 6 years here I have not heard of even one component contribution to Patternfly from our project. Contributions directly to Patternfly have a few hurdles:
Patternfly probably will not accept improvements to EOL versions such as PF5
Patternfly is written in TypeScript and most of our developers may not know TypeScript (hey, @thorbend )
On the other hand, Patternfly offers such a good selection of components that I think it’s incredibly rare that we would have to make a new one from scratch.
I think it’s worth calling out here that this means removal of JS snapshot tests.
Technically some snapshots are just from Jest, and can stay. It seems that its mostly snapshot tests since we use Enzyme to render the component, and then use Jest to save the snapshot.
It’s nice to say this, but in my 6 years here I have not heard of even one component contribution to Patternfly from our project.
We used to do that (from a quick glance, PF repo has at least 100 PRs from Foreman devs), but I agree that it might be too difficult now, and also that the PFs component library has grown to fit almost all our needs.
Full agree to move forward and replace this. Is this a priority like, first replace Angular pages with React/PF5 and then Service Side Rendered? I would have expected the other priority (Service-side first and then Angular)
For Angular we have 8 pages (Katello), we already started to make plans for them.
For .erbs we have many more pages, across many plugins. Some helpers we might be able to convert to React to ease the proccess, its a lot more to plan. Some .erbs are easy to convert (Welcome pages), but some are very complex (host form).
Is there some time-line for this? I have seen a lot of PRs that replace/refactor components in foreman core, recently. I’d love to know in advance when things are planning to be removed such that we can update the plugins in time. I have already seen some deprecations, but it would be nice to have them collected in one place.
We do not have a timeline for this, is there anything you’re concerned we will remove? With deprecations - we leave the component in for 2 foreman versions before removing, and suggest alternatives to it.
We do not have a timeline for this, is there anything you’re concerned we will remove? With deprecations - we leave the component in for 2 foreman versions before removing, and suggest alternatives to it.
I am mostly concerned that we miss to update some components in time and where to look for information. But f I understand you correctly, we should pay attention to the deprecation announcements.
)