Комментарии 20
babel --optional es7.decorators
Это устаревший синтаксис для 5ой версии babel. Нынче он с поддержкой декораторов собирается с помощью stage 1 ключика ( babeljs.io/docs/plugins/preset-stage-1 ), хотя на практике 6ую версию у меня так и не удалось завести (stage-0 + flow, примерно месяц-два назад), какая-то там в ядре бага была.
0
Декораторы ещё не допилили под babel 6, остальное вроде как работает (использую stage-1, flow и jsx)
0
Здесь не «не допилили» (хотя кое-что действительно не допилили — например, оптимизацию хвостовой рекурсии), а не включили из-за обновления предложения. Доступен плагин babel-plugin-transform-decorators-legacy.
0
А можно пруф? Почитал бы что такого предлагают нового.
0
Вот давольно старый документ. Что после это решили — представления не имею, так как декораторы — штука не особо для меня интересная, помню даже обсуждалась смена
@
на #
. Ещё 2 фичи идут отдельными предложениями: декораторы параметров и function expression.0
>… используя императивный подход (то есть используя чистые функции)…
Вот тут смешно получилось.
Вот тут смешно получилось.
+1
Ваше мнение по поводу использования TypeScript, допусим для крупных проектах с распределенной командой? Разве эти миксины (mixins) не снесут крышу если ими слишком увлекаться (что откуда взялось проследить будет болью ибо все динамично — по канонам скриптинга)? По мне так TypeScript движется в верном направлении, в отлии от ECMAScript которые все добавляют и добавляют «сахара» (хотя TypeScript понимает большинство плюшек новых ES).
+1
Тут я с Вами согласен, TypeScript действительно движется в правильном направлении и статическая типизация для многих панацея. Но тут также стоит учитывать, что TS — компилируемый в JS язык и рассматривать TS отдельно от него губительно (вспомните CoffeeScript). Что касается крупных проектов то, имхо, TS подойдет лучше, так как статическая типизация и интерфейсы открывают больше возможностей для проектирования архитектуры приложения (легче мыслить привычными паттернами GoF и вообще применять методики разработки из «взрослых языков» по типу C# или Java, которые изначально ориентировались на крупные enterprise-проекты). Истина где-то посередине и мне кажется, что наилучшим выходом здесь будет гармоничное дополнение TS и ECMAScript (и попытки прийти к этому есть, стоит хотя бы взглянуть на гугловский SoundScript).
P.S. По поводу того, что миксины «снесут крышу». Ситуация похожая на промисы: разработчик только-только с ними познакомившийся пытается использовать их где нужно и не нужно, пока не поймет реально полезные кейсы их использования. Так же и с декораторами — должно быть чувство меры.
P.S. По поводу того, что миксины «снесут крышу». Ситуация похожая на промисы: разработчик только-только с ними познакомившийся пытается использовать их где нужно и не нужно, пока не поймет реально полезные кейсы их использования. Так же и с декораторами — должно быть чувство меры.
+2
> гармоничное дополнение TS и ECMAScript
как раз TS это позволяет делать, это ведь и есть ECMAScript + опциональная типизация
как раз TS это позволяет делать, это ведь и есть ECMAScript + опциональная типизация
0
И это замечательно. Но согласитесь, гораздо замечательнее было бы если бы эта опциональная типизация была в родном ECMAScript, хотя бы из соображений производительности.
0
Однозначно, я о том и пишу что не тем они занимаются в своих стандартах вот MS и пришлось выдумать TypeScript и разрабытывать его параллельно ECMAScript.
+1
декораторы ES2016
Декораторов в ES2016 не будет.
0
То есть декорировать экземпляр класса нельзя, только сам класс, я правильно понимаю?
0
Попали ли декораторы в черновики будущих стандартов ES или так и остались в предложениях?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разбираем декораторы ES2016