[docs] fix markdown issue in fragments.md

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: ``*<fragment_name>*``$key``, and a type for the shape of the data, which is the type with the `$data` suffix:  ``*<fragment_name>*``$data``; these types are available to import from files that are generated with the following name: `*<fragment_name>*.graphql.js`.
+    * The generated Flow types include a type for the fragment reference, which is the type with the `$key` suffix: `*<fragment_name>*$key`, and a type for the shape of the data, which is the type with the `$data` suffix:  `*<fragment_name>*$data`; these types are available to import from files that are generated with the following name: `*<fragment_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: `*<module_name>*_*<property_name>*`. 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.

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: ``*<fragment_name>*``$key``, and a type for the shape of the data, which is the type with the `$data` suffix:  ``*<fragment_name>*``$data``; these types are available to import from files that are generated with the following name: `*<fragment_name>*.graphql.js`.
+    * The generated Flow types include a type for the fragment reference, which is the type with the `$key` suffix: `*<fragment_name>*$key`, and a type for the shape of the data, which is the type with the `$data` suffix:  `*<fragment_name>*$data`; these types are available to import from files that are generated with the following name: `*<fragment_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: `*<module_name>*_*<property_name>*`. 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.