Improve formatting of TS casts with generics and unions#4219
Improve formatting of TS casts with generics and unions#4219suchipi merged 6 commits intoprettier:masterfrom
Conversation
| never | ||
| >>( | ||
| someExistingConfigMap.mergeDeep(fallbackOptions) | ||
| ); |
There was a problem hiding this comment.
What do you think about this formatting instead?
const stillTooLong = <
Immutable.Map<
string,
boolean,
number,
object,
null,
undefined,
any,
void,
never
>
>(
someExistingConfigMap.mergeDeep(fallbackOptions)
);There was a problem hiding this comment.
That looks better to me. It was a little more complicated to get working but I think I managed to do it.
j-f1
left a comment
There was a problem hiding this comment.
LGTM, but I’d like to get some 👀 from other maintainers.
| | never | ||
| >( | ||
| (<any>permissions)[receiverType] | ||
| ); |
There was a problem hiding this comment.
This looks like it would be better not to break here after the cast. Have you tried splitting this in 2 groups?
There was a problem hiding this comment.
I'm not against the suggestion that it might be better not to break in this case but I'm not sure how to implement it.
The point of the PR is essentially to make the first choice for breaking lines with casts be between the cast and the expression being cast. The hope being better output in cases where both the cast and the expression then both fit on their own lines without further breaking like in:
const breakAfterCast = <PermissionsChecker<any> | undefined>(
(<any>permissions)[receiverType]
);The problem in the case you're talking about is that even after breaking the cast and the expression onto their own lines, the cast still doesn't fit onto a single line and has to break more.
So what I can't figure out is a way to tell it "try to break on the outer group first, but if that doesn't make the subgroups fit onto their own line then undo the outer break and just break the subgroups."
Any thoughts?
|
@duailibe Figured out a way to have it work the way you suggested by using conditionalGroups. |
|
@kpdonn Thank you for this! The output looks way better. In general, I'd still like to see prettier be more willing to break an assignment after the In the meantime, thanks again! |
| typeAnnotationGroup, | ||
| ">", | ||
| ifBreak("("), | ||
| indent(concat([softline, path.call(print, "expression")])), |
There was a problem hiding this comment.
I think you could just wrap this in a group. The thing here is, when the typeAnnotationGroup breaks, it will also break the parent group, which will then make the behavior you are seeing.
But if you wrap this part here in a group, the fact that the parent is "broken" won't affect a child. It will try to print in a single line before breaking.
I'll try my suggestion in a bit and report back :-)
|
This have been recently talked in the Twitterverse :) What's the latest..? |
By adding a soft break between the cast and the expression. Also includes wrapping parentheses for clarity as suggested in prettier#4171. Avoids changing behavior at all though if casting an array or object literal because those already have good behavior where the array or object literal breaks before the cast does so including them would just result in a pointless extra layer of parentheses that would add no clarity.
Specifically it will break after the cast if that makes the cast itself fit on a single line. If the cast itself won't fit on a single line then the expression being cast will be placed directly after the `>` at the end of the cast.
c5741fd to
cbd1229
Compare
|
Rebased on master; I'll merge this once CI finishes. Thank you for the fix @kpdonn! |
|
Failure is unrelated |
fixes #4171
fixes #4168
Implemented by adding a soft break between the cast and the expression. Also includes wrapping parentheses for clarity as suggested in #4171.
Avoids changing behavior at all though if casting an array or object literal because those already have good behavior where the array or object literal breaks before the cast does so including them would just result in a pointless extra layer of parentheses that would add no clarity because the
{ }or[ ]wrapping the literal serves same purpose as the parentheses would.