Как стать автором
Обновить

Комментарии 20

babel --optional es7.decorators


Это устаревший синтаксис для 5ой версии babel. Нынче он с поддержкой декораторов собирается с помощью stage 1 ключика ( babeljs.io/docs/plugins/preset-stage-1 ), хотя на практике 6ую версию у меня так и не удалось завести (stage-0 + flow, примерно месяц-два назад), какая-то там в ядре бага была.
Декораторы ещё не допилили под babel 6, остальное вроде как работает (использую stage-1, flow и jsx)
Здесь не «не допилили» (хотя кое-что действительно не допилили — например, оптимизацию хвостовой рекурсии), а не включили из-за обновления предложения. Доступен плагин babel-plugin-transform-decorators-legacy.
А можно пруф? Почитал бы что такого предлагают нового.
Вот давольно старый документ. Что после это решили — представления не имею, так как декораторы — штука не особо для меня интересная, помню даже обсуждалась смена @ на #. Ещё 2 фичи идут отдельными предложениями: декораторы параметров и function expression.
>… используя императивный подход (то есть используя чистые функции)…

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

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

как раз TS это позволяет делать, это ведь и есть ECMAScript + опциональная типизация
И это замечательно. Но согласитесь, гораздо замечательнее было бы если бы эта опциональная типизация была в родном ECMAScript, хотя бы из соображений производительности.
Однозначно, я о том и пишу что не тем они занимаются в своих стандартах вот MS и пришлось выдумать TypeScript и разрабытывать его параллельно ECMAScript.
Ну JS же развивается усилиями комьюнити и, как правило, все эти плюшки добавляются разработчиками со стажем. Видать спрос на все эти «декораторы», :: и прочее. Но, без сомнений, сообществу стоит прислушаться к позиции MS.
То есть декорировать экземпляр класса нельзя, только сам класс, я правильно понимаю?
Почему же нельзя?

let Hero = new BaseHero;

canFly(Hero);

function canFly(target) {
      
      target.flyTo = function(destination) { /* navigation code */}
}
Но… это же не декораторы ES2016.
И даже не классы ES2015.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории