Skip to content
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

Usage reporting: fix TS declaration of fieldLevelInstrumentation #6763

Merged
merged 1 commit into from
Aug 4, 2022

Conversation

glasser
Copy link
Member

@glasser glasser commented Aug 3, 2022

Note that the const fieldLevelInstrumentation which this got assigned
to actually already inferred (roughly) the correct type because the type
got merged with a number-returning function from another case.

@changeset-bot
Copy link

changeset-bot bot commented Aug 3, 2022

⚠️ No Changeset found

Latest commit: bd9e3f9

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@netlify
Copy link

netlify bot commented Aug 3, 2022

Deploy Preview for apollo-server-docs canceled.

Name Link
🔨 Latest commit bd9e3f9
🔍 Latest deploy log https://app.netlify.com/sites/apollo-server-docs/deploys/62eafc17b6e37c00088d8ac3

Note that the `const fieldLevelInstrumentation` which this got assigned
to actually already inferred (roughly) the correct type because the type
got merged with a number-returning function from another case.
@glasser glasser force-pushed the glasser/fix-fieldlevelinstrumentation-type branch from 8642ad0 to bd9e3f9 Compare August 3, 2022 22:52
@codesandbox-ci
Copy link

codesandbox-ci bot commented Aug 3, 2022

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit bd9e3f9:

Sandbox Source
Apollo Server Typescript Configuration
Apollo Server Configuration

Copy link
Member

@trevor-scheer trevor-scheer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should fieldLevelInstrumentation also be assignable to a boolean value? Not a blocker - same functionality can be achieved with 0 and 1 as it currently exists.

@glasser
Copy link
Member Author

glasser commented Aug 4, 2022

@trevor-scheer I think my reasoning here was: fieldLevelInstrumentation: 0.01 is not the same thing as fieldLevelInstrumentation: () => 0.01 (it's a shorthand for something more complex, and is what we expect many users to do), so having the number option makes sense. But fieldLevelInstrumentation: false would be identical to fieldLevelInstrumentation: () => false, so why provide two ways to say the same thing.

Arguably we should have only supported a function here, and exported a function like function weightedSample(x: number) { return async () => Math.random() < x ? 1/x : 0 } from the package instead, and the recommended usage would be fieldLevelInstrumentation: weightedSample(0.01). (Maybe if we had had deep imports in AS3 that would have felt better.)

Anyway this PR is just about fixing the types to match the implementation, not about changing the implementation.

@glasser glasser merged commit 6140880 into main Aug 4, 2022
@glasser glasser deleted the glasser/fix-fieldlevelinstrumentation-type branch August 4, 2022 19:08
glasser added a commit that referenced this pull request Aug 4, 2022
Usage reporting: fix TS declaration of fieldLevelInstrumentation

Note that the `const fieldLevelInstrumentation` which this got assigned
to actually already inferred (roughly) the correct type because the type
got merged with a number-returning function from another case.
glasser added a commit that referenced this pull request Aug 4, 2022
Usage reporting: fix TS declaration of fieldLevelInstrumentation

Note that the `const fieldLevelInstrumentation` which this got assigned
to actually already inferred (roughly) the correct type because the type
got merged with a number-returning function from another case.
@github-actions github-actions bot mentioned this pull request Oct 10, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants