Разбираем декораторы ES2016

[SerafimArts]

babel --optional es7.decorators

Это устаревший синтаксис для 5ой версии babel. Нынче он с поддержкой декораторов собирается с помощью stage 1 ключика ( babeljs.io/docs/plugins/preset-stage-1 ), хотя на практике 6ую версию у меня так и не удалось завести (stage-0 + flow, примерно месяц-два назад), какая-то там в ядре бага была.

[Xazzzi]

Декораторы ещё не допилили под babel 6, остальное вроде как работает (использую stage-1, flow и jsx)

[rock]

Здесь не «не допилили» (хотя кое-что действительно не допилили — например, оптимизацию хвостовой рекурсии), а не включили из-за обновления предложения. Доступен плагин babel-plugin-transform-decorators-legacy.

[SerafimArts]

А можно пруф? Почитал бы что такого предлагают нового.

[rock]

Вот давольно старый документ. Что после это решили — представления не имею, так как декораторы — штука не особо для меня интересная, помню даже обсуждалась смена @ на #. Ещё 2 фичи идут отдельными предложениями: декораторы параметров и function expression.

[rock]

Заметки с январского собрания TC39.

[andy128k]

>… используя императивный подход (то есть используя чистые функции)…

Вот тут смешно получилось.

[TheBeatCoder]

Спасибо, недоглядел!

[serf]

Ваше мнение по поводу использования TypeScript, допусим для крупных проектах с распределенной командой? Разве эти миксины (mixins) не снесут крышу если ими слишком увлекаться (что откуда взялось проследить будет болью ибо все динамично — по канонам скриптинга)? По мне так TypeScript движется в верном направлении, в отлии от ECMAScript которые все добавляют и добавляют «сахара» (хотя TypeScript понимает большинство плюшек новых ES).

[TheBeatCoder]

Тут я с Вами согласен, TypeScript действительно движется в правильном направлении и статическая типизация для многих панацея. Но тут также стоит учитывать, что TS — компилируемый в JS язык и рассматривать TS отдельно от него губительно (вспомните CoffeeScript). Что касается крупных проектов то, имхо, TS подойдет лучше, так как статическая типизация и интерфейсы открывают больше возможностей для проектирования архитектуры приложения (легче мыслить привычными паттернами GoF и вообще применять методики разработки из «взрослых языков» по типу C# или Java, которые изначально ориентировались на крупные enterprise-проекты). Истина где-то посередине и мне кажется, что наилучшим выходом здесь будет гармоничное дополнение TS и ECMAScript (и попытки прийти к этому есть, стоит хотя бы взглянуть на гугловский SoundScript).

P.S. По поводу того, что миксины «снесут крышу». Ситуация похожая на промисы: разработчик только-только с ними познакомившийся пытается использовать их где нужно и не нужно, пока не поймет реально полезные кейсы их использования. Так же и с декораторами — должно быть чувство меры.

[serf]

> гармоничное дополнение TS и ECMAScript

как раз TS это позволяет делать, это ведь и есть ECMAScript + опциональная типизация

[TheBeatCoder]

И это замечательно. Но согласитесь, гораздо замечательнее было бы если бы эта опциональная типизация была в родном ECMAScript, хотя бы из соображений производительности.

[serf]

Однозначно, я о том и пишу что не тем они занимаются в своих стандартах вот MS и пришлось выдумать TypeScript и разрабытывать его параллельно ECMAScript.

[TheBeatCoder]

Ну JS же развивается усилиями комьюнити и, как правило, все эти плюшки добавляются разработчиками со стажем. Видать спрос на все эти «декораторы», :: и прочее. Но, без сомнений, сообществу стоит прислушаться к позиции MS.

[rock]

декораторы ES2016

Декораторов в ES2016 не будет.

[torbasow]

То есть декорировать экземпляр класса нельзя, только сам класс, я правильно понимаю?

[minnig]

Почему же нельзя?

let Hero = new BaseHero;

canFly(Hero);

function canFly(target) {
      
      target.flyTo = function(destination) { /* navigation code */}
}

[torbasow]

Но… это же не декораторы ES2016.
И даже не классы ES2015.

[minnig]

Если ты про синтаксис с @, то да — нельзя.

[Finesse]

Попали ли декораторы в черновики будущих стандартов ES или так и остались в предложениях?