State of React for Plugins


#1

Hi devs,

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?

Timo


React form inputs integration to rails forms
#2

I’m also interested. Once we’re ready, it would be great to update foreman_plugin_template or build foreman_plugin_react_template.


#3

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.


#4

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?


#5

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.

AFAIK @sharvit has been working addressing this issue in https://github.com/theforeman/foreman/pull/6434, so I’ll let him speak to the state of that work.

React in core IMHO is stable and there is no concern to it (besides the fact that there is a high burden for maintain both rails and react at the same time, which is maybe a different discussion).

regarding e2e ui testing, I fully support that, and I believe every build should be considered broken unless proven by CI, regardless if its react based or not.

the options I can imagine investigation further are:

  • evaluate if the path forward in https://github.com/theforeman/foreman/pull/6434 is valid.
  • move of all of the react ui into one repo (bad for plugin developers)
  • create a new foreman ui that can nativity be extended (e.g. a SPA with multiple bundles)

I believe its the fact that we are having a complex matrix of plugins, with rails views and webpack is challenging, and we are lacking a clear owner for driving this work forward.


#6

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?


#7

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.


#8

In my experience with React / ReactNative and Angular I’d highly recommend to use e2e tests with Protractor (unit tests with Karma / Jasmine should be taken for granted) from the very beginning. Developing JavaScript / TypeScript without TDD is giving you hell pretty soon.

Just my two cents on JS development in general :wink:

I’m feeling with you @ekohl…I’m not a fan of JS either.


#9

I mostly agree, atm React is stable in foreman core, but doesn’t in plugins.
We (@ui_ux) constantly work on react infrastructure:

  • Webpack redesign - which should improve packaging, production runtime errors, bundle duplication, etc…
  • Cooperation with QE in order to build UI dedicated E2E
  • Opinionated override mechanism - for instance, a PR in katello which replacing deface with react content using Slot&Fill
  • Adding client routing mechanism - https://github.com/theforeman/foreman/pull/6522

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.


#10

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?


#11

@sharvit, any ETA for webpack redesign ?


#12

It took me some time to update it and copy it from gdocs.
See: Redesigning the javascript stack


#13

I think there is more than one goal with the redesign and I believe we will ship it in more than one stage.
I believe 1.23 will contain most of it so plugins will have a stable env to work on.

Here is the RFC discussion: Redesigning the javascript stack