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

Replace invariant with inline throw error for production build? #2736

Closed
syranide opened this issue Dec 18, 2014 · 2 comments
Closed

Replace invariant with inline throw error for production build? #2736

syranide opened this issue Dec 18, 2014 · 2 comments

Comments

@syranide
Copy link
Contributor

Error: Minified exception occurred; use the non-minified dev environment for the full error
message and additional helpful warnings. in /build.js on line (of invariant implementation)

Perhaps there are larger issues preventing this, but considering production errors encountered by a user rarely has access to stack traces, so you only get the single top-level error location... if an error is thrown by React today that's all you know, an error was thrown.

It would be nice if invariant(...) was replaced with if (...) throw new Error(...) instead. I could then report vaguely meaningful error locations which could at least hint at what the error is, React would also avoid the invariant invocation overhead then.

cc @zpao @sebmarkbage @spicyj

@gaearon
Copy link
Collaborator

gaearon commented Dec 18, 2014

See also #2686

@sebmarkbage
Copy link
Collaborator

I think something like #2686 is a better solution. E.g. surfacing an error code or something in production. Maybe a hash of the original message.

The reason I don't think invariant(...) matters is that these checks often end up in common validation helpers. This is particularly common for warnings but also for invariants. We shouldn't have to take the levels of the stack trace into account when structuring our internal code. So even if we moved it one level, the next level will still be problematic.

Besides, you can catch complete stack traces in production in most browsers. That should be part of your error message / logging solution. That will give you much better error messages anyway since you can track the source in your own code easier.

*) We have experimented with converting invariant(...) to if (...) throw using a transpiler. That has shown to be a performance boost. We can also safely strip the error message for production builds. Especially in non-JIT environments and since a lot of our code currently deopts. That's unrelated to the problem of stack traces though.

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

No branches or pull requests

3 participants