Webpack HMR Throws React syntEvent Error due to jsPDF

Question

SYSTEM INFORMATION:

OSX 10.12.4 Sierra Node v7.10.0 npm v4.2.0 

VIEWING VIEWS:

 Chrome 58.0.3029.110 Safari 10.1 Firefox 53.0 

PROBLEM:

I have an application that works efficiently in production, which I cloned and am trying to update in preparation for building a sequel. However, I ran into the weird Webpack problem, updating its / React / HMR to more recent builds.

HMR will connect, and Webpack seems to be compiling just fine. However, interacting with the page (for example, clicking) results in the following error:

Obviously, the application is no longer functioning at this moment, since clicking on things does not knock anything down. Interestingly, we also get the following 404 error in the Node console and in the browser:

(NOTE: this is apparently a gigantic query string, including functions, and in particular syntEvent links. I can print all this for you if you want)

NODE v6.3.1

RELEVANT NPM:

 "react": "^15.5.4", "react-dom": "^15.5.4", "react-transform-catch-errors": "^1.0.0", "react-transform-hmr": "^1.0.4", "webpack": "^2.5.1", "webpack-dev-middleware": "^1.10.2", "webpack-hot-middleware": "^2.18.0" "babel-cli": "^6.11.4", "babel-core": "^6.24.1", "babel-eslint": "^7.2.1", "babel-loader": "^7.0.0", "babel-plugin-array-includes": "^2.0.0", "babel-plugin-transform-decorators-legacy": "^1.0.0", "babel-plugin-transform-object-assign": "^6.0.0", "babel-preset-es2015": "^6.24.1", "babel-preset-react": "^6.24.1", "babel-preset-react-hmre": "^1.1.1", "babel-preset-stage-1": "^6.24.1", 

WEBPACK.CONFIG.DEV.JS:

 var path = require('path'); var webpack = require('webpack'); var autoprefixer = require('autoprefixer'); var hotMiddlewareScript = 'webpack-hot-middleware/client'; console.log('using the dev config file'); console.log('THE PUBLIC PATH: ' + path.join(__dirname, '/CLIENTSIDE/static')); module.exports = { devtool: 'eval', entry: { background: ['webpack-hot-middleware/client', path.join(__dirname, '/CLIENTSIDE/components/background')], uniqueShare: ['webpack-hot-middleware/client', path.join(__dirname, '/CLIENTSIDE/components/uniqueShare')], starRating: ['webpack-hot-middleware/client', path.join(__dirname, '/CLIENTSIDE/components/starRating')], testingPage: ['webpack-hot-middleware/client', path.join(__dirname, '/CLIENTSIDE/components/testingPage')], style: ['webpack-hot-middleware/client', path.join(__dirname, '/CLIENTSIDE/components/style')] }, output: { path: path.join(__dirname, '/CLIENTSIDE/static'), filename: '[name].js', publicPath: '/static/' }, plugins: [ new webpack.optimize.OccurrenceOrderPlugin(), new webpack.HotModuleReplacementPlugin(), new webpack.NoEmitOnErrorsPlugin() ], module: { loaders: [ { test: /\.(js|jsx)$/, exclude: /(node_modules|bower_components)/, loader: 'babel-loader', query: { cacheDirectory: true, presets: ['react', 'es2015', 'stage-1'], plugins: ['transform-decorators-legacy', 'transform-object-assign', 'array-includes'], }, }, { test: /\.scss$/, loaders: ['style-loader', 'css-loader', 'sass-loader'] } ] } }; 

WHERE WE LOAD HMR:

  console.log('****************************** RUNNING IN DEV MODE ******************************'); var webpack = require('webpack'); var webpackConfig = require('./webpack.config.dev'); var compiler = webpack(webpackConfig); console.log('Looking for the HMR here: ' + webpackConfig.output.publicPath); app.use(require('webpack-dev-middleware')(compiler, { noInfo: true, publicPath: webpackConfig.output.publicPath })); app.use(require('webpack-hot-middleware')(compiler)); 

Now, here is the weird part. Babel / Webpack will compile everything in order, in production mode, without a hot reboot. The application works fine when we set Node ENV to "PRODUCTS" - no errors in the synthesis.

In addition, the application works in dev mode (with a hot restart) just fine, using the previous stack, which includes the following NPM versions:

 "react": "^0.14.8", "react-dom": "^0.14.3", "react-transform-catch-errors": "^1.0.0", "react-transform-hmr": "^1.0.0", "webpack": "^1.13.1", "webpack-dev-middleware": "^1.2.0", "webpack-hot-middleware": "^2.0.0" "babel": "^6.5.2", "babel-cli": "^6.10.1", "babel-core": "^6.10.4", "babel-loader": "^6.2.4", "babel-plugin-transform-es2015-modules-commonjs": "^6.0.2", "babel-plugin-transform-react-constant-elements": "^6.0.2", "babel-preset-es2015": "^6.0.8", "babel-preset-react": "^6.0.2", 

UPDATE 5/16/17:

We highlighted the migration problem from React / React DOM 0.14.8 to v15.0.0 . Doing this immediately causes our error - but only in HMR / Dev mode.

Production assembly, without HMR, compiles just fine; referring to the mini files that Webpack produces through this configuration allows the function to work 100% normally.

accurate build works 100% in React / DOM 0.14.8 , in Dev mode, with HMR. Upgrading ONLY Webpack / HMR / webpack-hot-middleware to the latest versions DOES NOT cause an error.

I spent some time searching in the debug panel and found the following:

This is a worthy look at the real event object created initially by React. In this case, "topClick", which is not associated with the handlers that we created. I can literally run this and error by clicking anywhere on the page.

This is the line where the error occurs. It comes from the reaction-dom / lib / SyntheticUIEvent.js - and it seems that it failed to initialize the .call method in the SyntheticEvent class ...

It is also worth noting that the console also launches the following error on every reboot , firstly.

 GET http://localhost:3333/[object%20Object]?url=function%20SyntheticEvent(dispa…d%20%3D%20emptyFunction.thatReturnsFalse%3B%0A%20%20return%20this%3B%0A%7D 404 (Not Found) (anonymous) @ jspdf.debug.js:17350 l @ jspdf.min.js:284 u @ jspdf.min.js:284 XHR @ jspdf.debug.js:17334 Proxy @ jspdf.debug.js:16928 (anonymous) @ SyntheticEvent.js:188 (anonymous) @ SyntheticEvent.js:268 (anonymous) @ background.js:805 __webpack_require__ @ background.js:658 fn @ background.js:86 (anonymous) @ SyntheticCompositionEvent.js:13 (anonymous) @ background.js:2110 __webpack_require__ @ background.js:658 fn @ background.js:86 (anonymous) @ BeforeInputEventPlugin.js:16 (anonymous) @ background.js:1767 __webpack_require__ @ background.js:658 fn @ background.js:86 (anonymous) @ ReactDefaultInjection.js:14 (anonymous) @ background.js:1963 __webpack_require__ @ background.js:658 fn @ background.js:86 (anonymous) @ ReactDOM.js:16 (anonymous) @ ReactDOM.js:111 (anonymous) @ background.js:1844 __webpack_require__ @ background.js:658 fn @ background.js:86 (anonymous) @ index.js:3 (anonymous) @ background.js:812 __webpack_require__ @ background.js:658 fn @ background.js:86 (anonymous) @ background.js:9 (anonymous) @ background.js:3178 __webpack_require__ @ background.js:658 fn @ background.js:86 (anonymous) @ background:2 (anonymous) @ background.js:3287 __webpack_require__ @ background.js:658 (anonymous) @ background.js:707 (anonymous) @ background.js:710 

Same error from Node console:

 GET /[object%20Object]?url=function%20SyntheticEvent(dispatchConfig%2C%20targetInst%2C%20nativeEvent%2C%20nativeEventTarget)%20%7B%0A%20%20if%20(process.env.NODE_ENV%20!%3D%3D%20%27production%27)%20%7B%0A%20%20%20%20%2F%2F%20these%20have%20a%20getter%2Fsetter%20for%20warnings%0A%20%20%20%20delete%20this.nativeEvent%3B%0A%20%20%20%20delete%20this.preventDefault%3B%0A%20%20%20%20delete%20this.stopPropagation%3B%0A%20%20%7D%0A%0A%20%20this.dispatchConfig%20%3D%20dispatchConfig%3B%0A%20%20this._targetInst%20%3D%20targetInst%3B%0A%20%20this.nativeEvent%20%3D%20nativeEvent%3B%0A%0A%20%20var%20Interface%20%3D%20this.constructor.Interface%3B%0A%20%20for%20(var%20propName%20in%20Interface)%20%7B%0A%20%20%20%20if%20(!Interface.hasOwnProperty(propName))%20%7B%0A%20%20%20%20%20%20continue%3B%0A%20%20%20%20%7D%0A%20%20%20%20if%20(process.env.NODE_ENV%20!%3D%3D%20%27production%27)%20%7B%0A%20%20%20%20%20%20delete%20this%5BpropName%5D%3B%20%2F%2F%20this%20has%20a%20getter%2Fsetter%20for%20warnings%0A%20%20%20%20%7D%0A%20%20%20%20var%20normalize%20%3D%20Interface%5BpropName%5D%3B%0A%20%20%20%20if%20(normalize)%20%7B%0A%20%20%20%20%20%20this%5BpropName%5D%20%3D%20normalize(nativeEvent)%3B%0A%20%20%20%20%7D%20else%20%7B%0A%20%20%20%20%20%20if%20(propName%20%3D%3D%3D%20%27target%27)%20%7B%0A%20%20%20%20%20%20%20%20this.target%20%3D%20nativeEventTarget%3B%0A%20%20%20%20%20%20%7D%20else%20%7B%0A%20%20%20%20%20%20%20%20this%5BpropName%5D%20%3D%20nativeEvent%5BpropName%5D%3B%0A%20%20%20%20%20%20%7D%0A%20%20%20%20%7D%0A%20%20%7D%0A%0A%20%20var%20defaultPrevented%20%3D%20nativeEvent.defaultPrevented%20!%3D%20null%20%3F%20nativeEvent.defaultPrevented%20%3A%20nativeEvent.returnValue%20%3D%3D%3D%20false%3B%0A%20%20if%20(defaultPrevented)%20%7B%0A%20%20%20%20this.isDefaultPrevented%20%3D%20emptyFunction.thatReturnsTrue%3B%0A%20%20%7D%20else%20%7B%0A%20%20%20%20this.isDefaultPrevented%20%3D%20emptyFunction.thatReturnsFalse%3B%0A%20%20%7D%0A%20%20this.isPropagationStopped%20%3D%20emptyFunction.thatReturnsFalse%3B%0A%20%20return%20this%3B%0A%7D 404 4.745 ms - 35162 

Answer 1

UPDATE 5/24/17:

Finally, we realized this problem - a classic mistake!

After our entire stack is reconfigured according to create-react-app , I migrated our previous React application to the dev server index file. Worked as expected, although without the right HTML packaging and styles, etc.

However, when I transferred the full HTML page to which the application was placed to the <div id="root> element, it again started to spit out SyntheticEvent! A lot of work and restructuring finally isolated the problem from the HTML file (which actually was actually an EJS file initially and basically contains the basic skeleton as well as SEO tracking).

Here is rub: we had an obsolete <script/> that called jsPDF v1.2.61 ( https://github.com/MrRio/jsPDF ). We no longer use this plugin , and the script seems to have snuck back into our code due to a merge conflict.

In retrospect, the code hosted in the OP refers to the jsPDF plugin, but the stack trace does not actually give any indication of where the error occurs. Since we literally did not touch the plugin from the very beginning of the application and used an alternative approach, the name did not cause any calls - given the later calls to React scripts, I just assumed that the first three or so lines the stack trace indicated by jspdf was some obscure part of the library React

IN THIS ISSUE OF TWO FIXES:

• Removing the script completely - this is what we have done since we no longer use jsPDF in our application.
• Update jsPDF - , now the plugin is in v1.3.4 . In the previous version v1.2.61 , a discontinuous conflict is generated with React v15.0.0+ library scripts. The new version DOES NOT create conflicts.

Hope this helps someone along the way!

Reference information only; The previous solution, which did not work and threw us back to the correction above:

To move our project forward, we chose an alternative stack using create-react-app and custom-react-scripts .

https://github.com/facebookincubator/create-react-app

https://github.com/kitze/custom-react-scripts

Ultimately, we (freely) follow this pattern to launch CRA Stack along with our Node / Express products at the same time: https://www.fullstackreact.com/articles/using-create-react-app-with-a-server /

In the end, this completes our task - to push a new stack to modern technology. And it's probably a little cleaner than we used to be.

However, I am still completely puzzled by the origin of the error above. I moved the material to a bunch of other test stacks and didn't seem to be able to reproduce the w / Webpack 2 and React 15+ problem - and there is nothing fundamentally different in the way I configure them from our original stack.

Whatever happens is very strange.