Last active
December 15, 2015 18:09
-
-
Save skwp/5302250 to your computer and use it in GitHub Desktop.
Hexagonal extraction of a controller action from reverb.com, showing reuse between controller and Grape/Roar based API. This is sample code stripped down to the essentials and is not guaranteed to work as-is :)
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
class Reverb::Actions::WatchListing | |
def self.watch(user, product, listener) | |
if product.owner?(user) | |
listener.failure(I18n.t('flash.watchlist.error_own')) | |
else | |
Reverb::Analytics.track(user, :watch_product) # FIXME, this doesn't belong here | |
user.user_watch_products.create(:product_id => product.id) | |
listener.success | |
end | |
end | |
end |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
module Reverb | |
class Wants < Grape::API | |
post '/wants' do | |
class WatchListingResponder < SimpleDelegator | |
def success | |
{"success" => true} | |
end | |
def failure(message) | |
error!({ "error" => message}, 412) | |
end | |
end | |
Reverb::Actions::WatchListing.watch(current_user, Product.find(params[:id]), WatchListingResponder.new(self)) | |
end | |
end | |
end |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
class Dashboard::Buying::WatchedProductsController < Dashboard::BaseController | |
def create | |
product = Product.find(params[:id]) | |
Reverb::Actions::WatchListing.watch(current_user, product, WatchListingResponder.new(self)) | |
redirect_to product_url(product) | |
end | |
private | |
class WatchListingResponder < SimpleDelegator | |
def success | |
flash[:success] = "Listing has been added to #{link_to_watchlist}." | |
end | |
def failure(message) | |
flash[:error] = message | |
end | |
def link_to_watchlist | |
view_context.link_to 'your watchlist', dashboard_buying_watched_products_url | |
end | |
end | |
end |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
describe Dashboard::Buying::WatchedProductsController do | |
stub_user | |
let(:product) { mock('product', :id => 1) } | |
before { Product.stub(:find).with("1") { product } } | |
describe "#create" do | |
let(:responder) { Dashboard::Buying::WatchedProductsController::WatchListingResponder.new(subject) } | |
it "watches the listing" do | |
Reverb::Actions::WatchListing.should_receive(:watch).with(user, product, anything) | |
post :create, :id => product.id | |
response.should redirect_to product_url(product) | |
end | |
it "handles error display" do | |
responder.failure("foo") | |
flash[:error].should == "foo" | |
end | |
it "handles success display" do | |
responder.success | |
flash[:success].should =~ /Listing has been added to.*your watchlist.*/ | |
end | |
end | |
end |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Thank you for the comments, @mattwynne. Agreed, the analytics should be a listener. As far as abstracting the wiring, that's definitely an idea. I mean essentially what i'm going for is that Reverb::Analytics would eventually be wired into pretty much every business class.
I'm also looking toward the future and implementing activity streams. Maybe the listener api is that the business case sends out a success with a sort of actor/action/properties stream which can then be picked up by listeners such as analytics, activity stream processors, etc.
Again the biggest question is where the wiring happens. Your statement about abstracting the wiring makes sense to me in principle but..would it look something like this? A base class that sets up default listeners and children then add to that...