Offer more Builders when wrapping widgets

[matthew-carroll]

I'd like for the "wrap widget" context menu to offer a greater selection of builders, e.g., AnimatedBuilder and LayoutBuilder.

When it comes to single-child widgets, and even multi-child widgets, it's easy to select a similar widget and then rename it. For example, if I want a Stack, it's not available in the context menu, but I can easily select Column and then rename it. However, Builders are not so easily substituted.

Builders have varying additional arguments, e.g., Stream, Listenable, etc. Moreover, the builder delegate signature varies between Builders.

Providing more Builders would be a much bigger time saver for me than having a long list of interchangeable widgets.

[devoncarew]

Hey Matt, thanks for the feedback! This aligns with some work we've been doing recently to inform our tooling w/ a statistical analysis of Flutter code.

For example, if I want a Stack, it's not available in the context menu, but I can easily select Column and then rename it.

I myself use the Wrap with widget... item for this - it doesn't name the item.

Providing more Builders would be a much bigger time saver for me than having a long list of interchangeable widgets.

We do need to be careful about not making that menu too long; this is what it looks like for Align:

We created those current items through reasonable guesses of which would be most valuable to users. I think now we could base it off which widgets are most common in user code, including builder pattern widgets. We should do some statistical analysis here; in the meantime, some questions:

• are there any non-builder widgets that you think that menu should have?
• are there any non-builder widgets in the menu currently that you think don't pay their way (aren't as used as other widgets)?
• which builder widgets would you recommend in that menu (are common, or, infrequent but high value)?

cc @pq @bwilkerson @InMatrix

[matthew-carroll]

For me, personally, the structure is all that matters. I haven't found much value in filling in the name of a widget. Instead, the value is generating the child: line or the children:[] array, or in the case of the builders, the actual builder function.

Builders are the most problematic because most builder functions differ in signature, and on top of that, they all take different required parameters.

I'm not the sure the heuristic of "widgets...most common in user code" is necessarily a good one because the frequency of use doesn't reflect the tediousness of adding the widget. If you again consider something like LayoutBuilder, I may only use that once in my app, but I'd be far more appreciative of not having to lookup that builder function signature online than I would to have quick access to a Center widget, which only saves me a couple seconds vs the generic "wrap with widget"

PS - I understand that the needs of beginner Flutter developers may be different here. I am transparently saying this as someone who knows most of the widgets that are available.

[InMatrix]

I agree it's valuable for the IDE to fill out the template of a builder. Should this be done through code completion or refactor assists, as in the original post, or both?

[matthew-carroll]

Perhaps both, but in my case, I always end up adding a builder after I've built out part of my tree. Usually I realize I need one, or I integrate data that wasn't there before. So code completion would not help my use cases.

[Nash0x7E2]

Maybe it might be better to offer separate a menu/popup with the various builder types and preserve the current menu for those who use it or who may be intimidated by a long list of widgets.

Definitely agree with @matthew-carroll, since Animation, Layout, and ValueListenable are some of the most common builders people use.

[pq]

Maybe it might be better to offer separate a menu/popup with the various builder type

I've been thinking about this a bit and trying to find a precedent where an assist/intention invokes a popup/dialog. @alexander-doroshko?

[alexander-doroshko]

I've been thinking about this a bit and trying to find a precedent where an assist/intention invokes a popup/dialog.

@pq
IntelliJ Platform doesn't have any limitations here. Some intentions do open a dialog. Usually they are intentions that have an clear intent to open a dialog and they do not modify code. Example: select a piece of Java code, there'll be 'Adjust code style settings' intention that opens a dialog.

For intentions that modify code, showing a dialog sounds like a too heavy solution. Lightweight popups that don't require user action but allow to change something in the intention behavior look more appropriate. But this will probably require changes both in the Analysis Server protocol and in the Dart plugin.

By the way, Analysis Server and IntelliJ already support so called 'linked edits' with suggestions list. Can they help to improve the wrapping usability?

[InMatrix]

How about replacing "Wrap with StreamBuilder >" with "Wrap with a builder >" that shows a sub-menu of different kinds of builders?

[matthew-carroll]

I think that's worth a try if it can be done. I think the frequency of use is low enough, and the value of the generator is high enough to make a submenu worth the extra click.

[bwilkerson]

@alexander-doroshko I'm wondering what you would recommend for how to handle a situation like this.

[pq]

@bwilkerson, @alexander-doroshko suggested this idea above:

By the way, Analysis Server and IntelliJ already support so called 'linked edits' with suggestions list. Can they help to improve the wrapping usability?

What do think?

[alexander-doroshko]

@bwilkerson Is the 'linked edits' concept enough for the task? In this case a single 'Wrap with a builder' quick assist that will open a list of applicable builders sounds good to me. And this won't require any changes in the protocol or in the Dart plugin.

But I speak for technical solutions only. Flutter plugin engineers might want to run a UX study to check whether such change makes the feature more or less discoverable / convenient / often used.

[bwilkerson]

Sorry, I missed the earlier comment on linked edits.

@matthew-carroll @InMatrix Interested to hear what you think. In case you're not familiar with it, you can see the UX by creating a file containing

void f() {
  StringBuffer();
}

place the cursor inside StringBuffer, and select the intension "Assign value to new local variable" (from the lightbulb menu). The menu of options that opens is the same as what we're talking about here, except that it would contain the names of relevant builders.

[pq]

@matthew-carroll (or anyone): could you describe some of the template content you'd like to see generated for some select builders? Is there anything generalizable or does it vary greatly between specific builder implementations?

[idkq]

@pq StreamBuilder but a generic builder could work such as adding builder: (_,__){ return [code goes here]; }

Is there a limit from IntelliJ on this dropbox? IMHO the more options the better since searching and pressing takes way less time than typing even for a larger list. Maybe sort alphabetically.

StreamBuilder does not show up on wrapping another StreamBuilder for example

[matthew-carroll]

@pq I guess I missed some of the followup messages here a year ago.

Here are some examples of what I'd expect to see generated for a few different builders:

LayoutBuilder(
  builder: (context, constraints) {
    [CODE_NEEDED]
  },
)

AnimatedBuilder(
  animation: [CODE_NEEDED]
  builder: (context, value) {
    [CODE_NEEDED]
  },
)

And then perhaps support for a "generic builder", which won't completely satisfy any builder, but would be a nice headstart for custom builders:

MyBuilder(
  builder: (context) {
    [CODE_NEEDED]
  },
)

I do think this is worth some UX investigation. CC @InMatrix

[pq]

Thanks for the added context @matthew-carroll!