feat(feathers): add defineHooks utility#2761
feat(feathers): add defineHooks utility#2761fratzinger wants to merge 1 commit intofeathersjs:dovefrom
Conversation
|
I like the idea. Wondering if the utility is necessary if we instead just type the hook map as export const userHooks: HookMap<Application, UserService> = {
around: []
}Would that have the same effect? The error might have something to do with how |
|
Mostly same effect. Pros
Cons
|
|
In #2772 I changed the generated service and hook registration to import { authenticate } from '@feathersjs/authentication'
import type { Application } from '../../../../declarations'
import { TestingService, getOptions } from './test.class'
export * from './test.class'
// A configure function that registers the service and its hooks via `app.configure`
export const testing = (app: Application) => {
// Register our service on the Feathers application
app.use('path/to/test', new TestingService(getOptions(app)), {
// A list of all methods this service exposes externally
methods: ['find', 'get', 'create', 'update', 'patch', 'remove'],
// You can add additional custom events to be sent to clients here
events: []
})
// Initialize hooks
app.service('path/to/test').hooks({
around: {
all: [authenticate('jwt')]
},
before: {
all: []
},
after: {
all: []
},
error: {
all: []
}
})
}
// Add this service to the service type index
declare module '../../../../declarations' {
interface ServiceTypes {
'path/to/test': TestingService
}
}This will infer the correct service types automatically. Do you think we'd still need this utility? My suggestion would be to go with that (since with schemas we'll probably have a lot less hooks to worry about) and type it explicitly when someone still wants to extract it into a separate file. |
|
Thanks for the explanation. It's good to me. I see me adding this utility in our code base anytime soon, but that's okay. Closing this for now. |
I love these
define*utility function so much! Wether it's vuesdefineComponentfeathers-pinia example, vitesdefineConfigfeathers dove docs vitepress example or other configs.The implementation seems simple and therefore useless but the DX while using it, is soooo nice!
It's a convenient way to provide type safety and hassle free autocompletion.
Reasons why they are nice and should be used and promoted extensively:
(context: HookContext<A, S>)needed.It also captures typos at compile time. Even for named hooks it's pretty useful. Even for a plain javascript implementation, it's an improvement!
See:
2. With the dove implementation: depending on the `Service` methods, we get autocompletion for custom method names for free:This is brought to you by:
create). Why should we add hooks for otherNotImpletedmethods of this service? Throw a compilation error and remove these hooks for the custom service!
You also get them in the `defineHooks` util for free:Summary
If you ask me, these LOC for
defineHookscould be spent more wasteful. What do you think? Should we use them all over the place and add them to the cli templates and to the docs?On a fresh cli generated project using this utility:
Sorry for german error. I think it's clear what it's about even without knowing a german word. Maybe my implementation of
defineHooksis not quite right? See that it passes forauthenticatebut not forresolveAll. Should I open a separate issue?Used packages: