Комментарии 22
Еще декораторы могут буть удобны для реализации IoC не только для Angular. Есть уже неплохая реализация: InversifyJS
@logger
class SomeClass extends Component {}
в devtools даст название компонента logger вместо ожидаемого SomeClass. Если код чужой, то потребуется дополнительное время чтобы разобраться, что это вообще за компонент.
А так да, фича довольно-таки удобная
Надо в таких случаях переопределять name
у внутренней функции.
// <debug>
if (params.name) {
Constructor = new Function('con', 'return {"' + params.name + '": ' +
function(){ return con.apply(this, arguments) }
+ '}["' + params.name + '"];')(Constructor);
}
// </debug>
И как же это поможет?
Пока что не вижу связи. Не могли бы вы пояснить детали реализации?
function withSubscription(WrappedComponent) {
class WithSubscription extends React.Component {/* ... */}
WithSubscription.displayName = `WithSubscription(${getDisplayName(WrappedComponent)})`;
return WithSubscription;
}
function getDisplayName(WrappedComponent) {
return WrappedComponent.displayName || WrappedComponent.name || 'Component';
}
https://facebook.github.io/react/docs/higher-order-components.html#convention-wrap-the-display-name-for-easy-debugging
Декоратор observer
во-первых называется без s на конце, во-вторых находится в библиотеке mobx-react, а не mobx, и в-третьих применяется не к «классам», а к React-компонентам, оборачивая их метод render
в autorun
— который в свою очередь и является одной из стандартных утилит для подписки на изменение observable'ов в mobx.
Ну, с autorun вы загнули. Там не простая обертка, а микс-ин на полтораста строк. С остальным я согласен.
Суть миксина примерно аналогична оборачиванию render в autorun
, и даже документация mobx-react предлагает думать об этом именно в таком ключе :) Но да, ваша правда, как минимум там внутри Reaction
для более тонкого управления вызовами.
Если вы используете Babel, для работы с декораторами можно обратиться к плагину transform-decorators-legacy.
Обратите внимание на то, что в названии этого плагина используется слово «legacy», которое можно трактовать как указание на некую устаревшую технологию. Дело тут в том, что здесь поддерживается то, как декораторы обрабатывает Babel 5. Этот подход может отличаться от той формы, которая, в итоге, будет стандартизирована.
Скорее дело в том, что этот плагин обрабатывает декораторы несколько по иному по сравнению с тем видом, который сейчас специфицирован в Stage 2. Независимо от того, будет ли спека меняться дальше или нет, актуальной реализации на сегодняшний день нет. Нужно понимать, что даже если спека будет утверждена в текущем виде, то код, работающий с transform-decorators-legacy может оказаться неработающим на нативных реализациях декораторов.
Декораторы в JavaScript