Skip to content

Hide implementation of static constants #2657

Closed

Description

@guidezpl

The Icons class defines icons as IconData constants. This has lead a number of devs to use the implementation (e.g. IconData(57399, fontFamily: 'MaterialIcons')) rather than the interface Icons.airplane. This is a problem because all codepoints (e.g. 57399) change every time the font is updated.

Is there an option or annotation to hide the implementation in docs?

Activity

  1. srawlins commented on May 25, 2021

    @srawlins
    Member

    Do you have evidence that developers are copy/pasting from dartdoc rather than from the source (like clicking through in their IDE)?

    Can the constructor be made private or @internal so that users are discouraged from using it?

  2. added
    P2A bug or feature request we're likely to work on
    on May 25, 2021
  3. jcollins-g commented on May 25, 2021

    @jcollins-g
    Contributor

    The way this looks now on the top level page, I could see how people might interpret the text string as an example.

    Screen Shot 2021-05-25 at 3 08 25 PM

    What if we moved the value onto the same line as the definition in the template? That might make it more obvious that it isn't intended as an example.

  4. jcollins-g commented on May 25, 2021

    @jcollins-g
    Contributor

    So the first line for a constant would be something like adb_outlined -> const IconData(60984, fontFamily: 'MaterialIcons'), all in the same font/weight.

  5. guidezpl commented on May 26, 2021

    @guidezpl
    ContributorAuthor

    @srawlins I've lost count but it happens fairly regularly (e.g. flutter/flutter#83208). The IconData constructor can be used legitimately for other purposes (such as with one's own icon font). The @internal annotation is not suitable beause it generates can only be used within its package analysis warnings.

    @jcollins-g that would be a slight improvement, but ideally I'd like to completely hide the constants' implentation from the API docs.

  6. jcollins-g commented on Jun 2, 2021

    @jcollins-g
    Contributor

    Another way to implement this is as a dartdoc tag. Something like @hideImplementations in the enum -- that would enable us to drop that tag in in places where the implementation is uninteresting or even distracting/leading users down the wrong path.

  7. guidezpl commented on Jun 3, 2021

    @guidezpl
    ContributorAuthor

    That would be ideal!

  8. added
    P1A high priority bug; for example, a single project is unusable or has many test failures
    and removed
    P2A bug or feature request we're likely to work on
    on Aug 30, 2021
  9. jcollins-g commented on Aug 30, 2021

    @jcollins-g
    Contributor

    This page turns out to have a lot of traffic in the Flutter docs, so finding a way to reduce misinterpretations here would have a high impact.

  10. guidezpl commented on Nov 5, 2021

    @guidezpl
    ContributorAuthor

    Hey, wondering if adding this tag is something I could do? How would I go about that?

  11. guidezpl commented on May 23, 2022

    @guidezpl
    ContributorAuthor

    sorry to ask, but "any updates?"

  12. srawlins commented on Aug 4, 2022

    @srawlins
    Member

    Sorry, no updates.

  13. self-assigned this
    on Apr 24, 2023
  14. guidezpl commented on May 4, 2023

    @guidezpl
    ContributorAuthor

    Thanks @jcollins-g! I wonder though, since we now rely on the single staticIconProvider annotation (e.g. https://github.com/guidezpl/flutter/blob/constrain-dialogs/packages/flutter/lib/src/material/icons.dart#L152) rather than insert thousands of individual annotations, to achieve the same result?

  15. jcollins-g commented on Jun 2, 2023

    @jcollins-g
    Contributor

    Thanks @jcollins-g! I wonder though, since we now rely on the single staticIconProvider annotation (e.g. https://github.com/guidezpl/flutter/blob/constrain-dialogs/packages/flutter/lib/src/material/icons.dart#L152) rather than insert thousands of individual annotations, to achieve the same result?

    You shouldn't need thousands of annotations, you should only need a single annotation for the class containing the constants in question.

  16. guidezpl commented on Jun 2, 2023

    @guidezpl
    ContributorAuthor

    You're right, I don't know where I got that idea (:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P1A high priority bug; for example, a single project is unusable or has many test failurescustomer-flutterIssues originating from important to Fluttertype-enhancementA request for a change that isn't a bug

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions