You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Larger, more complex products can have a lot of modules. Currently, each has their own DocC compiled package without knowledge of dependant modules. This feature request describes an extra wish on top of #255, namely browsing through multiple targets that reference/use each other.
Additionally, there would be support for a general index page that links to all of the targets/modules included in that documentation archive. As an example, I refer to Apple's technologies overview page.
Motivation:
If/when this feature is implemented, it would be possible to navigate through different targets/products/frameworks in the same documentation package. The use case here is that it should be possible to look at a documented protocol in package A and then see all of the structs in package B and C that implement the protocol in package A. (And the other way around, being able to click through to the protocol in package A when looking at the implementation in package C.
Importance:
This feature is an expansion of the new use-case in #255, so possibly this can be done at the same time. It is not uncommon that packages have shared logic in other packages, or implement a shared layer between multiple apps.
The general overview page that is referenced in the description can be generated manually or automatically, as described in #255. However, this could also be an out-of-the-box generated page in the documentation archive, as I can imagine it would be beneficial to a lot of developers to have one documentation portal and easy access to any module.
Thanks for filing this @jbehrens94! I agree, once we support publishing documentation for multiple targets together, it would make sense to have UI that allows you to switch between targets easily. As you mention, an "index" page could work well. I think being able to switch technologies via the navigation sidebar would be neat as well.
The use case here is that it should be possible to look at a documented protocol in package A and then see all of the structs in package B and C that implement the protocol in package A. (And the other way around, being able to click through to the protocol in package A when looking at the implementation in package C.
This should come with together with #255. It doesn't really make sense to publish documentation for multiple targets if the documentation doesn't include relationships between their symbols and ways to link between pages.
Would it be reasonable to focus this issue on the ability to focus this issue on the top-level index page that contains an overview of what target documentation is available on the site? Something like "Index page for all published target documentation" could work.
Feature Request: Multi-target browsing
Description:
Larger, more complex products can have a lot of modules. Currently, each has their own DocC compiled package without knowledge of dependant modules. This feature request describes an extra wish on top of #255, namely browsing through multiple targets that reference/use each other.
Additionally, there would be support for a general
index
page that links to all of the targets/modules included in that documentation archive. As an example, I refer to Apple's technologies overview page.Motivation:
If/when this feature is implemented, it would be possible to navigate through different targets/products/frameworks in the same documentation package. The use case here is that it should be possible to look at a documented protocol in package A and then see all of the structs in package B and C that implement the protocol in package A. (And the other way around, being able to click through to the protocol in package A when looking at the implementation in package C.
Importance:
This feature is an expansion of the new use-case in #255, so possibly this can be done at the same time. It is not uncommon that packages have shared logic in other packages, or implement a shared layer between multiple apps.
The general overview page that is referenced in the description can be generated manually or automatically, as described in #255. However, this could also be an out-of-the-box generated page in the documentation archive, as I can imagine it would be beneficial to a lot of developers to have one documentation portal and easy access to any module.
Alternatives Considered
None other than already mentioned in #255.
The text was updated successfully, but these errors were encountered: