Dart-code: Experiment making the widget hierarchy structure more glanceable in code

[xster]

We briefly talked about it during dartconf. Sometimes users get lost in a wall of UI declaring text and can't easily pick out the important structural parts from the 'adjectives'.

Can we experiment a bit with how to elevate Widget subclass instantiation from various other parameter setting?

Maybe a decoration treatment

or mix in font sizes

Or maybe include the new/const and the start/end parens.

cc @devoncarew @sethladd

[sethladd]

I love this idea.

[DanTup]

I think we can tweak the styling in a similar way to we do with closing labels, though we'd need this data from somewhere. Is the analysis server going to get a Flutter plugin? Seems like something we'd need support for (getting Widget constructor calls) but is pretty Flutter-specific.

Slight tangent, but on the subject of making Flutter code easier to read; some things that are always on my mind (I realise some of these are restricted by the language):

• Why do we have to write child/children? Why can't that be a positional parameter? And why can't we put positional params after named (when calling)?
• Why do we write <Widget> for children, why can't it be inferred?
• Why do we have to put [] around the children, why can't it work like params in C#?

(I know this isn't the place to raise feature requests, but maybe these may be things you guys have asked about/though of before?)

[sethladd]

Great questions! cc @leafpetersen

Leaf might know what's the latest on rest params or varargs or whatever can allow us to put a list as the last parameter, and omit the [ ].

You don't need to specify <Widget> in front of children in Dart 2. That's a Flutter team style preference, but everyone else will probably omit it, because it is inferred.

[leafpetersen]

One of the user scenarios we've been asked to look at from a language perspective is making code like this better, and rest params are one of the things we've talked about as part of this. This quarter is entirely about Dart 2 and the core lib changes, but starting Q2 we'll hopefully be able to spend more time on it.

[DanTup]

Sounds good :)

What about positional args after named? C# doesn't allow this either but I never understood whether it was just a preference or if there was some issue it would introduce?

MyWidget(
  color: red,
  new Text("Test")
);

It works with the args the other way around, but it feels wonky to specify the children before the parameters for this widget. Why can't named args be taken out before looking at positionals? That could eliminate all the child/children noise (looking at the screenshot above, there's quite a lot of it). React code looks kinda like that (though their named args are put into the first param as an object)

[leafpetersen]

I don't think there are any issues with allowing named arguments to appear anywhere in the invocation list. I think it's on the list of things we'd like to add, but are mostly blocked on waiting for implementations to stabilize.

[devoncarew]

Calling out widgets better in the text generally sounds good, though the above sample styles are a bit too over-emphasized in my opinion.

I wonder if just eliminated the new and consts in the above samples will help out a lot w/ readability?

I think we can also add ruler column decorations in VS Code. If so, we could add small flutter badge icons in the editor's left ruler? That's not directly next to the construction site, but might help pick out widgets in the tree.

Also, using an actual tree might help - adding a contribution to the Explorer that displayed the widget tree as defined in the build() method.

[xster]

Ya, I think the example styling above is likely overdone. It could be subtler like just a box border or just a background etc.

One additional thing that could be helpful is letting the structural hierarchy be instantly glanceable based on the left indent which isn't clear from the example above. Having an emphasis plus letting the left indent of widget declarations be clear (by removing child/children and new/const) would be a huge win too.

Though I think it wouldn't be sufficient just removing new/const to make the widget hierarchy glanceable.

For instance, in

it wouldn't be clear with just

Container(
  decoration: BoxDecoration(
    color: Color(0xFFE5E5E5),
  ),
  child: Padding(
    padding: EdgeInsets.symmetric(...
    child: Row(
      mainAxisAlignment: ...

that Container->Padding->Row is the meat of the structure here and the rest like BoxDecoration are just adjectives.

Some emphasis (a highlight, a box, a badge) would still help.

[devoncarew]

Here's a mockup which _does_ left align widgets in the code, based on their depth in the tree:

  Widget build(BuildContext context) {
    return
    Scaffold(
      appBar:
      AppBar(
        title:
        Text(widget.title),
      ),
      body:
      Center(
        child:
        Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            Text('You have pushed the button this many times:'),
            Text('$_counter'),
          ],
        ),
      ),
      floatingActionButton:
      FloatingActionButton(
        onPressed: _incrementCounter,
        tooltip: 'Increment',
        child:
        Icon(Icons.add),
      ),
    );
  }

This depends on very customized formatting in build() methods.

[xster]

I was disturbed at first that named parameter and the actual arguments are aligned, but the more I looked at it, the more I love it despite the non-orthodoxy. I especially love that MainAxisAlignment, is not colored and Text is. It makes a huge difference in glanceability.

Maybe a low invasiveness version of this could just be getting a specialized syntax highlighter.

[DanTup]

I'm conflicted about @devoncarew's mockup... It looks really weird but also kinda clean (I think the colours help - maybe we should ship a Flutter theme in Dart Code 😁). I'd be curious to see some more complicated code (like @xster's original screenshot) formatted like that.

[xster]

Circling back to this. I +1 compositional/incremental changes. Just being able to take an existing theme, cmd-shift-p -> Generate Color Theme from Current Settings -> add one more clause for 'flutter widget constructor color' would be big help already.

[DanTup]

I don't think you'd need to create a whole theme to do this. From Flutter Outline notifications we can figure out where the constructor calls are should be able to use decorations (like we do closing labels) to set a color, and let you change it using workspace colour customisations.

Any now I think about it, I wonder if we could actually simulate the whole of https://github.com/Microsoft/vscode/issues/585 by doing this...!

I don't think it's much effort to try out what you're suggesting so I'll see if I can give it a go on a branch and post back.

[DanTup]

I was investigating #611 and remembered a comment Devon made above about icons in the gutter for this case. Excuse that they're on the wrong lines (I hit save and it formatted but my samples were hard-coded), but I think this might be a nice idea?

It wouldn't be much work to use the Flutter Outline data to render, so if it seems like a reasonable idea I could add it in to a beta or behind a flag or something to test out.

[xster]

I personally liked the selective color/font theming solutions more than additive solutions like adding more closing tags or start-locating tags. Reducing but qualifying the data that's already on screen seems more minimalistic.

[escamoteur]

Referencing https://github.com/dart-lang/sdk/issues/15398

[DanTup]

It's been a while since this was raised, and there have been many changes since (removing new/const, Flutter Outline in VS Code, UI guides - albeit still in preview in VS Code because they're a bit wonky).

How do people feel about this now - are there still things we should look at (like highlighting constructor names differently), or is everything solved? 😬

[DanTup]

Tidying up some old issues.. Closing this as it doesn't seem like there's anything concrete to do here. Happy to re-open (or we can file new issues) if there are specific things we might still want to try out though!