Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails – The Missing Parts

eng.joingrouper.com

Post reply on HN
Print view View original

41–50 of 173 posts

Re: Rails – The Missing Parts

#41

Post by tomblomfield »

dhh wrote: post #39

The proof is always in the pudding. While there are good and reasonable times to introduce "interactors", this particular example is poor. The tests presented are anemic, and the code is absolutely not any clearer by being extracted and wrapped. I would indeed have kept all this in the controller. The key point for an "interactor" extraction is imo when you have multiple models being created in symphony, like a Signu…

I agree with you - Interactors are particularly useful when you're creating multiple models, and the example could have been better.

But they're useful for dealing with side-effects of a particular operation too (sending multiple emails, notifying admins). Much better than ActiveRecord callbacks.

If you put this logic in the controller, what happens when you want a separate API controller that does the same thing? Or some admin functionality elsewhere in the codebase? There's zero possibility of code re-use.

Re: Rails – The Missing Parts

#42

Post by ryanbrunner »

avitzurel wrote: post #27

As always, the question is should be in Rails or not. I think that the answer is clear, this should not be a part of rails since it's not true to all apps. I think that if you want to have something real quick, you don't need an interactor/service class. When you have a bigger app, you definitely need that, or you will get to a point where you code is split into models/observers/callbacks/lib/app/concerns and you can…

Mailers, concerns, helpers, observers and a lot of other things in Rails aren't universally used by all apps. Even something as simple as an empty directory and some generators in a stock Rails app would go a long way in educating people that these are patterns that you can use / provide a common language for where these sorts of things should go and what we should call them.

Re: Rails – The Missing Parts

#43

Post by ryanbrunner »

rubiquity wrote: post #24
Axsuul wrote: post #10

I've been looking into incorporating this pattern into my larger Rails apps as well. Another benefits of interactions is DRYing up your code for use in APIs. Some of the more popular interactor gems: https://github.com/orgsync/active_interaction https://github.com/cypriss/mutations

If you need a gem to implement some of these complementary patterns, you're doing it wrong. Draper, Naught, DisplayCase and all of the other gems of patterns are over abstraction 99% of the time. Implement the pattern yourself. Most of these Presenter and Service object patterns are different variations of the Decorator pattern. Ruby happens to ship with 3 great ways to implement decorators: SimpleDelegator (my perso…

The biggest pain points that gems like Draper solve are allowing view helpers in your decorators (which is by no means straightforward when you get into routing helpers), and dealing with some of the strangeness that you get into by wrapping ActiveRecord models (JSON serialization was a biggie for us). It's less about what Ruby gives you, and more about navigating around some of the darker, messier corners of Rails.

Re: Rails – The Missing Parts

#44

Post by jhund »

nwienert wrote: post #32

I've found a happy balance developing with rails by adding two strategies: 1) Use presenters for display-only logic to keep controllers concerned with managing requests only. 2) Using service object / custom classes in /lib for actions on models as well as abstracting any common related functionality. Creators, Updaters, Processors, Orchestrators, etc. Keep your models only concerned with data and not data transforma…

I have documented my strategy for moving from a simple MVP to a maintainable and complex Rails app. Basically I look at factors like how many objects are affected by an operation, and how complex the additional processing is. TL;DR: Use Rails magic when possible, and Object Oriented best practices when necessary.

I created a flowchart that illustrates this strategy: http://rails-recipes.clearcove.ca/pages/how_to_change_object...

Re: Rails – The Missing Parts

#45

Post by ryanbrunner »

seancoleman wrote: post #21

A good litmus test of an experienced Rails developer is how large their /lib directories are in relation to project sizes.

Even better is realizing that you can put whatever you want into /app, and having /app/presenters, /app/decorators, and /app/services directories in your application.

Re: Rails – The Missing Parts

#46

Post by malyk »

tomblomfield wrote: post #41
dhh wrote: post #39

The proof is always in the pudding. While there are good and reasonable times to introduce "interactors", this particular example is poor. The tests presented are anemic, and the code is absolutely not any clearer by being extracted and wrapped. I would indeed have kept all this in the controller. The key point for an "interactor" extraction is imo when you have multiple models being created in symphony, like a Signu…

I agree with you - Interactors are particularly useful when you're creating multiple models, and the example could have been better. But they're useful for dealing with side-effects of a particular operation too (sending multiple emails, notifying admins). Much better than ActiveRecord callbacks. If you put this logic in the controller, what happens when you want a separate API controller that does the same thing? Or…

I bet dhh is going to say something like "then refactor your controller into a service/interactor/etc., but not before".

YAGNI, and all that.

Re: Rails – The Missing Parts

#47

Post by dhh »

dhh wrote: post #39

The proof is always in the pudding. While there are good and reasonable times to introduce "interactors", this particular example is poor. The tests presented are anemic, and the code is absolutely not any clearer by being extracted and wrapped. I would indeed have kept all this in the controller. The key point for an "interactor" extraction is imo when you have multiple models being created in symphony, like a Signu…

I rewrote the code in this example to use the "Beginner's Version" of Rails (sigh). You judge which you like better: https://gist.github.com/dhh/9333694

Re: Rails – The Missing Parts

#48

Post by dhh »

tomblomfield wrote: post #41
dhh wrote: post #39

The proof is always in the pudding. While there are good and reasonable times to introduce "interactors", this particular example is poor. The tests presented are anemic, and the code is absolutely not any clearer by being extracted and wrapped. I would indeed have kept all this in the controller. The key point for an "interactor" extraction is imo when you have multiple models being created in symphony, like a Signu…

I agree with you - Interactors are particularly useful when you're creating multiple models, and the example could have been better. But they're useful for dealing with side-effects of a particular operation too (sending multiple emails, notifying admins). Much better than ActiveRecord callbacks. If you put this logic in the controller, what happens when you want a separate API controller that does the same thing? Or…

Coulda, woulda, damn shoulda. You're future coding with your "what ifs". Most controller actions are not reused. The time to extract for reuse is when you need to reuse. Not crystal balling about that you probably will be in the future.

Because when the reuse case actually arrives, you might find that you need to reuse some, but not all of the action. If you're literally doing the exact same thing for both web and api, why are you using a separate API controller? Just use respond_to with formats.

Second, yes, you shouldn't have side-effects like sending email in your models. But you don't need to! Just stick that logic in your controllers. That's what it's there for -- to render the views (of which emails is one of them -- see http://david.heinemeierhansson.com/2012/emails-are-views.htm...).

The AR callbacks are wonderful for coordinating the domain model. Often times you'll want to create auxiliary objects when something else is created. That's what's it's there for. Or to otherwise keep the integrity of the domain model in place.

Re: Rails – The Missing Parts

#49

Post by rasur »

ollysb wrote: post #2

Perhaps because it's written with examples in java but I often feel like no one in the rails community has ever read Eric Evan's Domain Driven Design[1]. It's far and away the best material I've ever seen on how to organise large code bases. It covers pretty much every suggestion that I've seen from the rails community. Sometimes the rails community can feel like the fitness industry, everybody just rebranding things…

In my first Rails job, I was handed a copy of this book to read. I would agree with your comments, although I cannot speak for the Ruby Community as such. Well worth reading.

Re: Rails – The Missing Parts

#50

Post by rgbrgb »

tomblomfield wrote: post #41
dhh wrote: post #39

The proof is always in the pudding. While there are good and reasonable times to introduce "interactors", this particular example is poor. The tests presented are anemic, and the code is absolutely not any clearer by being extracted and wrapped. I would indeed have kept all this in the controller. The key point for an "interactor" extraction is imo when you have multiple models being created in symphony, like a Signu…

I agree with you - Interactors are particularly useful when you're creating multiple models, and the example could have been better. But they're useful for dealing with side-effects of a particular operation too (sending multiple emails, notifying admins). Much better than ActiveRecord callbacks. If you put this logic in the controller, what happens when you want a separate API controller that does the same thing? Or…

>> If you put this logic in the controller, what happens when you want a separate API controller that does the same thing?

You refactor.

In my experience, anytime you're writing something for the sake of "possible code re-use", you're wasting time. Code should and does get refactored often. By adding levels of indirection from the outset, you add a barrier to refactoring and likely additional unnecessary code.

Post reply on HN