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

Refactor inheritance in babel-plugin-transform-classes #7444

Merged
merged 11 commits into from
Mar 19, 2018

Conversation

thymikee
Copy link
Contributor

@thymikee thymikee commented Feb 27, 2018

Q                       A
Fixed Issues? Fixes #7202
Patch: Bug Fix?
Major: Breaking Change?
Minor: New Feature?
Tests Added + Pass? Yes
Documentation PR
Any Dependency Changes?
License MIT

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

@babel-bot
Copy link
Collaborator

babel-bot commented Feb 27, 2018

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/7312/

@Andarist
Copy link
Member

Im wondering if we could just iterate through given class to collect "meta" object describing the class, smth like:

{ methods, constructor, super, }

(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".

@xtuc xtuc changed the title chore(plugin-transform-classes): refactor inheritance Refactor inheritance in babel-plugin-transform-classes Feb 28, 2018
@xtuc
Copy link
Member

xtuc commented Feb 28, 2018

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.

@thymikee
Copy link
Contributor Author

Yep, I'm planning to move this to functions 👍.
Some conditions were already there, so the separation was artificial (and undone). Let's treat it as a in-progress state, I'll try to update this today.

@thymikee
Copy link
Contributor Author

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 setState() (can be refactored to other data structure, or debugged easily).
Let me know what do you think of this direction.

@thymikee thymikee force-pushed the chore/refactor-transform-class branch from 420cd6d to 31b494d Compare February 28, 2018 19:42
@thymikee
Copy link
Contributor Author

thymikee commented Mar 1, 2018

I think this is ready to review. Some things got simplified throughout the process, but not much. I recommend reviewing with ?w=1 query param :)

@thymikee thymikee force-pushed the chore/refactor-transform-class branch from a58c017 to cfcff06 Compare March 16, 2018 16:49
@thymikee
Copy link
Contributor Author

FYI, just rebased to master

@existentialism existentialism added the PR: Internal 🏠 A type of pull request used for our changelog categories label Mar 16, 2018
@xtuc
Copy link
Member

xtuc commented Mar 17, 2018

Thanks, I'll review your work shortly.

Copy link
Member

@Andarist Andarist left a 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() {
Copy link
Member

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" 😉

Copy link
Contributor Author

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.

@Andarist Andarist merged commit e2c5f25 into babel:master Mar 19, 2018
@thymikee thymikee deleted the chore/refactor-transform-class branch March 19, 2018 15:38
@thymikee
Copy link
Contributor Author

Thanks @Andarist & @xtuc! :)

@xtuc
Copy link
Member

xtuc commented Mar 19, 2018

Thanks for your contribution!

@@ -0,0 +1,718 @@
// @flow
Copy link
Member

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.

Copy link
Contributor Author

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) 😬

Copy link
Member

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.

mAAdhaTTah added a commit to valtech-nyc/babel that referenced this pull request Mar 21, 2018
* 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)
  ...
@lock lock bot added the outdated A closed issue/PR that is archived due to age. Recommended to make a new issue label Oct 5, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
outdated A closed issue/PR that is archived due to age. Recommended to make a new issue PR: Internal 🏠 A type of pull request used for our changelog categories
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Refactor transform-classes
6 participants