-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
Refactor inheritance in babel-plugin-transform-classes #7444
Refactor inheritance in babel-plugin-transform-classes #7444
Conversation
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/7312/ |
Im wondering if we could just iterate through given class to collect "meta" object describing the class, smth like:
(not that i havent analyzed the source to see what properties we would have to gather). And use that collected meta (mostly consisted of PathNodes) to construct conditionally (based on the meta & loose) the final es5 class. Would that make sense to you? Would it make it more readable in your eyes? I kinda feel that having a class here (in its current form at least) is kinda clunky and the same output could be achieved by "just functions". |
I agree with that. Looking at the code and your change it feels like we have removed the inheritance in favor of conditions, which is probably inevitable but would be clearer with just functions. |
Yep, I'm planning to move this to functions 👍. |
My battery is running low, so I'll just commit some wip stuff. I've moved class to a function with a simple object as a state. I also found pretty flexible to update the state with a function |
420cd6d
to
31b494d
Compare
I think this is ready to review. Some things got simplified throughout the process, but not much. I recommend reviewing with |
a58c017
to
cfcff06
Compare
FYI, just rebased to master |
Thanks, I'll review your work shortly. |
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.
LGTM, we can always work on it more later if anyone would be interested in doing so
*/ | ||
|
||
constructorMeMaybe() { | ||
function createConstructor() { |
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.
nitpick - from what I observed maybe*
is a convention used in babel's codebase to indicate that a function attempts to do something, but may bail out - imho it might be good to preserve it here as this function won't always "create constructor" 😉
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.
Renamed it to maybeCreateConstructor
. See last 2 commits.
Thanks for your contribution! |
@@ -0,0 +1,718 @@ | |||
// @flow |
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.
It looks like this file was given Flow annotations, but fails a few checks. Would someone be up for taking a look? Looks like just a couple failures.
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.
Oh, sorry about that! I wasn't sure how to type it in a usable way (without blindly patching) 😬
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.
No problem. I'd say we should just remove the @flow
annotation if it isn't actually intended to typecheck them. The flow type definitions are still useful for documentation, so those are fine though.
* master: (140 commits) Update to beta.42 (babel#7609) Disable flow on transformClass, fix preset-env errors (babel#7605) Logical Assignment: ensure computed key isn't recomputed (babel#7604) Remove obsolete max-len eslint rule and reformat some stuff to fit (babel#7602) Centralize Babel's own compilation config to make it easier to follow. (babel#7599) Run prettier to format all JSON. Tweak es2015-related plugin order in preset-env (babel#7586) Refactored quirky inheritance in babel-plugin-transform-classes (babel#7444) Add RegExp support to include/exclude preset-env options (babel#7242) v7.0.0-beta.42 Use strict namespace behavior for mjs files. (babel#7545) Remove outdated spec deviation note [skip ci] (babel#7571) Ensure that the backward-compat logic for plugin-utils copies over the version API properly. (babel#7580) Rename actual/expected test files to input/output (babel#7578) Use helper-module-import inside entry plugin too Use helper-module-imports instead of custom import (babel#7457) Fix "Module build failed: Error: Cannot find module '@babel/types'" (babel#7575) Wrap wrapNativeSuper helpers in redefining functions for better tree-shakeability (babel#7188) Favour extends helper over objectWithoutProperties when whole object gets copied anyway (babel#7390) Fix incorrect value of _cache in _wrapNativeSuper (babel#7570) ...
Implementing
loose
type of classes transform as a class extending from vanilla transform seems a bit indirect, cause confusion and artificial constructs like here. To simplify things I've decided to merge them into one class and expose as a function to not promote further inheritance.By the way I've added
// @flow
pragma to the files and adjusted some typings (but not all of them, I'm not sure how to type Babel so help appreciated)@Andarist let me know if that's what you were thinking about, or maybe I got it wrong.
cc @xtuc