Integrating React.js into Plone

NB: this post is not related to the recent discussion about using React.js or Angular.js recently appeared on the core-dev mailing list. Let's say that although Plone will choose Angular.js (or no framework) someone can like to use React.js.

I'd like to use React.js in Plone and there are any integration product right now, so I think we can evaluate a collective.js.react. Question is: what is the best way to do it?

The mainstream way of using React.js is by developing through the JSX format, then process it to a real JavaScript source.

Some notes:

  • while developing the transformation of JSX to JS can be done using nodes.js and the jsx command, or including the JSXTransformer javascript source (last one is a realtime build, slow and not to be used in production)
  • in production mode, only build JavaScript source must be distributed

How can we integrate this in a normal Plone development?

The simple way I see is to use nodes, distribute the JSX source inside add-on packages, then call jsx --watch to build it during the development process. Then the final resource (loaded by portal_javascript, or whatever) will be only the final build.
In this way the integration package will be really simple.

There' also a PyReact python package, to do JSX transforms from Python.

Any better point of view?

1 Like

I just started using React.js and did some sample integrations in Plone.

So far I always integrated the build.js (minified /gzipped) directly. Size was approx. 50Kb.
But yes if there are like 5 React apps running on the same page, it does not make sense to include React and ReactDOM in every build.js.

But currently im struggling at complete different points, like "How to do a full integration test, without robot test framework". While I can test the backend and the front end independently, the grant come-together is not possible. Also development with plone as backend ist no always that easy (proxy, auth, etc.).

You will likely need the ZSERVER_FIXTURE so you can hit Plone via http:

Note that technically this means your tests need to be functional tests, not integration tests, since the request handling on the http interface will do auto-commits for you (which is ok for functional, but not acceptable for integration testing).