Discuss
  • Inline class decorators suggestion

Inline class decorators suggestion

# Don Griffin (8 years ago)

Greetings!

Greetings! I work at Sencha and we have spent considerable time in recent months deciding how we will use decorators and how they could replace the various aspects of our Ext JS class system ( docs.sencha.com/extjs/6.2.0/classic/Ext.Class.html).

Because these features are class-level concerns, we are seeing this unfortunate pattern emerge:

@decoratorA({
    // maybe 1-100 lines
})
@decoratorB({
   // another long thing (maybe some html template)
})
class MyComponent extends Component {
    // empty? yes... often!
}

I would like to prose an inline alternative syntax that would be equivalent to the above:

class MyComponent extends Component {
    @decoratorA {
        // maybe 1-100 lines
    }

    @decoratorB {
       // another long thing (maybe some html template)
    }
}

Basically a decorator name followed by an object literal. This maintains the aesthetic flow of describing the contents of a class within its body and does not "bury the headline" so to speak (that a class is being declared here).

You could see the benefits of this approach better with some simple decorators like @internal (a debug aid to detect accidental name collisions) or @statics (for better compression) or @prototype (to put data on the class prototype):

class MyComponent extends Component {
    @statics {
        create () { ... },
        // many more static methods
    }

    @prototype {
         answer: 42,
         defaultText: 'Hello world'
    }

    @internal {
        deepThought () { ... },
        moreDeepThoughts () { ... }
    }
}

For what it's worth, you see this same top-heavy class pattern in Angular 2 as well. The large numbers of lines above the class keyword marginalize the class statement.

I look forward to your thoughts.

If this is not the right place to post suggestions, apologies in advance and I would greatly appreciate a pointer to the proper place.

Thanks!

Best, Don

Don Griffin Director of Engineering Sencha, Inc.

# Andy Earnshaw (8 years ago)

This breaks consistency with other decorator proposals, where the decorator precedes the decoratee. Also remember that decorators don't have to take parameters:

// Issues a warning on instantiation
@deprecated
class Foo {
   ...
}

If the decorator goes inside the class declaration, it conflicts with method parameters.

Probably the right place for discussion is on the proposal report though:

wycats/javascript-decorators

On Tue, 4 Oct 2016, 19:39 Don Griffin, <don at sencha.com> wrote:

Greetings!

Greetings! I work at Sencha and we have spent considerable time in recent months deciding how we will use decorators and how they could replace the various aspects of our Ext JS class system ( docs.sencha.com/extjs/6.2.0/classic/Ext.Class.html).

Because these features are class-level concerns, we are seeing this unfortunate pattern emerge:

@decoratorA({
    // maybe 1-100 lines
})
@decoratorB({
   // another long thing (maybe some html template)
})
class MyComponent extends Component {
    // empty? yes... often!
}

I would like to prose an inline alternative syntax that would be equivalent to the above:

class MyComponent extends Component {
    @decoratorA {
        // maybe 1-100 lines
    }

    @decoratorB {
       // another long thing (maybe some html template)
    }
}

Basically a decorator name followed by an object literal. This maintains the aesthetic flow of describing the contents of a class within its body and does not "bury the headline" so to speak (that a class is being declared here).

You could see the benefits of this approach better with some simple decorators like @internal (a debug aid to detect accidental name collisions) or @statics (for better compression) or @prototype (to put data on the class prototype):

class MyComponent extends Component {
    @statics {
        create () { ... },
        // many more static methods
    }

    @prototype {
         answer: 42,
         defaultText: 'Hello world'
    }

    @internal {
        deepThought () { ... },
        moreDeepThoughts () { ... }
    }
}

For what it's worth, you see this same top-heavy class pattern in Angular 2 as well. The large numbers of lines above the class keyword marginalize the class statement.

I look forward to your thoughts.

If this is not the right place to post suggestions, apologies in advance and I would greatly appreciate a pointer to the proper place.

Thanks!

Best, Don

Don Griffin Director of Engineering Sencha, Inc.

# Don Griffin (8 years ago)

Thanks for the pointer. I'll head over there.

My suggestion here is a fix for the inconsistency specifically with class decorators and the class keyword... That is that the contents of a class go inside the class body :) Some decorators as I've suggested are simply ways to add content to the class and these tend to be quite lengthy.

I agree this suggestion is not consistent with other forms of decorator usage. I don't see the conflict you are suggesting with method parameters, though.

In this suggestion there is no argument-less aspect to consider. Argumentless class decorators still go above the class. That location is aesthetically pleasing when it is a decoration not an obfuscation... as is the case when you have hundreds of lines of decorator statements and no content to the class body itself. imho and all :)

Thanks for feedback!

Best, Don

Don Griffin Director of Engineering Sencha, Inc.