Dartdoc: Добавить возможность создания документации для частных классов

Это как задумано. Однако мы могли бы добавить возможность документировать их.

@sathishmscict Вы имеете в виду идентификаторы, которые начинаются с подчеркивания (_), или идентификаторы, которые не относятся к export из библиотеки (т.е. обычно используются только в / lib / src)?

Мне было бы интересно, если бы он документировал что-либо в библиотеке, что явно не экспортируется как часть ее API, пожалуйста!

Меня также интересует возможность создавать документы для всех классов, включая частные классы.

У меня есть частный класс, инициализированный в другом классе (который экспортируется / общедоступен), чтобы гарантировать, что они не могут инициализировать его за пределами класса и поэтому он не загрязняет intellisense, но я бы хотел, чтобы они могли прочитать документацию по внутренние функции для этого класса.

Во Flutter у нас есть виджеты с отслеживанием состояния, где общедоступный класс обычно небольшой и неинтересный, со всей логикой в ​​классе состояния с частным именем. Эти Государственные классы требуют документирования!

Есть обновления по этому поводу? Есть ли возможность документировать и частные классы?

Обновления пока нет, но, поскольку трафик по этому запросу функции продолжается, он повышается до P2.

Похоже, что общая тенденция состоит в том, чтобы желать документации для всех членов частной библиотеки в библиотеке или даже пакете.

Если это будет на уровне библиотеки или пакета, я бы, возможно, склонился к списку файлов параметров dartdoc_options и / или переключению всего пакета. Не очень мелкозернистый, но во многих случаях любой из этих двух вариантов сработает. В противном случае, аннотация package:meta - что-то вроде @visibleInDocumentation - может показаться подходящим вариантом, аналогичным @visibleForTesting . Одним из недостатков этого подхода является то, что вам придется пометить этим тегом любой непубличный символ, чтобы он появился. Есть предположения?

@visibleInDocumentation здесь кажется лучшим вариантом, так как это также дает возможность документировать определенные частные члены, сохраняя при этом полностью конфиденциальность других.

Все это можно сделать, причем более конкретное преобладает над более общим. В случае флаттера я хотел бы задокументировать свои собственные пакеты, а не все пакеты, поэтому уровень пакета мне подошел бы.

Поскольку аннотации могут присутствовать в библиотеках, если мы сделаем и то, и другое, вероятно, версия dartdoc_options будет ограничена целыми пакетами или деревьями каталогов.

Это также хорошее время, чтобы отказаться @nodoc устаревшей директивы

Возможность включения частных классов ( _Foo ) важна для документирования приложений флаттера, потому что в противном случае вы не сможете задокументировать StatefulWidget s

да, было бы здорово, если бы мы могли документировать и виджеты с отслеживанием состояния. Если кто-то может указать, где можно включить ведение журнала частного класса, я хотел бы создать вилку и использовать ее тем временем