Refactor UserController#search_users #57

Merged
merged 6 commits into from Feb 7, 2013

Projects

None yet

7 participants

@blowmage
Contributor
blowmage commented Feb 7, 2013

Move the SQL generation behind an intention revealing name, add tests.

@eviltrout
Member

Love it. Any idea why it doesn't merge cleanly? Also would you mind filling out our CLA: http://www.discourse.org/cla

@SamSaffron this approach keeps the SQL but isolates it from the controller. I vastly prefer it but would be more comfortable with your approval before merging.

@blowmage
Contributor
blowmage commented Feb 7, 2013

@eviltrout I created the branch around nine hours ago. If it doesn't merge then you guys must have been busy in that time. :) I'll update on master and re-push.

@blowmage
Contributor
blowmage commented Feb 7, 2013

FWIW, an accompanying blog explaining the thought behind this change here.

@eviltrout
Member

Just wanted to say thanks for an awesome blog post explaining why you did it. It's one thing to link to some code on twitter, it's another to submit a patch to fix it and a detailed blog post of why. I am super impressed, and will happily merge this once @SamSaffron has a chance to review.

@ZogStriP
Member
ZogStriP commented Feb 7, 2013

👍 for the awesome blog post!

@nlalonde
Member
nlalonde commented Feb 7, 2013

Great changes, thanks so much, blowmage! One minor comment is that UserSearch is a service class, not really a model. It belongs in lib, imho.

@steveklabnik
Contributor

One minor comment is that UserSearch is a service class, not really a model. It belongs in lib, imho.

It models searching for a User. Sounds like a model to me.

(Regardless, I think service classes belong in app/models too: like Mike said in his blog post, lib is for things that could be used on other projects.)

@blowmage
Contributor
blowmage commented Feb 7, 2013

A word on UserSearch. The reason it is a class and not a module, even though it is never instantiated, is because I expected to instantiate it as part of this refactor. Ideally, the UserSearch.search implementation would have instantiated a UserSearch object and looked like so:

def self.search term, topic_id = nil
  UserSearch.new(term, topic_id).search_with_sql
end

That would allow me to add new capabilities in a non-destructive way. So if a pure arel search was added, it could look like the following:

def self.search term, topic_id = nil
  UserSearch.new(term, topic_id).search_with_arel
end

That said, I got sleepy and never got that far. I'm still not sure if an arel/ActiveRecord::Relation implementation is wanted, so I figured I'd submit this anyway and see what happened. I suppose this info would be better in a commit message than a comment on the pull request, but there you go.

¯_(ツ)_/¯

@bbonamin
Contributor
bbonamin commented Feb 7, 2013

@blowmage seems like a good choice. I was just about to ask why you decided for a class instead of a module. Your last comment reminded me of this codeclimate blog post http://blog.codeclimate.com/blog/2012/11/14/why-ruby-class-methods-resist-refactoring/

@SamSaffron
Member

I am totally fine with this, more test, more readable code, big wins for Discourse

@eviltrout
Member

❤️❤️❤️

@eviltrout eviltrout merged commit 63c0fdd into discourse:master Feb 7, 2013
@nnrd nnrd added a commit to NickIvanter/discourse that referenced this pull request Apr 24, 2016
@nnrd nnrd Queued posts alerts (task #57) 267eb32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment