Convert to Babel plugin?

[bebraw]

It might be cool to write a Babel transformation to use this. After that it's simple to setup although perhaps it matches too much then. Any thoughts?

[aweary]

@bebraw interesting idea, I like it. I think the end user experience for implementation would be easier, but my question would be how you would opt in and out specific components?

It'd be potentially overwhelming to have every single shouldComponentUpdate call output to the log, unless there's a way to handle that with a babel transform?

We're always open to PR's as well if anyone want's to give this a try. If anything we could offer both options 👍

[bebraw]

@aweary First idea - agree on an annotation that's placed at the beginning of a file (lint style).

[aweary]

I think that would be an interesting API, how would we handle components that have their own shouldComponentUpdate method already defined?

[bebraw]

Two options:

• Lazy - Don't touch it if it exists + document this behavior.
• Less lazy - Patch it to include shouldComponentUpdateDev.call(this, nextProps, nextState); at the beginning of the method. To do this properly you'll need to check out the parameter names at least. This is more labor intensive and could be added in a later version.

[aweary]

I think that the lazy approach is the correct approach here. This tool can't tell you why a custom shouldComponentUpdate method might be failing, since it really just implements an equivalent of the pure render mixin / shallowCompare with logs.

So in this case we should just overwrite the shouldComponentUpdate method of any component decorated with the decided annotation at the top of the file.

I'm not familiar with writing babel plugins, so this is open to anyone to give a shot. Otherwise I'll get to it eventually :)