Why doesn't React on Rails hydrate at the DOMContentLoaded event?

[kotarella1110]

In React on Rails, hydration and rendering sometimes occur at the load event. This happens because of the current implementation of the onPageReady function.

react_on_rails/node_package/src/clientStartup.ts

Lines 310 to 337 in 4339d30

	function onPageReady(callback: () => void) {
	if (document.readyState === "complete") {
	callback();
	} else {
	document.addEventListener("readystatechange", function onReadyStateChange() {
	onPageReady(callback);
	document.removeEventListener("readystatechange", onReadyStateChange);
	});
	}
	}
	export function clientStartup(context: Context): void {
	// Check if server rendering
	if (!isWindow(context)) {
	return;
	}
	// Tried with a file local variable, but the install handler gets called twice.
	// eslint-disable-next-line no-underscore-dangle
	if (context.__REACT_ON_RAILS_EVENT_HANDLERS_RAN_ONCE__) {
	return;
	}
	// eslint-disable-next-line no-underscore-dangle, no-param-reassign
	context.__REACT_ON_RAILS_EVENT_HANDLERS_RAN_ONCE__ = true;
	onPageReady(renderInit);
	}

If clientStartup is executed when readyState is loading, hydration occurs at the interactive state (DOMContentLoaded event). However, if clientStartup runs when readyState is already interactive, hydration is delayed until the complete state (load event). => When clientStartup is executed, hydration always occurs when readyState is complete.

This behavior causes hydration to wait until all sub-resources, such as third-party JavaScript or Google Fonts, are fully loaded, potentially delaying the user’s interaction readiness.

Would it be possible to allow hydration at the DOMContentLoaded event when the readyState is already interactive? For example, the following update to onPageReady could address this:

function onPageReady(callback: () => void) {
- if (document.readyState === "complete") {
+ if (document.readyState !== "loading") {
    callback();
  } else {
    document.addEventListener("readystatechange", function onReadyStateChange() { 
      onPageReady(callback); 
      document.removeEventListener("readystatechange", onReadyStateChange); 
    });
  }
}

This adjustment ensures hydration begins as soon as the DOMContentLoaded event fires, even if clientStartup is executed after the interactive state.

Are there any reasons or side effects that might prevent this change from being implemented? If this approach is acceptable, I’d be happy to submit a PR for it.

[alexeyr]

As it happens, I was looking into this as well.

It used to be on DOMContentLoaded, but was switched to load: #1540, mentioning an issue with DOMContentLoaded was revealed in #1539.

And that mentions 7b301f9 which changed it the other way around earlier...

@Judahmeek @justin808 Do you remember what exactly "the race condition revealed by #1539" was? And was the intention actually "after DOMContentLoaded" or "on load"?

If clientStartup is executed when readyState is loading, hydration occurs at the interactive state (DOMContentLoaded event).

I don't think that's correct; when the state changes to interactive, it just adds onReadyStateChange as a listener again, and the callback will only run when it's complete.

[kotarella1110]

I don't think that's correct; when the state changes to interactive, it just adds onReadyStateChange as a listener again, and the callback will only get run when it's complete.

My understanding was incorrect. You’re absolutely right. It seems that hydration always happens at the onload event.
I’m currently facing this issue and looking for a way to address it because the hydration process is too slow.
By the way, in our current product using React on Rails, it takes about 4 seconds to load all sub-resources after DOMContentLoaded. This means there is a significant delay before users can interact with the page.

[justin808]

Should we make this configurable? Or is there a way that we can choose sensible defaults?