From b203c7dcb2de0bd1db243dcef86b2e3ef80889ed Mon Sep 17 00:00:00 2001 From: "Ayaan B. Bordoloi" Date: Mon, 30 Oct 2023 16:02:50 +0530 Subject: [PATCH] fix-typo (#1551) --- web/docs/advanced/web-sockets.md | 2 +- web/docs/introduction/what-is-wasp.md | 2 +- web/docs/language/features.md | 8 ++++---- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/web/docs/advanced/web-sockets.md b/web/docs/advanced/web-sockets.md index 6812c1fdf..ac3f3b605 100644 --- a/web/docs/advanced/web-sockets.md +++ b/web/docs/advanced/web-sockets.md @@ -222,7 +222,7 @@ export const ChatPage = () => { Wasp's **full-stack type safety** kicks in here: all the event types and payloads are automatically inferred from the server and are available on the client 🔥 -You can additonally use the `ClientToServerPayload` and `ServerToClientPayload` helper types to get the payload type for a specific event. +You can additionally use the `ClientToServerPayload` and `ServerToClientPayload` helper types to get the payload type for a specific event. ```tsx title=src/client/ChatPage.tsx import React, { useState } from 'react' diff --git a/web/docs/introduction/what-is-wasp.md b/web/docs/introduction/what-is-wasp.md index ed79417b7..542dcaf27 100644 --- a/web/docs/introduction/what-is-wasp.md +++ b/web/docs/introduction/what-is-wasp.md @@ -52,7 +52,7 @@ Let's say you want to build a web app that allows users to **create and share th Let's start with the main.wasp file: it is the central file of your app, where you describe the app from the high level. -Let's give our app a title and let's immediatelly turn on the full-stack authentication via username and password: +Let's give our app a title and let's immediately turn on the full-stack authentication via username and password: ```wasp title="main.wasp" app RecipeApp { title: "My Recipes", diff --git a/web/docs/language/features.md b/web/docs/language/features.md index ae23dc066..43a2046cc 100644 --- a/web/docs/language/features.md +++ b/web/docs/language/features.md @@ -198,7 +198,7 @@ on top of it. The workflow is as follows: 1. Wasp developer creates/updates some of the entities in `.wasp` file. 2. Wasp developer runs `wasp db migrate-dev`. -3. Migration data is generated in `migrations/` folder (and should be commited). +3. Migration data is generated in `migrations/` folder (and should be committed). 4. Wasp developer uses Prisma JS API to work with the database when in Operations. #### Using Entities in Operations @@ -584,7 +584,7 @@ In practice, this means that Wasp keeps the queries "fresh" without requiring yo On the other hand, this kind of automatic cache invalidation can become wasteful (some updates might not be necessary) and will only work for Entities. If that's an issue, you can use the mechanisms provided by _react-query_ for now, and expect more direct support in Wasp for handling those use cases in a nice, elegant way. -If you wish to optimistically set cache values after perfomring an action, you can do so using [optimistic updates](https://stackoverflow.com/a/33009713). Configure them using Wasp's [useAction hook](#the-useaction-hook). This is currently the only manual cache invalidation mechanism Wasps supports natively. For everything else, you can always rely on _react-query_. +If you wish to optimistically set cache values after performing an action, you can do so using [optimistic updates](https://stackoverflow.com/a/33009713). Configure them using Wasp's [useAction hook](#the-useaction-hook). This is currently the only manual cache invalidation mechanism Wasps supports natively. For everything else, you can always rely on _react-query_. ### Prisma Error Helpers In your Operations, you may wish to handle general Prisma errors with HTTP-friendly responses. We have exposed two helper functions, `isPrismaError`, and `prismaErrorToHttpError`, for this purpose. As of now, we convert two specific Prisma errors (which we will continue to expand), with the rest being `500`. See the [source here](https://github.com/wasp-lang/wasp/blob/main/waspc/e2e-test/test-outputs/waspMigrate-golden/waspMigrate/.wasp/out/server/src/utils.js). @@ -1622,7 +1622,7 @@ When using Social Login Providers, Wasp gives you the following options: When a user signs in for the first time, if the `userEntity` has `username` and/or `password` fields Wasp assigns generated values to those fields by default (e.g. `username: nice-blue-horse-14357` and a strong random `password`). This is a historical coupling between auth methods that will be removed over time. If you'd like to change this behavior, these values can be overridden as described below. :::tip Overriding Defaults -It is also posslbe to [override the default](features#overrides-for-social-login-providers) login behaviors that Wasp provides for you. This allows you to create custom setups, such as allowing Users to define a username rather than the default random username assigned by Wasp on initial Login. +It is also possible to [override the default](features#overrides-for-social-login-providers) login behaviors that Wasp provides for you. This allows you to create custom setups, such as allowing Users to define a username rather than the default random username assigned by Wasp on initial Login. ::: #### `externalAuthEntity` @@ -2162,7 +2162,7 @@ Since environmental variables are usually different for server-side and client a `.env.server` and `.env.client` files have to be defined in the root of your Wasp project. -`.env.server` and `.env.client` files should not be commited to the version control - we already ignore it by default in the .gitignore file we generate when you create a new Wasp project via `wasp new` cli command. +`.env.server` and `.env.client` files should not be committed to the version control - we already ignore it by default in the .gitignore file we generate when you create a new Wasp project via `wasp new` cli command. Variables are defined in `.env.server` or `.env.client` files in the form of `NAME=VALUE`, for example: ```