React-redux-starter-kit: Q. Automatically finding errors that generate React `Warning: React.createElement: type should not be null, undefined, boolean, or number. It should be a string (for DOM elements) or a ReactClass (for composite components).`

[JMacLulich]

Hi Guys,

I'm really enjoying using the this starter kit as it has saved me a lot of time.

However, is it just me or is anyone else running into a large number of these types of errors:

warning.js:44Warning: React.createElement: type should not be null, undefined, boolean, or number. It should be a string (for DOM elements) or a ReactClass (for composite components).warning @ warning.js:44createElement @ ReactElementValidator.js:221renderError @ main.js:64render @ main.js:70(anonymous function) @ main.js:79__webpack_require__ @ bootstrap 84723e2…:585fn @ bootstrap 84723e2…:109(anonymous function) @ app.84723e2….js:6__webpack_require__ @ bootstrap 84723e2…:585webpackJsonpCallback @ bootstrap 84723e2…:21(anonymous function) @ app.84723e2….js:1
invariant.js:38Uncaught Invariant Violation: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object.

It's literally costing me hours trying to track down where exactly I'm not exporting a function/object or some other error.

The error for all intents is basically _useless_.

I have no idea where in the code base it's complaining about, or what its complaining about.

This is basically, "there is an error somewhere in your code, I'm not going to give you any idea where it is."

I'm sure I'm missing something, is there an option or some kind of processor I can enable that can tell me these things in advance? or in the browser? because it's very very painful process to try and find these by trial and error.

Kind regards, Jason.

[kolpav]

I think you have wrong import somewhere most likely something like

import { Counter } from 'components/counter'

when it should be

import Counter from 'components/counter'

Meaning you are trying to import something with default export like it is named export. Or it could be something else

[JMacLulich]

Thanks @kolpav

Yes, its things like this or, maybe something like:

export class Counter extends React.component {
  render() {
    return null;
  }
}

export default Counter

where the problem is that you forgot to capitalise the c in Component.

This is something you can stare at for literally minutes scratching your head because you missed a uppercase C and nothing in the error says: error on line 9, missing class component. I'd even settle for not identifying the problem with the class name and just say tried to instantiate the class Counter and failed.

There are also other errors like this that compile silently and fail with the same error:

export const RESET_ERROR_MESSAGE = `error\${message}`

this generates the same Warning: React.createElement: type s... error.

Again, totally unhelpful, sure that's incorrect JS, but I didn't know that as someone attempting to learn ES6.

Kind regards, Jason.

[JMacLulich]

Another thing is that if there is an error because of PropTypes not being satisfied the component fails to instantiate.

Why are _all_ errors being treated as the same error?

Is this something to do with hot reloading? If I were to compile this normally without hot loading would I get an error saying that PropTypes was not being satisfied rather than Warning: React.createElement: type s...?

[eduards]

Agree. Hopefully, this will be fixed soon. This decreases the productivity enormously as there is no indicator where an error is (Syntax error? Missing state variable? Wrong import? etc...)

[davezuko]

This is something that would have to be fixed on the webpack or babel level, since they are responsible for building the dependency tree and importing all of the modules. If somebody knows of a plugin or configuration option to switch on, I'd love to do so, but I really don't think there is much we can do.

We do have ESLint, but there's a limit to how much we can control. If you do want to get rid of these errors entirely, I recommend trying out something like TypeScript, since what you're referring to are fairly common troubles for JS devs, and not exactly something specific to this project.

[eduards]

Even with TypeScript or other static type checkers, the problem remains that we do not have any indicator for runtime errors. E.g. just adding console.log(library.undefinedProp.value); somewhere in your code results in the pretty non-saying error

warning.js:44Warning: React.createElement: type should not be null, undefined, boolean, or number. It should be a string (for DOM elements) or a ReactClass (for composite components).

Uncaught Invariant Violation: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object.

instead of something like Uncaught ReferenceError: undefinedProp is not defined

[davezuko]

Ok, I think I see the problem, that the issue totally unrelated to React but is still causing those render errors. @JMacLulich 's idea sounds correct that it could be related to the HMR setup. I'll dig into this ASAPly.

[JMacLulich]

Thanks @eduards and @davezuko I'm pretty sure its got something to do with HMR.

Because once you're past errors in loading the first page of your app and can start clicking on links (route transitions) to take you to components with errors you start getting the more familiar React errors I'm used to -- like failed props and other things.

If I then modify the page and hot reload the changes I get the generic React.createElement: type should not be null error.

I have to return to a different route (that loads) then go back to the route that was causing the issue to get the proper Rect error to present.

[davezuko]

Maybe this will light a fire under me to try to get the new react hot loader setup working finally.

[davezuko]

It definitely is the current hot reload setup, since if you disable it the errors display correctly. Working on this now.

[davezuko]

WIP branch for RHL 3 here: https://github.com/davezuko/react-redux-starter-kit/tree/feature/react-hot-loader-v3. It doesn't play well with react-router and async routes, it seems, so right now it isn't actually doing anything different than what exists now, _but_ the annoying React issue is fixed... so it may be worth checking out.

[jnarowski]

+1 for this fix.

It's cost me a lot of time today to have this unhelpful error message. Can we disable HMR and get our normal errors back?

[davezuko]

@jnarowski until I get that branch merged you can just uncomment https://github.com/davezuko/react-redux-starter-kit/blob/master/src/main.js#L59-L74. This is very much in limbo right now, unfortunately.

[jnarowski]

Thanks.

I guess I don't quite get it. I gutted all the HMR and hot reloading stuff and still got the invariant message for a simple intentional syntax error after doing a full reload. Does this have to do with React?

I did get it working with the react-hot-loader branch (3.0.0-alpha.8), and the error was properly displayed in my console (woop), but then when I did a full page reload the correct error was gone and replaced by the pesky Invariant error.

[davezuko]

I'm still troubleshooting it myself, honestly, so not entirely sure. The whole hot reloading ecosystem seems to be up in the air right now, at least from my point of view, as we've now gone from react-hot-loader -> react-transform-hmr -> back to react-hot-loader, and there's so much going on in the build system that it's a bit difficult to wade through.

[jnarowski]

Ok, I'll let you know what I find also. If it helps, it seems to only be happening to class based components. functional components raise errors properly.