Has the payload dependency container experiment been successful?

The upcase-exercises repo uses an experimental payload gem for defining dependencies, sort of like an IoC Container.

Has it made code more maintainable and easier to change?

Is the complexity and indirection worth it?

Would thoughtbot recommend its use on other projects?

@benorenstein @jferris

Has it made code more maintainable and easier to change?
Is the complexity and indirection worth it?

In some places, it’s definitely been worth it. If you page through the Git history, you can see some interesting examples where we were able to introduce functionality by only writing new classes. It makes it very easy to layer things in and remove them, or conditionally apply logic. It also generally makes it easier to achieve separation of concerns. Reusability has been fairly easy, and performing large changes and refactorings has been better than usual.

That being said, there are some issues with it.

The current upcase-exercises repository has all its dependencies wired together in a single file, which is getting rather large, even though the project isn’t crazy complex. I’ve played with some ideas around namespacing and modules, but haven’t been able to apply them successfully yet.

There’s some lingering confusion around the service vs factory ideas. The decorator concept we have in there right now doesn’t seem very powerful, and I think it causes more problems than it’s worth.

We experimented with exposing the request to the dependency configuration file, and I consider that to be a failure. I’d like to remove that and try some other ideas instead.

Bottom line: if you’re interested in SOLID or dependency injection in general, I’d recommend giving it a shot. However, I don’t think Payload has proven to be good or bad so far.

Tangent: although I’ve found SOLID to fix a number of issues in the class-based approach used by most Rails applications, the additional complexity required to decorate simple behaviors has increased my desire to explore new approaches like functional composition. Using SOLID was nicer in some ways, but I still hope there’s something much better out there.

1 Like

Thanks for the detailed response!

That was my initial concern, it felt like CanCan’s ability.rb file. The one for our API is monstrous!

I’m at the point where a lot of my controllers just line up dependencies, so it feels like I’m ready to give an IoC container a chance!

I’m also interested in functional composition, the idea of piping data through many objects (ala unix) sounds great to me. There’s a talk by @jessitron that’s worth a look for anyone interested :smile: