nodejs fonctionne ensuite dans express

Cette fois, je vais vous présenter nodejs pour fonctionner ensuite en express. Quelles sont les précautions pour que nodejs fonctionne ensuite en express. Ce qui suit est un cas pratique, jetons un coup d'œil.

Je crois que beaucoup de gens ne savent pas grand-chose de next in express dans nodejs. La plupart des gens ne savent pas ce que fait next et dans quelles circonstances il est utilisé. introduction. Si vous êtes intéressé, apprenons à l’utiliser.

Récemment, l'entreprise a utilisé Node pour séparer le front-end et le back-end. Le framework Web utilisé est express, j'ai donc une compréhension approfondie du framework express. J'ai écrit un article sur le routage express il y a quelque temps, mais il semble que ce soit le cas. Il y a une chose importante qui manque dans cet article. Le contenu est le prochain d'Express, donc aujourd'hui, je parlerai du prochain d'Express séparément.

Concernant la suite, je vais l'expliquer principalement à partir de trois points :

• Quelle est la fonction de next ?

• Quand devrions-nous l'utiliser ensuite ?

• Quel est le mécanisme de mise en œuvre interne de next ?

Le rôle du Suivant

Lorsque nous définissons la fonction expressmiddleware, nous définirons le troisième paramètre comme next. Ce next est notre protagoniste aujourd'hui. La fonction suivante est principalement responsable de transmettre le contrôle au middleware suivant si le. La requête n'est pas terminée par le logiciel et next n'est pas appelée, la requête sera suspendue et le middleware défini ultérieurement n'aura aucune chance d'être exécuté.

Quand utiliser Suivant

D'après la description ci-dessus, nous savons déjà que la fonction suivante est principalement utilisée pour garantir que tous les middlewares enregistrés sont exécutés les uns après les autres. Ensuite, nous devrions appeler la fonction suivante dans tous les middlewares, mais il y a un cas particulier si nous définissons le middleware. termine cette requête, donc la fonction suivante ne doit pas être appelée à nouveau, sinon des problèmes pourraient survenir. Jetons un coup d'œil au code

app.get('/a', function(req, res, next) {
  res.send('sucess');
  next();
});
// catch 404 and forward to error handler
app.use(function(req, res, next) {
 console.log(404);
 var err = new Error('Not Found');
 err.status = 404;
 next(err);
});
app.use(function(err, req, res, next) {
 res.status(err.status || 500);
 res.render('error', {
  message: err.message,
  error: {}
 });
});

. Envoyer la requête "/a", le journal d'impression de la console est le suivant :

404
GET /a 500 6.837 ms - -
Error: Can't set headers after they are sent.
  at ServerResponse.OutgoingMessage.setHeader (_http_outgoing.js:345:11)

Pourquoi le code lève-t-il une exception ?C'est parce que nous avons appelé la fonction suivante après res.send.Bien que notre requête ait été terminée, le middleware 404 suivant sera toujours exécuté et le middleware suivant essaiera d'accéder à res. aux en-têtes, donc l'exception ci-dessus sera levée.

Après avoir lu ceci, vous vous posez peut-être une question : si je n'appelle pas la fonction suivante après res.send, le middleware 404 défini plus tard ne sera-t-il jamais exécuté ? Maintenant, nous supprimons le prochain appel de fonction après res.send et envoyons la requête "/xxx", nous constaterons que le middleware 404 est exécuté, (ㄒoㄒ), n'est-ce pas contradictoire avec ce que nous avons dit précédemment, notre personnalisation Le le middleware n'appelle pas ensuite, mais le middleware défini plus tard est toujours exécuté. Pourquoi ? Il semble que nous ne pouvons demander de l'aide qu'au code source~~~

Le mécanisme interne de Next

function next(err) {
  ... //此处源码省略
  // find next matching layer
  var layer;
  var match;
  var route;
  while (match !== true && idx < stack.length) {
   layer = stack[idx++];
   match = matchLayer(layer, path);
   route = layer.route;
   if (typeof match !== 'boolean') {
    // hold on to layerError
    layerError = layerError || match;
   }
   if (match !== true) {
    continue;
   }
   ... //此处源码省略
  }
 ... //此处源码省略
  // this should be done for the layer
  if (err) {
    layer.handle_error(err, req, res, next);
  } else {
   layer.handle_request(req, res, next);
  }
 }

Ce qui précède est le code source de next in express. Afin d'expliquer le problème plus facilement, le code a été supprimé. À partir du code source ci-dessus, nous pouvons constater qu'il y a une boucle while à l'intérieur de la fonction suivante. Chaque boucle supprimera une couche de la pile. Cette couche contient des informations de routage et de middleware, puis la couche et. Le chemin demandé correspondra. Si la correspondance réussit, layer.handle_request sera exécuté et la fonction middleware sera appelée. Mais si la correspondance échoue, la couche suivante (c'est-à-dire le middleware) sera bouclée.

Nous pouvons maintenant expliquer le problème soulevé ci-dessus, pourquoi la fonction suivante n'est pas appelée dans notre middleware personnalisé, mais le middleware 404 suivant sera toujours exécuté car le "/xxx" que nous avons demandé ne correspond pas à celui que nous avons enregistré "/a". achemine le middleware, de sorte que la boucle while continuera à s'exécuter. Si le middleware 404 correspondant réussit, le middleware 404 sera exécuté.

Remarque : Pour les middlewares enregistrés avec app.use, si le paramètre path est vide, sa valeur par défaut est "/", et les middlewares avec un chemin de "/" correspondent à toutes les requêtes par défaut.

Une chose est à souligner en particulier. En effet, lorsque l'on définit un middleware de routage , le troisième paramètre next de la fonction n'est pas le même next que le troisième paramètre next de la fonction lorsque l'on définit un middleware de non-routage. Ce que vous voyez ci-dessus est la prochaine fonction du middleware sans routage, et la prochaine fonction du middleware de routage est comme ceci

function next(err) {
  if (err && err === 'route') {
   return done();
  }
  var layer = stack[idx++];
  if (!layer) {
   return done(err);
  }
  if (layer.method && layer.method !== method) {
   return next(err);
  }
  if (err) {
   layer.handle_error(err, req, res, next);
  } else {
   layer.handle_request(req, res, next);
  }
 }

这个next比上边的那个next要简单很多，它负责同一个路由的多个中间件的控制权的传递，并且它会接收一个参数"route"，如果调用next(“route”)，则会跳过当前路由的其它中间件，直接将控制权交给下一个路由。

最后有必要再说一说next(err)，next(err)是如何将控制权传递到错误处理中间件的，从前边的代码我们知道，当调用next(err)是，express内部会调用layer.handle_error，那我们来看看它的源码

Layer.prototype.handle_error = function handle_error(error, req, res, next) {
 var fn = this.handle;
 if (fn.length !== 4) {
  // not a standard error handler
  return next(error);
 }
 try {
  fn(error, req, res, next);
 } catch (err) {
  next(err);
 }
};

代码中的fn就是中间件函数，express会对fn的参数个数进行判断，如果参数个数不等于4则认为不是错误处理中间件，则继续调用next(err)，这样就会进入到下一个中间件函数，继续进行参数个数判断，如此方式一直到某个中间件函数的参数个数是4，就认为找到了错误处理中间件，然后执行此中间件函数。

相信看了本文案例你已经掌握了方法，更多精彩请关注php中文网其它相关文章！

推荐阅读：

Express Session实现登录验证功能（附代码）

js面向对象深入理解

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!