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

Position JSX whitespace ({" "}) at the end of lines #1964

Merged
merged 2 commits into from
Jun 5, 2017

Conversation

karl
Copy link
Collaborator

@karl karl commented Jun 4, 2017

Currently we place JSX whitespace ({" "}) at the beginning of lines, this PR is an exploration of placing JSX whitespace at the end of lines instead.

It was inspired by @SimenB's comment in #1831 (comment).

It works nicely, although with one drawback that it is now possible for a line ending with {" "} to be longer than the max line length.

I'd be interested in people's opinions on this. If people prefer this way of outputting whitespace I'm happy to have it merged and reviewed.

Currently we place JSX whitespace at the beginning of lines.
@vjeux
Copy link
Contributor

vjeux commented Jun 4, 2017

This looks better than what we had before to me based on the examples.

it is now possible for a line ending with {" "} to be longer than the max line length.

I wouldn't worry too much about it, prettier occasionally goes beyond 80 columns as well for other constructs.

@rattrayalex, would you mind reviewing this?

@SimenB
Copy link
Contributor

SimenB commented Jun 5, 2017

This looks better than what we had before to me based on the examples.

+1. It also better matches the mental model I have about the spaces - "I want a space after this element/string".

</span>
);

before_break2 = (
<span>
<span
barbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbarbar
/>
{" "}foo
/>{" "}
Copy link
Contributor

Choose a reason for hiding this comment

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

before_break{1,2} can go either way for me (I do prefer this new version, though), but after_breaklooks way better, and I also think regression_not_transformed_2 is more readable. So I'm really digging this change! 😁

@karl
Copy link
Collaborator Author

karl commented Jun 5, 2017

Having slept on it I'm also very positive about this change. It makes me think that having the {" "} elements at the beginning of lines is giving them much more importance than they need.

@karl
Copy link
Collaborator Author

karl commented Jun 5, 2017

Thanks for the inspiration to tackle this @SimenB!

@rattrayalex
Copy link
Collaborator

rattrayalex commented Jun 5, 2017

I'm definitely 👍 to the change itself – haven't looked at the code yet. Thanks for putting together @karl / @SimenB !

Copy link
Collaborator

@rattrayalex rattrayalex left a comment

Choose a reason for hiding this comment

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

One possible "cross-parser" concern, otherwise LGTM!

src/printer.js Outdated
const followedByJSXWhitespace =
next &&
next.type === "JSXExpressionContainer" &&
next.expression.type === "Literal" &&
Copy link
Collaborator

Choose a reason for hiding this comment

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

might need to also support StringLiteral? I'm not up on the latest of the prettier codebase. Glancing up a line it looks like isLiteral(next.expression) might be what you want

Copy link
Contributor

Choose a reason for hiding this comment

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

Yup, isLiteral is the right way to go now.

// NOTE: Currently this only detects elements that are already
// multiline before formatting!
multilineChildren.push(concat([hardline, rawJsxWhitespace, hardline]));
multilineChildren.push(rawJsxWhitespace);
Copy link
Collaborator

Choose a reason for hiding this comment

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

ahh, so much simpler!

@vjeux
Copy link
Contributor

vjeux commented Jun 5, 2017

I'll merge this once you fix the small isLiteral issue. This is going to be glorious :)

@karl
Copy link
Collaborator Author

karl commented Jun 5, 2017

@vjeux I've made the isLiteral change, all good to go!

I'm happy to merge it myself (once the tests pass), if that works for you.

@vjeux
Copy link
Contributor

vjeux commented Jun 5, 2017

Do it!

@karl
Copy link
Collaborator Author

karl commented Jun 5, 2017

@vjeux Any preference on squash, rebase, or normal merge?

@vjeux
Copy link
Contributor

vjeux commented Jun 5, 2017

Squash & Merge please

@karl karl merged commit 73432c2 into prettier:master Jun 5, 2017
@karl karl deleted the jsx-alternate-whitespace-positioning branch June 5, 2017 20:53
@karl
Copy link
Collaborator Author

karl commented Jun 5, 2017

👍🏻

vjeux added a commit that referenced this pull request Jun 7, 2017
* Fix support for node 4 (#1988)
* Fix website on iOS Safari (#1970)

Formatting change:
* Position JSX whitespace (`{" "}`) at the end of lines (#1964)

Lots of small fixes, mainly for TypeScript.
@kentor
Copy link

kentor commented Oct 19, 2017

Why not in their own line? This is weird

-            <span className={cx('g-icon', opened ? 'check' : 'unchecked')} />
-            {' '}
+            <span
+              className={cx('g-icon', opened ? 'check' : 'unchecked')}
+            />{' '}

@karl
Copy link
Collaborator Author

karl commented Oct 19, 2017

I believe at one point {“ ”} used to always be put on its own line (there is mention of that here #1582). Having it attached to the end of a line improved the formatting of JSX containing text.

We could revisit this if we had a comprehensive proposal for new behaviour.

@lock lock bot added the locked-due-to-inactivity Please open a new issue and fill out the template instead of commenting. label Jan 19, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jan 19, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked-due-to-inactivity Please open a new issue and fill out the template instead of commenting.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants