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

[Feature request] Improved suggestion for invalid element type #9231

Closed
nycdotnet opened this issue Mar 21, 2017 · 4 comments
Closed

[Feature request] Improved suggestion for invalid element type #9231

nycdotnet opened this issue Mar 21, 2017 · 4 comments

Comments

@nycdotnet
Copy link

This is a feature request.

Current behavior:
If ReactDOM.render() is called using a component name that is declared later in the same file, the resulting error suggests that the component wasn't exported from the file it was defined in.

Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in.

Example code where the suggestion is inappropriate:

var mountNode = document.getElementById("mountNode");
ReactDOM.render(<HelloMessage name="Jane" />, mountNode);

// oops!!!
class HelloMessage extends React.Component {
  render() {
    return <div>Hello {this.props.name}</div>;
  }
}

What is the expected behavior?
The suggestion does not help in this instance. It would be helpful if the error message also suggested that ReactDOM.render() may have been called too early. For example:

Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you tried to render the component before it was declared in the current file.

I am an experienced ES6+ developer, but new to React. I just finished the tic-tac-toe tutorial and was attempting to apply what I had learned to one of my web sites when I made the above mistake. Since this mistake is plausible to be made by someone just getting started (especially if they are taking the tutorial code as their starting point, and are new to ES6+), it would be useful to suggest the alternate possible fix. It might help other beginners out there.

If this is OK, I'll send a PR ASAP. Thank you for your consideration.

This is on the latest version of React and should affect all environments. Thank you.

@aweary
Copy link
Contributor

aweary commented Mar 21, 2017

Thanks for the issue @nycdotnet! Welcome to the React community ⚛️ That's definitely one scenario where the warning may not be as helpful. But since there's usually only a single ReactDOM.render call in an application and it's essentially a community standard to call ReactDOM.render at the bottom of your entry file, I think that >99% of the time the current warning will suffice.

If we can verify that more new users experience this specific issue than we can definitely consider it, but as it stands I think this is an edge case that might distract from the most common case and confuse some new React developers.

Maybe ReactDOM.render should fail fast if the element's type is undefined? The current warning is a little confusing for this case since the top-level component is usually in the same file as the ReactDOM.render call. If we validate early we can throw a more descriptive error message specifically addressing this issue. @gaearon what do you think?

@nycdotnet
Copy link
Author

Thanks for considering this.

@gaearon
Copy link
Collaborator

gaearon commented Oct 4, 2017

Seems like we haven't seen much confusion in this area so it's probably not worth spending extra doc or warning space on this (and thus confusing people who don't have this problem but have more common ones).

@gaearon gaearon closed this as completed Oct 4, 2017
@nycdotnet
Copy link
Author

Thank you for the consideration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants