Reaction Commerce - Should I use it?

Hey fellow Meteor lovers! I’m going to be starting a new e-commerce project soon and came across Reaction Commerce. Does anyone here have experience using and customizing it? I’m going to have to the following:

  • Remove payment methods - customers will enter custom G/L fields
  • Add custom fields to product detail, based on product/type.
  • Remove shipping information in checkout/order detail/etc - my app will sell subscriptions to various pieces of software

These types of customizations, from my research, should be possible, although might get hairy. My questions for anyone who’s used RC are, how was the development experience, deployment, upgrading, etc? Is this project stable enough for me to use now, or should I build out a very simple store custom? One important piece to note is that I’ve already built out a subscription management app. RC (or my custom shop) is only going to facilitate customers purchasing subscriptions. After the purchase, everything goes to the subscription management app to provision the software, fill out more details, get a manager’s approval (customers are employees of a company).

Thoughts? Should I use RC or just do it custom? Thanks!

Dan C

Have you checked the other forum posts?

1 Like

Hey @robfallows thanks, I have now. Seems like it’s been several months since anyone’s posted about their experience with Reaction Commerce. Looks like a really great alternative to Magento or other open source e-commerce platforms. Although it looks like there’s still a ways to go in terms of the more advanced features like digital products and per line item fulfillment.

1 Like

Hey @dancastellon have you used RC yet or did you end up with other solutions? I’m currently trying to build a very simple store in Meteor but not sure which one is better: RC, Magento or custom store.

Hey @hamxiaoz, I did end up using Reaction Commerce. It was really easy to setup and extend :slight_smile:

1 Like

How did you end up getting around the shipping option? I sell services and don’t want that pane at all… Did you solve this?

Thanks for sharing your experience @dancastellon

My use case was somewhat unique - I built a custom plugin that overwrote a lot of the checkout components and removed some (shipping, card payment). It was easy to do just following their docs and example plugin, but that was 6 months ago. Since then I’ve updated RC to the latest version twice. The first time required a good amount of work because they replaced core blaze templates with React. The second time I had to rollback because I couldn’t figure it out with the time I had.

So just keep in mind that working with RC’s upgrade path isn’t perhaps as straightforward as you would expect with other open source systems, like Drupal for example.

@dancastellon thanks for your experience. re: upgrades. We’re working on that. When we release 1.5 for instance, we tested the upgrade path all the way back to 1.0. It gets a little hard because of the ongoing mix of blaze and react, so custom developments that use Blaze over react will have a harder upgrade path sometimes, but we’re really close to being react only. Makes the UI harder to use,(we’ll all miss blaze), but infinitely more extendable and re-usable. We’ve tried our best to follow the direction of Meteor as well, and with Meteor 1.6 out, we’re going to start modularizing both packages and the client so that components and packages are more easily extended, replaced, overwritten. Overall our goal is complete transparently updates, but as you can tell, we’re still learning the best way to do that and ensure we’re always keeping up with the Meteor / JS ecosystem.


@aaronjudd Last week I updated to 1.5 successfully. There was a good bit of rework I had to do to my custom plugin, but I’m impressed with the current state of the API. Overall, I now have less overridden code thanks to the new React component replacement API. Schemas are even easier to add to, which I’m doing heavily for my use case.

One thing I’ve noticed that’s different than other open source platforms, like Drupal, is the rapid development/improvement of core. While Drupal often requires no changes to custom modules when you update (to a certain extent), Drupal’s progress is very slow. The way they do PHP today is similar to how I did CakePHP/Symfony 5 years ago, for example. I agree with the API improvements RC’s making - replacing Blaze in favor of React, making components and schemas easily customizable, and the new group-based permission system.

The only thing I would like to see is some documentation around API changes for developers looking to go take their plugins from older RC versions to the latest. I was able to figure out the changes by looking at the example plugin and the latest docs - but it took a while.