Perhaps it would be better to update the current helpers to use the react components instead? that way all the forms get updated without anyone having to change all the views to use the react version (except obviously where new field types are added).
2 Likes
that’s the way we have been doing it so far (e.g. autocomplete, pagination etc)
While it is a convenient way, no doubt, I do have some concerns that it would keep some distance from react, and developers would prefer using this approach instead of do some hands on with react.
so instead of gradually replacing forms into react, it will embrace using components into erbs
There is something on what you are saying. But I believe that till there is some ERB left, it should be embraced and done the “Rails” way. Meaning integrating nicely in RoR frontent.
I guess we are too from rewriting whole app in React, so I would make the effort to integrate with the Rails code, I see nothing bad about it to live together (as I were reading through the opinions we don’t know if we are going to be fully React in the end anyway)
3 Likes
I agree that with this way we get some better integration between rails and react, but meanwhile we discourage consuming react independently. IMHO while we add react content into rails helpers, we should also simplifies the way of consuming and creating react content by it own, with better documentation and better infrastructure my vision is that a developer (even a ruby dev 
) will prefer option B, because it will give more capabilities and better user experience.
1 Like
I totally agree with replacing existing ERB helpers content to mount react components. The example @ezr-ondrej mentioned is a new component though, there’s no helper for datetime as of now. The select is I believe the new implementation, not the select2 we use. I agree that having these helpers is beneficial for time being. If we prefix them with react_, we know that we should only use them on places where we combine ERB and react. So for the proposal from me.
Once we feel there’s minimum of ERB and all plugin maintainers write UI in react, I’d change my mind. Given State of React for Plugins I don’t think that happens anytime soon.
Is that a bad thing really?
I would prefer to offer better UI components (and consistent) regardless of how and where they were created.
on the other side, I do understand the extra work / pressure to make it work with the entire application…
I’d also say that the more use the React components get, the more they get tested and ensured they support all the needed options. When you’re converting pages to pure React, that makes it easier.
This exactly was the main motivation, I am not skilled JavaScript developer however I have no problems if JS team provides me set of good components, documented, with a demo (which we have) so I can try them and then put them onto a page in a Rails way.
I am payed by Red Hat therefore if managers decide we should all learn JavaScript, I can do that. However we have many community members with Rails skills who may not have time for this.
But if there’re enough components (forms, tables, pagination, etc) which allows creating a full react page, why should I mount these on rails erb? if I can gain a much better user experience with react javascript stack?
Because we already have multiple pages in both core and plugins that use the erb helpers right now, and you don’t want to rewrite them all just to change the implementation.
Helpers are an abstraction - they make it easy to consume a component and ensure we have consistent layout across the whole application. A developer doesn’t need to care about whether the form field uses jquery or react - they just add a line and know it will look the same as everywhere else.
The component should care either whether it’s mounted from an ERB helper or from a parent component - it should have a clear API that defines which props it expects, not caring about where the actual data comes from.
If we split the react implementations from the legacy ones, we will end up in a situation similar to what we have in some of the katello pages that use a different angular implementation and look different to the rest of the app.
As long as we don’t have a reliable way of including react in plugins, that also means plugins will not be able to consume the same components. If there is a helper that mounts the component that is provided in core - the plugin doesn’t actually need to care about it or even compile its own code, it essentially benefits from the change in implementation for free.
Once we have pages that are composed only of helpers that are all implemented in react, it makes sense to say “we don’t need the ERB anymore” and get rid of it in favor of a fully react page, but I don’t think that we are going to be close to that anytime soon.
2 Likes
actually… I beg the difference 
have a look at the model page [1] and the audit page [2] as examples
[1] https://github.com/theforeman/foreman/blob/develop/app/views/models/index.html.erb
[2] https://github.com/theforeman/foreman/blob/develop/app/views/audits/index.html.erb
That’s not accurate, atm katello uses the same components from core, and in fact two major pages (subscriptions and repositories) are 100% react with client routing.
But I agree it’s not 100% reliable, because of the current JavaScript stack architecture.
I partly agree, as soon as we’ll have a critical mass of components (IMHO we almost there), and better infrastructure (Packaging / webpack / client routing / slot & fill). moving to react based page happens naturally, and in fact it already happened in audit and hardware model pages. But If we will wait until all of the pages will be made from react generated helpers through erbs, we will never have a react page.
I’m not against using ruby helpers for creating react content at the moment, In addition to that we can encourage others how to use react and about the great advantages of having a full react page, which can happen simultaneously
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 difference
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…)