Open dongryphon opened 7 years ago
Even though the syntax is borrowed from function calls (as it does in most annotation language features) it is not fair to say it is a function call when clearly there must be much more to the consumption of whatever follows the @
Consider:
I am attempting to provide a decorator that accepts fully optional arguments including optional class parameters. Is there some idea brewing how to reliably determine the context of such things?
Given the current spec as I understand it (using
babel-plugin-transform-decorators-legacy
), there is no way to distinguish the above forms. To support case 1 you would do:To support case 2, you would do:
But since the parameter is a class there is no way to tell which form is being invoked.
If I could wish :) I would rather write decorators like so:
The idea there is that
args
is whatever (if anything) is supplied in parens after the decorator name. So to handle both cases:One could debate whether
args
should be an empty array to distinguish@foo
from@foo()
I suppose.