sdk
sdk copied to clipboard
dart-lang
Support fixes to create stateful and stateless widgets
When an undefined name appears as a class name in a constructor invocation and the context type is Flutter's Widget (such as nested inside another constructor invocation or in a return statement), there should be quick fixes to 'Create stateful widget' and 'Create stateless widget'.
The fixes should create code similar to the corresponding snippets, but tailored by any additional information in the constructor invocation, such as a constructor name or parameter names and types.
Noting that this is similar to what I had asked at https://github.com/dart-lang/sdk/issues/60002. Do you want to make these on their own first, or would you rather make this as a whole?
I don't think the order matters. And I'm always fine with making small incremental steps toward a larger goal, so the size of the CL should be more about what the author and reviews can comfortably handle.
The idea from #60002 is to use more of the information from the context to fill in the right information. I like that, but it isn't clear to me that there's any contextual information that would tell us whether to create a stateful or a stateless widget just from knowing the name.
I do want these to use contextual information to define the constructor when possible, so it might be able to share some code with the expanded support described in #60002.
I do want these to use contextual information to define the constructor when possible, so it might be able to share some code with the expanded support described in https://github.com/dart-lang/sdk/issues/60002.
This is a part of it, yes.
The other thing I meant could be at least started here about https://github.com/dart-lang/sdk/issues/60002, is that I asked there if we could make classes extend/implement classes when needed for the expected type (in this case, widgets).
This would only add two specific fixes for when the expected type is a Widget (and stop the default Create class, I'd say but not sure) and for all other cases we could follow to what we decide over there.
I'll start something on this tomorrow and share here.
Edit
P.S.: I'd love to start working on this after the mixin (tests on the expected type) and type inference changes in https://dart-review.googlesource.com/c/sdk/+/432580 have been merged so I can continue on those.