React.NET and React v18 support

[LorenDorez]

For v18, I think its going to be best to do a major breaking change here and move the React.Net.

Goal is to start a new branch doing something like Daniil started with NodeReact.NET. We would leverage Javascript.NodeJS for the interop work between NodeJS and .NET. The biggest concern right now is support for CSS-IN-JS which this project did with RenderFunctions. This has yet to be implemented in NodeReact.NET but i have a working POC for work to add this support as we heavily use MUI which depends on emotion at this time.

The reason I recommend basically merging the concepts from NodeReact.NET to this project is mainly due to the popularity of project and just make sense for a natural transition here.

This one will be a bigger discussion going forward as we look to better align with .NET 6+ and React v18+.

Please leave any thoughts, concerns etc...

[enkelmedia]

Hi!

Really nice that you're looking at React v18 support for this package, I'm a log time user.

I was looking at NodeReact.NET as a possible alternative since I really need support for React 18 for a project right now. I really struggled to get something to render with React.NET but after applying some hacks I got things to render =D

• self is not defined "self" is not defined error on server side generated entry file gregberge/loadable-components#276
• TextEncoder https://stackoverflow.com/questions/73422871/reactjs-net-referenceerror-textencoder-is-not-defined by edit: /node_modules/react-dom/cjs/react-dom-server.browser.production.min.js

The browser shows the following errors when hydrating:

react-dom.development.js:86 Warning: ReactDOM.hydrate is no longer supported in React 18. Use hydrateRoot instead. Until you switch to the new API, your app will behave as if it's running React 17. Learn more: https://reactjs.org/link/switch-to-createroot
printWarning @ react-dom.development.js:86
error @ react-dom.development.js:60
hydrate @ react-dom.development.js:29650
(anonymous) @ (index):72
2 react-dom.development.js:86 Warning: Cannot hydrate Suspense in legacy mode. Switch from ReactDOM.hydrate(element, container) to ReactDOMClient.hydrateRoot(container, <App />).render(element) or remove the Suspense components from the server rendered components.
    at Suspense
    at div
    at App (http://localhost:5203/assets/client/client.bundle.js:40054:61)
    at Router (http://localhost:5203/assets/client/client.bundle.js:36306:15)
    at BrowserRouter (http://localhost:5203/assets/client/client.bundle.js:34411:5)
    at AppClient

Also, when using React.NET any content inside React.Suspense-components will not be rendered on the server side. As far as I understand this is because the new "streaming" way to render components on the server is not used today.

I made some simple benchmarks to compare with NodeReact.NET and the current implementation that React.NET uses was a lot faster. I'm running the same code (a simple React test app with react-dom-router and using React.Lazy and React.Suspense.

Results:

NodeReact:NET
Requests per s: 19
Median load time: 216ms

React.NET
Requests per s: 3017
Median load time: 0,55ms

What I'm trying to say: The speed and scalability of the current implementation with V8 seem to be a lot better if you still consider Javascript.NodeJS I would encourage some benchmarks just to make sure that numbers are not way off.

Edit:
Wanted to share the some updates on the performance-issue. It not as bad as my initial tests indicates but still there is a difference: DaniilSokolyuk/NodeReact.NET#12

[LorenDorez]

@enkelmedia Thats for the reply, good to hear others are excited for the upcoming updates.

As for the React.NET, getting the current structure to run on v18 while do able brings in other issues, headaches and complications. React.NET currently leverages the .renderToString() method which React is trying to slowly distance it self in favor of the new streaming APIs. React v18 has a lot of performance improvements and the new streaming apis are just the beginning for some cool features they have planned for in the future.

As for the benchmarks, performance is definitely going to be something that will be a top priority but comparing React.Net to NodeReact.NET isnt really an apple to apples comparison. Thier underlying structures are different as React.NET uses JSE which uses libraries to allow running Javascript through what is called engines but mainly uses sync based calls. While NodeReact.net actually boots up a full Node.JS Server Process and interops between the 2 processes and is fully geared to async. With NodeReact.NET things like NodeJS version and usage comes into play, also the version of .NET and if your leveraging full async in your render process. There are setting ill play with as well but also keep in mind the version of .NET your using, for example there was a bug in versions before .NET 6 that causes the Environment.ProcessorCount to bet which can lead to terrible performance. see here for reference

Also while I love NetLing for basic load testing I've wouldn't use it as a benchmark tool. I would recommend using something like Benchmark.NET

Either way rest assured I will always keep performance as a top priority in any work I do.

[enkelmedia]

Hi!

Thanks for getting back with a great response! =D

I actually played for almost 10 hours this weekend to get to know how things work. I came to the understanding that the ClearScript-engine does not implement the JavScript Web APIs that browsers do. Hence, like you say, it would probably very hacky and bring headaches and complications if someone would try to polyfill all of the stuff that React uses for ReactDOMServer.renderToReadableStream().

I got renderToString() to work with V18 but it only renders fallbacks for React.Suspense on the server and while renderToReadableStream would evaluate and render them as well using stuff in the Web APIs that's not implemented in ClearScript.

I know that NetLing is not state of the art in any way and I often use Benchmark.NET but in this case the differences are so clear that the point is still valid.

I agree that the Node-interop approach is most likely the only sensible way to approach this even if that means a dependency on the hosting environment.

I'm happy to help out in any way, maybe feedback, testing etc. Just let me know.

Cheers!

[LorenDorez]

Thanks for the update and ill definitely ping you about helping to test.

Yeah renderToString() will never support lazy or suspense sadly so moving to the streaming apis is the only choice.

It will be a bit before I can get to this (its in between my paid tasks) as I plan to do these upgrades the the project in order:

1. Upgrade .NET dependencies
2. Update React to v17.0.2
3. Tackle the v18 beast.

v18 will be a major breaking change and restructure a lot of this project im afraid. So, my plan there is to do a new branch there and more or less start from scratch while keeping the new API as compatible as possible with the old one so it can be an easy transition..

[MoboDK]

LorenDorez i would like to help, but i am afraid that i am not much help with react. But I cheer on you 🚀
I know there is a lot of people which will love to get the module to work on react 18

[mootinator]

I'm not sure I'm using most of the features of this library, but I did get some of my apps to play nice with React 18

Got around the missing TextEncoder/TextDecoder by adding the fastestsmallesttextencoderdecoder npm module to my server.jsx and referencing it as such:

import { TextEncoder, TextDecoder } from 'fastestsmallesttextencoderdecoder';

Thought I'd throw that out there.

This doesn't, of course, address the problem of the old .NET dependency.

[enkelmedia]

@mootinator its possible to get it to work/render but only when using:

ReactDOMServer.renderToString()

This method of doing SSR is not recommended by React anymore. If you render a simple react app or an app that does not use features like React.Suspense you might be just fine.

However, in the long run it’s not a wild guess to think that more and more new features will be unsupported with the legacy renderToString().

The new recommended way is

ReactDOMServer.renderToReadableStream()

And this is where the problems starts to show up and there are a lot more stuff that needs to be polyfilled, probably not impossible but also very hacky and probably not a sustainable long term solution.

[mootinator]

Right.

I'm at a point where I'm letting these projects limp along for the time being, but have some time allocated to a long-term solution. If we're reviving this repo I wouldn't be opposed to learning the ins and outs of React a bit better and throwing those cycles towards helping out.

[Daniel15]

We would leverage Javascript.NodeJS for the interop work between NodeJS and .NET.

I was thinking the same thing. In the early days of React, it was mostly JS-engine-agnostic and everything worked fine. These days it's using more Node.js feature and only Node and mostly-Node-compatible (Bun, Cloudflare workers, etc) engines work well with it.

It's worth noting that Andrey added support for the JeringTech library to JavaScriptEngineSwitcher a few years ago, so it might be possible to prototype something using the JavaScriptEngineSwitcher infra that currently exists.

It might be worth seeing if react-rails still supports server-side rendering, and if so, how it's implemented. That library was the original inspiration for this one.

[LorenDorez]

IIRC the JSE added JeringTech but didnt have NodeStream support. See Taritsyn/JavaScriptEngineSwitcher#100

also ive been thinking more on this as well because seems like Reactis getting closer to Next.js. What i mean by this is that seems like some of the newer features are directly related/tied to Next.JS features/support. While other framework can still build there own it might be worth also exploring using JeringTech to spin up Next.JS. I believe its pretty customizeable and had the option/config to change the process name so something we can also look at.

PS. sorry been a bit busy with some other paying gigs but still very high on my list :)