Not sure what the difference between underscore (student_state) and tableize (student_states), other than tableize also pluralizes. However, not sure how they can be used
differently. Obviously, you can use tableize to reference table name in
database. But what different functionality does underscore provide, such as when you see :student_state compared to :student_states when used as symbols. Thanks for suggestions.
tableize will pluralize your string whether the original was singular or plural, while underscore will only add underlines.
While this may seem trivial, it's all about abstracting the details of database implementation away from the developer. If, down the road, Rails began formatting table names differently, the only method that would need to change would be tableize. All other places in the Rails code that refer to table names can stay the same, because they're still calling the tableize method. A change to the underlying structure of rails is therefore limited and much less damaging.
This is referred to as "orthoganality" in computer science. Now that you know what it means, try to throw it around in conversation to make yourself look smarter. Did it work for me? :)
Related
I am working through a tutorial book and I came across something I had never seen before. In rails I am accustomed to getting the values of a relationship like this
<%= current_user.favorites.count %>
The author of the book used the & operator when doing this though, which appeared to do the same thing (I believe that I understand the & operator, I have just never seen it used like this)
<%= current_user&.favorites&.count %>
There was no explanation for this, so I took it as just another way to write it, but I have never seen this before in years of working with Rails and reading books/tutorials.
Is there a performance reason for doing it like this, or is it just personal preference?
It was inside a turbo_frame_tag if that makes any difference.
& is the safe navigation operator and prevents a NoMethodError if you call a method on Nil.
Its use here isn't really that strange - what you're calling an "association" is after really just a method generated what is presumably has_many :favorites. So here the author is calling the method no matter if the record exists or not and is then creating an extra db hit with a COUNT query. Not great.
Its all kind of silly too since you most like want to wrap it with some markup so you'll need an if anyways.
Using long chains of the safe navigation operator is regarded as an antipattern of sorts since it lets you violate the Law of Demeter with blatant disregard and masks bugs.
Now that my controllers are expanding beyond the basic REST actions it can get somewhat confusing as to whether a given expression is either a built in method, a controller method, from the model, or a variable.
Would adding empty parentheses to my controller methods when I call them from other methods cause any problems down the road? Like so:
if customer.save?
subscription_checker()
end
I'm at least trying to always use an underscore in the names of the methods I create in order to make them look different from most of the built in methods.
Would adding empty parentheses to my controller methods when I call them from other methods cause any problems down the road?
This is a valid way to distinguish between variables vs methods in ruby, but "You're Doing It Wrong" ™
Part of the ruby paradigm is that you shouldn't typically care whether the thing you're referencing is a variable or a method. This makes the code easier to read and refactor; keeping the developer's attention focused on code's intent rather than its implementation.
This design pattern is often referred to as "bare words", and I highly recommend the following RubyTapas episode on the subject: http://www.virtuouscode.com/2012/10/01/barewords/
I would also recommend that you have a quick read through a ruby style guide, to see what common conventions are considered "good" or "bad" by the community. (Ruby code styles are extremely well conformed to by the community!) For example, from this guide:
Only omit parentheses for
Method calls with no arguments:
# bad
Kernel.exit!()
2.even?()
fork()
'test'.upcase()
# good
Kernel.exit!
2.even?
fork
'test'.upcase
In your particular code above, although it's hard to say for sure without knowing more context, I suspect that subscription_checker should actually be abstracted into a separate class rather than yet-another-method in the controller. But as I say, in order to give any concrete advice here I'd need to see more of the source file this is taken from.
much to quite a few people's disappointment. I've decided to learn Ruby on Rails (I've been told by many people it's pointless to learn it, but ruby seems easy to get into and rails is a fun framework).
So I'm just now slowly starting to wrap my head around the naming convention with singular being used for the model and plural being used for the controller.
One thing I'm having a bit of trouble finding concise information on is Capitalization vs lowercase usage.
Example being
#order = Order.create(order_date: Time.now, customer_id: #customer.id)
Why exactly is 'Order.create' capitalized but not 'order_date'?
When to invoke capitalization has really got me confused when I use the rails console. I don't know when I'm suppose to be capitalizing or why. I want to say it too has to do with the model/controller naming scheme but neither of them are plural so that can't be the answer right?
Thanks for any help that is given, I really would/do appreciate it.
CamelCase is used for classes and modules (e.g. String, Array, etc.)
snake_case is used for variables and methods (symbols are also usually snake_case)
SCREAMING_SNAKE_CASE is used for naming constants (e.g. STDOUT)
This is to do with naming conventions in Ruby and/or Rails.
Typically:
Create classes, modules using CamelCase.
Create methods, variables using underscore_case.
Create constants using UPPER_UNDERSCORE_CASE.
Take a look at different methods available in ActiveSupport to convert a string into various cases. http://apidock.com/rails/v4.1.8/String/camelize
Read Naming and Schema Conventions at Rails Guide.
A more succinct information.
HTH
This is more a ruby thing actually. In ruby you use capitalization (camel case) for class and module names. And snake_case for method and variable names.
In your specific case Order is a class, create is a method, #order is an instance variable. order_date and customer_id are symbols that represent the columns on the database.
I'm about to add a model to my app and I was inclined to call it "collection". It was also to have a field called "status" but it occurred to me that I think Rails uses both those terms elsewhere and this might be a problem worth avoiding.
Should I pick another model name instead of collection? and would state be better than status?
Thanks.
I've used both before - I think you should use whatever makes most sense to you, that aren't reserved words. If you think they will conflict with logic elsewhere in your app, then you might consider a different model name and/or column name.
I am using Ruby on Rails 3.1 and I would like to know how, when and why I should use one of the following code rather than another on internationalizing my application (I18n gem):
t(:test_key)
t('test_key')
t('.test_key')
That is, what is the "subtle" difference between using t(:test_key), t('test_key') and t('.test_key')? What are best practices about this issue?
I think first two are equivalent and you just refer to main key in your translations, fo example
t('hello_world')
# t(:hello_world) is an equivalent
would reffer to
en:
hello_world: "Hello world"
However if you use dot notation, its called lazy lookup
and it will look deeper in your translation structure based on controller/action notation
So if you use this inside users/index template
t('.hello_world')
it will be resolved to
pl:
users:
index:
hello_world: "Witaj świecie"
You'll find more about internalization in Rails Guides
I guess it's a but up to you to decide when you actually want to use the different ones, but I'd prefer to use lazy lookup as much as possible in my views, unless you need to translate some generic component whose keys does not live in the scope of your view.
The reason why I prefer the lazy lookup is that it makes the code look cleaner, and as long as you're familiar with how the i18n gem works, you shouldn't have any trouble knowing where to look for the keys.
On the other hand, if you have such components, they should really live in a partial, a cell or something similar.
One thing worth mentioning abouth the non-lazy ones, are that you can provide them with a scope for where to look for the key in question. Again, it's up to you whether you like t('foo.bar.baz.test_key') or t(:test_key, :scope => 'foo.bar.baz').
It also takes a bunch of other options, but all of this is neatly documented in the rails guide, so I won't explain it further here.