README
express-class-views
A simple library to add class-based view support for ExpressJS.
If you're familiar with ExpressJS views/routing you're probably accustomed to a pattern like:
let router = express.Router();
router.route('/')
.get(function(req, res, next) {
// Same handler code.
})
.post(function(req, res, next) {
// Same handler code.
});
There are a couple subjective issues here:
- Individual verbs are somewhat awkward to document.
- ExpressJS feels that verbs that aren't explicitly handled should return 404 errors (as opposed to 405 errors).
- Variables pertinent to multiple verb handlers are more difficult to organize.
- OPTIONS handlers need to be manually specified.
All this library does is rectify these behaviors while piggybacking on the otherwise straightforward ExpressJS pattern.
So re-tooling the example above:
const View = require('express-class-views');
class MyView extends View {
get(req, res, next) {
// Same handler code.
}
post(req, res, next) {
// Sample handler code.
}
}
let router = express.Router();
// Generate middleware function for class and map it to "all" HTTP verbs.
router.route('/')
.all(MyView.handler());
// OR
router.route('/')
.use(MyView.handler());
Any verbs (besides OPTIONS which is automatic) which are not specifically defined as a class method will generate a 405
error by way of the http-errors
module.
If you'd like to specify the error library that will be used to create the 405 error (which may affect instanceof
checks elsewhere in your application code) you can pass in the option errors
to the .handler()
static method.
MyView.handler({
errors: require('http-errors')
});
You can also specify a property on the constructor.
MyView.errors = require('http-errors');
The only requirements for these options:
- Needs to be a function.
- Should accept an integer as the first argument to specify which error gets created.
Overriding OPTIONS
The OPTIONS verb will be handled by default and will send a simple Accepts header including all the verbs specified on your view class. You can easily override this behavior by specifying a class method for the OPTIONS verb.
const View = require('express-class-views');
class MyView extends View {
options(req, res, next) {
// Overriding behavior.
}
get(req, res, next) {
// Same handler code.
}
post(req, res, next) {
// Sample handler code.
}
}
Scoping Variables
You can easily tie variables to a particular class inside of a constructor.
const View = require('express-class-views');
class MyView extends View {
constructor() {
this.someVariable = 'foo';
}
get(req, res, next) {
// Same handler code.
this.someVariable === 'foo'; // true
}
}
Whenever you call the class method .handler()
an instance of your view class is created. For every method handler the
context this
will be the instance of your view. So any variables you add in the constructor will be available there.
What's Left
There are still some pain points that may be addressed in future versions.
For instance it's still cumbersome to prepend your class views with middleware to handle behaviors. Let's say you wanted
to check that a request is logged in with some middleware function loginRequred
on all verbs and validate CSRF tokens
with another middleware function csrfValidate
on POST and PUT.
You'd need to do something irritating like:
let router = express.Router();
// Generate middleware function for class and map it to "all" HTTP verbs.
router.route('/')
.all(loginRequired)
.post(csrfValidate)
.put(csrfValidate)
.all(MyView.handler());
There are proposals to future ES specifications that might make this more straightforward with annotations.
@loginRequired
class MyView extends View {
get(req, res, next) {
// Some handler code.
}
@csrfValidate
post(req, res, next) {
// Same handler code.
}
@csrfValidate
put(req, res, next) {
// Same handler code.
}
}
But for now we wait.