babel-plugin-mobx-observer-on-every-react-component

babel-plugin-mobx-observer-on-every-react-component

What does this Babel plugin do?

This plugin will wrap literally every React component in a MobX observer higher order component.

Why would you want to do this?

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 from mobx-react or @observer from mobx-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.

What are the downsides of using this plugin?

• 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.

Are there any runtime performance concerns?

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!

Install

# 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

Usage

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'
    ]
  };
};

Options

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; 
}

More options on the way

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.

Ignore files/lines

Coming soon: eventually we'll have a syntax to ignore entire files or lines of code if you prefer to opt-out of plugin transformation.

Examples

Local Example with Vite

cd example
bun install
bun dev

Then check out the Vite app that starts.

Babel REPL

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.

Contributing

We'd love to have any help. Please open an issue or discussion if you want to get started.

Resources for Babel Plugin development

Here are some resources we've used to learn how to develop Babel plugins:

• Babel Plugin Handbook
• Build your own Babel plugin

Development environment

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.