updates chapter naming if the sub-chapters are more than 10 for maintaining lexicographical ordering on github and generated files

ishtms · ishtms · commit 6bcda9883ecf · 2024-08-29T17:23:18.000+05:30
diff --git a/Readme.md b/Readme.md
diff --git a/chapters/ch05.5-response-status-codes.md b/chapters/ch05.5-response-status-codes.md
@@ -379,4 +379,4 @@ But in-case you're curious you can check all the status codes here:
 | 504  | Gateway Timeout               | [Section 6.6.5](https://tools.ietf.org/html/rfc7231#section-6.6.5)   |
 | 505  | HTTP Version Not Supported    | [Section 6.6.6](https://tools.ietf.org/html/rfc7231#section-6.6.6)   |
 
-[![Read Next](/assets/imgs/next.png)](/chapters/ch06.0-velocy-our-backend-framework.md)
+[![Read Next](/assets/imgs/next.png)](/chapters/ch06.00-velocy-our-backend-framework.md)
diff --git a/chapters/ch06.00-velocy-our-backend-framework.md b/chapters/ch06.00-velocy-our-backend-framework.md
@@ -178,4 +178,4 @@ API rate limiting is a way to control how often clients, like apps or users, can
 
 We will begin building our backend library/framework in the upcoming chapters. However, before doing so, we need to have a strong understanding of HTTP. Let's tackle that first in the next chapter.
 
-[![Read Next](/assets/imgs/next.png)](/chapters/ch06.1-basic-router-implementation.md)
+[![Read Next](/assets/imgs/next.png)](/chapters/ch06.01-basic-router-implementation.md)
diff --git a/chapters/ch06.01-basic-router-implementation.md b/chapters/ch06.01-basic-router-implementation.md
@@ -1,4 +1,4 @@
-[![Read Prev](/assets/imgs/prev.png)](/chapters/ch06.0-velocy-our-backend-framework.md)
+[![Read Prev](/assets/imgs/prev.png)](/chapters/ch06.00-velocy-our-backend-framework.md)
 
 ## A basic `Router` implementation
 
@@ -524,4 +524,4 @@ Here are some general considerations, that I tend to follow:
 
 We'll take everything we've learned so far and apply it to our `Router` class in the next chapter.
 
-[![Read Next](/assets/imgs/prev.png)](/chapters/ch06.2-the-router-class.md)
+[![Read Next](/assets/imgs/prev.png)](/chapters/ch06.02-the-router-class.md)
diff --git a/chapters/ch06.02-the-router-class.md b/chapters/ch06.02-the-router-class.md
@@ -1,4 +1,4 @@
-[![Read Prev](/assets/imgs/prev.png)](/chapters/ch06.1-basic-router-implementation.md)
+[![Read Prev](/assets/imgs/prev.png)](/chapters/ch06.01-basic-router-implementation.md)
 
 ## The `Router` class
 
@@ -641,4 +641,4 @@ router.get(/", function handlePostBasePath(req, res) {
 
 This way, we'll provide a clean and clear interface for our clients.
 
-[![Read Next](/assets/imgs/next.png)](/chapters/ch06.3-improving-the-router-api.md)
+[![Read Next](/assets/imgs/next.png)](/chapters/ch06.03-improving-the-router-api.md)
diff --git a/chapters/ch06.03-improving-the-router-api.md b/chapters/ch06.03-improving-the-router-api.md
@@ -1,4 +1,4 @@
-[![Read Prev](/assets/imgs/prev.png)](/chapters/ch06.2-the-router-class.md)
+[![Read Prev](/assets/imgs/prev.png)](/chapters/ch06.02-the-router-class.md)
 
 ## Improving the `Router` API
 
@@ -162,4 +162,4 @@ $ curl http://localhost:5255/foo -v
 
 Great! This looks much better than the previous implementation.
 
-[![Read Next](/assets/imgs/next.png)](/chapters/ch06.4-the-need-for-a-trie.md)
+[![Read Next](/assets/imgs/next.png)](/chapters/ch06.04-the-need-for-a-trie.md)
diff --git a/chapters/ch06.04-the-need-for-a-trie.md b/chapters/ch06.04-the-need-for-a-trie.md
@@ -1,4 +1,4 @@
-[![Read Prev](/assets/imgs/prev.png)](/chapters/ch06.3-improving-the-router-api.md)
+[![Read Prev](/assets/imgs/prev.png)](/chapters/ch06.03-improving-the-router-api.md)
 
 ## The Need for a `Trie`
 
@@ -105,4 +105,4 @@ Every node, including `root` will be an object that contain some necessary infor
 
 Enough with the theory. In the next chapter, we'll dive into our very first exercise for this book: **implementing a Trie**.
 
-[![Read Next](/assets/imgs/next.png)](/chapters/ch06.5-ex-implementing-a-trie.md)
+[![Read Next](/assets/imgs/next.png)](/chapters/ch06.05-ex-implementing-a-trie.md)
diff --git a/chapters/ch06.05-ex-implementing-a-trie.md b/chapters/ch06.05-ex-implementing-a-trie.md
@@ -1,4 +1,4 @@
-[![Read Prev](/assets/imgs/prev.png)](/chapters/ch06.4-the-need-for-a-trie.md)
+[![Read Prev](/assets/imgs/prev.png)](/chapters/ch06.04-the-need-for-a-trie.md)
 
 ## Exercise 1 - Implementing a `Trie`
 
@@ -345,4 +345,4 @@ search(word) {
 
 Awesome work. Now you know the basics of the `Trie` data structure and how to implement it. In the next exercise, we'll implement our `Router` from scratch! The next exercise will be more challenging and exhaustive.
 
-[![Read Next](/assets/imgs/next.png)](/chapters/ch06.6-ex-implementing-router.md)
+[![Read Next](/assets/imgs/next.png)](/chapters/ch06.06-ex-implementing-router.md)
diff --git a/chapters/ch06.06-ex-implementing-router.md b/chapters/ch06.06-ex-implementing-router.md
@@ -1,4 +1,4 @@
-[![Read Prev](/assets/imgs/prev.png)](/chapters/ch06.5-ex-implementing-a-trie.md)
+[![Read Prev](/assets/imgs/prev.png)](/chapters/ch06.05-ex-implementing-a-trie.md)
 
 ## Exercise 2 - Implementing our Trie based `Router`
 
@@ -520,4 +520,4 @@ null
 
 Everything seems to be working well. This is it for the `findRoute` method. This was much easier than our `addRoute` implementation, since we only cared about searching. Excellent, we've grasped the basics well! Now let's move on to the more advanced features in the next chapter, ie Implementing HTTP methods with our router.
 
-[![Read Next](/assets/imgs/next.png)](/chapters/ch06.7-ex-adding-http-methods.md)
+[![Read Next](/assets/imgs/next.png)](/chapters/ch06.07-ex-adding-http-methods.md)
diff --git a/chapters/ch06.07-ex-adding-http-methods.md b/chapters/ch06.07-ex-adding-http-methods.md
@@ -190,4 +190,4 @@ findRoute(path, method) {
 
 In both the `addRoute` and `findRoute` methods, we've updated the line that sets and gets the handler for a specific path. Now, the handler is stored in the `handler` map of the current node, with the HTTP method as the key.
 
-[![Read Next](/assets/imgs/next.png)](/chapters/ch06.9-ex-dynamic-routing.md)
+[![Read Next](/assets/imgs/next.png)](/chapters/ch06.09-ex-dynamic-routing.md)
diff --git a/chapters/ch06.08-adding-verbs-api.md b/chapters/ch06.08-adding-verbs-api.md
diff --git a/chapters/ch06.09-ex-dynamic-routing.md b/chapters/ch06.09-ex-dynamic-routing.md
diff --git a/chapters/ch06.10-running-our-server.md b/chapters/ch06.10-running-our-server.md
@@ -204,7 +204,7 @@ if (route?.handler) {
 
 We're calling the `findRoute` method on the `router` object to find the route that matches the incoming request. The `findRoute` method will return an object with two properties: `handler` and `params`. If a route is found, we'll call the `handler` function with the `req` and `res` objects. If no route is found, we'll return a `404 Not Found` response.
 
-You might have noticed that we're using a hard-coded `Content-Length` header with a value of `9`. This is because, if we do not specify the `Content-Length` header, the response headers will include a header `Transfer-Encoding: chunked`, which has a performance impact. We discussed about this in a previous chapter - [Chunks, oh no!](chapters/ch06.1-basic-router-implementation.md#chunks-oh-no-)
+You might have noticed that we're using a hard-coded `Content-Length` header with a value of `9`. This is because, if we do not specify the `Content-Length` header, the response headers will include a header `Transfer-Encoding: chunked`, which has a performance impact. We discussed about this in a previous chapter - [Chunks, oh no!](chapters/ch06.01-basic-router-implementation.md#chunks-oh-no-)
 
 That's it! We have implemented the `run` function, which will allow us to run our server and listen for incoming requests. In the next chapter, we'll implement a simple server using our `Router` class and the `run` function.
 

Original file line number	Diff line number	Diff line change
`@@ -178,4 +178,4 @@ API rate limiting is a way to control how often clients, like apps or users, can`
`178`	`178`
`179`	`179`	`We will begin building our backend library/framework in the upcoming chapters. However, before doing so, we need to have a strong understanding of HTTP. Let's tackle that first in the next chapter.`
`180`	`180`
`181`		`-[![Read Next](/assets/imgs/next.png)](/chapters/ch06.1-basic-router-implementation.md)`
	`181`	`+[![Read Next](/assets/imgs/next.png)](/chapters/ch06.01-basic-router-implementation.md)`
Original file line number	Diff line number	Diff line change
`@@ -190,4 +190,4 @@ findRoute(path, method) {`
`190`	`190`
`191`	`191`	In both the `addRoute` and `findRoute` methods, we've updated the line that sets and gets the handler for a specific path. Now, the handler is stored in the `handler` map of the current node, with the HTTP method as the key.
`192`	`192`
`193`		`-[![Read Next](/assets/imgs/next.png)](/chapters/ch06.9-ex-dynamic-routing.md)`
	`193`	`+[![Read Next](/assets/imgs/next.png)](/chapters/ch06.09-ex-dynamic-routing.md)`