Super lightweight level Web framework KOA source code to read

Js is an entry file, which is an Application class inherited from the Emitter class in the Event module. This is where we defined the app instance we created when using KOA.

To analyze a class, you start by looking at its constructor, which defines an array of Middleware, and three properties: Context, Request, and Response, which are defined in three other files. Instead of looking at the other files, think about when we were using KOA. After we created the app instance, the next step was to use various middleware, so let’s look directly at the Use method.

Use receives a middleware function as an argument, does type verification first, and if it is passed a generator, koA2 converts it first with convert (this is for KOA1 compatibility, removed later versions), and does only one thing in the end. Push this function into the Middleware array. The use method finally returns this, which is the KOA instance itself, which means we can implement chained calls.

Set up the middleware, we start the KOA service last step is to call the listen method to set up the listening port, next we will look at the implementation of listen method. Listen is much simpler. It’s only two lines long, but you don’t do anything else. You just call the createServer method under node’s native HTTP module to create the service, and listen sets up the listener, and that’s it. As we all know, HTTP createServer needs to pass in a function that koA returns by calling the callback method.

The callback first uses compose to turn all middleware into a function (the implementation of Compose will also be discussed in detail later). It calls the Emitter listenerCount method to determine whether there are listeners for error events. If the default event-listening method onError is not registered for error events, then it is time to define the function we want to pass into createServer. This function takes req and res, and koA does something to it: The reQ and RES are wrapped into the familiar CTX object by calling the createContext method (what createContext does next), and then CTX and the middleware function fnMiddleware that we handled earlier are passed into the handleRequest method.

In handleRequest, first fetch res, first set the status to 404, then register the success and failure status methods after executing the middleware, call ctx. onError when the failure to catch the exception, call the success respond method to respond the result. The onFinished module is used again. OnFinished ensures that a stream will execute a callback when it closes, completes, and reports an error, passing in our exception handler to handle the error message. The respond method, on the other hand, reads the CTX message, writes the data to the RES and responds to the request. At this point, the whole process is complete.

The result is a function called fnMiddleware, which also has context and next parameters and uses index variables to record which middleware it is currently processing. Then call the Dispatch method from the first. The relationship between the current passed parameter and index is determined. If next is called several times within a middleware, the parameter will be smaller than index, and an error will be reported. After the current middleware to withdraw from an array, each CTX and next to it during the next call dispatch, the parameters for the next place, this will add the middleware in order to come in, finally when I equal to the middleware array length, which is no other middleware, then perform incoming next parameters at the beginning, If fn does not exist, return an empty promise. When the central execution is finished, that is, the next execution of the previous middleware is finished, it will naturally trigger “await” execution downward, and then the execution rights will be returned in reverse order. The final combination result is first from outside to inside, and then from inside to outside, which is the well-known onion circle model.