# Title: View Plugin Development

In most cases, we need to read the data, render the template and then present it to the user. The framework does not force the use of a template engine, allowing developers to select the template themselves. For details, see Template Rendering.

This article describes the framework's specification constraints on the View plugin, and we can use this to encapsulate the corresponding template engine plugin. The following takes egg-view-ejs as an example

# Plugin directory structure

├── config
│ ├── config.default.js
│ └── config.local.js
├── lib
│ └── view.js
├── app.js
├── test
├── History.md
├── README.md
└── package.json

# Plugin naming convention

"name": "egg-view-ejs",
"eggPlugin": {
"name": "ejs"
"keywords": ["egg", "egg-plugin", "egg-view", "ejs"]
// config/config.default.js
module.exports = {
ejs: {}

# View base class

The next step is to provide a View base class that will be instantiated on each request.

The base class of the View needs to provide render and renderString methods and supports generator and async functions (it can also be a function that returns a Promise). The render method is used to render files, and the renderString method is used to render template strings.

The following is a simplified code that can be directly view source

const ejs = require('ejs');

Mmdule.exports = class EjsView {
render(filename, locals) {
return new Promise((resolve, reject) => {
// Asynchronous API call
ejs.renderFile(filename, locals, (err, result) => {
if (err) {
} else {

renderString(tpl, locals) {
try {
// Synchronous API call
return Promise.resolve(ejs.render(tpl, locals));
} catch (err) {
return Promise.reject(err);

# Parameters

The three parameters of the render method are

The three parameters of the renderString method

# Plugin configuration

According to the naming conventions mentioned above, the configuration name is generally the name of the template engine, such as ejs

The configuration of the plugin mainly comes from the configuration of the template engine, and the configuration items can be defined according to the specific conditions, such as the configuration of ejs

// config/config.default.js
module.exports = {
ejs: {
cache: true

# Helper

The framework provides ctx.helper for developer use, but in some cases we want to override the helper method and only take effect when the template is rendered.

In template rendering, we often need to output a user-supplied html fragment, in which case, we often use the helper.shtml provided by the egg-security plugin.

<div>{{ helper.shtml(data.content) | safe }}</div>

However, as shown in the above code, we need to use | safe to tell the template engine that the html is safe and it doesn't need to run escape again.

This is more cumbersome to use and easy to forget, so we can package it:

First provide a helper subclass:

// {plugin_root}/lib/helper.js
module.exports = app => {
return class ViewHelper extends app.Helper {
// safe is injected by [egg-view-nunjucks] and will not be escaped during rendering.
// Otherwise, the template call shtml will be escaped
shtml(str) {
return this.safe(super.shtml(str));

Use a custom helper when rendering

// {plugin_root}/lib/view.js
const ViewHelper = require('./helper');

module.exports = class MyCustomView {
render(filename, locals) {
locals.helper = new ViewHelper(this.ctx); // call Nunjucks render

You can view the specific code here

Templates and security are related and egg-security also provides some methods for the template. The template engine can be used according to requirements.

First declare a dependency on egg-security

"name": "egg-view-nunjucks",
"eggPlugin": {
"name": "nunjucks",
"dep": ["security"]

The framework provides app.injectCsrf and app.injectNonce, for more information on security section.

# Unit tests

As a high-quality plugin, perfect unit testing is indispensable, and we also provide a lot of auxiliary tools to make it painless for plugin developers to write tests, see unit testing and plugin docs.