fix(data): fix broken DataStore code snippet; fix spelling and grammatical errors (#5140)

Author: david-mcafee

src/fragments/lib-v1/datastore/ios/sync/50-selectiveSync.mdx

@@ -27,9 +27,9 @@ Developers should only specify a single `syncExpression` per model. Any subseque
 
 </Callout>
 
-### Reevaluate expressions at runtime
+### Re-evaluate expressions at runtime
 Sync expressions get evaluated whenever DataStore starts.
-In order to have your expressions reevaluated, you can execute `Amplify.DataStore.clear()` or `Amplify.DataStore.stop()` followed by `Amplify.DataStore.start()`.
+In order to have your expressions re-evaluated, you can execute `Amplify.DataStore.clear()` or `Amplify.DataStore.stop()` followed by `Amplify.DataStore.start()`.
 
 If you have the following expression and you want to change the filter that gets applied at runtime, you can do the following:
 
@@ -64,7 +64,7 @@ func changeSync() {
     }      
 }
 ```
-Each time DataStore starts (via `start` or any other operation: `query`, `save`, `delete`, or `observe`), DataStore will reevaluate the `syncExpressions`.
+Each time DataStore starts (via `start` or any other operation: `query`, `save`, `delete`, or `observe`), DataStore will re-evaluate the `syncExpressions`.
 
 In the above case, the predicate will contain the value `1`, so all Posts with `rating > 1` will get synced down.
 
@@ -96,7 +96,7 @@ func changeSync() {
     }    
 ```
 
-This will clear the contents of your local store, reevaluate your sync expressions and re-sync the data from the cloud, applying all of the specified predicates to the sync queries.
+This will clear the contents of your local store, re-evaluate your sync expressions and re-sync the data from the cloud, applying all of the specified predicates to the sync queries.
 
 You can also have your sync expression return `QueryPredicateConstant.all` in order to remove any filtering for that model. This will have the same effect as the default sync behavior.
 

src/fragments/lib-v1/datastore/native_common/setup-env-cli.mdx

@@ -13,7 +13,7 @@ amplify add api
 amplify update api
 ```
 
-The CLI will prompt you to configure your API. Select **GraphQL** as the API type and reply to the questions as shown below. Conflict detection is **required** when using the DataStore to sync data with the cloud.
+The CLI will prompt you to configure your API. Select **GraphQL** as the API type and reply to the questions as shown below. Conflict detection is **required** when using DataStore to sync data with the cloud.
 
 ```console
 ? Please select from one of the below mentioned services:

src/fragments/lib-v1/datastore/native_common/sync.mdx

@@ -9,13 +9,13 @@ Once you're happy with your application, you can start syncing with the cloud by
 
 ## Setup cloud sync
 
-Synchronization between offline and online data can be tricky. DataStore goal is to remove that burden from the application code and handle all data consistency and reconciliation between local and remote behind the scenes, while developers focus on their application logic. Up to this point the focus was to setup a local datastore that works offline and has all the capabilities you would expect from a data persistence framework.
+Synchronization between offline and online data can be tricky. DataStore's goal is to remove that burden from the application code and handle all data consistency and reconciliation between local and remote behind the scenes, while developers focus on their application logic. Up to this point the focus was to setup a local data store that works offline and has all the capabilities you would expect from a data persistence framework.
 
-The next step is to make sure the local saved data is synchronized with a cloud backend powered by [AWS AppSync](https://aws.amazon.com/appsync/).
+The next step is to make sure the locally saved data is synchronized with a cloud backend powered by [AWS AppSync](https://aws.amazon.com/appsync/).
 
 <Callout>
 
-**Note:** Syncing data between the cloud and the local device starts automatically whenever you run any DataStore operation after your app is setup.
+**Note:** Syncing data between the cloud and the local device starts automatically whenever you run any DataStore operation after your app is set up.
 
 </Callout>
 

src/fragments/lib/datastore/flutter/relational/save-many-snippet.mdx

@@ -18,7 +18,7 @@ Future<void> savePostAndEditor() async {
   // secondly, you save the editor/user
   await Amplify.DataStore.save(editor);
 
-  // then you save the mode that links a post with an editor
+  // then you save the model that links a post with an editor
   await Amplify.DataStore.save(postEditor);
   print('Saved user, post and postEditor!');
 }

src/fragments/lib/datastore/js/data-access/observe-update-snippet.mdx

@@ -30,7 +30,7 @@ function App() {
         value={post?.title ?? ""}
         onChange={({ target: { value } }) => {
           /**
-           * Each keypress updates the post in local react state.
+           * Each keypress updates the post in local React state.
            */
           setPost(
             Post.copyOf(post!, (draft) => {
@@ -44,12 +44,13 @@ function App() {
         value="Save"
         onClick={async () => {
           /**
-           * This post is already up to date because observeQuery updated it.
+           * This post is already up-to-date because `observeQuery` updated it.
            */
           await DataStore.save(post!);
           console.log("Post saved");
         }}
       />
     </>
   );
+}
 ```

src/fragments/lib/datastore/js/examples.mdx

@@ -11,7 +11,7 @@ import "./App.css";
 import { Amplify, DataStore, Predicates } from "aws-amplify";
 import { Post, PostStatus } from "./models";
 
-//Use next two lines only if syncing with the cloud
+// Use next two lines only if syncing with the cloud
 import awsconfig from "./aws-exports";
 Amplify.configure(awsconfig);
 

src/fragments/lib/datastore/js/real-time/observe-snippet.mdx

@@ -14,7 +14,7 @@ const subscription = DataStore.observe(Post, id).subscribe(msg => {
 });
 ```
 
-Closing a subscription
+Closing a subscription:
 
 ```js
 const subscription = DataStore.observe(Post, id).subscribe(msg => {

src/fragments/lib/datastore/js/relational/query-many-snippet.mdx

@@ -7,16 +7,16 @@ const post = await DataStore.save(new Post({
   title: 'Amplify Weekly'
   rating: 10,
   status: PostStatus.ACTIVE,
-}))
+}));
 
 const user = await DataStore.save(new User({
   username: 'rene'
-}))
+}));
 
 const postEditor = await DataStore.save(new PostEditor({
   post: post,
   user: user
-}))
+}));
 ```
 
 Here we've first created a new `Post` instance and a new `User` instance. Then, saved those instances to a new instance of our join model `PostEditor`.
@@ -26,23 +26,23 @@ Here we've first created a new `Post` instance and a new `User` instance. Then,
 To query many-to-many relationships, use a nested predicate to filter the target model by the source model's id:
 
 ```js
-const editors = await DataStore.query(User, u => u.posts.post.id.eq(post.id))
+const editors = await DataStore.query(User, u => u.posts.post.id.eq(post.id));
 ```
 
 ### Delete
 
 Deleting the join model instance will not delete any source model instances.
 
 ```js
-await DataStore.delete(toBeDeletedPostEditor)
+await DataStore.delete(toBeDeletedPostEditor);
 ```
 
 Both the `Post` and the `User` instances will not be deleted. Only the join model instances containing the link between a `Post` and a `User`.
 
 Deleting a source model instance will also delete the join model instances containing the source model instance.
 
 ```js
-await DataStore.delete(toBeDeletedUser)
+await DataStore.delete(toBeDeletedUser);
 ```
-The `toBeDeletedUser` User instance and all `PostEditor` instances where `user` is linked to `toBeDeletedUser` will be deleted.
 
+The `toBeDeletedUser` User instance and all `PostEditor` instances where `user` is linked to `toBeDeletedUser` will be deleted.

src/fragments/lib/datastore/js/sync/50-selectiveSync.mdx

@@ -51,7 +51,7 @@ async function changeSync() {
   rating = 1;
   await DataStore.stop();
   await DataStore.start();
-}
+};
 ```
 
 Upon calling `DataStore.start()` (or executing a DataStore operation, e.g., `query`, `save`, `delete`, or `observe`), DataStore will reevaluate the `syncExpressions`. 
@@ -71,7 +71,7 @@ async function changeSync() {
   rating = 8;
   await DataStore.clear();
   await DataStore.start();
-}
+};
 ```
 This will clear the contents of your local store, reevaluate your sync expressions and re-sync the data from the cloud, applying all of the specified predicates to the sync queries.
 

src/fragments/lib/datastore/native_common/setup-auth-rules.mdx

@@ -18,7 +18,7 @@ import datastoreClearCallout from '/src/fragments/lib/datastore/native_common/ca
 
 ### Per User / Owner Based Data Access
 
-The following are commonly used patterns for owner based authorization. For more information on how to tune these examples, please see the [CLI documentation on owner based authorization](/cli/graphql/authorization-rules/#per-user--owner-based-data-access).
+The following are commonly used patterns for owner based authorization. For more information on how to fine tune these examples, please see the [CLI documentation on owner based authorization](/cli/graphql/authorization-rules/#per-user--owner-based-data-access).
 
 - Create/Read/Update/Delete mutations are private to the owner.
 
@@ -45,13 +45,13 @@ type YourModel
 
 ### Static Group Authorization
 
-The following are commonly used patterns for static group authorization. For more information on how to tune these examples, please see the [CLI documentation on static group authorization](/cli/graphql/authorization-rules/#user-group-based-data-access).
+The following are commonly used patterns for static group authorization. For more information on how to fine tune these examples, please see the [CLI documentation on static group authorization](/cli/graphql/authorization-rules/#user-group-based-data-access).
 
 - Users belonging to the "Admin" group can CRUD (create, read, update, and delete), others cannot access anything.
 
 ```graphql
 type YourModel @model @auth(rules: [{ allow: groups,
-                                      groups: ["Admin"] }]) {
+  groups: ["Admin"] }]) {
   ...
 }
 ```
@@ -73,7 +73,7 @@ type YourModel
 
 ### Owner and Static Group Combined
 
-The following are commonly used patterns for combining owner and static group authorization. For more information on how to tune these examples, please see the [CLI documentation on static group authorization](/cli/graphql/authorization-rules#static-group-authorization).
+The following are commonly used patterns for combining owner and static group authorization. For more information on how to fine tune these examples, please see the [CLI documentation on static group authorization](/cli/graphql/authorization-rules#static-group-authorization).
 
 - Users have their own data, but users who belong to the `Admin` group have access to their data and anyone else in that group. Users in the `Admin` group have the ability to make mutation on behalf of users not in the `Admin` group
 
@@ -87,7 +87,7 @@ type YourModel
 
 ### Public Data Access
 
-The following are commonly used patterns to grant everyone access. For more information on how to tune these examples, please see the [CLI documentation on public data access](/cli/graphql/authorization-rules/#public-data-access).
+The following are commonly used patterns to grant everyone access. For more information on how to fine tune these examples, please see the [CLI documentation on public data access](/cli/graphql/authorization-rules/#public-data-access).
 
 - Auth provider is API Key
 
@@ -107,7 +107,7 @@ type YourModel @model @auth(rules: [{ allow: public, provider: iam }]) {
 
 ### Signed-in User Data Access
 
-The following are commonly used patterns for private authorization. For more information on how to tune these examples, please see the [CLI documentation on signed-in user data access](https://docs.amplify.aws/cli/graphql/authorization-rules/#signed-in-user-data-access).
+The following are commonly used patterns for private authorization. For more information on how to fine tune these examples, please see the [CLI documentation on signed-in user data access](https://docs.amplify.aws/cli/graphql/authorization-rules/#signed-in-user-data-access).
 
 - Cognito user pool authenticated users can CRUD all posts, regardless of who created it. Guest users do not have access.
 
@@ -127,7 +127,7 @@ type YourModel @model @auth(rules: [{ allow: private, provider: iam }]) {
 
 ### Owner based Authorization with OIDC provider
 
-The following are commonly used patterns for owner based authorization using a 3rd party OIDC provider (e.g. Facebook, Google, etc...). For more information on how to tune these examples, please see the [CLI documentation on using an oidc authorization provider](/cli/graphql/authorization-rules/#using-oidc-authorization-provider).
+The following are commonly used patterns for owner based authorization using a 3rd party OIDC provider (e.g. Facebook, Google, etc...). For more information on how to fine tune these examples, please see the [CLI documentation on using an oidc authorization provider](/cli/graphql/authorization-rules/#using-oidc-authorization-provider).
 
 - Using a 3rd party OIDC provider to achieve owner based authorization.
 
@@ -153,7 +153,7 @@ import flutterOidc from '/src/fragments/lib/datastore/flutter/setup-auth-rules/o
 
 ### Static Group Authorization with OIDC provider
 
-The following are commonly used patterns for using `groupClaims` to achieve group based authorization using a 3rd party OIDC provider. For more information on how to tune these examples, please see the [CLI documentation on static group authorization](/cli/graphql/authorization-rules#custom-claims).
+The following are commonly used patterns for using `groupClaims` to achieve group based authorization using a 3rd party OIDC provider. For more information on how to fine tune these examples, please see the [CLI documentation on static group authorization](/cli/graphql/authorization-rules#custom-claims).
 
 - Using a custom value for `groupClaim` to achieve static group authorization with a 3rd party OIDC provider.