BrianVanLoo

The point of that particular item in the article was to eliminate the conditional logic for these display items from the place that it occurs: in the views. Make the goal to get rid of all the places where you want to put <% if ... %> in your view code. So rather than add even more logic to determine if it's the guest user or not to decide if you're displaying your reply button how about adding a method to your User object that returns the markup for your reply button? Then in the guest object make that return some kind of placeholder markup that isn't the reply button. The problem as I see it are complex view files that mix html (yeah, I know there are other templating options) with a whole bunch of conditional programming code. The cognitive load to try and understand if the html is correct (are all those tags closed properly?) combined with all that conditional logic quickly becomes overwhelming.

Glad to see some support on the gem list. That was one of the items I really hadn't seen discussed anywhere else and was wondering if it only bothered me. I did some dev ops for a project that turned out to be what would have sounded like a fairly simple, small Rails app on a rather low-traffic site. I kept having to increase the server instance size as the team cargo-culted more and more gems into the Gemfile and the multiple Rails executables run under Unicorn continued to grow in size and eventually run out of memory on the server. I agree that my example using OpenStruct only moves the conditional but in this case it moves it out of a place where I find conditional logic much harder to reason about. Also, if there were more attributes than just name that come out of that object you could potentially be eliminating many more conditionals with just the one in current_user which also seems like a win.

Glad you found this helpful. Regarding the TDD stuff, I went through the same difficulties as you described when I was starting out too. I even had that epiphany stage where I didn't write tests for something and ended up regretting it later. I have found that over time I've gotten much more efficient writing the tests and don't necessarily write them for everything, only the things that experience now tells me are important. Also, I give myself permission to "spike out" those features I'm still trying to figure out how they should work and not write any tests for them as I figure them out. After I've got it figured out I'll do a "git stash" (usually never returned to) and start over writing the feature I now understand using TDD.