[discussion] maybe change the name of the context parameter from 'hook' to 'context' or use 'this' in the future?

[beeplin]

Currently the hook function written as (hook) => {...; return hook; } is somehow confusing for many new users. The term hook has two meanings here: the function itself is called a hook or a hook function, but the context parameter passed into the hook function is also called hook.

In fact the parameter naming is arbitrary, and calling it hook is just a convention or a tradition of feathers which is initiated in the official docs. So I propose to (in the future) change the docs and rename it to something more clear, like context or so. So people use context.app, context.path etc. instead of hook.app, hook.path.

Another possible options is to use this instead of a parameter to pass the context object into the hook function. So people just use this.app or this.path ... I know this in hook function used to point to the current service object, so this might have some backward compatibility issues. But on the other hand, today we have the new syntax of arrow functions => which keepsthis and we don't need to manually bind this again and again, which makes the use of this in such situation quite concise and elegant and appealing.

[eddyystop]

People seem to just not like using this. That is the main reason hook.service was introduced.

I've also run into (transpiling?) issues passing params with .call(). See feathersjs-ecosystem/feathers-hooks-common#140 (comment) and feathersjs-ecosystem/feathers-hooks-common#116 . Thew problem is either me or Babel.

Your comments about 'rationalizing' naming have always been spot on. However it may be wiser to not use this.

[beeplin]

hmmm, I have never used hooks with babel... I agree this might be confusing too and sometimes problematic. How do you think of renaming it to context?

[marshallswain]

I like the separation of hook = function. context = hook object

[eddyystop]

context doesn't carry much meaning, so we can do better. Maybe something like request, even package suggests the thing gets passed along.

[beeplin]

I have been considering request and response before, but I doubt request might be too narrow since we also use the term in after hooks and request.result doesn't make any sense. If we use response in after hooks instead, then response.data seems weird too. And they can also be confusing since express/feathers middleware use request/response for something different, and we often have hooks and middleware in the one project at the same time.

context Is the best I can think of so far. Many projects use context in similar circumstances such as vue, ajv and etc.

[daffl]

I do like context. The problem with using this is that it already is the service the hook is running on and you can't set this in ES6 arrow functions (which is one of the reasons we added the .service property). I think request is too confusing with the HTTP request/response terminology.

[ekryski]

FWIW I 100% agree with @daffl's comment. I'd like to see context. Also, related feathersjs/feathers#562

[eddyystop]

I'm thinking about non-English speakers. Would `state` be easier to understand?

…

On Wed, May 10, 2017 at 12:39 PM, Eric Kryski ***@***.***> wrote: FWIW I 100% agree with @daffl <https://github.com/daffl>'s comment. I'd like to see context. Also, related feathersjs/feathers#562 <feathersjs/feathers#562> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#159 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABeznxs8oW7G6gJfce3jlvOtYnQ8IM7vks5r4ehZgaJpZM4NRpRI> .

[beeplin]

As a non English speaker I think state might be more ambiguous than context. Context has one and only one specific meaning which is easier to understand.

[eddyystop]

The renaming has started with feathersjs-ecosystem/feathers-hooks-common#200 .

An issue has been created for the rest feathersjs-ecosystem/feathers-hooks-common#201 .