I agree some pages might be already close to that state (or can be brought close to is with relatively small effort), but that isn’t yet the case for most pages yet. And once a page is just helpers implemented in react, it is also relatively easy to convert it to a fully react page with no helpers - but again, most pages aren’t in that state yet.
Like you said, we already have a couple of react only pages (or almost react only). I was talking about the use of helpers as a gradual process to migrate to react, which i think is still a long way off to accomplish completely.
@ohadlevy:
actually… I beg the differencehave a look at the model page [1] and the audit page [2] as examples
I would agree we are close somewhere, but are we so close (and confident), we want to do it everywhere?
I don’t think so, but if we are, I would agree with @amirfefer on a point the rails helper will make less likely for Rails only developers to actually go and develop in React.
My point of view is that we got the PoC working, but rather messy React codebase and I would like to see it more stable (at least in opinion on the structure) before going fully React. So for me we are like a year from going fully React and the helpers will help to stabilize and test the React codebase, but if its a question of months, I would not implement the helpers.
can you please expand? what in your opinion is messy or not good enough? what should we do different (not asking in sarcasm but trying to get something productive out of this point).
It seems to overflow this topic, but I will sum my key points from my onboarding to React and our React codebase I went through:
- Tests
- Structure of components is not consistent in a matter of test placing so I do not know where to put .test.js, fixtures.js for sure
- Test tools - I am not sure if snapshot testing is the way to go and the test helpers are not complete and above that not consitently used so I am not sure how to test in a right way.
- Fixtures files reusability for the storybooks - there are different example across code base and I am not certain what is the right way as a onboarder.
- Redux usage
- Inconsistancy again - I can find a lot of examples, I am not sure which is the right one.
- Usage - where to use redux and where not
- Uniqueness of the state space usage - there is problem with the component being on the page more times (being solved as we speek by Ron, but very young)
All of this comes from the very nature of React - that it is a library, not a framework, good read about it[1]. What is a good thing for me, because I like thinks being customizable for my use, but it means we need to invest few more months to figure and stabilize the coding guidelines and it’s usage.
I believe the UI team have put a lot of effort and the React onboarding in foreman was real fun for me because of that and they deserve big applause for that, but I had a lot of doubts how to do it in (Foreman) right way, what for me means the codebase is not mature enough yet to go fully React.
On the other hand, it can just means we got some legacy code, which missled me and if we put effort to clean up that, we can go fully React much sooner than how I feel it. The best way would be to create a simple handbook about the code guidelines (maybe something for a May meetup?)
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. 
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):
- I keep hearing “we’re almost there” for 1 year, the effort goes on for 2 years at least
- 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)
- we see (s)low adoption rate among developers
- 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
- 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
- UI team is aware of problems and work on them
- there are some developers outside of UI team contributing and even reviewing
- great improvements are being added in react - auto complete, datetime picker, tasks dashboard, templates editor, graphql being introduced
- 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
5 Likes
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.
2 Likes
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?
2 Likes
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 
) .
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
[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.
3 Likes
Oh, I still don’t like it. But it’s good that we reached a consensus.
3 Likes
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).
2 Likes
Captured on dev env, with no high server load simulation (that called cheating… ) I agree it would be better to capture both on prod
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.