Co-authored-by: Kellen <9484709+goodroot@users.noreply.github.com>
This commit is contained in:
parent
a0e0696714
commit
9eed9ee39b
|
@ -111,7 +111,7 @@ export getSearchService: (searchSpec: { username: string; password: string }) =>
|
|||
|
||||
In the former, there will be a link to the `SearchSpec` interface with documentation for the `username` and `password` properties. In the latter the object will render inline, without comments:
|
||||
|
||||
![prefer interfaces documentation](./assets/dev_docs_nested_object.png)
|
||||
![prefer interfaces documentation](../assets/dev_docs_nested_object.png)
|
||||
|
||||
#### Export every type used in a public API
|
||||
|
||||
|
@ -135,7 +135,7 @@ export type foo: string | AnInterface;
|
|||
|
||||
`Pick` not only ends up being unhelpful in our documentation system, but it's also of limited help in your IDE. For that reason, avoid `Pick` and other similarly complex types on your public API items. Using these semantics internally is fine.
|
||||
|
||||
![pick api documentation](./assets/api_doc_pick.png)
|
||||
![pick api documentation](../assets/api_doc_pick.png)
|
||||
|
||||
### Example plugins
|
||||
|
||||
|
@ -210,7 +210,7 @@ your large change right _after_ feature freeze. If you are worried about missing
|
|||
|
||||
When possible, build features with incrementals sets of small and focused PRs, but don't check in unused code, and don't expose any feature on master that you would not be comfortable releasing.
|
||||
|
||||
![product_stages](./assets/product_stages.png)
|
||||
![product_stages](../assets/product_stages.png)
|
||||
|
||||
If your feature cannot be broken down into smaller components, or multiple engineers will be contributing, you have a few other options to consider.
|
||||
|
||||
|
|
Loading…
Reference in a new issue