Formatting call chain is a bit off

[long1eu]

Hi!

I really love dartfmt in general but there is this issue that bugs my head.

Why does the following piece of code format like this:

    _firestore //
        .doc('$_usersCollection/$uid/streams/$streamId')
        .update(<String, dynamic>{
      'relocationOffered': relocation,
      'workSituation': workSituation,
      'zipCode': zipCode,
    });

and not like this:

    _firestore //
        .doc('$_usersCollection/$uid/streams/$streamId')
        .update(<String, dynamic>{
          'relocationOffered': relocation,
          'workSituation': workSituation,
          'zipCode': zipCode,
        });

Sure it looks even worse if I do this:

    _firestore //
        .doc('$_usersCollection/$uid/streams/$streamId')
        .update(<String, dynamic>{
      'relocationOffered': relocation,
      'workSituation': workSituation,
      'zipCode': zipCode,
    }).then((value) => null);

But looks perfect if I do this:

    _firestore //
        .doc('$_usersCollection/$uid/streams/$streamId')
        .update(<String, dynamic>{
          'relocationOffered': relocation,
          'workSituation': workSituation,
          'zipCode': zipCode,
        })
        .then((value) => null)
        .then((value) => null);

But of course I can live with something like this:

    final Map<String, dynamic> data = <String, dynamic>{
      'relocationOffered': relocation,
      'workSituation': workSituation,
      'zipCode': zipCode,
    };

    await _firestore //
        .doc('$_usersCollection/$uid/streams/$streamId')
        .update(data);

[DanWatkins]

@long1eu This behavior is actually by design if you read their FAQ. However, I have to agree with you that the output is confusing when coming from other formatters such as Prettier for JS/TS or dotnet format. It would be nice to have an option to indent relative to the surrounding expression. At the end of the day, it might just be something we have to adjust to since configuration options are not a goal of this project (#534).

Give this issue a +1 if you'd like to see an alternative formatter: Dart-Code/Dart-Code#914

[munificent]

Yeah, the formatter's heuristics around when to do "block-like" formatting for nested function expressions and collection literals currently lean pretty hard towards block style. That's good for some things like tests:

test('blah', () {
  // Potentially lots of code here.
});

But it doesn't look great in some cases, like your example here. This is a difficult part of the formatter to change because it impacts so much existing formatted code and it tends to make some cases better and others worse. Users don't like it when any existing formatted code gets uglier. At some point, though, it may be worth revisiting this.

[munificent]

The forthcoming tall style does the right thing. It gives you:

    _firestore //
        .doc('$_usersCollection/$uid/streams/$streamId')
        .update(<String, dynamic>{
          'relocationOffered': relocation,
          'workSituation': workSituation,
          'zipCode': zipCode,
        });

And:

    _firestore //
        .doc('$_usersCollection/$uid/streams/$streamId')
        .update(<String, dynamic>{
          'relocationOffered': relocation,
          'workSituation': workSituation,
          'zipCode': zipCode,
        })
        .then((value) => null);