trailing commas for tree-like code in Dart

tree_code_fmt.dart

// 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?

Actually, if you use the latest dartfmt, it produces:

main() {
  var componentTree = new MyButton(
      title: 'Save',
      onClick: () {
        doSomthing();
      },
      icon: new Image(src: '/images/save.png', width: 10));
}

That's an improvement, but unfortunately it's not good enough, and there are plenty of other cases that even the new formatter (I tried 0.2.4) will completely butcher, such as:

  div(style: {
    'display': 'block',
    'width': '10px',
  })(
    span(id: 'msg')(
      text(this.message)
    ),
    button()(
      text('Save')
    )
  );

becoming:

  div(style: {'display': 'block', 'width': '10px',})(
      span(id: 'msg')(text(this.message)), button()(text('Save')));

However, I do not expect the current formatter to help here. It's not the formatter's fault. The language lacks syntax that a formatter could rely on.

That's definitely not a style of API that the formatter was designed for (or that I've seen in any existing Dart code before), so it's no surprise that it isn't handled well. Dart is nowhere near as DSL friendly as I'd like, but I wonder if there's a different way to design that API that accomplishes the same goals but without using something akin to currying.

Maybe:

  div(style: {
    'display': 'block',
    'width': '10px',
  }, contents: [
    span(id: 'msg', contents: [
      text(this.message)
    ]),
    button(contents: [
      text('Save')
    ])
  ]);

or:

  div(style(display: 'block', width: '10px'), [
    span(id('msg'), [
      text(this.message)
    ]),
    button([
      text('Save')
    ])
  ]);

  div(
    style: {
      'display': 'block',
      'width': '10px',
    },
    contents: [
      span(
        id: 'msg',
        contents: [
          text(this.message)
        ]
      ),
      button(
        contents: [
          text('Save')
        ]
      )
    ]
  );

Could you eliminate extra list allocations and named parameters from the API and still make it look nice?

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.

@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.)