Skip to content

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

@srawlins

Description

@srawlins

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.

Metadata

Metadata

Assignees

Labels

P2A bug or feature request we're likely to work ontype-performanceIssues related to slow dartdoc generation.type-tech-debtIssues that slow or block desirable development paths for Dartdoc, or create such problems for users

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions