Many people that use ReactJS as their renderer are using some kind of the
Flux architecture to store data, react to actions and notify components
about changes. After a University project involving Scala and RxJava, I wanted
to use these ideas together with ReactJS views. Besides that I found two things
missing in the Flux architecture:
composing different kinds of data easily
interaction with the server
Of course there are ways to solve this, but perhaps reactive streams can help
ease these shortcomings.
ReactJS is becoming a hugely popular
solution for building complex Web Applications. It is so nice to use because
it really resembles building applications like you used to in the good old PHP
days a long time ago, where you construct the HTML once on the server, and be
done with it. Don't think about changing state over time, just render once, and
refresh once the data changed.
ReactJS runs entirely in the Browser. You give the components data, and it
constructs the DOM for you. This means that your initial page can be as simple
"Server rendering is not about SEO, it's about performance. Consider
the additional roundtrips to get scripts, styles, and subsequent API
requests. In the future, considering HTTP 2.0 PUSH of resources."
So we need to pre-render the DOM on the server too.
Fortunately this is really easy with ReactJS, using the React.renderToString
function. It's exactly like the React.render function, except rendering it to
in a DOM node, it returns a string. The HTML in that string contains
data-react-* attributes, so if you React.render on the client-side again,
it picks up the DOM that is already there and only applies the actual changes.
It takes the string as initial DOM state.
The thing with ReactJS, however, or with any client-side rendering engine, is
the client side. With NodeJS we have this amazing server-side runtime that can
ReactJS to generate the server-side HTML.
The downside of NodeJS is that not every server configuration has NodeJS easily
available. For example a lot of servers use Ruby, Python, Java or PHP.
There are two options: run NodeJS as a "render service" or use an embedded
NodeJS as local Render Service
One option would be to run a NodeJS process on your server, and use an internal
port or Unix Socket to render the ReactJS components with NodeJS and use the
result in the original stack.
And then your original code, for example your Python 3 server, can use this
very simple snippet to render the ReactJS component with NodeJS as service:
The downside of this approach is that you have to send your data from your
program through a TCP port or a Unix Socket.
ReactJS with the Embedded JS Runtime in Java
was Rhino, and now, since Java 8, there is Nashorn. In Java you have an entire
something like this, directly taken from the Nashorn website at Oracle:
As it turns out is is relatively easy to run ReactJS in Java, as shown here:
As shown above, there are two approaches that make loading the initial page
load, with pre-rendered ReactJS components on the Server super fast, as the
browser has to do less, and you don't need an initial Ajax request for your
initial data. The NodeJS solution is very flexible, as it can be used for any
programming language, but it requires running a NodeJS process along your
normal server. If you're using Java, or anything that runs on the JVM (Java,
Scala, Clojure, JRuby, etc.) you can use the embedded version. Finally thanks
to ReactJS, it perfectly consumes your server-generated DOM structure, so after
updates, it just updates the difference, which makes it a very fluid and easy
to program solution!