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

Rework fragment docs #12155

Merged
merged 35 commits into from
Nov 26, 2024
Merged

Rework fragment docs #12155

merged 35 commits into from
Nov 26, 2024

Conversation

jerelmiller
Copy link
Member

This PR does not yet contain docs on data masking, however this does make some tweaks to the existing fragments doc to make fragment colocation more prevalent and recommended. This should setup the data masking sections nicely.

@jerelmiller jerelmiller requested a review from a team as a code owner November 21, 2024 19:51
@svc-apollo-docs
Copy link

svc-apollo-docs commented Nov 21, 2024

✅ Docs Preview Ready

No new or changed pages found.

Copy link

changeset-bot bot commented Nov 21, 2024

⚠️ No Changeset found

Latest commit: db866e2

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.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

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

Copy link

pkg-pr-new bot commented Nov 21, 2024

npm i https://pkg.pr.new/@apollo/client@12155

commit: db866e2

Copy link
Contributor

github-actions bot commented Nov 21, 2024

size-limit report 📦

Path Size
dist/apollo-client.min.cjs 40.64 KB (0%)
import { ApolloClient, InMemoryCache, HttpLink } from "dist/main.cjs" 50.8 KB (0%)
import { ApolloClient, InMemoryCache, HttpLink } from "dist/main.cjs" (production) 47.68 KB (0%)
import { ApolloClient, InMemoryCache, HttpLink } from "dist/index.js" 36.15 KB (0%)
import { ApolloClient, InMemoryCache, HttpLink } from "dist/index.js" (production) 33.56 KB (0%)
import { ApolloProvider } from "dist/react/index.js" 1.26 KB (0%)
import { ApolloProvider } from "dist/react/index.js" (production) 1.24 KB (0%)
import { useQuery } from "dist/react/index.js" 5.21 KB (0%)
import { useQuery } from "dist/react/index.js" (production) 4.3 KB (0%)
import { useLazyQuery } from "dist/react/index.js" 5.71 KB (0%)
import { useLazyQuery } from "dist/react/index.js" (production) 4.78 KB (0%)
import { useMutation } from "dist/react/index.js" 3.62 KB (0%)
import { useMutation } from "dist/react/index.js" (production) 2.85 KB (0%)
import { useSubscription } from "dist/react/index.js" 4.43 KB (0%)
import { useSubscription } from "dist/react/index.js" (production) 3.48 KB (0%)
import { useSuspenseQuery } from "dist/react/index.js" 5.51 KB (0%)
import { useSuspenseQuery } from "dist/react/index.js" (production) 4.17 KB (0%)
import { useBackgroundQuery } from "dist/react/index.js" 5.01 KB (0%)
import { useBackgroundQuery } from "dist/react/index.js" (production) 3.66 KB (0%)
import { useLoadableQuery } from "dist/react/index.js" 5.09 KB (0%)
import { useLoadableQuery } from "dist/react/index.js" (production) 3.74 KB (0%)
import { useReadQuery } from "dist/react/index.js" 3.42 KB (0%)
import { useReadQuery } from "dist/react/index.js" (production) 3.36 KB (0%)
import { useFragment } from "dist/react/index.js" 2.37 KB (0%)
import { useFragment } from "dist/react/index.js" (production) 2.31 KB (0%)

Copy link

netlify bot commented Nov 21, 2024

Deploy Preview for apollo-client-docs ready!

Name Link
🔨 Latest commit 8a8b633
🔍 Latest deploy log https://app.netlify.com/sites/apollo-client-docs/deploys/673f8f2a3e0fe50008a990e1
😎 Deploy Preview https://deploy-preview-12155--apollo-client-docs.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Copy link

netlify bot commented Nov 21, 2024

Deploy Preview for apollo-client-docs ready!

Name Link
🔨 Latest commit cc777a5
🔍 Latest deploy log https://app.netlify.com/sites/apollo-client-docs/deploys/6744e261547c8e0008045970
😎 Deploy Preview https://deploy-preview-12155--apollo-client-docs.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@@ -45,15 +45,15 @@ If we later _change_ which fields are included in the `NameParts` fragment, we a

## Example usage
Copy link
Member Author

Choose a reason for hiding this comment

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

I made these changes here to try and move away from the notion that fragments should only be used as a DRY tool and instead should be combined with components. While it can be used for DRY, the composition unit should be the component itself rather than the fragment.

@jerelmiller jerelmiller force-pushed the jerel/rework-fragment-docs branch from f208671 to 4506df8 Compare November 21, 2024 20:53
```

After you define a fragment in a child component, the _parent_ component can refer to it in its _own_ colocated fragments, like so:

```js title="FeedEntry.jsx"
FeedEntry.fragments = {
Copy link
Member Author

Choose a reason for hiding this comment

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

I'm making a bold choice and moving away from this .fragments pattern that we've had in our docs for so long for a couple reasons:

  • Exports are fairly typical
  • Some React component TypeScript types (i.e. React.FC or forwardRef) complain when you try and add static properties on them. This avoids that issue.
  • Data masking will require these fragments to be used with useFragment. Its much more natural to use a variable than the static property:
useFragment({
  fragment: FeedEntryFragment
})

// vs

useFragment({
  fragment: FeedEntry.fragments.entry,
})

import { gql } from '@apollo/client';

export const CORE_COMMENT_FIELDS = gql`
fragment CoreCommentFields on Comment {
export const COMMENT_FRAGMENT = gql`
Copy link
Member Author

Choose a reason for hiding this comment

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

I'm noticing some of our examples use screaming snake case for variables that are assigned fragments, but others use PascalCase. Should we standardize in our docs?

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 for being consistent with style, no opinion on which one is better

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 on agreeing on a convention and not having a preference.

LMK what you decide on and I can add it to our style guide!

Copy link
Member Author

Choose a reason for hiding this comment

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

I went ahead and settled for SCREAMING_SNAKE_CASE in this doc, specifically to avoid a conflicting name with a TypeScript type of the same name.

For example,

import type { CommentFragment } from './path/to/gql/types.ts';

// Oops we have a conflicting name with the imported type!
const CommentFragment = gql`
  fragment CommentFragment on Comment {
    # ...
  }
`

This allows us to reuse the "comment fragment" name without the conflict and avoids the need to get creative either by aliasing the import or coming up with a new convention on the variable name itself.

Hope this clarifies it!


Starting in Apollo Client 3.7, fragments can be registered with your `InMemoryCache` so that they can be referred to by name in any query or `InMemoryCache` operation (such as `cache.readFragment`, `cache.readQuery` and `cache.watch`) without needing to interpolate their declarations.
Starting in Apollo Client 3.7, fragments can be registered with your `InMemoryCache` instance so that they can be referred to by name in any query or `InMemoryCache` operation (such as `cache.readFragment`, `cache.readQuery` and `cache.watch`) without needing to interpolate their declarations.
Copy link
Member Author

Choose a reason for hiding this comment

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

Since I've added the MinVersion tag, do we need to keep "Starting in Apollo Client 3.7" or should I get rid of it?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we can get rid of it 🔪


Consider the following view hierarchy for an app:

```
FeedPage
└── Feed
Copy link
Member Author

Choose a reason for hiding this comment

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

I got rid of this intermediate Feed component in the example because its not mentioned anywhere and I wanted to add the note about fragments only being used by their parent.

Copy link
Contributor

@bignimbus bignimbus left a comment

Choose a reason for hiding this comment

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

LGTM - added a few thoughts and a suggestion!

import { gql } from '@apollo/client';

export const CORE_COMMENT_FIELDS = gql`
fragment CoreCommentFields on Comment {
export const COMMENT_FRAGMENT = gql`
Copy link
Contributor

Choose a reason for hiding this comment

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

+1 for being consistent with style, no opinion on which one is better


Starting in Apollo Client 3.7, fragments can be registered with your `InMemoryCache` so that they can be referred to by name in any query or `InMemoryCache` operation (such as `cache.readFragment`, `cache.readQuery` and `cache.watch`) without needing to interpolate their declarations.
Starting in Apollo Client 3.7, fragments can be registered with your `InMemoryCache` instance so that they can be referred to by name in any query or `InMemoryCache` operation (such as `cache.readFragment`, `cache.readQuery` and `cache.watch`) without needing to interpolate their declarations.
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we can get rid of it 🔪

docs/source/data/fragments.mdx Show resolved Hide resolved
@jerelmiller jerelmiller force-pushed the jerel/rework-fragment-docs branch from cc777a5 to b36dd77 Compare November 25, 2024 22:42
Copy link
Contributor

@Meschreiber Meschreiber left a comment

Choose a reason for hiding this comment

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

Just some suggestions for clarity! I dig bumping up the colocation bit (which was the part I focused on when reviewing.)

Tomorrow I'll make sure that the mermaid diagram can render!

import { gql } from '@apollo/client';

export const CORE_COMMENT_FIELDS = gql`
fragment CoreCommentFields on Comment {
export const COMMENT_FRAGMENT = gql`
Copy link
Contributor

Choose a reason for hiding this comment

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

+1 on agreeing on a convention and not having a preference.

LMK what you decide on and I can add it to our style guide!

docs/source/data/fragments.mdx Outdated Show resolved Hide resolved
docs/source/data/fragments.mdx Outdated Show resolved Hide resolved
docs/source/data/fragments.mdx Outdated Show resolved Hide resolved
docs/source/data/fragments.mdx Outdated Show resolved Hide resolved
docs/source/data/fragments.mdx Outdated Show resolved Hide resolved
docs/source/data/fragments.mdx Outdated Show resolved Hide resolved
docs/source/data/fragments.mdx Outdated Show resolved Hide resolved
docs/source/data/fragments.mdx Show resolved Hide resolved
docs/source/data/fragments.mdx Outdated Show resolved Hide resolved
@github-actions github-actions bot added the auto-cleanup 🤖 label Nov 26, 2024
@jerelmiller jerelmiller merged commit f2c75dd into release-3.12 Nov 26, 2024
42 of 46 checks passed
@jerelmiller jerelmiller deleted the jerel/rework-fragment-docs branch November 26, 2024 16:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants