React form inputs integration to rails forms

some of the code is “older” and doesn’t follow the latest definitions that are defined at [1] - I assume you didn’t read it already?

There is even a code generator (React Component Generator) that follow that, the fact that its not known to developers is probably leading to the important point that enough communication is probably not happening…I know the UI team does try to send a newsletter( e.g. Foreman UX newsletter - January 2019, but maybe that’s not often enough…)


Can you elaborate? I am not familiar with React and “mounting”.

What kind of argument is this? I like static pages, if they are generated fast enough the experience is super awesome for me. Let’s not go deep into this, just scratch this. :smiley:

As someone who follows the react introduction to the Foreman from the very beginning, I thought it may be good to share my feelings (not data):

  1. I keep hearing “we’re almost there” for 1 year, the effort goes on for 2 years at least
  2. I don’t feel we’re there yet, both infrastructure-wise (slot/fill is not done, plugins are not solved, snapshot testing is not good enough and we don’t have other option yet) and component portfolio-wise (ERB helpers still gives me more tools like counter fields, blank_or_inherit, link_to_if_authorized family, action_buttons, truct_with_tooltip)
  3. we see (s)low adoption rate among developers
  4. critical and complicated pages are in ERB - hosts detail, host creation, the same for hostgroup, compute resource and profile, smart proxy detail - partially, report detail page, facts page
  5. there is a technical debt already

This puts me under impression, we’re not close to a point we should stop investing to ERB helpers. New CRUD pages or bigger changes in core should go fully react though. Adding more helpers internally using react gives plugin maintainers to get benefits of react early and without much work.

The progress or improvements I saw last year

  1. UI team is aware of problems and work on them
  2. there are some developers outside of UI team contributing and even reviewing
  3. great improvements are being added in react - auto complete, datetime picker, tasks dashboard, templates editor, graphql being introduced
  4. communication and knowledge transfer is better both directions, still potential to improve

which makes me feel we’re going that direction and one day, devs will default to consume react “natively”.

I think the big question we’ve been avoiding to answer loudly for some time is, is the end goal react only UI? I keep hearing two different opinions consistently. If we can come to a consensus on this, it may help accelerate the effort, regardless of the direction. I personally don’t have problem with having ERB around next 3 years, but I’d like to have more improvements added in react (host detail page, host form, smart proxy) and ideally not only rewritten but redesigned.

As I noted, these my are feelings not necessarily based on data and I can be proven wrong :slight_smile:


I think it’s a good and viable argument. The static page is not what make us existed but the fact we can easily update the UI after it got rendered based on browser events.
(Yes we can get it with JQuery but I don’t feel that I need to explain why it is wrong today. or should I?)
When @amirfefer says “user experience” he means (I believe) a UI that gets updated immediately based on the user interaction (what we call modern app).

My opinion about the helpers is that we should use them only when they deliver small components.
For example, it makes sense to me to deliver components for form_fields (e.g. autocomplete_f, checkbox_f) but I don’t think it would be wise with bigger components like Table Forms Modals which are more complex and usually composing more than 1 component inside.


Don’t get me wrong, I want you to keep explaining things that’s why I play the opposite party role in the SPA discussions.

The major problem for me is that we “swim against the current”, let me tell you what kind of issues we had when Katello had MongoDB instead of Postgres back in the wild days of the early prototype. Rails is a great framework and not leveraging its strengths is something I see as unwise.

We did this with asset compilation pipeline but luckily the Rails community decided to do the same. I am not sure if we now use the very same as Rails 5, however if we diverge too much with React/SPA and other new technologies we might get into situation that we actually no longer use Rails (routing, views) and this looks like rewriting things from scratch to me. And God knows how I hate rewriting things for nothing (nicer code is not an argument for me such a thing does not exist in real).

I understand that Rails community preferably still use the page generation approach which is still reasonable if you do it properly. We are not good example of this indeed (jQuery hell) however there are good examples of successful projects written in MVC pattern and with a bit of help from Turbolinks they are able to deliver SPA-like experience. For example Bootcamp 3 is completely based on this architecture, including mobile portions (native apps via web pane).

If we are getting rid of jQuery and replacing this with React components, reusable things with tests, I love that. But I still think it’s better to generate pages and avoid SPA completely. Foreman is not a gmail with millions of simultaneous users or ambitions to do super intuitive UX. We don’t need this, our users are IT and Ops in small teams. We can afford a page refresh here and there I think.

Now with my lack of understanding of how React and SPA works, I might argue in irrelevant discussions (e.g. here) but you get the idea and I hope it makes at least sense what I mean when I stand against SPA.

Maybe explain me one thing - does it make sense to work towards MVC “Rails” architecture with reusable React components or is this something that never was really planned?


I agree that a project like foreman shouldn’t jump and adopt new trends (but should experience and get an opinion about them) and rails is a great framework with some strengths. One of the strength was the view-controllers and the view-engine where IMO is not the strong point of Rails anymore so they embraced react into their framework while many projects moving to a Rails API only app (that serve static files).

First of all, AFAIK there was never a plan to break the Rails MVC architecture and to be honest I don’t think it is actually achievable for the medium-term and I don’t think we should set it is a goal for the long-term.
Notice more components are written with react, it leads to more “compiled” assets and less on-the-fly generated assets but it doesn’t break the rails MVC architecture (it is lead you to ask questions about the rule of MVC today :wink:) .

About SPA, I think the term SPA talk about an opinionated structure which I don’t think we should adopt blindly because there are some parts their which are not relevant for us while there are some other parts that can benefit us for the short/long-term.

For example, I see a great benefit using react-router to switch between the internal index/edit/show pages of a single instance, without managing the parent route with react-router.
It will allow us to show immediate response to the user, keeping the data locally between those transitions and do an API call to complete the missing data. Users will be able use the breadcrumb-switcher with an immediate response where we just update the view.
Moving from show to edit will not even cause any API call and can be done by switching the view internally. Overall I see a great improvement for the user experience here.
BTW, there are already cases when we are using react-router in core and plugins, (katello is not a good implementation example but there are some good implementations). Therefore I believe core should deliver infrastructure for plugins with good examples of how to benefit the client-routes including the Do and Don’t do.

About ERB and React components, one of the biggest strength of React (and where erb fails) is creating small, reusable and testable components while you can compose them into bigger and bigger components over time while you keep each component relatively small (It’s just a component the use some other smaller components).

Today, in some pages, we are in a stage where we have all the base components implemented with react and here comes the question “should we use all those components separately in an erb file? or should we compose them into one React component so the erb will only render this 1 component?” (The rails view-controller still deliver the data to the component)

For me the answer is clear, we should compose those components with React because this is the biggest strength of React and it gives us more options to create a rich UI. For example, an event in one component where we want it to affect another component in the page.

1 Like

UI is more important than ever, even for IT users, it’s functional as the face of the product, and If foreman won’t update its looks and feel, we might be irrelevant someday.

I know that a picture is worth a thousand words, what about two videos which demonstrate turbolinks vs client routing on hardware model page :slight_smile:

[EDIT: wrong links pasted, see correct links below -Tomer]

No one says we should move to SPA and re-write foreman from scratch, but adopting such a technology (client routing) on new content and pages, plugins and redesign some outdated pages (i.e host creation process) would make foreman a more like modern application.

I remember how many NACKS we got on the new vertical navigation, but today I don’t think we can find even one, having concerns about changes makes sense, however we will try our best to show that these changes are for the best.


Oh, I still don’t like it. But it’s good that we reached a consensus.


why is your demo so slow? are you simulated high server load? while I support your argument, I am not sure if the attached videos proved your point.

I would be extremely careful with this and strongly advise against not doing an API call to be honest. A detail page may have been open for a long time, things could have been updated in the background. Caching is among the hardest parts of computer science Here I’m with @lzap that we should stay on the side of correctness versus performance. Foreman is a crucial application in many people’s infrastructure where I think most people prefer correctness.

Note I’m not saying we shouldn’t render with React. I actually like the concept of React where the view is deterministically derived from a the state. My issue is with (premature) optimization (and Javascript as a language).


Captured on dev env, with no high server load simulation (that called cheating… :slight_smile: ) I agree it would be better to capture both on prod

To emphasize my point: Bug #24176: Smart proxy delete + recreate leads to 404 - Foreman

Actually I shared the wrong videos :sweat_smile:
Here’s with turbolinks
Here’s with client routing

Elaborate, remember we are not a twitter feed. I realize benefits of React and its reactive approach to updating browser DOM which is much faster, but we barely work with tables with 100 records. Also Foreman is usually not a public instance, we do not need to save milliseconds because in the end the orchestration/task/compute resource or smart proxy API will do super-slow requests somewhere else over VLAN/VPN tunnel and those milliseconds saved are gone. I would not like to see us solving problems which are not real.

Please stop marketing fluff and give us arguments. I am totally fine change my mind however I would like to read real reasons. Avoid terms like modern, UX is important or irreverent in the future and focus on why this is gonna be superior to the Rails way. If you think Foreman UI part is slow, let’s identify first what exactly is slow, how do we measure it. Let’s ask our users in the next survey. Because I believe that the slowest things are totally not in the UI part.

Wort things to do is to “optimize” things without actually measuring what’s actually slow. I’ve been there, I’ve “optimized” fact import to the degree it was actually slower than before. I made the mistake not measuring before and after. If you want to talk about performance, and that’s fair argument although I think it’s less relevant than we think, let’s measure what’s slow.

Client routing, as I understand it, will make the whole routing utterly difficult - we will end up with two places when dealing with routes. This will make for example authorization and authentication much more complex. There are permissions that allows you to view but not edit resources, we will need to handle this. And this is just a starter, something tells me that route handling of a web app should always be a single and clean component.

I did my homework and tried to dig this out, I haven’t stumbled upon a single nack. Frankly, I love the idea of putting things to the left side since we all have widescreen monitors and I’ve been doing this for years. There was a survey but the results are not visible. What I do not like tho is menu structure, I think we need to refactor where things are but this is totally different story.

However you put this into position “you keep complaining, look people were also nacking the vertnav and it’s fine”, that’s not fair. I am trying to argue the best out of this for the sake of community success. I love Foreman and I want it to be successful. And I am backend guy, yes I do not necessary understand how UI works (both in Rails and React), however this gives me opportunity to look from the 10,000 feet perspective asking unpopular things like “do we need this?” or “why we are doing this?”.

1 Like

I get your point, however what you load is a Hardware Models resource, the one that has two fields, no associations and real-world users barely visit it every day. Now try the same with Hosts where we load VM states on the background, where we actually deal with 10,000s records and not tens, where we do dozens of joins just to present the base table. That’s completely different story.

But what’s more important is Foreman don’t have problems with slowly loading pages. We’ve never had. Those which load slowly will load slow even after we migrated to React routing or SPA because it’s either slow database or slow backend service.

React isn’t here for improving round trip time and server’s capabilities, but it transforms the client into a state machine, which is much easier to maintain (managing distinct states than a collection of embedded views),

For instance, you can render an empty state page without any extra round trip, and also you can use the existing state for rendering part of it until you’ll have the whole picture from the server. this brings a much better experience - instant feedback.
Adding react router to it, just simplified the transition between one state to another, it won’t transform foreman into a deadly SPA :slight_smile: and it won’t switch our rails routes.

Keeping focus at the original question I would say the answer is obvious, if I understand correctly, most is in favor of having helpers for advanced form fields, because the rewriting whole app to React is not really on the table yet, if the argument is only the one the topic is strongly opinionated and most in favor we are not ready.

To summarize the other points given I feel like:

We should go React, but carefully.

I believe we hear actually a consensus on that, even though the convergence of opinions to it is not visible till we summarize.

It would be nice to actually analyze the topic a bit, share lessons learned and set the new goals for the transfer.

I agree with the:

as it really states what is important here, do not solve a problem, where there is none. But I believe in some truth in

and that is hard to measure, so we need a push by passion over data, not forgetting them for setting at least the high level goals, though. So I believe that “modern” application is not so bad argument, just we should gather some data to support it (work with the users more).

We feel we need a transform the UI and actually go with the flow (current) as Rails community is going where we are going [1][2][3]
And that we are a tech application is only partially viable with knowledge of Gitlab being one of the first adopters of webpack.[4]

But we should remember:

Rails is a strong and mature framework and foreman is a mature Rails application.

and do not rewrite and make mess in funcionality Rails is good at.

So I believe we all feel we should go React, but we still need to discuss where is the final goal, taking routing, static pages renders as example, there are actually parts we might want to keep around forever in Rails and it could diverge the final goal.



thanks for the summary, in the past, I did write The journey to Single Page Application and created redmine issues etc,what I think I failed to relay is that I’m not really pushing towards rewriting the application, but rather enabling the infrastructure needed to benefit from SPA like (without needing to rewrite the entire code base).

In my opinion we should keep on replacing small components that are used everywhere,
support rails helpers with the change, for example: Autocomplete, Pagination, Table etc…

and once there are enough component to replace the whole page,
I see no value in mounting it from erb

instead we could absolutely divide the back-end code with the front-end and it would be much easier to manage the page from both sides, it will reduce full-page reloads and make the user experience much better as in many modern apps.

Until we will reach the level that the whole application has components for any need,
I agree that we should supply ruby helpers.

I promise you that when each page will manage its own components for its own scope,
even the helpers will get simpler, without the need to support each edge case.


I think we don’t necessarily need to wait for the whole application to be component based.
IMO once an ERB file becomes a list of react components only, we should compose those components into a single component so this ERB will render only one component (that might replace the ERB itself).

1 Like