Custom service events

[daffl]

As discussed in #108 it would be nice to allow custom events on services. As an example, a payment service might want to notify the user about the process during payments by emitting log events:

var paymentService = {
  events: [ 'log' ],

  create(data, params) {
    var log = message => this.emit('log', { message: message, user: params.user });
    var errorHandler = error => log(`There was an error processing your payment: ${error.message}`);

    return addCreditCard(data.cc).then(cc => {
      log(`Credit card ${cc.displayName} added successfully`);

      return processPayment(data).then(paymentInfo => {
        log(`Payment of ${paymentInfo.amount}.- successful!`);

        return paymentInfo
      });
    }).fail(errorHandler);
  }
};

app.use('/payments', paymentService);

And on the client we could do:

socket.on('payments log', function(data) {
  $('#payment .logs').append(`<li>${data.message}</li>`);
});

And also generalize event filtering which helps decide to decide what events to dispatch where:

let paymentService = app.service('payments');

paymentService.filter('updated', function(data, params, callback) {
  if(data.company_id !== params.user.company_id) {
    return callback(null, false);
  }

  return callback(null, data);
});

paymentService.filter('log', function(data, params, callback) {
  if(data.user.id !== params.user.id) {
    return callback(null, false);
  }

  return callback(null, data.message);
});

[daffl]

The default behaviour for updated, patched, created and removed events is currently to dispatch them to every connected client. You probably do not want that in any application which currently means you have to always add a filter. It would probably also make sense to have a filter that is applied to everything by default (which e.g. checks if the connected user is the same as the user set in the data).

The default for events should be to not dispatch at all until you add a filter. Unfortunately that would be a breaking change and could only be introduced in version 2.

[marshallswain]

Maybe the current default behavior for events could be moved into a plugin? Maybe a dedicated page for creating plugin would be a good thing for the new site. I need to re-read the entire site. It seems like quite a bit has been added since my last read.

[daffl]

Actually I think for Feathers 2, the providers (feathers.rest, feathers.socketio, feathers.primus maybe feathers.zerorpc) should be moved into their own plugins. Then yes, adding event handling separately would make sense (e.g. those plugins would depend on feathers-events or the core would depend on some kind of events plugin).

For 1.1 we'll have to add this into the core and also keep backwards compatibility with the updated(data, params, callback) etc. methods.