mirror of
https://github.com/wasp-lang/wasp.git
synced 2024-12-23 17:13:40 +03:00
docs: fix various typos in documentation and comments (#2424)
This commit is contained in:
parent
017217d3a3
commit
4c2a9353d9
@ -103,7 +103,7 @@ This is the main repo of the Wasp universe, containing core code (mostly `waspc`
|
||||
|
||||
# Project status
|
||||
|
||||
Currently, Wasp is in beta, with most features flushed out and working well.
|
||||
Currently, Wasp is in beta, with most features fleshed out and working well.
|
||||
However, there are still a lot of improvements and additions that we have in mind for the future, and we are working on them constantly, so you can expect a lot of changes and improvements in the future.
|
||||
|
||||
While the idea is to support multiple web tech stacks in the future, right now, we are focusing on the specific stack: React + react-query, NodeJS + ExpressJS, and Prisma.
|
||||
|
@ -58,7 +58,7 @@ You can now write this:
|
||||
|
||||
```typescript
|
||||
|
||||
improt { App } from 'wasp-config'
|
||||
import { App } from 'wasp-config'
|
||||
|
||||
const app = new App('TodoApp', {
|
||||
wasp: {
|
||||
@ -1621,7 +1621,7 @@ Make sure to update your Wasp VSCode extension to get the benefits of Wasp Langu
|
||||
### [NEW FEATURE] Optimistic updates via useAction hook
|
||||
|
||||
We added `useAction` hook to our JS API, which allows you to specify optimistic update details for an Action.
|
||||
This means that, if you have a good idea of how an Action will affect the state on the client, you can perform those changes immediatelly upon its call (instead of waiting for Action to finish), by modifying what specific Queries currently return.
|
||||
This means that, if you have a good idea of how an Action will affect the state on the client, you can perform those changes immediately upon its call (instead of waiting for Action to finish), by modifying what specific Queries currently return.
|
||||
Once Action is actually done, related Queries will be unvalidated as usual and therefore fetch the real result, but in the meantime the changes you specified via optimistic updates will be visible.
|
||||
|
||||
This is great for apps where there is a lot of interactivity and you want the UI to update instantly with your changes, even as they are still being saved to the server.
|
||||
@ -1648,7 +1648,7 @@ Check out https://wasp-lang.dev/docs/language/features#the-useaction-hook for mo
|
||||
|
||||
### Upgraded Prisma to latest version (13.15.2)
|
||||
|
||||
Among various other things, this brins support for OpenSSL3. So if you couldn't run Wasp on your operating system due to Prisma not supporting OpenSSL3, those days are over!
|
||||
Among various other things, this brings support for OpenSSL3. So if you couldn't run Wasp on your operating system due to Prisma not supporting OpenSSL3, those days are over!
|
||||
|
||||
---
|
||||
|
||||
@ -1682,8 +1682,8 @@ To run Jobs, you don't need any additional infrastructure at the moment, just a
|
||||
### BREAKING CHANGES
|
||||
|
||||
- Wasp now requires latest LTS version of NodeJS
|
||||
- We had a bit of issues with being too relaxed on the version of NodeJS that can be used with Wasp so we thightened it up a bit.
|
||||
We also added a more thorough check in Wasp for it, that will warn you very explicitely if you are using the wrong version of Node.
|
||||
- We had a bit of issues with being too relaxed on the version of NodeJS that can be used with Wasp so we tightened it up a bit.
|
||||
We also added a more thorough check in Wasp for it, that will warn you very explicitly if you are using the wrong version of Node.
|
||||
- Updated react-query to v3
|
||||
- This brings some new features from react query while also laying the foundation for the further features we are building on top of it in Wasp (coming soon!).
|
||||
- Updated python to python3 in Dockerfile generated upon `wasp build`.
|
||||
|
@ -11,8 +11,8 @@ If you would like to make your first contribution, here is a handy checklist we
|
||||
- [ ] Read [Quick overview](#quick-overview).
|
||||
- [ ] Compile the project successfully and get todoApp example running (follow [Basics](#basics)).
|
||||
- [ ] Join [Discord](https://discord.gg/rzdnErX) and say hi :)!
|
||||
- [ ] Pick an issue [labeled with "good first issue"](https://github.com/wasp-lang/wasp/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) and let us know you would like to work on it - ideally immediatelly propose a plan of action and ask questions.
|
||||
If you can't find a suitable issue for you, reach out to us on Discord and we can try to find smth for you together.
|
||||
- [ ] Pick an issue [labeled with "good first issue"](https://github.com/wasp-lang/wasp/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) and let us know you would like to work on it - ideally immediately propose a plan of action and ask questions.
|
||||
If you can't find a suitable issue for you, reach out to us on Discord and we can try to find something for you together.
|
||||
- [ ] Make a PR targeting `main` and have it accepted! Check [Typical workflow](#typical-development-workflow) and [Branching and merging strategy](#branching-and-merging-strategy) for guidance, and consult [Codebase overview](#codebase-overview) for more details on how Wasp compiler works internally.
|
||||
|
||||
## Quick overview
|
||||
@ -21,7 +21,7 @@ Wasp compiler is implemented in Haskell, but you will also see a lot of Javascri
|
||||
|
||||
You don't have to be expert in Haskell to contribute or understand the code, since we don't use complicated Haskell features much -> most of the code is relatively simple and straight-forward, and we are happy to help with the part that is not.
|
||||
|
||||
Main result of building the project is `wasp` executable (also reffered to as CLI), which is both Wasp compiler, CLI and Wasp project runner in one - one tool for everything Wasp-related.
|
||||
Main result of building the project is `wasp` executable (also referred to as CLI), which is both Wasp compiler, CLI and Wasp project runner in one - one tool for everything Wasp-related.
|
||||
|
||||
`wasp` executable takes `.wasp` files and `ext/` dir as input and generates a web app from them.
|
||||
|
||||
@ -125,7 +125,7 @@ NOTE: Reload page if blank.
|
||||
Rinse and repeat.
|
||||
4. Run `cabal test` to confirm that the project's unit and integration tests are passing (both new and old).
|
||||
5. For easily testing the changes you did on a Wasp app, you have `examples/todoApp`, which we always keep updated. Also, if you added a new feature, add it to this app. Check its README for more details (including how to run it).
|
||||
6. There is also `headless-test/examples/todoApp`, that comes equiped with Playwright tests. This one is not so much for experimenting as `examples/todoApp` is, but more for running Playwright tests in the CI. Make sure this one is also passing, and add a new feature to it (+ tests) if needed. We will be merging this one with `examples/todoApp` in the future so it is a single app.
|
||||
6. There is also `headless-test/examples/todoApp`, that comes equipped with Playwright tests. This one is not so much for experimenting as `examples/todoApp` is, but more for running Playwright tests in the CI. Make sure this one is also passing, and add a new feature to it (+ tests) if needed. We will be merging this one with `examples/todoApp` in the future so it is a single app.
|
||||
7. If you did a bug fix, added new feature or did a breaking change, add short info about it to Changelog.md. Also, bump version in waspc.cabal and ChangeLog.md if needed -> check the version of latest release when doing it. If you are not sure how to decide which version to go with, check later in this file instructions on it.
|
||||
8. Squash all the commits into a single commit (or a few in case it makes more sense) and create a PR.
|
||||
Keep an eye on CI tests -> they should all be passing, if not, look into it.
|
||||
@ -142,7 +142,7 @@ In order to better support a wider range of developer operating systems, we have
|
||||
If the feature you are implementing is complex, be it due to its design or technical implementation, we recommend creating a [design doc](https://www.industrialempathy.com/posts/design-docs-at-google/) (aka RFC).
|
||||
It is a great way to share the idea you have with others while also getting help and feedback.
|
||||
|
||||
To create one, make a PR that adds a markdown document under `wasp/docs/design-docs`, and in that markdown document explain the thinking behind and choice made when deciding how to implement a feature.
|
||||
To create one, make a PR that adds a markdown document under `wasp/docs/design-docs`, and in that markdown document explain the thinking behind and choices made when deciding how to implement a feature.
|
||||
|
||||
Others will comment on your design doc, and once it has gone through needed iterations and is approved, you can start with the implementation of the feature (in a separate PR).
|
||||
|
||||
|
@ -48,7 +48,7 @@ There are two main solutions:
|
||||
2. Seeding script
|
||||
|
||||
*** Database snapshots
|
||||
Database snapshots sound relatively straight forward to implement, also easy for devs to create.
|
||||
Database snapshots sound relatively straightforward to implement, also easy for devs to create.
|
||||
So they could use the app itself, or =db studio=, or some richer postgresql client, or their own scripts,
|
||||
to put db into a certain state, and then they can do snapshot and there you go.
|
||||
What is not great is that data can easily become out of sync with how app currently works,
|
||||
|
@ -43,7 +43,7 @@ The solution that people suggested was an async function that returns an object
|
||||
### Advanced
|
||||
- Instead of returning an object that will be added to `context`, function could return a function that modifies the `context`.
|
||||
This gives more control to dev, but it can also lead to them messing up `context`.
|
||||
- Function could take arguments which expose certain parts of the server and therefore give the dev an ooportunity to affect certain parts of the app.
|
||||
- Function could take arguments which expose certain parts of the server and therefore give the dev an opportunity to affect certain parts of the app.
|
||||
For example, they could modify the expressJS router. Or they would get access to Prisma.
|
||||
This again can be problematic as if gives developer space to mess things up.
|
||||
- Function could return not just object to be added to `context`, but also other things that modify how Wasp works.
|
||||
|
@ -104,7 +104,7 @@ runNodeCommandAsJobWithExtraEnv extraEnvVars fromDir command args jobType chan =
|
||||
runProcessAsJob nodeCommandProcess jobType chan
|
||||
where
|
||||
-- Haskell will use the first value for variable name it finds. Since env
|
||||
-- vars in 'extraEnvVars' should override the the inherited env vars, we
|
||||
-- vars in 'extraEnvVars' should override the inherited env vars, we
|
||||
-- must prepend them.
|
||||
getAllEnvVars = (extraEnvVars ++) <$> getEnvironment
|
||||
exitWithError exitCode errorMsg = do
|
||||
|
@ -99,7 +99,7 @@ This code does not compile, because compiler can't match type of `ys` with the r
|
||||
Why though, when they are both `[a]`? Well, that is because that is not the same `a`!
|
||||
Try changing `ys :: [a]` to `ys :: [b]` and you will get the exact same error,
|
||||
because it is exactly the same code -> `a` in `ys :: [a]` and `a` in `f :: [a] -> [a]` are different `a`s and there is no connection between them.
|
||||
`a` in `ys :: [a]` stands for "any type", not for "that type that is reffered to with `a` in the type signature above".
|
||||
`a` in `ys :: [a]` stands for "any type", not for "that type that is referred to with `a` in the type signature above".
|
||||
|
||||
This is where `ScopedTypeVariables` comes in:
|
||||
```hs
|
||||
|
@ -34,7 +34,7 @@ Since the [launch of Wasp Alpha](https://news.ycombinator.com/item?id=26091956)
|
||||
- [Farnance: SaaS for farmers, a HackLBS 2021 winner](/blog/2022/10/28/farnance-hackathon-winner)
|
||||
- [Amicus: Planning and workflow tracking for legal teams](/blog/2022/11/26/erlis-amicus-usecase)
|
||||
|
||||
Here are the the new features that ship with Beta:
|
||||
Here are the new features that ship with Beta:
|
||||
|
||||
### 🟦 TypeScript support
|
||||
|
||||
|
@ -27,7 +27,7 @@ The fact that so many libraries and frameworks exist in 2023, and that **the bes
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
For example, according the the [StateOfJS](https://2022.stateofjs.com/en-US/libraries/front-end-frameworks/) survey, there were 5 Front-end Frameworks with good retention in 2018, now there are 11 in 2022. That’s a 120% increase in a matter of 4 years, and that’s not even taking into account the hot meta-frameworks like NextJS, SvelteKit, or Astro!
|
||||
For example, according the [StateOfJS](https://2022.stateofjs.com/en-US/libraries/front-end-frameworks/) survey, there were 5 Front-end Frameworks with good retention in 2018, now there are 11 in 2022. That’s a 120% increase in a matter of 4 years, and that’s not even taking into account the hot meta-frameworks like NextJS, SvelteKit, or Astro!
|
||||
|
||||
<br/>
|
||||
<ImgWithCaption
|
||||
|
@ -1093,7 +1093,7 @@ export const editMeme: EditMeme<EditMemeArgs, Meme> = async ({ id, text0, text1
|
||||
};
|
||||
```
|
||||
|
||||
As you can see, this function expects the `id` of the already existing meme, along with the new `text` boxes. That’s because we’re letting the user manually input/edit the text that GPT generated, rather than making another request the the OpenAI API.
|
||||
As you can see, this function expects the `id` of the already existing meme, along with the new `text` boxes. That’s because we’re letting the user manually input/edit the text that GPT generated, rather than making another request the OpenAI API.
|
||||
|
||||
Next, we look for that specific meme in our database, and if we don’t find it we throw an error (`findUniqueOrThrow`).
|
||||
|
||||
|
@ -57,7 +57,7 @@ Let's take a look together at the nice things that v0.15 brings us:
|
||||
|
||||
As mentioned above, we got to keep up with the trends! Here's what's new:
|
||||
- **Upgraded Prisma to v5** - no major interface changes, but brings a lot of performance improvements which also make Wasp faster by default 🏎️
|
||||
- **React Router is now at v6** - v6 has been around for a while (you can see the the main changes from v5 [here](https://blog.saeloun.com/2021/12/02/new-features-in-react-router-6/)) and it made the code even more compact and elegant.
|
||||
- **React Router is now at v6** - v6 has been around for a while (you can see the main changes from v5 [here](https://blog.saeloun.com/2021/12/02/new-features-in-react-router-6/)) and it made the code even more compact and elegant.
|
||||
- **We cleaned up and bumped a lot of other dependencies** - including Express.js on which we base Wasp’s API layer and our type-safe RPC.
|
||||
|
||||
## #2: TS SDK early preview 🤩 - give it a spin and let us know what you think!
|
||||
|
@ -246,7 +246,7 @@ Make sure to add your client-side environment variables every time you redeploy
|
||||
|
||||
### `cmd`
|
||||
|
||||
If want to run arbitrary Fly commands (e.g. `flyctl secrets list` for your server app), here's how to do it:
|
||||
If you want to run arbitrary Fly commands (e.g. `flyctl secrets list` for your server app), here's how to do it:
|
||||
|
||||
```shell
|
||||
wasp deploy fly cmd secrets list --context server
|
||||
|
@ -292,7 +292,7 @@ The Job declaration has the following fields:
|
||||
type Input = { name: string; }
|
||||
type Output = { tasks: Task[]; }
|
||||
|
||||
export const foo: MySpecialJob<Input, Output> = async (args, context) => {
|
||||
export const foo: MySpecialJob<Input, Output> = async ({ name }, context) => {
|
||||
console.log(`Hello ${name}!`)
|
||||
const tasks = await context.entities.Task.findMany({})
|
||||
return { tasks }
|
||||
|
@ -12,7 +12,7 @@ export const userSignupFields = defineUserSignupFields({
|
||||
throw new Error('Address is required')
|
||||
}
|
||||
return data.address
|
||||
}
|
||||
},
|
||||
phone: (data) => data.phone,
|
||||
})
|
||||
```
|
||||
|
@ -1,7 +1,7 @@
|
||||
```ts
|
||||
const emailIdentity = user.identities.email
|
||||
|
||||
// Email address the the user used to sign up, e.g. "fluffyllama@app.com".
|
||||
// Email address the user used to sign up, e.g. "fluffyllama@app.com".
|
||||
emailIdentity.id
|
||||
|
||||
// `true` if the user has verified their email address.
|
||||
|
@ -607,7 +607,7 @@ import { getFoo } from 'wasp/client/operations'
|
||||
import { getFoo } from 'wasp/server/operations'
|
||||
```
|
||||
|
||||
On the the client, the Query expects
|
||||
On the client, the Query expects
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="ts" label="TypeScript">
|
||||
|
@ -205,7 +205,7 @@ wasp deploy fly deploy
|
||||
|
||||
### `cmd`
|
||||
|
||||
If want to run arbitrary Fly commands (e.g. `flyctl secrets list` for your server app), here's how to do it:
|
||||
If you want to run arbitrary Fly commands (e.g. `flyctl secrets list` for your server app), here's how to do it:
|
||||
|
||||
```shell
|
||||
wasp deploy fly cmd secrets list --context server
|
||||
|
@ -301,7 +301,7 @@ Let's deploy our server first:
|
||||
Open the `Settings` and go to the `Variables` tab:
|
||||
|
||||
- click **Variable reference** and select `DATABASE_URL` (it will populate it with the correct value)
|
||||
- add `WASP_WEB_CLIENT_URL` - enter the the `client` domain (e.g. `https://client-production-XXXX.up.railway.app`)
|
||||
- add `WASP_WEB_CLIENT_URL` - enter the `client` domain (e.g. `https://client-production-XXXX.up.railway.app`)
|
||||
- add `JWT_SECRET` - enter a random string at least 32 characters long (use an [online generator](https://djecrety.ir/))
|
||||
|
||||
<AddExternalAuthEnvVarsReminder />
|
||||
|
@ -209,7 +209,7 @@ wasp deploy fly deploy
|
||||
|
||||
### `cmd`
|
||||
|
||||
If want to run arbitrary Fly commands (e.g. `flyctl secrets list` for your server app), here's how to do it:
|
||||
If you want to run arbitrary Fly commands (e.g. `flyctl secrets list` for your server app), here's how to do it:
|
||||
|
||||
```shell
|
||||
wasp deploy fly cmd secrets list --context server
|
||||
|
@ -324,7 +324,7 @@ Let's deploy our server first:
|
||||
Open the `Settings` and go to the `Variables` tab:
|
||||
|
||||
- click **Variable reference** and select `DATABASE_URL` (it will populate it with the correct value)
|
||||
- add `WASP_WEB_CLIENT_URL` - enter the the `client` domain (e.g. `https://client-production-XXXX.up.railway.app`)
|
||||
- add `WASP_WEB_CLIENT_URL` - enter the `client` domain (e.g. `https://client-production-XXXX.up.railway.app`)
|
||||
- add `JWT_SECRET` - enter a random string at least 32 characters long (use an [online generator](https://djecrety.ir/))
|
||||
|
||||
<AddExternalAuthEnvVarsReminder />
|
||||
|
@ -209,7 +209,7 @@ wasp deploy fly deploy
|
||||
|
||||
### `cmd`
|
||||
|
||||
If want to run arbitrary Fly commands (e.g. `flyctl secrets list` for your server app), here's how to do it:
|
||||
If you want to run arbitrary Fly commands (e.g. `flyctl secrets list` for your server app), here's how to do it:
|
||||
|
||||
```shell
|
||||
wasp deploy fly cmd secrets list --context server
|
||||
|
@ -246,7 +246,7 @@ Make sure to add your client-side environment variables every time you redeploy
|
||||
|
||||
### `cmd`
|
||||
|
||||
If want to run arbitrary Fly commands (e.g. `flyctl secrets list` for your server app), here's how to do it:
|
||||
If you want to run arbitrary Fly commands (e.g. `flyctl secrets list` for your server app), here's how to do it:
|
||||
|
||||
```shell
|
||||
wasp deploy fly cmd secrets list --context server
|
||||
|
@ -1,7 +1,7 @@
|
||||
```ts
|
||||
const emailIdentity = user.identities.email
|
||||
|
||||
// Email address the the user used to sign up, e.g. "fluffyllama@app.com".
|
||||
// Email address the user used to sign up, e.g. "fluffyllama@app.com".
|
||||
emailIdentity.id
|
||||
|
||||
// `true` if the user has verified their email address.
|
||||
|
@ -607,7 +607,7 @@ import { getFoo } from 'wasp/client/operations'
|
||||
import { getFoo } from 'wasp/server/operations'
|
||||
```
|
||||
|
||||
On the the client, the Query expects
|
||||
On the client, the Query expects
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="ts" label="TypeScript">
|
||||
|
@ -246,7 +246,7 @@ Make sure to add your client-side environment variables every time you redeploy
|
||||
|
||||
### `cmd`
|
||||
|
||||
If want to run arbitrary Fly commands (e.g. `flyctl secrets list` for your server app), here's how to do it:
|
||||
If you want to run arbitrary Fly commands (e.g. `flyctl secrets list` for your server app), here's how to do it:
|
||||
|
||||
```shell
|
||||
wasp deploy fly cmd secrets list --context server
|
||||
|
@ -1,7 +1,7 @@
|
||||
```ts
|
||||
const emailIdentity = user.identities.email
|
||||
|
||||
// Email address the the user used to sign up, e.g. "fluffyllama@app.com".
|
||||
// Email address the user used to sign up, e.g. "fluffyllama@app.com".
|
||||
emailIdentity.id
|
||||
|
||||
// `true` if the user has verified their email address.
|
||||
|
@ -607,7 +607,7 @@ import { getFoo } from 'wasp/client/operations'
|
||||
import { getFoo } from 'wasp/server/operations'
|
||||
```
|
||||
|
||||
On the the client, the Query expects
|
||||
On the client, the Query expects
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="ts" label="TypeScript">
|
||||
|
Loading…
Reference in New Issue
Block a user