Make feathers-hooks part of core and service events a hook

[daffl]

The feathers-hooks plugin has become such an essential part of Feathers that it should probably become a core dependency. A good time to implement this is when removing callback support in both, hooks and services in Feathers v3.

This would also allow us to improve the service event dispatching by turning it into a hook (that always runs last) instead of a separate mixin (where the same functionality is currently provided by a different dependency Rubberduck).

Related issues:

• hook.app is undefined in Event filters #405 and Create an app reference on service event hook object #406 are related to this but not completely solve the problem because the hook object in a service event is not the same as during the method call (which it should be).
• Hooks do not apply for realtime events #376 can also be solved with this since it would then allow us to set the data that need to be dispatched in the hook
• Also addresses Event channels/rooms #388 (specifically Event channels/rooms #388 (comment)) since you can set the dispatch data already in the hook which also allows to simplify and make event filtering more performant.

[beeplin]

👍
Agree that the more quality hooks integrated into core, the better. Hooks are too vital to be scattered all around, and then we won't have to write or search for them by ourselves any more. :)

and also agree that server-event-emitting can be treated as a kind of hooks. Actually I found hooks and server-event-filters are quite similar: hooks get something done under some situations; filters get something(event broadcasting) not done under some situations.

Before the filters become hooks, I would like to suggest adding 'feather generate filter' to the cli tool, since I find myself always writing the same filter structuring code (just like hooks/index.js) over and over again.

[daffl]

Filters (with some sane defaults) are definitely going to be added in the next version of the CLI.

I don't think we'll add any built in hooks to core, instead it probably makes most sense to consolidate them all in https://github.com/feathersjs/feathers-hooks-common (unless they are specific to the plugin, e.g. for feathers-authentication).

[petermikitsh]

This sounds like a fantastic idea, treating service events as hooks. I have a use case where I only want to send changed properties over the wire for patched service events. If the filter functions were hooks, it might make that easier to implement.

[subodhpareek18]

I have a use case where I only want to send changed properties over the wire for patched service events. If the filter functions were hooks, it might make that easier to implement.

@petermikitsh I have the exact use case. Were you able to figure out a solution for this with the current system?

[daffl]

You can already create a hook that does a diff with the previous data like this:

app.service('myservice').hooks({
  before: {
    patch(hook) {
      return hook.service.get(hook.id).then(previous => {
        hook.previousData = previous;

        return hook;
      });
    }
  },

  after: {
    patch(hook) {
      hook.result = diff(hook.result, hook.previousData);
    }
  }
});

[eddyystop]

I've been happy with npm deep-diff for diff'ing nested objects.

[lock]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue with a link to this issue for related bugs.