ReactDOMServer 0.14.0 doesn't eval on Java 8 Nashorn JavaScript Engine

[aantono]

With the release of 0.14.0 and the modular split, the use of ReactDOMServer.renderToString(...) in the code instead of the original React.renderToString(...) results with an error in Nashorn, as it does not support any module system, so it is not possible to execute the suggested require('react-dom/server').

The code for testing was obtained from here and modified to use version 0.14.0 instead of 0.13.1 - https://github.com/sdeleuze/spring-react-isomorphic
This is being executed on the latest version of Java 8 - 1.8.0_66

Potentially related to #3037

Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is java.lang.IllegalStateException: Failed to render script template] with root cause
jdk.nashorn.internal.runtime.ECMAException: ReferenceError: "ReactDOMServer" is not defined
    at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:57) ~[nashorn.jar:na]
    at jdk.nashorn.internal.runtime.ECMAErrors.referenceError(ECMAErrors.java:319) ~[nashorn.jar:na]
    at jdk.nashorn.internal.runtime.ECMAErrors.referenceError(ECMAErrors.java:291) ~[nashorn.jar:na]
    at jdk.nashorn.internal.objects.Global.__noSuchProperty__(Global.java:1432) ~[nashorn.jar:na]
    at jdk.nashorn.internal.scripts.Script$Recompilation$779$48AA$\^eval\_#1\!6653\^eval\_.process(<eval>#1:6653<eval>:25) ~[na:na]
    at jdk.nashorn.internal.scripts.Script$Recompilation$777$1754AA$\^eval\_.L:1$render(<eval>:1) ~[na:na]
    at jdk.nashorn.internal.scripts.Script$Recompilation$757$33AA$\^eval\_.render(<eval>:3) ~[na:na]
    at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:644) ~[nashorn.jar:na]
    at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:228) ~[nashorn.jar:na]
    at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393) ~[nashorn.jar:na]
    at jdk.nashorn.api.scripting.ScriptObjectMirror.callMember(ScriptObjectMirror.java:199) ~[nashorn.jar:na]
    at jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(NashornScriptEngine.java:383) ~[nashorn.jar:na]
    at jdk.nashorn.api.scripting.NashornScriptEngine.invokeFunction(NashornScriptEngine.java:190) ~[nashorn.jar:na]
    at org.springframework.web.servlet.view.script.ScriptTemplateView.renderMergedOutputModel(ScriptTemplateView.java:294) ~[spring-webmvc-4.2.0.RELEASE.jar:4.2.0.RELEASE]

[jimfb]

Yep, sounds like another reason to include renderToString on ReactDOM. This is also causing problems for testing (on jsfiddle), ClojureScript, bower distribution, etc.

Can we polyfill Nashorn with a module loader? Something like jvm-npm?

[sophiebits]

Just as for a browser, you can use browserify to create a bundle that Nashorn will understand.

[Daniel15]

Can we polyfill Nashorn with a module loader?

It's easier to just build a bundle at compile time :)

Just as for a browser, you can use browserify to create a bundle that Nashorn will understand.

I think this is the approach I'll be taking for ReactJS.NET. Currently I'm still using React.renderToString and ignoring the deprecation error, but that's super janky.

Is there anything actionable left? It sounds like this is by design. Is there debug code to detect bad environments that could be updated to check for the existence of required globals?

[sophiebits]

@JaRail I'm not sure what you mean, but no, there's nothing actionable here.

I just mean a guard to make this misconfigure easier to debug.

if (DEBUG && !require) { throw new Error("You need a module loader."); }

Thanks Ben.

[sophiebits]

React doesn't use require internally so I don't think that would make much sense. I'm hopeful that people who write a require() call and immediately see that it doesn't work will realize that they need a module loader.

[aantono]

So what would be a proposed solution for handling this for a Nashorn Java 8 environment?

[sophiebits]

You should use a module bundler like browserify to make a single bundle that you can load, much like people do when using React from npm and sending the result to a browser. It sounds like something like jvm-npm might work too.

[Download]

Can we polyfill Nashorn with a module loader?

In theory we can. There is the jvm-npm project which aims to do this, however I tried and failed at getting it to work.

It's easier to just build a bundle at compile time :)

Maybe.... It depends. I am loading React and ReactDOM from CDN, so my bundle,js does not contain it. This makes my bundle (which changes every couple of minutes during development and every week or so on production) a lot smaller and faster to update. I am including React, ReactDOM and my own bundle in Nashorn to get it to work on the server as well. This used to work via React.renderToString but this approach is going to stop working once that option disappears.

I have a hard time following the reasoning of you guys. You take a problem which is as simple as adding:

ReactDOM.ReactDOMServer = ReactDOMServer;

at the right place in the ReactDOM code and turn it into the user of the library having to polyfill CommonJS modules on the target platform, just to get a reference to ReactDOMServer...

Why?

I mean if you grab the bundled version of ReactDOM, ReactDOMServer is already in there. It's just not exposed. That's very silly actually isn't it? This bundle contains code that can never be used...

I am so hoping you guys are able to come up with a more elegant solution than this for us Java devs.