This plugin will wrap literally every React component in a MobX observer higher order component.
When using MobX, MobX-State-Tree, or any other library in the MobX ecosystem, you may find yourself in one of two scenarios:
- You sometimes waste a lot of time debugging why a component isn't updating even though you think it should, only to realize that you forgot to wrap a component in an observer.
- You just really dislike the way it looks to import
observer
frommobx-react
or@observer
frommobx-react-lite
in every single file and wrap your components. This is something that seems to come up again and again.
The typical recommendation from MobX is to just use the @observer
decorator or the observer
HOC and accept that you'll have to import it and use it in every file. This plugin doesn't actually change that requirement, it just makes it so that you don't have to manually do that. You may find value in this plugin if you either hate having to remember that, or if you just don't like the way it looks.
- This plugin is currently in early development, so there will probably be bugs. As more people try and adopt it, we will clean up whatever doesn't work. If we get enough adoption and stability, we will mark this library as v1 and remove this bullet point. But for now, use at your own risk!
- If you're not already using Babel, you'll have to add it to your tool chain.
- It will make your Babel build take a little longer, although we can improve that over time with performance enhancements.
- You may pick up some convenience, but it also adds a little magic to your project. You or your coworkers may sort of "forget" about the observer HOC and not realize that it's not actually being applied. That could lead to hard-to-debug issues in your own codebase, or just a general degradation of your own mental model of how your code works.
Not that we have evidence for. The MobX docs specifically recommend wrapping every component in an observer, saying:
observer only enhances the component you are decorating, not the components called by it. So usually all your components should be wrapped by observer. Don't worry, this is not inefficient. On the contrary, more observer components make rendering more efficient as updates become more fine-grained.
We don't actually have benchmarks to share, so it's always possible there's some small cost, but it's likely to be negligible. If you disagree, send us some benchmarks and we'll update this section!
# npm
npm install --save-dev babel-plugin-mobx-observer-on-every-react-component
# yarn
yarn add --dev babel-plugin-mobx-observer-on-every-react-component
# pnpm
pnpm add --dev babel-plugin-mobx-observer-on-every-react-component
# bun
bun add --dev babel-plugin-mobx-observer-on-every-react-component
Add the plugin to your .babelrc
file:
{
"plugins": [
["babel-plugin-mobx-observer-on-every-react-component"]
]
}
If you prefer using a JavaScript configuration file, you can add the plugin to your babel.config.js
:
module.exports = function(api) {
api.cache(true);
return {
plugins: [
'babel-plugin-mobx-observer-on-every-react-component'
]
};
};
You can pass an optional object to the plugin to configure the behavior of the plugin. Options look like this:
/**
* Options for the plugin
*/
interface PluginOptions {
// Default false, controls if we log debug statements during plugin execution. Mostly intended for plugin developers.
debugEnabled?: boolean;
}
Here are some options we'll eventually add:
- Array of files to ignore
- Some kind of pattern matching to ignore certain files
- Allow transformation of node_modules (right now we have it hardcoded to skip node_modules)
- We are open to suggestions! Please open an issue or discussion if you have ideas.
If you want to ignore an entire file, add a comment to the top of the file:
// @auto-observer-ignore-file
If you want to ignore a specific block, add a comment to the start of the block:
// @auto-observer-ignore-block
cd example
bun install
bun dev
Then check out the Vite app that starts. It'll look something like this:
mobx-auto-observer-plugin-demo.mov
You can see the plugin in action with different starting points using the Babel REPL. This is also a great way to provide us with reproducible examples for bug reports.
We'd love to have any help. Please open an issue or discussion if you want to get started.
Here are some resources we've used to learn how to develop Babel plugins:
We use Bun for package management, running tests, and building the project (sort of - we are actually using tsc under the hood with Bun as a task runner for this).
- Clone the repo
- Make sure you have the most recent version of Bun installed (check their website for instructions)
- Install dependencies with
bun install
- Make sure tests are passing with
bun test
- Hop into the example folder and also install dependencies with
cd example && bun install
- Once in the example folder, you can run
bun dev
to start the dev server and see a Vite app that points to a local build of this package. - To update the build of this package that the example is pointing to, run
bun run build
in the root of the project and restart the dev server in the example folder. - To build your changes, run
bun run build
in the root of the project.