Closed sonhanguyen closed 6 years ago
Shoot, I'm not following 😞 Could you maybe reword with some more real-world examples?
sorry for the reasoning not being fully fleshed out, my main motivation is that I'm not fan of method decorators. The decorator pattern like many other OOP patterns follow the open/closed principle: given a thing, without modifying the thing's source code, enhance it.
Method decorators require you to do this source code modification, which is sometimes possible sometimes not. e.g. given a 3rd library
export default AbcClient {
doThing() {
...
}
now if I want to apply the decorator @time
to doThing
. Of course I can't just go into node_modules
and annotate the method. I'll instead have to do the following:
import AbcClient as OriginalAbcClient from 'abc'
class AbcClient extends OriginalAbcClient {
@time
doThing() {
return super.doThing(arguments)
}
}
// rest of the code unchanged
which is verbose as said, with this hypothetical decorateMethod
, I can instead do
const AbcClient = decorateMethod({doThing: time})
(OriginalAbcClient)
actually nvm, I just saw we have applyDecorators
which is the exact thing
wonder what do you think about adding a
@decorateMethod
to convert method decorators to class decorators? The usecase is implementing the actual decorator pattern. Which using method decorators would look like this:which does look a bit repetitive, I'm proposing the following
looking for some hacktoberfest contribution so just checking if I should open a pull request