then - promises javascript w3schools

¿Es ".then(function(a){return a;})" un no-op para las promesas?

Question

Estoy leyendo este tutorial sobre Bookshelf . Estantería utiliza las promesas de Bluebird. Hay bastantes ejemplos que se parecen a esto:

var getEvents = function(participantId) {  
  return new models.Participant()
    .query({where: {id: participantId}})
    .fetch({withRelated: [''events''], require: true})
    .then(function(model) {
      return model;
    });
};

Todavía no me siento cómodo con las promesas, pero por lo que he aprendido hasta ahora esto parece extraño. Mi pregunta es, ¿la función anterior es exactamente la misma que devolver fetch() directamente y dejar el final then() :

var getEvents = function(participantId) {  
  return new models.Participant()
    .query({where: {id: participantId}})
    .fetch({withRelated: [''events''], require: true});
};

Es decir, sigue haciendo lo mismo, devuelve la misma promesa, se puede llamar de la misma manera, etc.

Por lo que entiendo, el parámetro a la función pasada then obtiene el valor de retorno de la promesa anterior en la cadena. Entonces, me parece que .then(function (a) { return a; }) en general es solo un no-op. ¿Correcto?

Si no son lo mismo, ¿cuál es la diferencia? ¿Qué está pasando y por qué el autor lo escribió de esa manera?

Answer 1

Me parece que .then(function (a) { return a; }) es solo un no-op. ¿Correcto?

Sí. ¹

Es inútil y debe omitirse.

¿Qué está pasando y por qué el autor lo escribió de esa manera?

Es un error. O el autor no entendió las promesas.

_{1: Si no son lo mismo, ¿cuál es la diferencia?}

_{Como siempre, hay algunos casos extremos. Realmente raros. Que nadie debería usar (sin comentarios extensos):
a) devuelve una nueva instancia de promesa, un objeto distinto, para evitar compartir. Sin embargo, .then() haría.
b) a se prueba nuevamente para su capacidad de tenabilidad. Si de repente se convirtió en una promesa desde el cumplimiento, ahora será esperado. Esto sería horrible, por supuesto.}

Answer 2

La respuesta de Bergi es correcta, pero solo para demostrar un caso donde no es un no-op aquí hay un ejemplo artificial donde no es un no-op:

o = {};
Promise.resolve(o).then(o => o.then = () => {}); // make thenable
Promise.resolve(o).then(console.log); // logs the object
Promise.resolve(o).then(x => x).then(console.log); // doesn''t log the object

En general, no lo haga then(function(a) { return a; })