• Introduction
• 1. Introduction to MobX
  • 1.1. Why MobX?
  • 1.2. The Gist of MobX
  • 1.3. Concepts & Principles
• 2. Core API
  • 2.1. observable
  • 2.2. @observable
  • 2.3. (@)computed
  • 2.4. autorun
  • 2.5. @observer
• 1. Advanced API
  • 3.1. autorunAsync
  • 3.2. createTransformer
  • 3.3. expr
  • 3.4. extendObservable
  • 3.5. isObservable(..)
  • 3.6. map
  • 3.7. modifiers
  • 3.8. observe
  • 3.9. tojson
  • 3.10. transaction
  • 3.11. untracked
  • 3.12. when
  • 3.13. extending mobx
  • 3.14. miscellaneous
• 1. Best Practices For Large Apps
  • 4.1. Defining data stores
  • 4.2. Writing (async) actions
  • 4.3. Organizing React components
• 1. How does MobX work?
  • 5.1. In depth explanation of MobX
• 1. Tips & Tricks
  • 6.1. DevTools
  • 6.2. ES5 / ES6 / TypeScript syntax
  • 6.3. Stateless Components and Hot Module Reloading
  • 6.4. Tracking state changes
  • 6.5. Performance considerations
• 7. Resources
• 8. Frequently Asked Questions
• Published with GitBook

MobX

Edit This Page

Organizing React Components

See also @observer

@observer is quite similar to decorators like @connect as found in several flux libraries, yet there are some important differences.

• @observer needs no configuration; dependencies will be detected automatically.
• The subscriptions and updates of @observer are far more fine-grained; exactly those values used in the last rendering will be observed, so there is no risk of over- or undersubscription. Large applications really benefit from this in terms of simplicity performance.
• This mechanism does not depend on the concept of context.

Rule of thumb is to use observer on every component in your application that is specific for your application. With @observer there is no need to distinguish 'smart' components from 'dumb' components. All components become responsible for updating when their own dependencies change. Its overhead is neglectable and it makes sure that whenever you start using observable data the component will respond to it.

Since in practice you will see that most reactive components become stateless, they can easily be hot-reloaded. You will discover that many small components will consist of just a render function. In such cases, you can also directly pass the render function to observer, without building a component. The props will then be available as first argument of the function.

observer also prevents re-renderings when the props of the component have only shallowly changed, which makes a lot of sense if the data passed into the component is reactive. This behavior is similar to React PureRender mixin, except that state changes are still always processed. If a component provides its own shouldComponentUpdate, that one takes precedence.