Future of UI infrastructure and development in Foreman

[MariaAga]

@Shimon_Shtein

First I will describe the desired end state. We want to have a page built on top of latest PatternFly components. This page will use state and custom hooks to manage the API requests/responses (the view model). For the model we can either create dedicated objects or use the API responses directly (similar to our current state in redux). The model will be retrieved by a dedicated endpoint on the server side that can be different from the one used by the “official” API.
I think we should not use the same endpoint for the “official” API and for the API calls performed by the UI. The UI is stateful, and does not face the user directly.

I would like to say, that we aim to not even use too much custom things in simple components (example of the modals index page, that passes just column names and an api path) - and to create and maintain a generic table for index pages (and maybe a generic show page component in later stages?
And for some REX pages, we had to create custom api endpoints, which I agree makes more sense.

@qcjames53

Are we considering React 19 + PF 6 or are we sticking with the current React + PF 5 to reuse as much as possible?

We are now in the process of converting pf3 to pf5 so we can later convert them together to pf6.
We also are in the process of rewriting the Enzyme tests so we can upgrade to a newer React version.

@aruzicka

With that being said, are we sure this is what we really want? What are the benefits we get out of it and are they worth all the work that’s being put into it?

I assume you ask if React is what we want, since we use Patternfly, the answer is probably yes, as PF supports React and HTML, and we already have React, and probably dont want to write all the JS that will be needed for the pure html version.

@aruzicka

• We still have leftovers from the time when react best practices were being changed weekly scattered all over the code base where conceptually similar things are implemented in wildly different ways in different places, even though it is all technically a single ui component technology stack - just react
• Often, new react-based pages and features take way too long to implement and are often implemented in seemingly unmaintainably high numbers of lines of code

I generally agree and I think since we work very individually on the UI, its written in a less optimized way as we dont have many (or any?) discussions with as a group of people who write FE on how to approach tasks, and where can we do better. I try to update some of the dev/contribution docs to be more updated, but I cant assume they are read or understood, and we probably dont update them fast enough.

And for the API I would like to connect this maybe to this effort: Foreman REST API version 3 initial thoughts