class decorator optional opts

[cztomsik]

Is it really necessary to make difference between regular class decorators and those accepting arguments?

Because it would be great if we didn't have to test presence of arguments, how would you implement @dec with optional arguments?

It feels inconsistent - I'd rather have to return function all the time instead of doing nasty isClass checks

@dec({...})
class SomeClass{
  ...
}

@dec
class AnotherClass{
  ...
}

[dead-claudia]

I believe this is valid syntax:

@dec()
class AnotherClass{
  // ...
}

That should solve your use case.

[cztomsik]

Yeah, I know but it feels weird.

[dead-claudia]

True. I was thinking that as I typed that reply. And as for the checking, I
don't think it's worth adding that boilerplate to the proposal, though.
Especially considering the recent disdain on es-discuss over proposed new
language features that are better off as macros.

On Sat, Jun 20, 2015, 06:55 Kamil Tomšík notifications@github.com wrote:

Yeah, I know but it feels weird.

—
Reply to this email directly or view it on GitHub
#23 (comment)
.

[Aaike]

i have been struggling with the same thing. I wanted an easy way to create decorators that could be used with or without the parenthesis.
I ended up creating some utility functions to help with that, it's probably not the best way of doing it , but it works : https://github.com/gooy/js-deco

[dead-claudia]

If you want a proper, complete checker, you'd have to write a helper function for it, and it could still be theoretically fooled if it's given something that looks enough like a duck.

[dead-claudia]

Although in practice, it is not quite that likely.

[lukescott]

Is there any reason to not require the outer function to always return a decorator function as the OP suggests? It would make things far simpler.

[cztomsik]

@lukescott yeah, that was my point - but I'm afraid it's too late as there is a lot of libs already using it.

[jeffijoe]

@lukescott @cztomsik I think always wrapping in a function makes sense, to avoid confusion. Existing libs shouldn't be hard to fix?

[dead-claudia]

Shouldn't be, as far as I know.

On Wed, Nov 4, 2015, 05:42 Jeff Hansen notifications@github.com wrote:

@lukescott https://github.com/lukescott @cztomsik
https://github.com/cztomsik I think always wrapping in a function makes
sense, to avoid confusion. Existing libs shouldn't be hard to fix?

—
Reply to this email directly or view it on GitHub
#23 (comment)
.

[jeffijoe]

I have 2 production app's that are heavily powered by custom decorators, so I know for a fact that it won't be difficult.

[cztomsik]

Do you really want to see warnings like these all over the internet?

[dead-claudia]

@cztomsik Either they didn't think of this, or they don't trust this:

function InjectableImpl(target, prop, desc, opts = {}) {
    // ...
}

function Injectable(opts, prop, desc) {
    // You can check `opts` and/or `prop` as well, if you want extra insurance.
    if (arguments.length === 3 && typeof desc === "object") {
        return InjectableImpl(opts, prop, desc)
    } else {
        return (target, prop, desc) => InjectableImpl(target, prop, desc, opts)
    }
}

It's possible to overload a function and just check the types to make sure it's not being used as/like a decorator. Should this be able to fix the other half of the issue?

[dead-claudia]

That's also possible in TypeScript as well. You just need to overload the function type signature.

function InjectableImpl(
    target: any,
    prop: string,
    desc: PropertyDescriptor,
    opts: Options = {}
) {
    // ...
}

interface InjectableDecorator {
    (target: any, prop: string, desc: PropertyDescriptor): any;
}

function Injectable(opts: Options): InjectableDecorator;
function Injectable(opts: any, prop: string, desc: PropertyDescriptor): any;

function Injectable(opts: any, prop: string, desc: PropertyDescriptor) {
    // You can check `opts` and/or `prop` as well, if you want extra insurance.
    if (arguments.length === 3 && typeof desc === "object") {
        return InjectableImpl(opts, prop, desc)
    } else {
        return (target: any, prop: string, desc: PropertyDescriptor) => {
            InjectableImpl(target, prop, desc, <Options> opts)
        }
    }
}

[dead-claudia]

So, it should be possible to optionally take arguments, if you're willing to accept a little bit of boilerplate.

For a general solution assuming a single options object is taken:

function makeDecorator(callback) {
    return function (opts, _, desc) {
        // You can check `opts` and/or `prop` as well, if you want extra
        // insurance.
        if (arguments.length === 3 && typeof desc === "object") {
            return callback({}).apply(this, arguments)
        } else {
            return callback(opts !== undefined ? opts : {})
        }
    }
}

// Example usage:
var Injectable = makeDecorator(function (opts) {
    return function (target, prop, desc) {
        // do stuff
    }
})

Or if you'd prefer just a single function:

function makeDecorator(callback) {
    return function (opts, prop, desc) {
        // You can check `opts` and/or `prop` as well, if you want extra insurance.
        if (arguments.length === 3 && typeof desc === "object") {
            return callback({}, opts, prop, desc)
        } else {
            if (opts === undefined) opts = {}
            return function (target, prop, desc) {
                return callback(opts, target, prop, desc)
            }
        }
    }
}

// Example usage:
var Injectable = makeDecorator(function (opts, target, prop, desc) {
    // do stuff
})