📘 doc: expand more in order of code

Author: SaltyAom

docs/essential/handler.md

@@ -204,7 +204,7 @@ new Elysia()
 
 <Playground :elysia="handler2" />
 
-It's recommend to use `error` inside main handler as it has better inference:
+It's recommend to use `status` inside main handler as it has better inference:
 
 - allows TypeScript to check if a return value is correctly type to response schema
 - autocompletion for type narrowing base on status code
@@ -228,7 +228,7 @@ new Elysia()
     .listen(3000)
 ```
 
-Unlike `error` function, `set.status` cannot infer the return value type, therefore it can't check if the return value is correctly type to response schema.
+Unlike `status` function, `set.status` cannot infer the return value type, therefore it can't check if the return value is correctly type to response schema.
 
 ::: tip
 HTTP Status indicates the type of response. If the route handler is executed successfully without error, Elysia will return the status code 200.

docs/essential/life-cycle.md

@@ -171,22 +171,20 @@ See [scope](/essential/plugin#scope) to find out why
 
 The order of Elysia's life-cycle code is very important.
 
-Elysia's life-cycle event is stored as a queue, aka first-in first-out. So Elysia will **always** respect the order of code from top-to-bottom followed by the order of life-cycle events.
+Because event will only apply to routes **after** it is registered.
+
+If you put the onError before plugin, plugin will not inherit the onError event.
 
 ```typescript
 import { Elysia } from 'elysia'
 
 new Elysia()
-    .onBeforeHandle(() => {
+ 	.onBeforeHandle(() => {
         console.log('1')
     })
-    .onAfterHandle(() => {
-        console.log('3')
-    })
-    .get('/', () => 'hi', {
-        beforeHandle() {
-            console.log('2')
-        }
+	.get('/', () => 'hi')
+    .onBeforeHandle(() => {
+        console.log('2')
     })
     .listen(3000)
 ```
@@ -195,10 +193,32 @@ Console should log the following:
 
 ```bash
 1
-2
-3
 ```
 
+Notice that it doesn't log **3**, because the event is registered after the route so it is not applied to the route.
+
+This also applies to the plugin.
+
+```typescript
+import { Elysia } from 'elysia'
+
+new Elysia()
+	.onBeforeHandle(() => {
+		console.log('1')
+	})
+	.use(someRouter)
+	.onBeforeHandle(() => {
+		console.log('2')
+	})
+	.listen(3000)
+```
+
+In the code above, only **1** will be logged, because the event is registered after the plugin.
+
+This is because each events will be inline into a route handler to create a true encapsulation scope and static code analysis.
+
+The only exception is `onRequest` which is executed before the route handler so it couldn't be inlined and tied to the routing process instead.
+
 ## Request
 
 The first life-cycle event to get executed for every new request is recieved.
@@ -769,8 +789,8 @@ If no error response is returned, the error will be returned using `error.name`.
 
 It could either be **return** or **throw** based on your specific needs.
 
-- If an `error` is **throw**, it will be caught by `onError` middleware.
-- If an `error` is **return**, it will be **NOT** caught by `onError` middleware.
+- If an `status` is **throw**, it will be caught by `onError` middleware.
+- If an `status` is **return**, it will be **NOT** caught by `onError` middleware.
 
 See the following code:
 
@@ -828,8 +848,6 @@ new Elysia()
     })
 ```
 
-Properties of `error` code is based on the properties of `error`, the said properties will be used to classify the error code.
-
 ### Local Error
 
 Same as others life-cycle, we provide an error into an [scope](/essential/plugin.html#scope) using guard:

docs/essential/validation.md

@@ -674,7 +674,7 @@ This is an Elysia-specific feature, allowing us to make a field optional.
 
 There are two ways to provide a custom error message when the validation fails:
 
-1. Inline `error` property
+1. Inline `status` property
 2. Using [onError](/essential/life-cycle.html#on-error) event
 
 ### Error Property

docs/key-concept.md

@@ -217,6 +217,38 @@ const main = new Elysia()
 
 As mentioned in [dependencies](#dependencies), we can use the `name` property to deduplicate the instance so it will not have any performance penalty or lifecycle duplication.
 
+## Order of code
+
+The order of Elysia's life-cycle code is very important.
+
+Because event will only apply to routes **after** it is registered.
+
+If you put the onError before plugin, plugin will not inherit the onError event.
+
+```typescript
+import { Elysia } from 'elysia'
+
+new Elysia()
+ 	.onBeforeHandle(() => {
+        console.log('1')
+    })
+	.get('/', () => 'hi')
+    .onBeforeHandle(() => {
+        console.log('2')
+    })
+    .listen(3000)
+```
+
+Console should log the following:
+
+```bash
+1
+```
+
+Notice that it doesn't log **3**, because the event is registered after the route so it is not applied to the route.
+
+Learn more about this in [order of code](/essential/life-cycle.html#order-of-code).
+
 ## Type Inference
 Elysia has a complex type system that allows you to infer types from the instance.