-
-
Notifications
You must be signed in to change notification settings - Fork 225
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
Minify some Logical Expression patterns #227
Conversation
This looks awesome @boopathi |
@@ -124,6 +124,54 @@ module.exports = ({ types: t }) => { | |||
], | |||
}, | |||
|
|||
LogicalExpression(path) { | |||
const left = path.get("left"); |
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.
nit: declarations can be moved closer to usage.
}; | ||
const FALSY = (input) => { | ||
// NaN and undefined are falsy | ||
if (input.isIdentifier()) { |
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.
Is this needed because the .isPure()
method doesn't work for NaN
and undefined
yet, since !undefined
and !NaN
are true
? Are there any other such special instances?
if (result.match) { | ||
// here we are sure that left.evaluate is always confident becuase | ||
// it satisfied one of TRUTHY/FALSY paths | ||
path.replaceWith(result.value(t.valueToNode(left.evaluate().value), right.node)); |
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.
Would it be worth caching/re-using the result of left.evaluate()
? I don't know how expensive these evaluations generally are.
@@ -124,6 +124,54 @@ module.exports = ({ types: t }) => { | |||
], | |||
}, | |||
|
|||
LogicalExpression(path) { |
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 feels these simplifications should be done in a post-order traversal (i.e. on exit
) -- does this resolve properly for nested conditions?
e.g. (3 || foo()) || bar()
should simplify to just 3
.
expect(transform(sources[i])).toBe(sources[i]); | ||
} | ||
}); | ||
|
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.
test cases for nested logical expressions?
ac0c38c
to
4b1c29d
Compare
No description provided.