With joy, I can see that more and more of Foreman’s core UI is moved to react. As most of you know, we develop and maintain a lot of plugins. I’d really like to start using react in plugins as I fear normal rails / erb templates won’t be supported in the long term future.
I know that using react works quite well in a development environment, but there are issues in a production environment. I believe that right now you have to always rebuild the plugin rpms once there are changes to a core package.
And my goal is to keep the maintainance effort for (our) plugins as low as possible.
My questions are:
What is the current status of React in plugins?
Would you recommend starting to use react in plugins?
Is the interface stable enough for production use?
What steps are required to move a plugin to react only?
Every plugin adds a webpack bundle with its specific webpack code. It also depends on the vendor webpack bundle. Because we don’t ship the vendor bundle in every plugin but rather share this, we add a dependency on the vendor.js bundle in RPM packaging. Because it’s unversioned, we depend on the hash as it’s mentioned in manifest.json. This means that if something changes in the vendor bundle, the hash changes and we need to rebuild plugins. In effect we depend on a specific build of Foreman where for plugins without webpack we only set a minimum Foreman version and trust it’ll work.
We do this because webpack wraps modules in an interesting way. By default it uses hashes that are order dependent. I think @tbrisker changed this to load them by source filename so perhaps this is no longer needed. We are evaluating the options to change this.
In Debian packaging we rebuild all bundles on the target machines. Essentially every Debian install is a source build. It reaches out to the internet for bundle install and npm install.
IMHO it’s experimental quality. Right now we’re trying to figure out why the new subscriptions page is broken in Katello and it’s a pain to debug why it doesn’t work in production but does work in development.
We are looking at changing the build process to be more reliable, but it’s unlikely this will be ready in time for 1.22.
No. As a release engineer I can tell you that in its current state it’s a constant source of pain and frustration. There is no automated way to know if the application actually works. Since there are no automated UI tests on the actual releases I always consider the UI broken unless proven otherwise.
My recommendation is to see how Katello stabilizes and once we’ve had a release that wasn’t delayed by webpack issues then to start converting.
Disclaimer: I have an intense hate for webpack and npm combined with a dislike for JS as a language. My view is colored.
Thanks for the honest assessment. Frankly speaking, this is quite staggering. What does that mean for react in core in general? Isn’t it wise to wait before merging react prs before the issues have been resolved?
Is there something I can help with?
The main issue as I see it today, is that wepack was not design to build assets in separation, or in other words, it is expected to build all of the assets at the same time to multiple bundles.
the issue that we face today, is the fact that are still assuming webpack should handle this part, but as a complied process, we lack the proper “api” between the various parts (core and plugins), as mentioned earlier, @tbrisker did solve some of the issues, however, that was not solving the core issue at hand.
I beg to differ. Using react components in core looks stable to me. I was talking about plugins. And as long as the packaging situation is not resolved, I concur with @ekohl that react for plugins has to be considered experimental. My concern is, that if we move more and more pages to react, we lose the ability for plugins to extend core. Frankly speaking, we’re introducing a lot of (unjustified) risk by not solving the issue.
Sounds great. What is the status there? How can we increase visibility and track the progress?
I don’t think that’s worth commenting.
That sounds interesting, What’s the difference to our current approach? Can we do the same with the current plugin architecture?
Can we integrate “old” rails/erb based pages into an SPA app?
I do agree with this with the side note that pages that should be modified from plugins are problematic.
That I agree with. We do have some (simple) scripts that actually hit the API, test hammer, apply puppet so that gives me at least a decent confidence in the core application code. I would really like something similar for the UI that gives me a base level of confidence.
Just my two cents on JS development in general
I’m feeling with you @ekohl…I’m not a fan of JS either.
I would say that currently react in plugins is in kind of experimental stage, therefore I’m not recommending using it for large parts atm, at least until we will stabilize it, which that point is close then ever I believe.
Thanks for the feedback @amirfefer. I really appreciate it. For me the most important aspect is packaging (I believe that would be “webpack redesign”). Do we have a rough ETA for that? Are we talking about 4 weeks, 8 weeks, 12 weeks or a larger timeframe?