From 149ccfefa885d7cd8f1c0679efc2eb07703a025f Mon Sep 17 00:00:00 2001 From: David McAfee Date: Mon, 20 Feb 2023 21:20:44 -0800 Subject: [PATCH] fix(data): fix broken DataStore code snippet; fix spelling and grammatical errors --- .../datastore/ios/sync/50-selectiveSync.mdx | 8 ++++---- .../datastore/native_common/setup-env-cli.mdx | 2 +- .../lib-v1/datastore/native_common/sync.mdx | 6 +++--- .../flutter/relational/save-many-snippet.mdx | 2 +- .../js/data-access/observe-update-snippet.mdx | 5 +++-- src/fragments/lib/datastore/js/examples.mdx | 2 +- .../datastore/js/real-time/observe-snippet.mdx | 2 +- .../js/relational/query-many-snippet.mdx | 14 +++++++------- .../lib/datastore/js/sync/50-selectiveSync.mdx | 4 ++-- .../datastore/native_common/setup-auth-rules.mdx | 16 ++++++++-------- .../datastore/native_common/setup-env-cli.mdx | 2 +- .../lib/datastore/native_common/sync.mdx | 6 +++--- 12 files changed, 35 insertions(+), 34 deletions(-) diff --git a/src/fragments/lib-v1/datastore/ios/sync/50-selectiveSync.mdx b/src/fragments/lib-v1/datastore/ios/sync/50-selectiveSync.mdx index 7d02e28662d..712b7e55452 100644 --- a/src/fragments/lib-v1/datastore/ios/sync/50-selectiveSync.mdx +++ b/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 -### 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. diff --git a/src/fragments/lib-v1/datastore/native_common/setup-env-cli.mdx b/src/fragments/lib-v1/datastore/native_common/setup-env-cli.mdx index 6017fd86c84..6888a749711 100644 --- a/src/fragments/lib-v1/datastore/native_common/setup-env-cli.mdx +++ b/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: diff --git a/src/fragments/lib-v1/datastore/native_common/sync.mdx b/src/fragments/lib-v1/datastore/native_common/sync.mdx index ff5ff4ddd4b..a3adf34977b 100644 --- a/src/fragments/lib-v1/datastore/native_common/sync.mdx +++ b/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/). -**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. diff --git a/src/fragments/lib/datastore/flutter/relational/save-many-snippet.mdx b/src/fragments/lib/datastore/flutter/relational/save-many-snippet.mdx index c0df5ccb68e..4e6cfccbd62 100644 --- a/src/fragments/lib/datastore/flutter/relational/save-many-snippet.mdx +++ b/src/fragments/lib/datastore/flutter/relational/save-many-snippet.mdx @@ -18,7 +18,7 @@ Future 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!'); } diff --git a/src/fragments/lib/datastore/js/data-access/observe-update-snippet.mdx b/src/fragments/lib/datastore/js/data-access/observe-update-snippet.mdx index dfe018ba27c..168ffedaed4 100644 --- a/src/fragments/lib/datastore/js/data-access/observe-update-snippet.mdx +++ b/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,7 +44,7 @@ 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"); @@ -52,4 +52,5 @@ function App() { /> ); +} ``` \ No newline at end of file diff --git a/src/fragments/lib/datastore/js/examples.mdx b/src/fragments/lib/datastore/js/examples.mdx index 22d19b9b059..c145a81aa8e 100644 --- a/src/fragments/lib/datastore/js/examples.mdx +++ b/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); diff --git a/src/fragments/lib/datastore/js/real-time/observe-snippet.mdx b/src/fragments/lib/datastore/js/real-time/observe-snippet.mdx index 307edf64990..752ccf9baec 100644 --- a/src/fragments/lib/datastore/js/real-time/observe-snippet.mdx +++ b/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 => { diff --git a/src/fragments/lib/datastore/js/relational/query-many-snippet.mdx b/src/fragments/lib/datastore/js/relational/query-many-snippet.mdx index 772528b4aea..0df0e51b2e4 100644 --- a/src/fragments/lib/datastore/js/relational/query-many-snippet.mdx +++ b/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,7 +26,7 @@ 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 @@ -34,7 +34,7 @@ const editors = await DataStore.query(User, u => u.posts.post.id.eq(post.id)) 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`. @@ -42,7 +42,7 @@ Both the `Post` and the `User` instances will not be deleted. Only the join mode 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. diff --git a/src/fragments/lib/datastore/js/sync/50-selectiveSync.mdx b/src/fragments/lib/datastore/js/sync/50-selectiveSync.mdx index 0b00e49a29e..baeca37fb30 100644 --- a/src/fragments/lib/datastore/js/sync/50-selectiveSync.mdx +++ b/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. diff --git a/src/fragments/lib/datastore/native_common/setup-auth-rules.mdx b/src/fragments/lib/datastore/native_common/setup-auth-rules.mdx index 4b52602b043..98f8afb8963 100644 --- a/src/fragments/lib/datastore/native_common/setup-auth-rules.mdx +++ b/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. diff --git a/src/fragments/lib/datastore/native_common/setup-env-cli.mdx b/src/fragments/lib/datastore/native_common/setup-env-cli.mdx index 6017fd86c84..6888a749711 100644 --- a/src/fragments/lib/datastore/native_common/setup-env-cli.mdx +++ b/src/fragments/lib/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: diff --git a/src/fragments/lib/datastore/native_common/sync.mdx b/src/fragments/lib/datastore/native_common/sync.mdx index eb99183d56f..ef590bc81d3 100644 --- a/src/fragments/lib/datastore/native_common/sync.mdx +++ b/src/fragments/lib/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/). -**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.