feat: several improvements, merge the latest changes

content/components.md

@@ -2,7 +2,7 @@
 
 Providers are a fundamental concept in Nest. Many of the basic Nest classes may be treated as a provider – services, repositories, factories, helpers, and so on. The main idea of a provider is that it can be **injected** as a dependency; this means objects can create various relationships with each other, and the function of "wiring up" these objects can largely be delegated to the Nest runtime system.
 
-<figure><img src="/assets/Components_1.png" /></figure>
+<figure><img class="illustrative-image" src="/assets/Components_1.png" /></figure>
 
 In the previous chapter, we built a simple `CatsController`. Controllers should handle HTTP requests and delegate more complex tasks to **providers**. Providers are plain JavaScript classes that are declared as `providers` in a [module](/modules).
 

content/controllers.md

@@ -2,7 +2,7 @@
 
 Controllers are responsible for handling incoming **requests** and returning **responses** to the client.
 
-<figure><img src="/assets/Controllers_1.png" /></figure>
+<figure><img class="illustrative-image" src="/assets/Controllers_1.png" /></figure>
 
 A controller's purpose is to receive specific requests for the application. The **routing** mechanism controls which controller receives which requests. Frequently, each controller has more than one route, and different routes can perform different actions.
 

content/exception-filters.md

@@ -3,7 +3,7 @@
 Nest comes with a built-in **exceptions layer** which is responsible for processing all unhandled exceptions across an application. When an exception is not handled by your application code, it is caught by this layer, which then automatically sends an appropriate user-friendly response.
 
 <figure>
-  <img src="/assets/Filter_1.png" />
+  <img class="illustrative-image" src="/assets/Filter_1.png" />
 </figure>
 
 Out of the box, this action is performed by a built-in **global exception filter**, which handles exceptions of type `HttpException` (and subclasses of it). When an exception is **unrecognized** (is neither `HttpException` nor a class that inherits from `HttpException`), the built-in exception filter generates the following default JSON response:

content/first-steps.md

@@ -4,7 +4,7 @@ In this set of articles, you'll learn the **core fundamentals** of Nest. To get
 
 #### Language
 
-We're in love with [TypeScript](https://www.typescriptlang.org/), but above all - we love [Node.js](https://nodejs.org/en/). That's why Nest is compatible with both TypeScript and **pure JavaScript**. Nest takes advantage of the latest language features, so to use it with vanilla JavaScript we need a [Babel](https://babeljs.io/) compiler.
+We're in love with [TypeScript](https://www.typescriptlang.org/), but above all - we love [Node.js](https://nodejs.org/en/). That's why Nest is compatible with both TypeScript and pure JavaScript. Nest takes advantage of the latest language features, so to use it with vanilla JavaScript we need a [Babel](https://babeljs.io/) compiler.
 
 We'll mostly use TypeScript in the examples we provide, but you can always **switch the code snippets** to vanilla JavaScript syntax (simply click to toggle the language button in the upper right hand corner of each snippet).
 

content/fundamentals/lifecycle-events.md

@@ -6,7 +6,7 @@ A Nest application, as well as every application element, has a lifecycle manage
 
 The following diagram depicts the sequence of key application lifecycle events, from the time the application is bootstrapped until the node process exits. We can divide the overall lifecycle into three phases: **initializing**, **running** and **terminating**. Using this lifecycle, you can plan for appropriate initialization of modules and services, manage active connections, and gracefully shutdown your application when it receives a termination signal.
 
-<figure><img src="/assets/lifecycle-events.png" /></figure>
+<figure><img class="illustrative-image" src="/assets/lifecycle-events.png" /></figure>
 
 #### Lifecycle events
 

content/guards.md

@@ -2,7 +2,7 @@
 
 A guard is a class annotated with the `@Injectable()` decorator, which implements the `CanActivate` interface.
 
-<figure><img src="/assets/Guards_1.png" /></figure>
+<figure><img class="illustrative-image" src="/assets/Guards_1.png" /></figure>
 
 Guards have a **single responsibility**. They determine whether a given request will be handled by the route handler or not, depending on certain conditions (like permissions, roles, ACLs, etc.) present at run-time. This is often referred to as **authorization**. Authorization (and its cousin, **authentication**, with which it usually collaborates) has typically been handled by [middleware](/middleware) in traditional Express applications. Middleware is a fine choice for authentication, since things like token validation and attaching properties to the `request` object are not strongly connected with a particular route context (and its metadata).
 

content/interceptors.md

@@ -2,7 +2,7 @@
 
 An interceptor is a class annotated with the `@Injectable()` decorator and implements the `NestInterceptor` interface.
 
-<figure><img src="/assets/Interceptors_1.png" /></figure>
+<figure><img class="illustrative-image" src="/assets/Interceptors_1.png" /></figure>
 
 Interceptors have a set of useful capabilities which are inspired by the [Aspect Oriented Programming](https://en.wikipedia.org/wiki/Aspect-oriented_programming) (AOP) technique. They make it possible to:
 

content/microservices/basics.md

@@ -4,7 +4,7 @@ In addition to traditional (sometimes called monolithic) application architectur
 
 In Nest, a microservice is fundamentally an application that uses a different **transport** layer than HTTP.
 
-<figure><img src="/assets/Microservices_1.png" /></figure>
+<figure><img class="illustrative-image" src="/assets/Microservices_1.png" /></figure>
 
 Nest supports several built-in transport layer implementations, called **transporters**, which are responsible for transmitting messages between different microservice instances. Most transporters natively support both **request-response** and **event-based** message styles. Nest abstracts the implementation details of each transporter behind a canonical interface for both request-response and event-based messaging. This makes it easy to switch from one transport layer to another -- for example to leverage the specific reliability or performance features of a particular transport layer -- without impacting your application code.
 

content/microservices/redis.md

@@ -2,7 +2,7 @@
 
 The [Redis](https://redis.io/) transporter implements the publish/subscribe messaging paradigm and leverages the [Pub/Sub](https://redis.io/topics/pubsub) feature of Redis. Published messages are categorized in channels, without knowing what subscribers (if any) will eventually receive the message. Each microservice can subscribe to any number of channels. In addition, more than one channel can be subscribed to at a time. Messages exchanged through channels are **fire-and-forget**, which means that if a message is published and there are no subscribers interested in it, the message is removed and cannot be recovered. Thus, you don't have a guarantee that either messages or events will be handled by at least one service. A single message can be subscribed to (and received) by multiple subscribers.
 
-<figure><img src="/assets/Redis_1.png" /></figure>
+<figure><img class="illustrative-image" src="/assets/Redis_1.png" /></figure>
 
 #### Installation
 

content/middlewares.md

@@ -2,7 +2,7 @@
 
 Middleware is a function which is called **before** the route handler. Middleware functions have access to the [request](https://expressjs.com/en/4x/api.html#req) and [response](https://expressjs.com/en/4x/api.html#res) objects, and the `next()` middleware function in the application’s request-response cycle. The **next** middleware function is commonly denoted by a variable named `next`.
 
-<figure><img src="/assets/Middlewares_1.png" /></figure>
+<figure><img class="illustrative-image" src="/assets/Middlewares_1.png" /></figure>
 
 Nest middleware are, by default, equivalent to [express](https://expressjs.com/en/guide/using-middleware.html) middleware. The following description from the official express documentation describes the capabilities of middleware:
 

content/modules.md

@@ -2,7 +2,7 @@
 
 A module is a class annotated with a `@Module()` decorator. The `@Module()` decorator provides metadata that **Nest** makes use of to organize the application structure.
 
-<figure><img src="/assets/Modules_1.png" /></figure>
+<figure><img class="illustrative-image" src="/assets/Modules_1.png" /></figure>
 
 Each application has at least one module, a **root module**. The root module is the starting point Nest uses to build the **application graph** - the internal data structure Nest uses to resolve module and provider relationships and dependencies. While very small applications may theoretically have just the root module, this is not the typical case. We want to emphasize that modules are **strongly** recommended as an effective way to organize your components. Thus, for most applications, the resulting architecture will employ multiple modules, each encapsulating a closely related set of **capabilities**.
 

content/pipes.md

@@ -3,7 +3,7 @@
 A pipe is a class annotated with the `@Injectable()` decorator, which implements the `PipeTransform` interface.
 
 <figure>
-  <img src="/assets/Pipe_1.png" />
+  <img class="illustrative-image" src="/assets/Pipe_1.png" />
 </figure>
 
 Pipes have two typical use cases:

content/websockets/gateways.md

@@ -4,7 +4,7 @@ Most of the concepts discussed elsewhere in this documentation, such as dependen
 
 In Nest, a gateway is simply a class annotated with `@WebSocketGateway()` decorator. Technically, gateways are platform-agnostic which makes them compatible with any WebSockets library once an adapter is created. There are two WS platforms supported out-of-the-box: [socket.io](https://github.com/socketio/socket.io) and [ws](https://github.com/websockets/ws). You can choose the one that best suits your needs. Also, you can build your own adapter by following this [guide](/websockets/adapter).
 
-<figure><img src="/assets/Gateways_1.png" /></figure>
+<figure><img class="illustrative-image" src="/assets/Gateways_1.png" /></figure>
 
 > info **Hint** Gateways can be treated as [providers](/providers); this means they can inject dependencies through the class constructor. Also, gateways can be injected by other classes (providers and controllers) as well.
 

src/app/common/social-wrapper/social-wrapper.component.html

@@ -27,4 +27,5 @@
      rel="nofollow">
     <i class="fa-brands fa-discord"></i>
   </a>
+  <app-theme-mode-toggle></app-theme-mode-toggle>
 </div>

src/app/common/social-wrapper/social-wrapper.component.scss

@@ -1,11 +1,11 @@
-@import '../../../scss/variables.scss';
 @import '../../../scss/utils.scss';
 
 .social-wrapper {
   @extend .center-top;
   float: right;
   padding-right: 40px;
   position: relative;
+  display: flex;
 
   a {
     @extend .transition-fast;
@@ -21,15 +21,15 @@
       position: relative;
 
       &:hover {
-        fill: $red-color;
+        fill: var(--primary);
       }
     }
 
     &:first-of-type {
       font-size: 20px;
     }
     &:hover {
-      color: $red-color;
+      color: var(--primary);
     }
   }
   @include media(medium) {

src/app/homepage/footer/footer.component.scss

@@ -4,7 +4,7 @@
 :host {
   @extend .transition;
   @extend .box-sizing;
-  background: variables.$black-color;
+  background: var(--header-background);
   display: block;
   padding: 40px 0;
   margin: 0 -85px;
@@ -34,15 +34,13 @@ footer {
   text-align: center;
 
   a {
-    color: variables.$red-color;
+    color: var(--primary-5dp);
     font-weight: 600;
 
     @include utils.text-gradient();
 
     &:hover {
-      color: variables.$red-color;
       background: #fff;
-
     }
   }
 
@@ -73,12 +71,13 @@ footer {
     font-size: 20px;
     margin-left: 15px;
     cursor: pointer;
+    color: #fff;
 
     &:first-of-type {
       font-size: 20px;
     }
     &:hover {
-      color: variables.$red-color;
+      color: var(--primary);
     }
   }
 

src/app/homepage/header/header.component.scss

@@ -2,10 +2,14 @@
 @use '../../../scss/utils';
 
 :host {
+  background: var(--header-background);
+  display: block;
+  width: 100%;
+  height: 70px;
   position: fixed;
   z-index: 10000;
   width: 100%;
-  height: 105px;
+  height: 70px;
 
   @media print {
     position: relative;
@@ -46,7 +50,7 @@
 header {
   display: block;
   position: relative;
-  background: variables.$black-color;
+  background: var(--header-background);
   width: 100%;
   height: 70px;
   z-index: 10000;
@@ -129,7 +133,7 @@ header {
   padding: 14px 25px;
 
   @media (min-width: 1500px) {
-    margin-right: 80px;
+    margin-right: 30px;
   }
 
   @media (max-width: 1499px) {
@@ -142,8 +146,12 @@ header {
     }
   }
 
-  @media (max-width: 1250px) {
+  @media (max-width: 1350px) {
     padding: 14px 5px;
+
+    li:nth-of-type(3) {
+      display: none;
+    }
   }
 
   @media (max-width: 1150px) {
@@ -213,7 +221,7 @@ header {
     font-weight: 600;
 
     &:hover {
-      color: variables.$red-color;
+      color: var(--primary-4dp);
     }
   }
   @media print {
@@ -274,9 +282,9 @@ header {
     position: relative;
 
     &:hover {
-      color: variables.$red-color;
+      color: var(--primary);
       &::after {
-        background: variables.$red-color;
+        background: var(--primary);
       }
     }
 
@@ -390,11 +398,11 @@ header {
 
   &:active,
   &:focus {
-    border-bottom-color: variables.$red-color;
+    border-bottom-color: var(--primary);
     width: 190px;
   }
 
-  @media (min-width: 1200px) and (max-width: 1300px) {
+  @media (max-width: 1300px) {
     width: 190px;
   }
 }
@@ -459,7 +467,7 @@ header {
   &::after,
   &::before {
     content: '';
-    background: variables.$red-color;
+    background: var(--primary);
     display: block;
     height: 2px;
     position: absolute;