-
-
Save yjbanov/04436939b02f1f190504 to your computer and use it in GitHub Desktop.
// frameworks such as Flutter and UIX encourage users to express their | |
// UI using tree-like syntaxes. | |
// unfortunately dartfmt will format this code: | |
main() { | |
var componentTree = new MyButton( | |
title: 'Save', | |
onClick: () { | |
doSomthing(); | |
}, | |
icon: new Image( | |
src: '/images/save.png', | |
width: 10 | |
) | |
); | |
} | |
// to this: | |
main() { | |
var componentTree = new MyButton(title: 'Save', onClick: () { | |
doSomthing(); | |
}, icon: new Image(src: '/images/save.png', width: 10)); | |
} | |
// what if Dart allowed trailing commas in function/method/constructor calls and | |
// dartfmt treated them as a signal that the closing paren must go on the next line? | |
main() { | |
var componentTree = new MyButton( | |
title: 'Save', | |
onClick: () { | |
doSomthing(); | |
}, | |
icon: new Image( | |
src: '/images/save.png', | |
width: 10, // <-- trailing comma | |
), // <-- trailing comma | |
); | |
} | |
// problem solved? |
@Hixie, that's true, however, how would the formatter choose between putting a newline and not putting one after the opening paren? I'm proposing a simple syntactic rule:
Is there a trailing command in the function call/constructor call/annotation/list literal/map literal?
Yes: put newline after the opening paren and before the closing paren
No: no newlines (or whatever it does today)
@munificent: oh yeah, I forgot to mention annotations. Today we have:
@Component(
selector: 'my-component',
host: const {
'(keypress)': 'handleKeyPress()',
'tabindex': '0',
}, // awesome
directives: const [
NgIf,
NgFor,
], // awesome!!!
styleUrls: const ['some.css']) // :(
While with this proposal we could have:
@Component(
selector: 'my-component',
host: const {
'(keypress)': 'handleKeyPress()',
'tabindex': '0',
}, // awesome
directives: const [
NgIf,
NgFor,
], // awesome!!!
styleUrls: const ['some.css'],
) // woohoo!!!
It would just do whatever the author did. If the author includes a newline, include a newline and match it before the closing punctuation, otherwise, try to fit it on one line and break if necessary (and if there's a good breaking point -- but after an open punctuation is not a good breaking point).
(I understand that what I'm proposing is incompatible with dartfmt's current goals. I think dartfmt's goals should change.)
The formatter should just never have assymetric whitespace around punctuation pairs. If there's a newline after the (, it should put a newline before the ), and so on. The alternative is much uglier in general, not just around this kind of tree structure.