Chili
Have you ever wanted to test out a new feature on only a subset of users? Did that implementation end up being lots of if/else statements embedded in the main code? If so, Chili can help.
Chili is built on top of Rails Engines and Deface and allows you to conditionally add new/modify existing views, while leaving the main code untouched.
Installation
Install Chili on your system (not in your app):
$ gem install chili
Usage
Just like engines chili extensions are like mini apps that are created separately from the main app using the "chili" command.
Creating a new chili extension
Assuming you want to add a new extension that adds exposes a new social feature such as a "like" button feature to a subset of users, first run:
$ chili social # social is the name of the extension
This is basically a shortcut for running the rails plugin new
engine generator with a custom template and will:
- Create a directory named chili_social containing the basic structure for the extension
- Clone the app you are adding the extension to as a submodule into chili_social/main_app
- Add a reference to the extension to the main app gemfile for development/testing
Define who can see the extension
Use the active_if block to control whether new controllers/overrides are visible or not. The context of the active_if block is the application controller so you can use any methods available to that.
# lib/chili_social.rb
module ChiliSocial
extend Chili::Activatable
active_if { logged_in? && current_user.admin? } # Extension is only visible to logged in admin users
end
Modifying view templates in main app
Chili uses deface to modify existing view templates (see deface docs for details)
Add overrides to the app/overides
directory mirroing the path of the view you want to modify.
For example, assuming the main app has the partial app/views/posts/_post.html.erb
:
<% # app/overrides/posts/_post/like_button.html.erb.deface (folder should mirror main app view path) %>
<!-- insert_bottom 'tr' -->
<td><%= link_to 'Like!', chili_social.likes_path(like: {post_id: post}), method: :post %></td>
Adding new resources
Use rails g scaffold Like
as usual when using engines. The new resource will be namespaced to ChiliSocial::Like
and automounted in the main app at /chili/social/likes
, but only accessible when active_if is true.
All the rules for using engine-based models apply.
Modifying existing models
Create a model with the same name as the one you want to modify: rails g model User --migration=false
and inherit from the original:
# app/models/chili_social/user.rb
module ChiliSocial
class User < ::User
has_many :likes
end
end
Access through the namespaced model:
<%= ChiliSocial::User.first.likes %>
<%= current_user.becomes(ChiliSocial::User).likes %>
Adding new stylesheets/javascripts
Add files as usual in app/assets/chili_social/javascripts|stylesheets
and inject them into the layout using an override:
<% # app/overrides/layouts/application/assets.html.erb.deface %>
<!-- insert_bottom 'head' -->
<%= stylesheet_link_tag 'chili_social/application' %>
<%= javascript_include_tag 'chili_social/application' %>
Releasing to production
Once your chili extension is ready to be released all you have to do is push the repo somewhere, add the extension to the Gemfile of the app you are releasing it to:
gem 'chili_social', git: '[email protected]:githubuser/chili_social.git'
...and bundle and install any migrations (just like any other engine):
$ bundle
$ rake chili_social:migrations:install
$ rake db:migrate
Gotchas
- Chili will not be able to automount if you use a catch-all route in your main app (ie
match '*a', to: 'errors#routing'
), you will have to remove the catch-all or manually add the engine to the main app's routes file. - Just like normal engines, Chili requires you to prepend path helpers with
main_app
(iemain_app.root_path
etc) in view templates that are shared with the main app (such as the main app's application layout file).