You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Document expected behavior for APIs that expect a return type of Type? #56500
In Flutter 1.17.0, a breaking change was made to ParentDataWdiget. A new method debugTypicalAncestorWidgetClass requires users to override and return Type of its ancestor widget.
However, the ancestor could be a generic type, and Dart does not support generic type literals.
Since it is a relatively uncommon pattern in Flutter (AFAIK), and the solution is tricky to get around this Dart limitation, it could be confusing whether the user should return with or without generic type arguments. So mentioning this in documentation for relevant APIs can be helpful.
Can you make a suggestion as to what you would like us to add to the documentation? Looking at it, it seems pretty clear. You're supposed to provide a widget type that's typically used. The one that's typically used would have a specific type, not a generic one.
Due to this Dart limitation, we need to manually create a getType function to retrieve the type (in this answer). This workaround requires quite some serious Dart knowledge, primarily reified generics, for user (especially users from JS or Java background, whose generics use type erasure and have very different behavior).
For future APIs designed in this pattern, it may be helpful to add a line of comment about the best solution for generic types, until this Dart limitation has been solved.
debugTypicalAncestorWidgetClass is the only property or method I could find that returns a type where this might be an issue. I've added the following to the documentation:
/// /// ## Implementations /// /// The returned type should be a subclass of `RenderObjectWidget`. /// /// ```dart /// @override /// Type get debugTypicalAncestorWidgetClass => FrogJar; /// ``` /// /// If the "typical" parent is generic (`Foo<T>`), consider specifying either /// a typical type argument (e.g. `Foo<int>` if `int` is typically how the /// type is specialized), or specifying the upper bound (e.g. `Foo<Object?>`).
(It's now possible to create a generic literal, FWIW.)
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
goderbauer commentedon May 13, 2020
Can you make a suggestion as to what you would like us to add to the documentation? Looking at it, it seems pretty clear. You're supposed to provide a widget type that's typically used. The one that's typically used would have a specific type, not a generic one.
znjameswu commentedon May 14, 2020
Due to this Dart limitation, we need to manually create a
getTypefunction to retrieve the type (in this answer). This workaround requires quite some serious Dart knowledge, primarily reified generics, for user (especially users from JS or Java background, whose generics use type erasure and have very different behavior).For future APIs designed in this pattern, it may be helpful to add a line of comment about the best solution for generic types, until this Dart limitation has been solved.
Hixie commentedon Jul 13, 2023
debugTypicalAncestorWidgetClassis the only property or method I could find that returns a type where this might be an issue. I've added the following to the documentation:(It's now possible to create a generic literal, FWIW.)
Add implementation advice to debugTypicalAncestorWidgetClass (#130530)
Add implementation advice to debugTypicalAncestorWidgetClass (flutter…
github-actions commentedon Aug 2, 2023
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.