-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
disable removeComments
, add docmodel, inheritDoc processing
#11290
Conversation
|
size-limit report 📦
|
✅ Deploy Preview for apollo-client-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Okay, trying to get some short explanations in here. A Docblock in TSDoc has a few "sections": /**
* Returns the average of two numbers.
*
* @remarks
* This method is part of the {@link core-library#Statistics | Statistics subsystem}.
*
* @param x - The first input number
* @param y - The second input number
* @returns The arithmetic mean of `x` and `y`
* @example
* Prints "true" for `{@link}` but "false" for `@internal`:
* ```ts
* console.log(isInlineTag('{@link}'));
* console.log(isInlineTag('@internal'));
* ```
* @see {@link http://example.com/@internal | the @internal tag}
* @beta
*/
function between(a: number, b: number): number{
} We have a
We can reference those from the documentation: <DocBlock canonicalReference="@apollo/client!ApolloClient:constructor(1)" /> would render by default the <DocBlock summary={false} remark canonicalReference="@apollo/client!ApolloClient:constructor(1)" /> Adding the Options here are:
If we just need a little piece, we can also use <DocPiece summary canonicalReference="@apollo/client!ApolloClient:constructor(1)" />
<DocPiece remark canonicalReference="@apollo/client!ApolloClient:constructor(1)" />
<DocPiece example collapsible canonicalReference="@apollo/client!ApolloClient:constructor(1)" /> Apart from that, we currently have these components (but can add more!) <FunctionDetails canonicalReference="@apollo/client!ApolloClient#watchQuery:member(1)" />
<InterfaceDetails canonicalReference="@apollo/client!ApolloClientOptions:interface" />
// can be configured a bit:
<InterfaceDetails canonicalReference="@apollo/client!ApolloClientOptions:interface" headingLevel={4} /* size of the heading*/ link={false} /* if the heading should be a link anchor */ /> |
@@ -118,7 +118,7 @@ export interface QueryOptions<TVariables = OperationVariables, TData = any> { | |||
export interface WatchQueryOptions< | |||
TVariables extends OperationVariables = OperationVariables, | |||
TData = any, | |||
> extends Omit<QueryOptions<TVariables, TData>, "fetchPolicy"> { | |||
> { |
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.
This interface had "complicated inheritance", so inherited members cannot be automatically determined - we have to inline them.
(We could alternatively create a supertype without fetchPolicy
and inherit from that)
@@ -149,6 +149,33 @@ export interface WatchQueryOptions< | |||
* behavior, for backwards compatibility with Apollo Client 3.x. | |||
*/ | |||
refetchWritePolicy?: RefetchWritePolicy; | |||
|
|||
/** {@inheritDoc @apollo/client!QueryOptions#query:member} */ |
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.
This will be inlined from the comment on QueryOptions.query
during build time and on docmodel generation, to prevent duplication of identical comments - @jerelmiller this will come very handy with your plan of flattening interface hierarchies.
* @example | ||
* ```js | ||
* import { ApolloClient, InMemoryCache } from '@apollo/client'; |
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.
This example moved into the code and is now just referenced from the docs.
Comment has been resolved by Lenz Weber-TronicLenz Weber-Tronic left a comment:
Browser metadata
|
.gitignore
Outdated
@@ -73,3 +73,4 @@ esbuild-why-*.html | |||
|
|||
.yalc | |||
yalc.lock | |||
docs/shared/client.api.json |
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.
This file is autogenerated on a bunch of occasions and doesn't need to be checked in.
@@ -37,14 +38,17 @@ | |||
}, | |||
|
|||
"docModel": { | |||
"enabled": false | |||
"enabled": false, |
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.
We are now also generating a docModel for consumption in the docs build.
const parsed = parseArgs({ | ||
options: { | ||
generate: { | ||
type: "string", | ||
multiple: true, | ||
default: ["apiReport"], | ||
}, | ||
"main-only": { | ||
type: "boolean", | ||
default: false, | ||
}, | ||
}, | ||
}); |
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.
Adding some new command line arguments that allow us to use this tool in a few different ways.
console.log( | ||
"Processing {@inheritDoc <canonicalReference>} comments in .d.ts files." | ||
); |
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.
This CLI tool will inline docblocks specified with @inheritDoc
on build. We need this here for situations where inheritance is not possible for docModel
generation (interface Foo extends Omit<Bar, 'baz'> {}
is too complicated a type for it to parse) and we want to flatten types - or going forward, for generally flattening types without repeating docs everywhere.
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.
This is super useful information. Would it be useful to add this as a code comment in this file? I think future us could benefit from this information in case we stumble across this script again and wonder why its needed.
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.
Added a comment at the top of the file :)
Extractor.invoke(extractorConfig); | ||
|
||
const model = new ApiModel(); | ||
model.loadPackage(tempModelFile); |
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.
There's unfortunately no better way than writing and immediately reading this file 🤦
|
||
const entryPoints = require("./entryPoints"); | ||
const distDir = "./dist"; | ||
|
||
const removeComments = cleanup({}); |
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.
In .js
rollup builds we still want to remove comments - they only increase bundle size here and we only need them in .d.ts
files.
They will still be in the ESM files directly built by tsc
, but these will always be used by some kind of bundler on user side, so it's okay.
api_doc: | ||
- "@apollo/client!ApolloClient:class" | ||
- "@apollo/client!DefaultOptions:interface" |
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.
We need to reference the "parent" entities of things we want to document on this page, so they are available for the DocBlock
etc. components later on.
netlify.toml
Outdated
cd ../ | ||
rm -rf monodocs | ||
git clone https://github.com/apollographql/docs --branch main --single-branch monodocs | ||
git clone https://github.com/apollographql/docs --branch pr/apidoc --single-branch monodocs |
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.
This needs to change once apollographql/docs#588 has been merged - we'll have to coordinate both of those PRs.
/** | ||
* | ||
* @param observable the observable query to subscribe to | ||
* @param shouldResolve should we resolve after seeing all our callbacks [default: true] | ||
* (use this if you are racing the promise against another) | ||
* @param wait how long to wait after seeing desired callbacks before resolving | ||
* [default: -1 => don't wait] | ||
* @param errorCallbacks an expected set of errors | ||
*/ | ||
export type Options = { |
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.
These are not parameters, but interface members => fixing up the docblocks.
@@ -7,7 +7,6 @@ | |||
"skipLibCheck": true, | |||
"moduleResolution": "node", | |||
"importHelpers": true, | |||
"removeComments": true, |
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.
This is the one line that triggered this rabbit hole 🐇
apollographql/docs#588 has been reviewed and is approved. |
} from "@microsoft/api-extractor"; | ||
import { parseArgs } from "node:util"; |
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.
TIL Node has a parseArgs
utility. Neat!
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.
Nice work! Will be great to have some better DX when using the client. Hard to believe we've gone this long and not realized this has been a problem.
src/core/ApolloClient.ts
Outdated
/** | ||
* If `true`, the [Apollo Client Devtools](https://www.apollographql.com/docs/react/development-testing/developer-tooling/#apollo-client-devtools) browser extension can connect to Apollo Client in your production environment. The extension can _always_ connect in a non-production environment. | ||
* | ||
* The default value is `false`. |
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.
Perhaps I'm being a bit overly detailed here, but the default value looks to be inferred on whether we are in a browser environment in development mode. Should this be a bit closer to actual, or leave it as false here? Also, should this be a @defaultValue
?
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.
Also, should this be a @DefaultValue
I believe not, since this is an interface and not a function parameter.
Perhaps I'm being a bit overly detailed here, but the default value looks to be inferred on whether we are in a browser environment in development mode.
Good point, I believe the whole long description here was wrong, with statements that it would always be allowed in Dev, even if this were false. Adjusted.
removeComments
removeComments
, add docmodel, inheritDoc processing
I just noticed this on accident - apparently we have been stripping all our comments, which also removed DocBlocks and left our users without documentation in their IDE, even if we had written it for them.
This also means that none of our
@deprecated
annotations ever had a chance to reach our usersIf you look at the Build Output Comparison, a few things come to mind:
.js
files now also preserve comments - including non-docblock comments. Without an additional build step, there's no way around that..cjs
files have a few different line breaks. I couldn't find a tool that would remove comments in the exact same way..d.ts
files now have docblocks. That's what we want.Please review, but don't merge yet.
This also needs a review over in apollographql/docs#588
Checklist: