You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: docs/standards.md
+15-15
Original file line number
Diff line number
Diff line change
@@ -82,7 +82,7 @@ Things to take note of:
82
82
message: string,
83
83
error: any
84
84
}
85
-
```
85
+
```
86
86
***Wrapping async functions**: Asynchronous middleware must be wrapped with`Util.asyncMiddleware(...)`. This is so that if a `Promise` is rejected, the reject reason is handled gracefully. To understand how this works, please look at the code for`asyncMiddleware`.
87
87
***Organization ofimport statements**: We organize our import statements according to their general function. If a file is a `Service` (such as `user.service.js`), then we place it inside of the `Service` object. This is to make code readability better.
88
88
@@ -201,9 +201,9 @@ Things to take note of:
201
201
* **`activate` function**: Every route file contains one exported function, called `activate`. This takes as input an `ExpressRouter`, to which we will attach the sub router to. We will also define all of the sub-routes in this function.
202
202
* **Chaining middlewares in a route**: We chain middlewares together by placing them one after another as arguments to the http request of the route.
203
203
* **Ordering of middleware**:
204
-
* If input is expected, validation of that input should be done promptly. Therefore validators are generally the first middlewares.
204
+
* If input is expected, validation of that input should be done promptly. Therefore validators are generally the first middlewares.
205
205
* The first middleware should be the validator for the inputted data of a route. In this case, we have the validator for a new account.
206
-
* The next middleware should be `Middleware.parseBody.middleware` to parse the validated information. This middleware also places the data inside of `req.body`. If validation fails, it fails the request.
206
+
* The next middleware should be `Middleware.parseBody.middleware` to parse the validated information. This middleware also places the data inside of `req.body`. If validation fails, it fails the request.
207
207
* The following middlewares will depend on what type of route it is. In this case, we are creating a new item in our database, so we want to create a new `Account` object. This is what `Middleware.Account.parseAccount` does.
208
208
* Finally, we want to interact with the database. This is done either in the `Controller` function, or in another `middleware` function.
209
209
* the last middleware should always be a `Controller` (since we want to respond to the user of the api).
* **async & await**: When the service call is to a mongoose model, they generally return a mongoose query. These can be handled as a promise, and Mongoose has further documentation on it [here](https://mongoosejs.com/docs/api.html). We handle then by using `await` on the service call. For example, a middleware function that uses `findById` would be:
245
+
* **async & await**: When the service call is to a mongoose model, they generally return a mongoose query. These can be handled as a promise, and Mongoose has further documentation on it [here](https://mongoosejs.com/docs/api.html). We handle then by using `await` on the service call. For example, a middleware function that uses `findById` would be:
* Check the output of the service function call for any errors. In the code snippet we need to check for a scenario where the account is not found, which is a 404 error. A full list of the current error messages are in [error.constant.js](../constants/error.constant.js).
265
265
More information on asynchronous functions can be found [here](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function).
266
-
* **queryCallbackFactory**: The query callback factory returns a function that uses winston to log the success or failure of the service call. The callback factory is used for mongoose service calls.
266
+
* **logQuery**: This function wraps the query's `then` method and uses winston to log the success or failure of the mongoose service call.
267
267
268
268
### Test files
269
269
@@ -281,7 +281,7 @@ We repopulate the test server before each test to ensure consistency. [setup.spe
281
281
282
282
##### Motivation
283
283
284
-
We wanted to have a scalable way to create new entities that properly reference each other. The biggest challenge lied in creating enough accounts that can be properly referenced during specific tests.
284
+
We wanted to have a scalable way to create new entities that properly reference each other. The biggest challenge lied in creating enough accounts that can be properly referenced during specific tests.
285
285
286
286
##### Util.js
287
287
@@ -309,7 +309,7 @@ let hackerAccounts = {
309
309
};
310
310
```
311
311
312
-
In this example the `new` accounts are accounts that exist, but the hacker objects have not been created. The `stored.team` accounts are those linked to a hacker object that is in a team. The `stored.noTeam` accounts link to a hacker that is not in a team. The `invalid` accounts are created accounts that are linked to a hacker object that does not fit with the Hacker schema. The invalid accounts are used to test fail cases. The value for each key is an array of account objects.
312
+
In this example the `new` accounts are accounts that exist, but the hacker objects have not been created. The `stored.team` accounts are those linked to a hacker object that is in a team. The `stored.noTeam` accounts link to a hacker that is not in a team. The `invalid` accounts are created accounts that are linked to a hacker object that does not fit with the Hacker schema. The invalid accounts are used to test fail cases. The value for each key is an array of account objects.
313
313
314
314
On the other end of the account-hacker link, [hacker.util.js](../tests/util/hacker.test.util.js) contains the hacker data in the form of hacker objects. These hacker objects have an `accountId` attribute which references an account's `_id`. The matching between the hacker object and the respective account object it needs to link to is also done by nomenclature. For example, a hacker on a team would be called `TeamHackerX` where X is a number. This hacker's account object would be within the array specified by `hackerAccounts.stored.team`. The specific account object is referenced by its index in the array. That index is the same as the value X in the name of the hacker object.
It's important to note the use of `setProperValidationChainBuilder` to parse the input value from the appropriate input location. This is consistent across generic validators. It is also important to create a validator for situations where the input is optional.
337
337
338
-
A validator example, using generic validator functions.
338
+
A validator example, using generic validator functions.
339
339
```javascript
340
340
"use strict";
341
341
constVALIDATOR=require("./validator.helper");
@@ -358,7 +358,7 @@ module.exports = {
358
358
};
359
359
```
360
360
361
-
A route would use a validator in the following manner:
361
+
A route would use a validator in the following manner:
362
362
```javascript
363
363
accountRouter.route("/:id").patch(
364
364
...
@@ -377,8 +377,8 @@ A route would use a validator in the following manner:
377
377
{
378
378
"A":"foo",
379
379
"B":true,
380
-
"C": {
381
-
"bar":"baz"
380
+
"C": {
381
+
"bar":"baz"
382
382
}
383
383
}
384
384
```
@@ -429,4 +429,4 @@ We use apidoc.js to generate documentation for the API. This documentation is fo
429
429
430
430
For more info on how to write your own documentation, see their docs: <http://apidocjs.com/>.
431
431
432
-
To update the docs, run: `npm run docs`. Make sure that the version number for each route is correct!
432
+
To update the docs, run: `npm run docs`. Make sure that the version number for each route is correct!
0 commit comments