Themeing a Spree installation; causing a Deface nightmare

Question

Typed this up at Programmers.SE first, but imagine this may be better suited to here - purely because it's not asking for a advice regarding a specific technical issue. Feel free to vote to move though!

I'm currently working on a project using the "Spree" e-commerce platform for Ruby on Rails. It's been a complete joy to configure and to work with. The joy stopped there though.

I'm trying to develop a completely custom interface - one that bears no similarity at all with the default configuration. Now the Spree documentation suggests I have only two options:

1. Use deface overrides. Everywhere. Seemingly to override other overrides.
2. Completely rebuilding the views.

Naturally, for such a dramatic change in style using deface is a complete nightmare; Deface does not look like an acceptable way to be expected to re-write a complete UI in; nor does it seem very efficient. So I opted to completely rebuild the views.

Then the realisation hits that there are around 8 plugins all relying on deface overrides, with the view files hardcoded and the target selectors often being 'flakey' (at best).

Apart from the very minimal documentation on the spree website, all I can find are slideshows from various conferences, which - without the context of the talk are actually of minimal use. They all seem to focus on using deface overrides for largely simplistic changes, and the more recent ones appear to be over a year old.

Am I missing something? Does anyone know of the best practice for performing something like this? Where I should actually be looking?

Answer 1

Deface is a giant disaster. The whole concept is a huge anti-pattern and it leads to a complete, utter, undebuggable nightmare. I really wish the Spree community would move away from it, especially the plugins, and provide better options for view-level customization inside the app.

The biggest drawback to not going with Deface in Spree is that your customized code becomes deviated from the Spree 'stock' view code, and as you upgrade spree you have two different (your customization and the spree default) versions to reconcile for every upgrade of spree. And you have to do that file-by-file.

It's tedious, but I make it a little easier on myself by inserting comments 'begin customized code' and 'end customized code' in every view I make that has the spree default code mixed in with my own code. This makes the upgrade process a little smoother, but still there's no easy answer.

If Winston Churchill were a Rails developer he would say "view-overriding in Spree is the worst form of customization, except for all the others."

Answer 2

I have gone through the same problem and as you suggested, when there are lot of plugins using deface, it is better to use deface rather than overriding the entire view. It took some time to learn the fact that mecca of spree and the guide apart from documentation is the github sourcecode for spree. Anything missing in the documentation is present here.

If you want to override a view, there are two ways:

1) You want to override it completely using a new view. In such case, I would recommend not to change its existing structure used in the present source code and add your new changes. This way you are still making the data hooks available to other plugins depending on deface which depends on your view's html code structure and tags.

2) Using Deface. TO get started with Deface is a bit if a nightmare as there aren't sufficient documentations. The best way to get started using Deface is github. The most important utility to test your new view code after Deface has replaced is to use rake tasks. To see the elements selected with a tag use: rake deface:test_selector['spree/address/_form','p'] - This shows all elements using p in the corresponding view partial. To see the original partial use:

rake deface:get_result[shared/_head]

These are mentioned at deface's github but these come very handy, hence emphasizing.

Answer 3

Following on from a discussion on the Spree User's mailing list, the general consensus appeared to be:

The best option is to scrap deface for all view overrides - and this may best be achieved by forking spree-frontend.

Regarding plugins, things aren't going to be simple - and if it's not possible to keep data-hooks then I just need to disable the overrides and implement them directly in to the view.

Not very nice, but the lesser of two evils. By using deface for such a dramatic change you will find yourself in a mess of overrides.

The discussion also includes one developer mentioning the (very good idea) of utilising Capybara for testing after doing this, to ensure everything still works correctly. There will be maintenance involved after every update, which is what @Lavixu's answer was trying to avoid - and in an ideal world he'd be spot on and deface could be used for this..

For less drastic changes I'd recommend using deface every time though, and Lavixu mentions a very good tip with regards to testing deface overrides.

Unfortunately it's not that simple. If you find yourself in this situation it may be worth reading the discussion above, it was very helpful.