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