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

Fix yield block placement #563

Merged
merged 2 commits into from
May 4, 2017
Merged

Fix yield block placement #563

merged 2 commits into from
May 4, 2017

Conversation

Rich-Harris
Copy link
Member

Fixes #561

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.
@codecov-io
Copy link

codecov-io commented May 4, 2017

Codecov Report

Merging #563 into master will increase coverage by <.01%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #563      +/-   ##
==========================================
+ Coverage   87.78%   87.79%   +<.01%     
==========================================
  Files          95       95              
  Lines        2866     2867       +1     
==========================================
+ Hits         2516     2517       +1     
  Misses        350      350
Impacted Files Coverage Δ
src/generators/dom/visitors/YieldTag.js 100% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3a7f7e2...dd2e5e8. Read the comment docs.

const parentNode = state.parentNode || block.target;

( state.parentNode ? block.builders.create : block.builders.mount ).addLine(
`if ( ${block.component}._yield ) ${block.component}._yield.mount( ${parentNode}, null );`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for switching this (and the destroy block below) to a regular if from a short circuited &&? Just a style thing? It seems we're relying on short circuiting in generated code for conciseness elsewhere.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No particular reason, just saw it and thought there's no reason it shouldn't be an if — the intent is clearer, and it minifies the same way. I reckon we should generally prefer if to && for statements (as opposed to expressions). Don't feel all that strongly though

@Rich-Harris Rich-Harris merged commit 90d2e7f into master May 4, 2017
@Rich-Harris Rich-Harris deleted the gh-561 branch May 4, 2017 17:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants