-
Notifications
You must be signed in to change notification settings - Fork 40
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
Render documentation for provider init
callbacks
#224
Conversation
If a provider has a custom `init` callback, we want the summary blurb to show `init`'s parameters (since these are what the user will interact with); we have to render constructor paramaters and fields separately (and using separate html anchors) since there is not necessarily a 1-1 relationship between them, and since they may have different docs. Fixes bazelbuild#182
|
By default, we want the following behavior: * Custom init callback specified * The set of parameters for the init callback equals the set of fields for the provider; and the docs for the init callback's parameters are either empty or equal to corresponding field docs * Some init parameters have a default value: -> Render a single "Fields" table with 3 columns (name, doc, default value) * ... otherwise -> Render a single "Fields" table with 2 columns * ... otherwise -> Render two tables - "Constructor parameters" and "Fields" - with the links from the summary blurb (interfixed with "_init") leading to the parameters table (not the fields table) * ... otherwise -> Trivial case - single "Fields" table (as before).
I think by default, we want the following behavior:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed offline, approved but mind the rendering failure in one of the goldens,
If a provider has a custom
init
callback, we want the summary blurb to showinit
's parameters (since these are what the user will interact with); we have to render constructor paramaters and fields separately (and using separate html anchors) since there is not necessarily a 1-1 relationship between them, and since they may have different docs.Fixes #182