Repository: flutter
Issue: Re-exports in libraries makes the api-reference inaccessible
Labels: framework,f: material design,f: cupertino,d: api docs,c: proposal,team-design,triaged-design

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill out the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Use case

Lets take the material library as an example.
 
What are the members of this library?  
You can't tell, cause the material library re-export "widgets" which itself re-exports other members in a lot of different files.

The same applies to other libraries like cupertino. 

It seems there are two types of libraries in flutter/dart:

1. Libraries that export only the included members
2. Libraries that export the included members and frequently used other members from different
libaries

Unfortunately the second type causes some issue for the documentation:

- It's really hard to find things or look through the api-reference because of the sheer amount of 
members in some libraries (material, cupertino,...)
- It's difficult to get an overview of the members of a specific library, to the point were looking at the source code
gives you a much better overview. Which speeks for the source code but not some much for the documentation.
- You have to unintentionally jump between different libraries if you go through the api-reference

<!--
     Please tell us the problem you are running into that led to you wanting
     a new feature.

     Is your feature request related to a problem? Please give a clear and
     concise description of what the problem is.

     Describe the alternative solutions you've considered. Is there a package
     on pub.dev/flutter that already solves this?
-->

## Proposal

It seem there is no real guidelines or patterns in flutter and dart that covers this.
So here is my proposal:

---

**Do**: The default import should *only* contain the members of the library.

```dart
import 'package:flutter/material.dart'; //Contains only the included members and no re-export
```

**Don't**: The default import should *not* contain re-exports of other libraries.

```dart
import 'package:flutter/material.dart'; //Contains included members and re-exports
```

**Optionally**: Include a selection of frequently used other members from different libraries for convenience. 

```dart
import 'package:flutter/material_collection.dart'; // Contains included members and re-exports form other libaries
```
---

The term "collection" is just an example, but there should definitely be a term that everyone should agree on.  
Also, the existence of a "collection" should be documented, cause not every library needs or includes one.

I know that this proposal, by default, leads to a more imports. But i think it really worth it.
And its still possible to include a different export for convenience. 
I think thats mainly the reason why libraries like material and cupertino works the way they do now.

<!--
     Briefly but precisely describe what you would like Flutter to be able to do.

     Consider attaching something showing what you are imagining:
      * images
      * videos
      * code samples

     Does this have to be provided by Flutter directly, or can it be provided
     by a package on pub.dev/flutter? If so, maybe consider implementing and
     publishing such a package rather than filing a bug.
-->