Skip to content

Document expected behavior for APIs that expect a return type of Type? #56500

Closed

Description

@znjameswu

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.

Activity

  1. goderbauer commented on May 13, 2020

    @goderbauer
    Member

    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.

  2. added
    waiting for responseThe Flutter team cannot make further progress on this issue until the original reporter responds
    on May 13, 2020
  3. znjameswu commented on May 14, 2020

    @znjameswu
    Author

    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.

  4. removed
    waiting for responseThe Flutter team cannot make further progress on this issue until the original reporter responds
    on May 14, 2020
  5. added
    P2Important issues not at the top of the work list
    on Aug 23, 2022
  6. Hixie commented on Jul 13, 2023

    @Hixie
    Contributor

    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.)

  7. self-assigned this
    on Jul 13, 2023
  8. github-actions commented on Aug 2, 2023

    @github-actions

    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.

  9. locked as resolved and limited conversation to collaborators on Aug 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P2Important issues not at the top of the work listd: examplesSample code and demosframeworkflutter/packages/flutter repository. See also f: labels.team-frameworkOwned by Framework teamtriaged-frameworkTriaged by Framework teamwaiting for PR to land (fixed)A fix is in flight

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions