Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash when using React 16.4.1 #555

Closed
dustinsoftware opened this issue Jun 20, 2018 · 8 comments
Closed

Crash when using React 16.4.1 #555

dustinsoftware opened this issue Jun 20, 2018 · 8 comments
Labels

Comments

@dustinsoftware
Copy link
Member

While investigating #554, I discovered that React.NET totally breaks when using react and react-dom 16.4.1, but 16.4.0 seems to be unaffected, so users can pin to that version until we ship a fix.

Unfortunately the crash is obscured by a check that looks for React on the global scope. To see the real exception, patch ReactNET_initReact to always return true in shims.js. I'll open up a separate issue to investigate whether we still need to have that method around (we'd just crash at runtime if one of the globals was missing, right?)

Anyhow. The real crash is ReactScriptLoadException: Error while loading "~/components-bundle.generated.js": ReferenceError: 'setTimeout' is not defined

Which corresponds to SelectEventPlugin:

// We capture a local reference to any global, in case it gets polyfilled after
// this module is initially evaluated.
// We want to be using a consistent implementation.
var localDate = Date;
var localSetTimeout = setTimeout; // crash!
var localClearTimeout = clearTimeout;

The regression appears to be introduced by this change: https:/facebook/react/pull/12931/files#diff-bbebc3357e1fb99ab13ad796e04b69a6L47

I'll open an issue tomorrow and investigate a fix. cc @Daniel15

@ChadBurggraf
Copy link
Contributor

As a temporary workaround for folks, you can add the following shim to the beginning of your configuration scripts:

https://gist.github.com/ChadBurggraf/4c4abef515852aa1efee04478a8a8641

@dustinsoftware
Copy link
Member Author

I ran out of time to investigate this today, I'll pick it up again in a few days if someone doesn't get to it first. I wanted to repro the issue with the master branch of react since it looks like some recent changes have been made in the scheduler.

dustinsoftware pushed a commit to dustinsoftware/react that referenced this issue Jun 21, 2018
setTimeout and clearTimeout may not be available in some server-render
environments (such as ChakraCore in React.NET), and loading
ReactScheduler.js will cause a crash unless the existence of the
variables are checked via a typeof comparison.

reactjs/React.NET#555
dustinsoftware pushed a commit to dustinsoftware/react that referenced this issue Jun 21, 2018
setTimeout and clearTimeout may not be available in some server-render environments (such as ChakraCore in React.NET), and loading ReactScheduler.js will cause a crash unless the existence of the variables are checked via a typeof comparison.

reactjs/React.NET#555

The crash did not occur in 16.4.0, and the change appears to have been introduced here: https:/facebook/react/pull/12931/files#diff-bbebc3357e1fb99ab13ad796e04b69a6L47

I tested this by using yarn link and running it with a local copy of React.NET. I am unsure the best way to unit test this change, since assigning null to `setTimeout` causes an immediate crash within the Node REPL.
dustinsoftware pushed a commit to dustinsoftware/react that referenced this issue Jun 21, 2018
setTimeout and clearTimeout may not be available in some server-render environments (such as ChakraCore in React.NET), and loading ReactScheduler.js will cause a crash unless the existence of the variables are checked via a typeof comparison.

reactjs/React.NET#555

The crash did not occur in 16.4.0, and the change appears to have been introduced here: https:/facebook/react/pull/12931/files#diff-bbebc3357e1fb99ab13ad796e04b69a6L47

I tested this by using yarn link and running it with a local copy of React.NET. I am unsure the best way to unit test this change, since assigning null to `setTimeout` causes an immediate crash within the Node REPL.
gaearon pushed a commit to facebook/react that referenced this issue Jun 22, 2018
* Fix crash during server render.

setTimeout and clearTimeout may not be available in some server-render environments (such as ChakraCore in React.NET), and loading ReactScheduler.js will cause a crash unless the existence of the variables are checked via a typeof comparison.

reactjs/React.NET#555

The crash did not occur in 16.4.0, and the change appears to have been introduced here: https:/facebook/react/pull/12931/files#diff-bbebc3357e1fb99ab13ad796e04b69a6L47

I tested this by using yarn link and running it with a local copy of React.NET. I am unsure the best way to unit test this change, since assigning null to `setTimeout` causes an immediate crash within the Node REPL.

* Fix flow errors and log warning if setTimeout / clearTimeout are
not defined / not a function.

* Use invariant to assert setTimeout / clearTimeout are functions

* Remove use of invariant

* Explain
@Neuroforge
Copy link

@ChadBurggraf Where in the code do you add that?

I am seeing this error since adding Video.js via npm.

@Neuroforge
Copy link

Neuroforge commented Jun 24, 2018

@dustinsoftware When will the changes that were merged be released via Nuget? Or do i have to build from source now?

@dustinsoftware
Copy link
Member Author

dustinsoftware commented Jun 24, 2018 via email

@Neuroforge
Copy link

Neuroforge commented Jun 24, 2018

@dustinsoftware Awesome. Thank you for the response.

So i've downgraded React and React-Dom to 16.4.0 but still seeing the error.

The version number inside of react.development.js is 16.4.0 and same with react-dom.development.js

Still seeing the timeout issue.

Does Webpack or the JsEngineSwitcher affect this?

@dustinsoftware
Copy link
Member Author

@Neuroforge do you only see this error when adding Video.js? Are you bundling react with webpack or using the built in react version?

@Neuroforge
Copy link

I will try using another js library with timeout. Any ideas on a good one to try?

I am using Webpack and ChakraCore js engine.

dustinsoftware added a commit to dustinsoftware/React.NET that referenced this issue Jun 29, 2018
In some cases, React (or other libraries) will assume that setTimeout
and clearTimeout are defined on the global scope, without invoking it.

We should still throw an error in case a consumer expects this to just
work on the server (it won't), but we can avoid a crash by defining the
function on the global scope.

For context: reactjs#555
dustinsoftware added a commit that referenced this issue Jun 30, 2018
In some cases, React (or other libraries) will assume that setTimeout
and clearTimeout are defined on the global scope, without invoking it.

We should still throw an error in case a consumer expects this to just
work on the server (it won't), but we can avoid a crash by defining the
function on the global scope.

For context: #555
Daniel15 pushed a commit that referenced this issue Jul 1, 2018
In some cases, React (or other libraries) will assume that setTimeout
and clearTimeout are defined on the global scope, without invoking it.

We should still throw an error in case a consumer expects this to just
work on the server (it won't), but we can avoid a crash by defining the
function on the global scope.

For context: #555
toptaldev92 added a commit to toptaldev92/React.NET that referenced this issue Jul 28, 2021
In some cases, React (or other libraries) will assume that setTimeout
and clearTimeout are defined on the global scope, without invoking it.

We should still throw an error in case a consumer expects this to just
work on the server (it won't), but we can avoid a crash by defining the
function on the global scope.

For context: reactjs/React.NET#555
onlinehub0808 added a commit to onlinehub0808/React.NET that referenced this issue Jun 2, 2023
In some cases, React (or other libraries) will assume that setTimeout
and clearTimeout are defined on the global scope, without invoking it.

We should still throw an error in case a consumer expects this to just
work on the server (it won't), but we can avoid a crash by defining the
function on the global scope.

For context: reactjs/React.NET#555
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants