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
Optimize class properties output #6656
Conversation
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/7606/ |
Using the defineProperty helper looks good, but I don't really like the nested defineProperty calls. _defineProperty(_defineProperty(this, "foo", 1), "bar", 2); _defineProperty(this, "foo", 1);
_defineProperty(this, "bar", 2); The second is objectively longer after minification (4 bytes), but I think it is much easier to read. |
That is a valid concern, was thinking about it too, but ain't sure if we should optimize compiled output for readability. I've implemented this defineProperty calls folding as little experiment, because I've noticed it's easier for a minifier (at least UglifyJS) to detect single call's result as unused. Assignments to objects (static properties in this case) and calling functions (defineProperty here) with that object effectively prevent dead code elimination of the class in most cases - that's also probably true when considering imperfect algorithm for dead code elimination, but we could do a little bit to help it here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for delay in review, 👍.
FWIW, I don't have a terribly strong opinion re: folding vs readability, but I tend to favor not optimizing for readability.
4315637
to
c2587aa
Compare
This undoes the property call folding from babel#6656. It complicates the private property transforms, since they boil down to `map.set(this, vlaue)` and we definitely don't want the next call define a property on the map. /cc @Andarist
Similar to change in #6652 . Additionally I switch to using
defineProperty
helper instead of using bareObject.defineProperty
call - which should have benefit of not having to hit slowObject.defineProperty
path in most cases.