Skip to content

All exported elements are duplicated in dartdoc's model #3748

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
srawlins opened this issue Apr 15, 2024 · 0 comments · Fixed by #3838
Closed

All exported elements are duplicated in dartdoc's model #3748

srawlins opened this issue Apr 15, 2024 · 0 comments · Fixed by #3838
Assignees
Labels
P2 A bug or feature request we're likely to work on type-performance Issues related to slow dartdoc generation. type-tech-debt Issues that slow or block desirable development paths for Dartdoc, or create such problems for users

Comments

@srawlins
Copy link
Member

I found what I consider to be an issue, which is that every export of a library's elements duplicates those elements in Dartdoc's element model. E.g. given:

// sdk/lib/async/future.dart:
class Future { ... }

// sdk/lib/async.dart:
export 'async/future.dart';

// sdk/lib/core.dart:
export 'async.dart' show Future;

we have 3 copies of the Future class running around Dartdoc's graph of elements. We also have 3 copies of all of the class members of Future, etc.

I think this was designed insofar as it allows the following behavior: When we need to compute the "canonical library" which provides Future, we have an array of options. We can choose the best option, "Future as defined in sdk/lib/async.dart", and just drop the others on the floor. The others don't get documented, and no link to /// [Future] or Future in a signature ever goes to one of the non-canonical copies. However, the other copies are still lying around, causing confusion, bugs, and performance degredation (I imagine; I haven't measured).

I think a better setup would be to only create a Dartdoc model element one time for each declaration, and track exports separately. We can then say that "Future is declared in sdk/lib/async/future.dart" but simultaneously calculate that "the canonical library of Future is sdk/lib/async.dart." I don't think it is hard to implement this idea.

@srawlins srawlins added P2 A bug or feature request we're likely to work on type-tech-debt Issues that slow or block desirable development paths for Dartdoc, or create such problems for users type-performance Issues related to slow dartdoc generation. labels Apr 15, 2024
@srawlins srawlins self-assigned this Aug 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 A bug or feature request we're likely to work on type-performance Issues related to slow dartdoc generation. type-tech-debt Issues that slow or block desirable development paths for Dartdoc, or create such problems for users
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant