Customize Spree Views Without Deface

05 February 2017 on . 3 minutes to read

Spree and Deface

Spree is a very powerful and highly configurable Rails based ecommerce solution. It’s loaded full of awesome features which will let you handle most any situation or special edge case you may have for your business needs. From a user’s perspective, it’s awesome. In the current version of the Spree guide for customizing view, the recommendation is to use deface for these customizations. Deface is very powerful and aims to make Spree upgrades seamless. Unfortunately, it adds extra complexity and will make your codebase diverge from the standard Rails conventions. These conventions are part of what make efficient development using Rails possible, so why would you get away from that? Looking for a customized ecommerce solution? Spree is fantastic, shoot me a message if you’d like to discuss your needs.

In this post I’ll run through a quick example of what using Deface looks like, and then propose we return to the built in Rails functionality of overriding views as a means to have a more useable and efficient codebase.

Deface Example

From the gem’s examples:

Legacy Deface Overrides

The following inserts <%= link_to "List Comments", comments_url(post) %> before all instances of p with css class comment in posts/index.html.erb

# app/overrides/add_comments_list_before_p.rb
Deface::Override.new(:virtual_path => "posts/index", 
                     :name => "example-2", 
                     :insert_before => "p.comment",
                     :text => "<%= link_to 'List Comments', comments_url(post) %>")

Deface DSL (.deface files)

The same code as above, but using .deface DSL:

#app/overrides/posts/index/list_comment.html.haml.deface
/
  insert_before 'p.comment'
= link_to 'List Comments', comments_url(post)

Much more structured, and it follows the Rails pattern of using builders. Better than the legacy version in my opinion.

What’s Wrong With These?

This alone isn’t that complex; in fact it’s clean and to the point. The problem I’ve found with deface is that anything beyond this simple customizations quickly becomes clunky and disorganized unless you put a lot of extra effort into maintaining organization. Anything which requires extra brainpower to properly and cleanly implement raises a red flag. The reason is that your, mine and everyone else who has ever existed’s brain only has a limited capacity for concentration and application of thought. Development should flow effortlessly; but I’ve found using deface severely disrupts that flow and therefor reduces my output.

The Better Way: Classic Rails Overrides

When using engines, Rails gives us the power to override ride anything by simply putting a file in our app’s directory, so that file will be preferentially loaded over the engine’s file.

Using the same above example, where an engine (say Spree) has the view app/views/posts/index.html.erb, if we want to override this, then in our own application, we do the following:

  • Copy the engine’s view file (find on github or download the repo)
  • Paste this file to app/views/spree/posts/index.html.erb
  • Edit this file

It’s simple, follows conventions and best of all will be easily discoverable to any new developers who come in the future. Part of building a well designed application is following what’s called the ‘Bus Factor’: If the developer is hit by a bus and dies, someone with minimal Rails familiarity should be able to load your app up and immediately get to work on it. Don’t waste your own or someone else’s time and brain power deciphering unconvential coding.


If you enjoy having free time and the peace of mind that a professional is on your side, then you’d love to have me work on your project.

Contact or view a list of available services to see how I’ll make your life better, easier and bring satisfaction back into you running your business.