Merge pull request #91 from StrawHatHacker/Typos

SaltyAom · web-flow · commit 4b5dcd5528bc · 2023-09-11T19:40:51.000+07:00
Typo fixes
diff --git a/docs/blog/elysia-06.md b/docs/blog/elysia-06.md
@@ -122,7 +122,7 @@ By this, Elysia is partially follows WinterCG compliance as we are optimized to
 
 This allows any framework and code that is WinterCG compliance to be run together in theory, an implementation is proved by [Hono](https://honojs.dev) which introduce the **.mount** method to [runs multiple framework together in one codebase](https://twitter.com/honojs/status/1684839623355490304), including Remix, Elysia, Itty Router, and Hono itself in a simple function.
 
-By this, we implemented the same logic for Elysia by introducing `.mount` method to runs any framework or code that WinterCG compliance.
+By this, we implemented the same logic for Elysia by introducing `.mount` method to runs any framework or code that is WinterCG compliant.
 
 To use `.mount`, [simply pass a `fetch` function](https://twitter.com/saltyAom/status/1684786233594290176):
 ```ts
@@ -146,7 +146,7 @@ By default, this declaration are used by:
 - Netlify Edge Function
 - Remix Function Handler
 
-Which means you can run all of the above code to interlop with Elysia all in a single server, or reused and existing function all in one deployment, no need to setting up Reverse Proxy for handling multiple server.
+Which means you can run all of the above code to interlop with Elysia all in a single server, or re-used and existing function all in one deployment, no need to setting up Reverse Proxy for handling multiple server.
 
 If the framework also support a **.mount** function, you can deeply nested a framework that support it infinitely.
 ```ts
@@ -163,7 +163,7 @@ const main = new Elysia()
     .listen(3000)
 ```
 
-You can even reused multiple existing Elysia project in your server.
+You can even re-used multiple existing Elysia project in your server.
 
 ```ts
 import A from 'project-a/elysia'
diff --git a/docs/blog/elysia-supabase.md b/docs/blog/elysia-supabase.md
@@ -326,7 +326,7 @@ const authen = (app: Elysia) =>
 Great! We have just used name reference on our route!
 
 ::: tip
-If you found yourself with a long schema, you can declare them in a separate file and reuse them in any Elysia route to put the focus back on business logic instead.
+If you found yourself with a long schema, you can declare them in a separate file and re-use them in any Elysia route to put the focus back on business logic instead.
 :::
 
 ## Storing user session
@@ -478,7 +478,7 @@ And that's it!
 
 We have just implemented user authentication which is fun and game, but now you might find yourself in need of authorization for each route, and duplicating the same code to check for cookies all over the place.
 
-Luckily, we can reuse the function in Elysia.
+Luckily, we can re-use the function in Elysia.
 
 Let's paint the example by saying that we might want a user to create a simple blog post that can have the database schema as the following:
 
diff --git a/docs/concept/numeric.md b/docs/concept/numeric.md
@@ -19,7 +19,7 @@ head:
 
 Sometime you might find yourself in need of numeric string like extracting path parameter, but it's typed as string and need to be convert to number.
 
-Using Elysia's `transform` life-cycle, you can manually parse number to string and reuse the transform function in other handler as well.
+Using Elysia's `transform` life-cycle, you can manually parse number to string and re-use the transform function in other handler as well.
 
 ```ts
 app.get('/id/:id', ({ params: { id } }) => id, {
diff --git a/docs/patterns/body-parser.md b/docs/patterns/body-parser.md
@@ -37,7 +37,7 @@ new Elysia()
 ```
 
 ## Custom body parser
-If you want to support more `content-type`, you can use `onParse`:
+If you want to support more `content-type`s, you can use the `onParse` method:
 
 ```typescript
 new Elysia()
@@ -47,9 +47,9 @@ new Elysia()
     })
 ```
 
-The returned value will be assigned to `Context.body`, otherwise, Elysia will iterate more parser functions assigned by `onParse` until either body is assigned or all parsers are executed.
+The returned value will be assigned to Context.body. If not, Elysia will continue iterating through additional parser functions assigned by `onParse` until either body is assigned or all parsers have been executed.
 
-You can also use `request` to take advantage and add custom behavior for parsing the body.
+You can also use `request` to add custom parsing behavior.
 
 For example, parsing GraphQL on a specific path:
 ```typescript
diff --git a/docs/patterns/dependency-injection.md b/docs/patterns/dependency-injection.md
@@ -7,18 +7,18 @@ head:
 
   - - meta
     - name: 'description'
-      content: Dependency injection is a concept that allows you to separate a utility function, decouple route into a plugin and reuse them in a certain scope. This will allows you to control access to decorators of Elysia.
+      content: Dependency injection is a concept that allows you to separate a utility function, decouple route into a plugin and re-use them in a certain scope. This will allows you to control access to decorators of Elysia.
 
 
   - - meta
     - property: 'og:description'
-      content: Dependency injection is a concept that allows you to separate a utility function, decouple route into a plugin and reuse them in a certain scope. This will allows you to control access to decorators of Elysia.
+      content: Dependency injection is a concept that allows you to separate a utility function, decouple route into a plugin and re-use them in a certain scope. This will allows you to control access to decorators of Elysia.
 ---
 
 # Dependency Injection
 Sometimes you would like to separate routes from your main file.
 
-Normally you would normally decouple them into a plugin like:
+Normally you would decouple them into a plugin like:
 ```typescript
 // index.ts
 const app = new Elysia()
@@ -32,7 +32,7 @@ const authen = new Elysia()
     .post('/sign-up', signUp)
 ```
 
-But then sometime, at the main instance introduce some `state`, and `decorate` that you might need a separated module.
+You might want to introduce some `state`, and `decorate` in the main instance that you actually need in a separated module.
 ```typescript
 // index.ts
 const app = new Elysia()
@@ -54,7 +54,7 @@ const authen = new Elysia()
     })
 ```
 
-If you hovered over the main `app` in `index.ts`, you can see that it has some type auto-generated for your main server which might look something like this:
+If you hover over the main `app` in `index.ts`, you can see the auto-generated type for your main server which might look something like this:
 ```typescript
 const app: Elysia<'', {
     store: {
@@ -69,7 +69,7 @@ const app: Elysia<'', {
 
 But this type isn't applied to sub-modules.
 
-To apply the type to sub-modules, you can create a plugin which only contains `state` and `decorate` which caused **type side-effect** as dependency, and apply to the module you want to use.
+To apply the type to sub-modules, you can create a plugin which only contains `state` and `decorate` which causes **type side-effect** as a dependency, and applies it to any sub-modules you want.
 
 ```typescript
 const setup = new Elysia({ name: 'setup' })
@@ -89,4 +89,4 @@ const authen = new Elysia()
     })
 ```
 
-This will allows you to control access to decorators in modules, this concept is also known as **Dependency Injection** but only for types.
+This will allow you to control access to decorators in modules. This concept is also known as **Dependency Injection** but only for types.
diff --git a/docs/patterns/end-to-end-type-safety.md b/docs/patterns/end-to-end-type-safety.md
@@ -19,11 +19,11 @@ End-to-end type-safety refers to a system in which every component of the system
 
 This can help prevent bugs and errors by catching type mismatches early in the development process, rather than at runtime.
 
-Ensure that the system is working in a predictable way, thus reducing the risk of unexpected behavior.
+It ensures that the system is working in a predictable way, thus reducing the risk of unexpected behavior.
 
 ---
 
-Elysia support End-to-End Type-Safety between client-server with the [Eden](/plugins/eden/overview).
+Elysia supports End-to-End Type-Safety between client-server with the [Eden](/plugins/eden/overview) plugin.
 
 <iframe
     id="embedded-editor"
@@ -37,8 +37,6 @@ Elysia support End-to-End Type-Safety between client-server with the [Eden](/plu
 Hover over variable and function to see type definition.
 :::
 
-Elysia allows you change type on server and reflect the type definitions on the client, helping with auto-completion and type-enforcement.
+Elysia allows you change the type on server and it will be instantly reflected on the client, helping with auto-completion and type-enforcement.
 
-With End-to-End Type-Safety, migrating from old to new type also reflect which path of the codebase need to be migrate by line-of-code level.
-
-See [Eden](/plugins/eden/overview) for more example.
+See [Eden](/plugins/eden/overview) for more examples.
diff --git a/docs/patterns/error-handling.md b/docs/patterns/error-handling.md
@@ -32,7 +32,7 @@ new Elysia()
 With `onError` you can catch and transform the error into your custom error message.
 
 ::: tip
-It's important that `onError` must be call before handler you want to apply
+It's important that `onError` must be called before the handler you want to apply it to.
 :::
 
 For example, returning custom 404 messages:
@@ -128,7 +128,7 @@ new Elysia()
 ```
 
 ## Catching all error
-To list all error, you can list an error using `error.all`.
+To list all errors, you can list an error using `error.all`.
 
 ```ts
 new Elysia()
diff --git a/docs/patterns/file-upload.md b/docs/patterns/file-upload.md
@@ -15,7 +15,7 @@ head:
 ---
 
 # File Upload
-Elysia handle attachment of `multipart/form-data` to `Context.body` by default.
+Elysia handles attachment of `multipart/form-data` to `Context.body` by default.
 
 ```typescript
 import { Elysia, t } from '../src'
diff --git a/docs/patterns/lazy-loading-module.md b/docs/patterns/lazy-loading-module.md
@@ -17,9 +17,9 @@ head:
 # Lazy-Loading Module
 Modules are eagerly loaded by default. 
 
-Elysia loads all modules and registers and indexes all of the modules before starting the server. This enforces that all the modules should load before start accepting a request.
+Elysia loads all modules then registers and indexes all of them before starting the server. This enforces that all the modules have loaded before it starts accepting requests.
 
-While this is fine for most applications, it may become a bottleneck for a server running in a serverless environment and edge function, where the startup time is important.
+While this is fine for most applications, it may become a bottleneck for a server running in a serverless environment or an edge function, in which the startup time is important.
 
 Lazy-loading can help decrease startup time by deferring modules to be gradually indexed after the server start.
 
@@ -53,7 +53,7 @@ const app = new Elysia()
 
 Elysia static plugin is also a deferred module, as it loads files and registers files path asynchronously.
 
-To ensure module registration before the server start, you can use `await` on the deferred module.
+To ensure module registration before the server starts, you can use `await` on the deferred module.
 
 ```typescript
 // index.ts
@@ -66,7 +66,7 @@ const app = new Elysia()
 ## Lazy Load Module
 Same as the async plugin, the lazy-load module will be registered after the server is started.
 
-A lazy-load module can be both sync or async function, as long as the module is used with `import` the module will be lazy-load.
+A lazy-load module can be both sync or async function, as long as the module is used with `import` the module will be lazy-loaded.
 
 ```typescript
 import { Elysia } from 'elysia'
@@ -75,7 +75,7 @@ const app = new Elysia()
     .use(import('./plugin'))
 ```
 
-Lazy-loading module is recommended when the module is heavy and blocking a start-up time, especially in a serverless/edge environment.
+Using module lazy-loading is recommended when the module is computationally heavy and/or blocking.
 
 ## Testing
 In a test environment, you can use `await app.modules` to wait for deferred and lazy-loading modules.
diff --git a/docs/patterns/mount.md b/docs/patterns/mount.md
@@ -21,7 +21,7 @@ Elysia is WinterCG compliance as we are optimized to Bun but also openly support
 
 In theory, this allows any framework or code that is WinterCG compliance to be run together, allowing framework like Elysia, Hono, Remix, Itty Router to runs together in a simple function.
 
-By this, we implemented the same logic for Elysia by introducing `.mount` method to runs any framework or code that WinterCG compliance.
+By this, we implemented the same logic for Elysia by introducing `.mount` method to runs any framework or code that is WinterCG compliant.
 
 ## Mount
 To use `.mount`, [simply pass a `fetch` function](https://twitter.com/saltyAom/status/1684786233594290176):
@@ -31,7 +31,7 @@ const app = new Elysia()
     .mount('/hono', hono.fetch)
 ```
 
-A **fetch** function is a function that accept Web Standard Request and return Web Standard Response as the definition of:
+A **fetch** function is a function that accepts a Web Standard Request and returns a Web Standard Response with the definition of:
 ```ts
 // Web Standard Request-like object
 // Web Standard Response
@@ -47,7 +47,7 @@ By default, this declaration are used by:
 - Remix Function Handler
 - etc.
 
-Which means you can run all of the above code to interlop with Elysia all in a single server, or reused and existing function all in one deployment, no need to setting up Reverse Proxy for handling multiple server.
+Which means you can run all of the above code to interlop with Elysia all in a single server, or re-used and existing functions all in one deployment, no need to set up a Reverse Proxy for handling multiple servers.
 
 If the framework also support a **.mount** function, you can deeply nested a framework that support it infinitely.
 ```ts
@@ -65,7 +65,7 @@ const main = new Elysia()
 ```
 
 ## Reusing Elysia
-You can even reused multiple existing Elysia project in your server.
+You can even re-use multiple existing Elysia project in your server.
 
 ```ts
 import A from 'project-a/elysia'
@@ -78,6 +78,6 @@ new Elysia()
     .mount(C)
 ```
 
-If an instance passed to mount is an Elysia instance, it will resolve to `use` automatically, providing type-safety and support for Eden by default.
+If an instance passed to `mount` is an Elysia instance, it will be resolved with `use` automatically, providing type-safety and support for Eden by default.
 
-This made the possiblility of interlopable framework and runtime to a reality.
+This made the possiblility of interlopable framework and runtime, into a reality.
diff --git a/docs/patterns/reference-models.md b/docs/patterns/reference-models.md
@@ -55,7 +55,7 @@ const app = new Elysia()
 
 This is a good approach to keeping the code clean by creating a separation of concerns.
 
-However, as the app grows more complicated, you might re-use the many models on many multiple controllers.
+As the complexity of the app increases, you may find yourself reusing multiple models with various controllers.
 
 You can make it a bit cleaner by creating a "reference model".
 
@@ -123,9 +123,7 @@ export const authModel = new Elysia()
 ```
 
 ## Naming Convention
-Having multiple models in an app might have a duplicated name, by default Elysia will throw an error if the model name is duplicated.
-
-But to prevent declaring duplicate model names, you can create a naming convention for separating a model.
+Duplicated model names will cause Elysia to throw an error. To prevent declaring duplicate model names, you can use the following naming convention.
 
 Let's say that you have all models stored at `models/<name>.ts`, you can declare the prefix of the model as a namespace.
 
diff --git a/docs/patterns/testing.md b/docs/patterns/testing.md
@@ -39,10 +39,10 @@ describe('Elysia', () => {
 })
 ```
 
-You can also use other testing library like Jest to create a unit test for Elysia, but we recommended to use `bun:test` over others.
+You can also use other testing libraries like Jest to create a unit test for Elysia, but we recommended to use `bun:test` over others.
 
 ::: tip
-When creating a Request to Elysia server, Elysia expect an entire valid URL **NOT** a part of an URL. 
+When creating a Request to Elysia server, Elysia expects an entire valid URL, **NOT** a part of a URL. 
 
 For instance, "http://localhost/" is valid but "/user" is not.
 :::
diff --git a/docs/plugins/cookie.md b/docs/plugins/cookie.md
@@ -41,7 +41,7 @@ new Elysia()
 ## Config
 This plugin extends config from [cookie](https://npmjs.com/package/cookie)
 
-Below is a config which accepted by the plugin
+Below is a config which is accepted by the plugin
 
 ### secret
 The secret key for signing/un-signing cookies.
@@ -51,7 +51,7 @@ If an array is passed, will use Key Rotation.
 Key rotation is when an encryption key is retired and replaced by generating a new cryptographic key.
 
 ---
-Below is a config extends from [cookie](https://npmjs.com/package/cookie)
+Below is a config that extends from [cookie](https://npmjs.com/package/cookie)
 
 ### domain
 Specifies the value for the [Domain Set-Cookie attribute](https://tools.ietf.org/html/rfc6265#section-5.2.3).
diff --git a/docs/plugins/cors.md b/docs/plugins/cors.md
@@ -35,7 +35,7 @@ new Elysia()
 This will set Elysia to accept requests from any origin. 
 
 ## Config
-Below is a config which accepted by the plugin
+Below is a config which is accepted by the plugin
 
 ### origin
 @default `true`
diff --git a/docs/plugins/eden/fetch.md b/docs/plugins/eden/fetch.md
@@ -7,21 +7,20 @@ head:
 
   - - meta
     - name: 'description'
-      content: A fetch-like alternative to Eden Treaty with faster type inference. With Eden Fetch, you can fetch an API from Elysia server fully type-safe with end-to-end type safety without code generation.
+      content: A fetch-like alternative to Eden Treaty with faster type inference. With Eden Fetch, you can make requests to an Elysia server with end-to-end type-safety without the need of code generation.
 
   - - meta
     - name: 'og:description'
-      content: A fetch-like alternative to Eden Treaty with faster type inference. With Eden Fetch, you can fetch an API from Elysia server fully type-safe with end-to-end type safety without code generation.
+      content: A fetch-like alternative to Eden Treaty with faster type inference. With Eden Fetch, you can make requests to an Elysia server with end-to-end type-safety without the need of code generation.
 ---
 
 # Eden Fetch
 A fetch-like alternative to Eden Treaty with faster type inference.
 
-With Eden Fetch, you can fetch an API from Elysia server fully type-safe without code generation.
+With Eden Fetch, you can make requests to an Elysia server without code generation.
+----
 
----
-
-To use Eden Fetch, first export your existing Elysia server type:
+T without the need of use Eden Fetch, first export your existing Elysia server type:
 ```typescript
 // server.ts
 import { Elysia, t } from 'elysia'
@@ -40,7 +39,7 @@ const app = new Elysia()
 export type App = typeof app
 ```
 
-Then import the server type, and consume Elysia API on client:
+Then import the server type, and consume the Elysia API on client:
 ```typescript
 // client.ts
 import { edenFetch } from '@elysiajs/eden'
@@ -69,7 +68,7 @@ const nendoroid = await fetch('/mirror', {
 ```
 
 ## Error Handling
-You can handle error as same as Eden Treaty:
+You can handle errors the same way as Eden Treaty:
 ```typescript
 // response type: { id: 1895, name: 'Skadi' }
 const { data: nendoroid, error } = app.mirror.post({
@@ -107,4 +106,4 @@ With complex types and lot of server routes, using Eden Treaty on a low-end deve
 
 But as Elysia has tweak and optimized a lot of types and inference, Eden Treaty can be perform very well in the considerable amount of routes.
 
-If your single server or micro-service consists of **more than 500 routes per server** or micro-service, and need to consume all of the route **in a single frontend codebase**, then you might want to use Eden Fetch to as TypeScript as Eden Fetch has a significant better TypeScript performance.
+If your single process contains **more than 500 routes**, and you need to consume all of the routes **in a single frontend codebase**, then you might want to use Eden Fetch as it has a significant better TypeScript performance than Eden Treaty.
diff --git a/docs/plugins/eden/fn.md b/docs/plugins/eden/fn.md
diff --git a/docs/plugins/eden/installation.md b/docs/plugins/eden/installation.md
diff --git a/docs/plugins/eden/treaty.md b/docs/plugins/eden/treaty.md
diff --git a/docs/plugins/graphql-yoga.md b/docs/plugins/graphql-yoga.md
diff --git a/docs/plugins/jwt.md b/docs/plugins/jwt.md
diff --git a/docs/plugins/static.md b/docs/plugins/static.md
diff --git a/docs/plugins/swagger.md b/docs/plugins/swagger.md
