Notes on regular hooks support

[vonagam]

1. fromErrorHooks vs .map(fromErrorHook):
Initially there were only fromErrorHooks which were backwards compatible with feathers 4 error hooks - they all run in a single catch() call, so if one of them throws too then others do not run. I added fromErrorHook as a utility that person can use to get a single catch() hook. So if you do .map(fromErrorHook) then you get a bunch of catch() calls, not one as before.

I'm ok with this breaking change, but I assume that you are not and that it might have been overlooked. (If it was deliberate decision than all is good.)

2. Who should go first afterHooks or beforeHooks?
Small thing, but I think it is better for beforeHooks to run before afterHooks since there is no point to call an after hook if a before hook throws, it will just add noise to a trace. (I'm talking about this line.)

3. type should be required in runHook internal util:
It was optional for fromHooks and required for fromHook since there are no fromHooks now, type should be non-optional argument and if (type) can be simply removed. (This of course depends on the resolution for first point, if fromHooks will be back than this one needs no change.)

4. Propagation of bad practice with support for returning {...context}:
As I said in #1443 and #2462 supporting for returning new context object from a regular hook is a wrong choice (no upside beside backwards compatibility for obscure feature and a lot of downside). Now it tries to migrate from feathers into hooks. Additional example for why it is not right way: in a hook manager there is props() method with which you can set additional properties on a context, but props() does not simply Object.assign passed properties, it copies property descriptors, allowing for readonly and getters/setters things. Support for practice of {...context} goes against this, since all of those descriptors will be lost and will lead to bugs when those props get used before a cloned context is returned. (Thought about it when was looking how to migrate context.statusCode into context.http.statusCode with getters/setters.)

[marshallswain]

These are all valid points that I missed.

1. We'll take a look in our next pairing session. It wasn't done deliberately.
2. Good point. Agreed.
3. Noted. Will update.
4. We'll talk about this one, too.