The ReactiveSupport gem provides a re-implementation of certain ActiveSupport methods, allowing them to be used outside of the Rails ecosystem. This gem can be used in any kind of project and is not dependent on any frameworks, gemsets, etc. To add ReactiveSupport to your project, add this to your Gemfile and run bundle install:

gem 'reactive_support', '~> 0.5.0'

To install locally:

sudo gem install reactive_support

Or if you're using RVM:

gem install reactive_support

You can also point your Gemfile to this repo:

gem 'reactive_support', '~> 0.5.0.beta', git: 'https://github.com/danascheider/reactive_support.git

Like ActiveSupport, ReactiveSupport is designed to load only the code you are actually using in your app. For that reason, you will need to specify in your project files exactly what you're using. For example, in Canto, I have the following requires:

require 'reactive_support/core_ext/object/blank'
require 'reactive_support/core_ext/object/inclusion'
require 'reactive_support/core_ext/object/try'

I do have plans to add the ability to require the entire gem, or broader parts of it, in the future. This would also be a welcome contribution to the project if you're interested.

Please note that version 0.1.2 is the earliest available version of ReactiveSupport.

In its current version, ReactiveSupport adds methods to several core Ruby classes (including Object), so once required, its methods can be used on any object within your project.

Currently, ReactiveSupport's methods are a strict subset of ActiveSupport's. (This may change in future versions, or most saliently, if ActiveSupport's API changes.) That means that, while not all ActiveSupport methods are available, those that are can, as of September 2014, be found in ActiveSupport's API documentation with no functional differences. (This is true of ReactiveSupport 0.1.x and ActiveSupport 4.1.6.)

There are three main reasons why you might prefer ReactiveSupport over ActiveSupport:

1. Stability: ReactiveSupport is intended to work independently of Rails' rapidly changing ecosystem. ReactiveSupport methods are guaranteed not to be transferred to other Rails modules or refactored out. While ActiveSupport may be used independently of Rails, its developers are still primarily focused on its place within Rails. ReactiveSupport solves that problem.
2. Simplicity: ReactiveSupport can be added to other projects without additional abstraction layers, and it has no dependencies outside the development and test groups. You don't have to worry about configuration, compatibility with other gems*, or conflicting dependencies.
3. Transparency: Rails is an enormous gem, and gets larger and more complex with each major version. It is also opinionated, facilitating some development approaches while making others inordinately difficult. ReactiveSupport is not large or complicated. Any developer can read the documentation, or even the code itself, and know exactly what he or she is dealing with.

* I would not recommend using it in conjunction with ActiveSupport, though.

ReactiveSupport is a spinoff from my other project, Canto. Consequently, the methods it includes are primarily those that I have found a use for in Canto. As Canto grows, and as I have time, I will add more of ActiveSupport's numerous useful methods to ReactiveSupport. In the meantime, I welcome contributions and will respond quickly to pull requests.

Yes. Since stability is one of the main advantages of ReactiveSupport, I will be taking an "if it ain't broke, don't fix it" approach to maintaining it. An absence of recent contributions should not be taken to mean it has fallen off my radar.

Yes. ReactiveSupport is agnostic to the characteristics of your app, and there is no reason it cannot be used in any app where you feel it will be useful.

ReactiveSupport version 0.1 supports Ruby versions >= 1.9.3. Additional Rubies may be supported in the future. Adding such support would be a welcome contribution to the project.

Contributions are welcome and I will respond promptly to all issue reports and pull requests. Here are some guidelines to get started; I also encourage you to read the full CONTRIBUTING.md file to ensure your pull request will be accepted as is:

• Include passing RSpec tests with your pull request. I aim for 100% test coverage.
• Run the whole test suite before you make your PR. Make sure your changes don't break the rest of the gem.
• Make sure your changes are consistent with the functionality of ActiveSupport. Users should be able to learn about a ReactiveSupport method by reading the ActiveSupport docs for the corresponding ActiveSupport method.
• Don't add any new dependencies to ReactiveSupport, or methods that are specific to a particular framework, gemset, or type of app.
• Include documentation. ReactiveSupport uses Inch CI to evaluate the quality of documentation. Please help make it easy for others to use and contribute to this project.
• Keep ReactiveSupport principles - stability, simplicity, and transparency - in mind. Ideally, contributions should uphold these principles while expanding or enhancing functionality.

• The Rails guides on ActiveRecord give information about each of ReactiveSupport's methods.
• Those interested in contributing to ReactiveSupport are encouraged read up on Travis CI, Coveralls, CodeClimate, and Inch CI.
• Check out ReactiveSupport at Rubygems.org!