Naming of react-dom/server is misleading

[Merri]

TL;DR: I think it should be react-dom/static

If we have a look at what react-dom/server actually does, it only provides two methods: renderToString and renderToStaticMarkup. Both of these result in static HTML: the later one gives plain HTML while the first one gives React-flavored HTML that React can quickly inject to. But essentially all you get is static HTML as a string.

I can understand why it says server in the name: in most cases you really only want to use it in server-side and thus name it based on that. However I think this leads to people to think you should never use the code client-side, which isn't true for it's nature. There are perfectly fine use cases for client-side. For example, I've written a lazy loader component which renders this.props.children as "non-react" static HTML until component comes into the viewport.

The rendering trick must be done because you can't have real DOM elements inside a noscript element: it's contents is always seen as a string (or as nothing at all if you ask IE8-). The noscript element is important for the lazy loading trick in this case, because it allows for loading the images even if JavaScript is disabled and in addition search engines can also get access to the images; although Google these days does support JavaScript, but I have no idea if it deals with lazy loading via virtual viewport or not. Also, most importantly, by using noscript browser will not start fetching any images or resources contained within the noscript element when JavaScript is enabled.

So the use case in summary:

1. Server renders static HTML with noscript elements containing non-reactified static HTML.
2. Client must render this exact same static HTML inside noscript element on initial render.
3. Once componentDidMount client can start updating the DOM by checking if the component is in the viewport or not.
4. In case JavaScript is disabled you can still get the images / resources loaded. You just won't have them lazy loaded.

So I think it should be react-dom/static; although I might also question the fact whether static rendering really has to be abstracted to it's own dependency.

Finally, I already received a pull request that initially attempted to remove react-dom/server dependency purely because it's name is what it is. I don't know if anyone else gets this noise, but I guess it is quite likely for that to happen, because naming things is hard yet names are powerful.

[zpao]

Thanks for the detailed write-up. I get where you're coming from on the naming but I think we're unlikely to change this in the short term. As we flesh out the direction we're heading with multiple renderers and third-party rendering, we'll see where we end up.

[Merri]

I guess that will be good enough to know; and I guess I should've been more active on this immediately when I first heard about 0.14 changes as that would'be been a better time. But at that point I didn't have that lazy loader in a well tested form.

[likethemammal]

I agree with @Merri. There are still cases on the client side where rendering to static html is required. For instance, in my case I'm trying to pass along html (created from a react component) to a 3rd party lib, leaflet.js, the open-source JS map solution.

The popups on maps can take in html and display it whenever that popup's marker get clicked. To bind the popup to a marker you call bindPopup, sending in static html and some popup options. I used to accomplish this using renderToString, but I'm guessing renderToStaticMarkup will work for that now. It just feels wrong to use a tool designated for the server side on the client side, you know?

[jimfb]

Thanks for the great discussion!

The name server kind of makes sense, since everyone calls the most common usage/technique server-side-rendering (SSR). Although it can be used on the client side, that's far less common, and no name will be both completely generalized and completely precise (specific/meaningful). I'm going to close this out, because there is nothing actionable at the moment, but we can continue bikeshedding here and reopen if/when a name change seems imminent.