From 01f0f84f93f3fdbfb869a4ef17634ec6d55fe094 Mon Sep 17 00:00:00 2001 From: Tim Gates Date: Sun, 5 Mar 2023 13:30:38 +1100 Subject: [PATCH] docs: Fix a few typos There are small typos in: - packages/api-plugin-authorization-simple/README.md - packages/api-plugin-products/README.md - packages/api-plugin-sample-data/README.md Fixes: - Should read `published` rather than `publshed`. - Should read `parameters` rather than `parametes`. - Should read `beginning` rather than `begining`. - Should read `available` rather than `avaialble`. Signed-off-by: Tim Gates --- packages/api-plugin-authorization-simple/README.md | 2 +- packages/api-plugin-products/README.md | 2 +- packages/api-plugin-sample-data/README.md | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/packages/api-plugin-authorization-simple/README.md b/packages/api-plugin-authorization-simple/README.md index 337b519be86..68266c2e874 100644 --- a/packages/api-plugin-authorization-simple/README.md +++ b/packages/api-plugin-authorization-simple/README.md @@ -47,7 +47,7 @@ The action the user would like to preform. This can be anything, but we recommen Context is used to pass any extra information to the permissions check. We use it primarily for two things at this time: -1. We pass `shopId` in the context (somtimes referred to as `ketoContext`) everywhere it's avaialble +1. We pass `shopId` in the context (somtimes referred to as `ketoContext`) everywhere it's available 1. We pass `owner` into the context anywhere where a regular, non-admin user is allowed permissions to something they themselves own. For example, on an order they placed, they will have `owner` permissions on that particular order. ## Under the hood diff --git a/packages/api-plugin-products/README.md b/packages/api-plugin-products/README.md index c8c9bc30559..abd996ee42b 100644 --- a/packages/api-plugin-products/README.md +++ b/packages/api-plugin-products/README.md @@ -16,7 +16,7 @@ The `generateFilterQuery` function expects the input GraphQL conditions object t Please go through a general introduction of how to use this function which can be found in the [api-utils README](https://github.com/reactioncommerce/reaction/tree/trunk/packages/api-utils/docs) before going through the examples below on how to use this function in the context of the `products` plugin. -In the query endpoint, we pass the `FilterConditionsInput` input type object as the `conditions` argument. This object is passed to the `generateFilterQuery` function along with other parameters like `context`, `collectionName` and `shopId` to generate the MongoDB filter query. The `generateFilterQuery` function is generic and can be used to generate filter queries for any collection. Since the parametes like `context`, `collectionName` and `shopId` are pretty self-explanatory, we shall focus on explaining the various ways in which the `conditions` object can be used. +In the query endpoint, we pass the `FilterConditionsInput` input type object as the `conditions` argument. This object is passed to the `generateFilterQuery` function along with other parameters like `context`, `collectionName` and `shopId` to generate the MongoDB filter query. The `generateFilterQuery` function is generic and can be used to generate filter queries for any collection. Since the parameters like `context`, `collectionName` and `shopId` are pretty self-explanatory, we shall focus on explaining the various ways in which the `conditions` object can be used. 1. Single condition. Here we are querying products collection for entries with the handle as 'mens-waterproof-outdoor-rain-jacket'. Since it is single condition, using either `all` or `any` will not make difference. diff --git a/packages/api-plugin-sample-data/README.md b/packages/api-plugin-sample-data/README.md index 3f7911e11e9..9c999214eb3 100644 --- a/packages/api-plugin-sample-data/README.md +++ b/packages/api-plugin-sample-data/README.md @@ -358,7 +358,7 @@ The above steps translate to the below code (for reference) ``` Inside `/src/loaders/loadNavigation.js` we can see how this sub-level (`m1sub`) is subsequently added to the _items_ array which in turn is added to the top-level of Navigation. -The navigation changes are publshed via the _publishNavigationChanges_ mutation and the Shops collection is updated with the _navigationTreeId_. +The navigation changes are published via the _publishNavigationChanges_ mutation and the Shops collection is updated with the _navigationTreeId_. ##### 5. Adding Images to the product @@ -366,7 +366,7 @@ We could add one (or more) images for each of the leaf-level entries mentioned i To explain with an example, we have 'Jackets' as top-level product, variants as 'Black'/'Blue' and leaf-level entries as Small/Medium/Large. So in effect, we will have the same set of images for all the sizes (small/medium/large) under each Color. -Once we have identified the productID (_id) of the variant entries, we just need to update the file-name to include the productId at the begining of the file-name followed by a period '.'. So the specific format of the image would be `productID..`. Allowed image file extensions are jpg/jpeg/png. Once the image with the updated file-name is ready, we just need to place the file in the `/src/images` folder. +Once we have identified the productID (_id) of the variant entries, we just need to update the file-name to include the productId at the beginning of the file-name followed by a period '.'. So the specific format of the image would be `productID..`. Allowed image file extensions are jpg/jpeg/png. Once the image with the updated file-name is ready, we just need to place the file in the `/src/images` folder. Note: We have hard-coded the path to the images folder inside `/src/loaders/loadImages.js` as follows ` let folderPath = "./custom-packages/api-plugin-sample-data/src/images/"` By default, when a new plugin is added, the above mentioned path would be correct, but in case we have the plugin folder under a different name, we need to make sure that the above folderPath is updated to match the actual location.