Skip to content

Instantly share code, notes, and snippets.

@yjbanov
Last active February 4, 2016 18:34
Show Gist options
  • Save yjbanov/04436939b02f1f190504 to your computer and use it in GitHub Desktop.
Save yjbanov/04436939b02f1f190504 to your computer and use it in GitHub Desktop.
trailing commas for tree-like code in 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?
@munificent
Copy link

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));
}

@yjbanov
Copy link
Author

yjbanov commented Jan 22, 2016

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.

@munificent
Copy link

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')
    ])
  ]);

@sethladd
Copy link

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

@yjbanov
Copy link
Author

yjbanov commented Jan 25, 2016

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

@Hixie
Copy link

Hixie commented Jan 25, 2016

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.

@yjbanov
Copy link
Author

yjbanov commented Feb 4, 2016

@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!!!

@Hixie
Copy link

Hixie commented Feb 4, 2016

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

@Hixie
Copy link

Hixie commented Feb 4, 2016

(I understand that what I'm proposing is incompatible with dartfmt's current goals. I think dartfmt's goals should change.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment