MobX Quick Start Guide
上QQ阅读APP看书,第一时间看更新

Better syntax with decorators

All of our examples so far have used the ES5 API of MobX. However, there is a special form of the API, which gives us a very convenient way of expressing the observables. This is made possible with the @decorator syntax.

The decorator syntax is still a pending proposal  (as of this writing) for inclusion in the JavaScript language standard. But that doesn't stop us from using it, as we have Babel to help us out. By using the Babel plugin, transform-decorators-legacy, we can transpile the decorator syntax into regular ES5 code. If you are using TypeScript, you can also enable decorator support by setting your  { experimentalDecorators: true} compiler option in your tsconfig.json

The decorator syntax is only available for classes and can be used for class declarations, properties and methods. Here is an equivalent Cart observable, expressed with decorators:

class Cart {
@observable.shallow items = [];
@observable modified = new Date();

@computed get description() {
switch (this.items.length) {
case 0:
return 'There are no items in the cart';
case 1:
return 'There is one item in the cart';
default:
return `There are ${this.items.length} items in the
cart`
;
}
}
}

Notice the use of decorators to decorate the observable properties. The default @observable decorator does deep observation on all the properties of the value. It is actually a shorthand for using @observable.deep.

Similarly, we have the @observable.shallow decorator, which is a rough equivalent of setting the { deep: false } option on the observable. It works for objects, arrays, and maps. We will cover the more technically correct ES5 equivalent of observable.shallow in Chapter 4 , Crafting the Observable Tree.

The snippet below shows the items and metadata properties, marked as shallow observables:

class Cart {
// Using decorators
@observable.shallow items = [];
@observable.shallow metadata = {};
}

We will be covering a few more decorators in a later chapter, but we did not want to wait until then to discuss the decorator syntax. We definitely think you should pick decorators as your first choice for declaring observables. Note that they are only available inside classes. However, the vast majority of the time, you will be using classes to model your observable tree, so decorators greatly help in making it more readable.