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

Best practice for a meaningful componentStack in production? #12757

Closed
morloy opened this issue May 7, 2018 · 4 comments
Closed

Best practice for a meaningful componentStack in production? #12757

morloy opened this issue May 7, 2018 · 4 comments

Comments

@morloy
Copy link

morloy commented May 7, 2018

Using Sentry for bug reporting in our production build we often encounter a componentStack like:

    in b
    in li
    in ul
    in v
    in div
    in div
    in i
    in div
    in Unknown
    in t…

Of course, this doesn’t help to locate the problem at all. So I’m wondering, what’s the best practice to get usable information from ErrorBoundaries and the componentStack.
The following options seem to be available:

  • Set mangle: false in uglify (increases bundle size, but works)
  • Set displayName manually for all components (usually not feasible)
  • Use a babel plugin (somehow misses the majority of components for me)
  • Write a tool, that resolves the names using sourcemaps

I’m curious to hear, what most people are using. For me, only the first option works well, but it doesn’t feel like a very elegant solution.

@morloy morloy changed the title Best practice for a meaningful componentStack in production Best practice for a meaningful componentStack in production? May 7, 2018
@gaearon
Copy link
Collaborator

gaearon commented May 7, 2018

mangle: false sounds like enabling a really bad user experience. I strongly recommend against doing it.

Even a Babel plugin that automatically adds displayName would be much better than just disabling mangling. If it didn't work for me, I would look at its tests, and see how the code it's expecting is different from my code. And maybe even send a fix.

At FB we currently include filenames in displayName but it's only because we (inefficiently) currently have module names as strings in production. When we fix this, we'll probably change them to IDs, and then write some tool that matches IDs back to readable names.

@gaearon gaearon closed this as completed May 7, 2018
@morloy
Copy link
Author

morloy commented May 7, 2018

Cool, thanks for your feedback @gaearon!
Can you elaborate on why not mangling results in a really bad user experience? Intuitively, it should only affect the bundle size. But with added compression on top, the effect should be rather small.

@gaearon
Copy link
Collaborator

gaearon commented May 7, 2018

I guess it depends on how good the compression ends up being in your case. Have you measured the difference? In my experience mangling still ends up being significant.

Moreover, compression only helps with network. It doesn’t affect the parsing time.

@morloy
Copy link
Author

morloy commented May 7, 2018

I haven‘t measured the size, but I think it went up from 600 to 700kb, which I guess is all right for any non-FB scale app.
Sounds good to keep parsing time in mind, as well. Right now, meaningful bug reports are more critical than fast page loads. But for the future switching to a babel plugin sounds like a good solution, unless sourcemaps will be supported by the component stack.

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

2 participants