Sdk: Code completing builder fields in widgets should fill in the closure

[move[bot]]

@devoncarew commented on Jan 7, 2020, 9:44 PM UTC:

Code completing builder fields in widgets should fill in the closure; when code completing builder fields in widgets (like for ValueListenableBuilder, LayoutBuilder, and StreamBuilder), we should fill in the closure as well:

builder: (BuildContext context, BoxConstraints constraints) {
  …
}

This issue was moved by devoncarew from flutter/flutter-intellij#4257.

[pq]

See also https://github.com/dart-lang/sdk/issues/36112 and https://github.com/dart-lang/sdk/issues/35884.

[pq]

https://github.com/dart-lang/sdk/commit/e0c178b38e632b6af1b18c63285034a7a5eab600 WIP:

[shinayser]

@pq this is related to #36112?

[pq]

@shinayser: yep. Should be implemented w/ e0c178b.

[shinayser]

@pq Thank you so much for this implementation man! You have no idea how this will save us HOURS of work.

Do you have any idea when we will be able to put our hands on it?

And thanks again for you great work here!

[pq]

The initial implementation is landed in the Dart SDK and that should make its way into flutter master within a few days (I think?) If you're running on the Flutter stable channel, it'd have to wait for the next Stable release --- not sure when that is.

[shinayser]

@pq If you allow me, I would like to give a feedback about this feature.

Everything is working great but I found myself in some bad sittuations where the "auto-auto-complete" (yes, 2 autos) is kind of a pain. Isn't possible to auto-complete only when invoked by user?

For example:

When the user types then and summon the auto-complete, the SDK is automatically completing the lambda with (value) => null. But what if I want to pass an function as parameter or open a block function instead of arrow?
See my point? The user will have to erase all the (value) => manually and that can be a problem for usability.

I think the lambda completion should only be auto inserted by the SDK when requested by user, just like you did for optional parameters.

[pq]

Yeah. This is unfortunate. We've optimized what feels like the common case but at a cost. (And a big one if we're wrong about what's common.) I agree we should do a bit of a review. Could you open a fresh issue/feature request?

Thanks a million for all the feedback @shinayser!

[mannprerak2]

Hey @pq
Is this covered in your implementation?

For a function created like this (in a file, which is imported as bindings)-

/// C function Divide
final _divide_Dart divide =
    _dynamicLibrary.lookupFunction<_divide_C, _divide_Dart>(
  'divide',
);

// using this typedef
typedef _divide_Dart = ffi.Pointer<ffi.Float> Function(
  int a,
  int b,
);

The autocomplete shows this -