From 9486dcbed7e43575cbde1f4e53e8446913083e27 Mon Sep 17 00:00:00 2001 From: Lucas Weng Date: Sun, 14 Mar 2021 11:15:16 +0800 Subject: [PATCH] [docs] fix markdown issue in fragments.md --- website/docs/guided-tour/rendering/fragments.md | 2 +- .../version-v11.0.0/guided-tour/rendering/fragments.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/website/docs/guided-tour/rendering/fragments.md b/website/docs/guided-tour/rendering/fragments.md index aae9ad38301b3..81457e55b7283 100644 --- a/website/docs/guided-tour/rendering/fragments.md +++ b/website/docs/guided-tour/rendering/fragments.md @@ -85,7 +85,7 @@ Let's distill what's going on here: * A *fragment reference* is an object that Relay uses to *read* the data declared in the fragment definition; as you can see, the `UserComponent_user` fragment itself just declares fields on the `User` type, but we need to know *which* specific user to read those fields from; this is what the fragment reference corresponds to. In other words, a fragment reference ** is like *a pointer to a specific instance of a type* that we want to read data from. * Note that *the component is automatically subscribed to updates to the fragment data*: if the data for this particular `User` is updated anywhere in the app (e.g. via fetching new data, or mutating existing data), the component will automatically re-render with the latest updated data. * Relay ** will automatically generate Flow types for any declared fragments when the compiler is run, so you can use these types to declare the type for your Component's `props`. - * The generated Flow types include a type for the fragment reference, which is the type with the `$key` suffix: ``**``$key``, and a type for the shape of the data, which is the type with the `$data` suffix: ``**``$data``; these types are available to import from files that are generated with the following name: `**.graphql.js`. + * The generated Flow types include a type for the fragment reference, which is the type with the `$key` suffix: `**$key`, and a type for the shape of the data, which is the type with the `$data` suffix: `**$data`; these types are available to import from files that are generated with the following name: `**.graphql.js`. * We use our [lint rule](https://github.com/relayjs/eslint-plugin-relay) to enforce that the type of the fragment reference prop is correctly declared when using `useFragment`. By using a properly typed fragment reference as input, the type of the returned `data` will automatically be Flow typed without requiring an explicit annotation. * In our example, we're typing the `user` prop as the fragment reference we need for `useFragment`, which corresponds to the `UserComponent_user$key` imported from `UserComponent_user.graphql`, which means that the type of `data` above would be: `{ name: ?string, profile_picture: ?{ uri: ?string } }`. * Fragment names need to be globally unique. In order to easily achieve this, we name fragments using the following convention based on the module name followed by an identifier: `**_**`. This makes it easy to identify which fragments are defined in which modules and avoids name collisions when multiple fragments are defined in the same module. diff --git a/website/versioned_docs/version-v11.0.0/guided-tour/rendering/fragments.md b/website/versioned_docs/version-v11.0.0/guided-tour/rendering/fragments.md index aae9ad38301b3..81457e55b7283 100644 --- a/website/versioned_docs/version-v11.0.0/guided-tour/rendering/fragments.md +++ b/website/versioned_docs/version-v11.0.0/guided-tour/rendering/fragments.md @@ -85,7 +85,7 @@ Let's distill what's going on here: * A *fragment reference* is an object that Relay uses to *read* the data declared in the fragment definition; as you can see, the `UserComponent_user` fragment itself just declares fields on the `User` type, but we need to know *which* specific user to read those fields from; this is what the fragment reference corresponds to. In other words, a fragment reference ** is like *a pointer to a specific instance of a type* that we want to read data from. * Note that *the component is automatically subscribed to updates to the fragment data*: if the data for this particular `User` is updated anywhere in the app (e.g. via fetching new data, or mutating existing data), the component will automatically re-render with the latest updated data. * Relay ** will automatically generate Flow types for any declared fragments when the compiler is run, so you can use these types to declare the type for your Component's `props`. - * The generated Flow types include a type for the fragment reference, which is the type with the `$key` suffix: ``**``$key``, and a type for the shape of the data, which is the type with the `$data` suffix: ``**``$data``; these types are available to import from files that are generated with the following name: `**.graphql.js`. + * The generated Flow types include a type for the fragment reference, which is the type with the `$key` suffix: `**$key`, and a type for the shape of the data, which is the type with the `$data` suffix: `**$data`; these types are available to import from files that are generated with the following name: `**.graphql.js`. * We use our [lint rule](https://github.com/relayjs/eslint-plugin-relay) to enforce that the type of the fragment reference prop is correctly declared when using `useFragment`. By using a properly typed fragment reference as input, the type of the returned `data` will automatically be Flow typed without requiring an explicit annotation. * In our example, we're typing the `user` prop as the fragment reference we need for `useFragment`, which corresponds to the `UserComponent_user$key` imported from `UserComponent_user.graphql`, which means that the type of `data` above would be: `{ name: ?string, profile_picture: ?{ uri: ?string } }`. * Fragment names need to be globally unique. In order to easily achieve this, we name fragments using the following convention based on the module name followed by an identifier: `**_**`. This makes it easy to identify which fragments are defined in which modules and avoids name collisions when multiple fragments are defined in the same module.