Features/user controller

[npauzenga]

Happy weekend @enriikke!

I finished a pass on the users_controller, complete with interactors and specs all around. I'm going to add a few notes to things that might be worth checking out but please have a look and let me know what can be improved!

On futures PRs I'll submit all of the tests before the functionality. I just wanted to go through one (using TDD) to figure out what the tests were going to look like in the end 😁

[npauzenga]

@enriikke on #show and #destroy I've got else branches that handle errors. I don't often see this in other controllers I've looked at. Should I simplify these to the basic assignment (@user = User.find(:id) or similar) and forget about the elses? Seems like it's always better to have a safety net?

[enriikke]

I tend to prefer to maintain consistency and to keep using interactors throughout the app, even in simple cases like this. That's just my preference thought 😄. You can argue that abstracting something so simple into an interactor could make it harder to read.

It also depends on what you are doing. For some apps, show could required a more complex flow that you might want to check what the result was. Rails automatically handles not_found for ActiveRecord and Postgres, but if you decide to use something else then you have to catch those errors yourself. The interactor patter helps with that.

I think it really boils down to a matter of preference. Rails has conventions for things and some people like just following the same conventions. It makes it easier to read and understand an app if you know where to look. 😃

[enriikke]

Looking good @npauzenga!! 🚀 🐓