All exported elements are duplicated in dartdoc's model #3748
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
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:
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]
orFuture
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.
The text was updated successfully, but these errors were encountered: