
Debug React Component Performance with ES7 Annotations - skurfuerst
https://www.neos.io/blog/react-snippets-debug-component-performance-with-es7-annotations.html
======
taion
This code appears to be using the legacy Babel decorators transform in order
to use so-called "annotations".

This is a really bad idea. There is no decorator transform that matches the
current draft specification. There's only the legacy transform that matches an
old, outdated version of the decorator spec.

In general it's not a good idea to do this sort of thing – you're pretending
to use an ES7 feature, but actually you're not. You're using what's
effectively a bespoke version of the language with no necessary resemblance to
what's going to become the spec.

~~~
skurfuerst
Hey,

You're absolutely right; I maybe would not use this part for production.
However, create-react-app also implements these decorators; and they are a
quite elegant way of annotating methods or classes.

All the best, Sebastian

~~~
acemarke
Erm... no, it doesn't. Straight from the readme:

> Many popular libraries use decorators in their documentation. Create React
> App doesn’t support decorator syntax at the moment because:
    
    
      > It is an experimental proposal and is subject to change.
    
      > The current specification version is not officially supported by Babel.
    
      > If the specification changes, we won’t be able to write a codemod because we don’t use them internally at Facebook.
    

CRA _does_ support the not-yet-final object spread syntax, which is currently
Stage 3, and the class properties syntax, which is Stage 2. However, both of
those are pretty straightforward syntax sugar for existing capabilities, and
the React team has promised to provide codemods if they ever do happen to be
changed or canceled.

That said, the perf checking does look useful. I'll add this tool to my list
of React/Redux-related devtools, at [https://github.com/markerikson/redux-
ecosystem-links/blob/ma...](https://github.com/markerikson/redux-ecosystem-
links/blob/master/devtools.md) .

~~~
skurfuerst
Hey,

Thanks, you are right!

Do you have a good suggestion on a syntax how people could use the "debugger"
in a nice way? I kinda dislike first creating a component and then wrapping it
completely afterwards, although that of course would work.

All the best, Sebastian

~~~
jkrems
You could just imperatively instrument the component, e.g.:

    
    
        class MyComponent extends React.Component { /* ... */ }
        debugReasonForRendering(MyComponent);
    

Where `debugReasonForRendering` patches `arguments[0].prototype.
shouldComponentUpdate`.

~~~
adriancooney
Since this is entirely for debugging purposes, I feel like the decorator is
perfectly fine until the standard is complete. It's unobtrusive (i.e. no
refactoring needed) and easy to remember. Maybe a warning inside the decorator
is `process.env.NODE_ENV === "production"` warning would be nice.

