Finally it comes the time when (even if you avoided at all costs) you must develop the view part of the project. Here I'll summarize some of my experiences in Tips that you should keep in mind before start coding like a monkey.
Reorganize your view structure if the project doesn't follow the Rails golden path
A lot of people tries at all costs to adapt their code to the Rails organization, that shouldn't be always the case.
There will be times when you will have a same partial, shared in more than one controller. This normally causes some questions about why the partial is in this controller and not in the other, the simple answer to that question would be: "the partial is in the controller X because it was the first one who used it".
In this cases, you should keep a shared folder inside the views folder, this way you'll know that the partial doesn't belong to any controller at all, is just a shared view between lot's of controllers. If you notice that your shared folder is starting to get fat, organize partials that have common purposes in sub-folders, this way you won't be lost when looking for a shared partial with a particular purpose.
Then, when rendering a partial, you would do something like
Here we have shared partials that are being used in the header sections of lot's of controllers. This way you keep an order in your views that is more comfortable and more understandable.
In your partials, use helpers as much as you can
When you have partials, is probably because you repeat the same view in a lot of places. The thing is that you normally would like the partials to behave differently in some cases, say you want the URL's of the partials of a profile to point somewhere else or not to point anywhere at all (when you have a public profile for example). In this cases the best thing you can do is use helpers for returning the URL's.
You shouldn't bother with lots of if's and else's when the sweet polymorphism can do the job quite easy, just overwrite the method in the controller's helper and the partial will behave differently on each controller it is called1.
So for example, Imagine we have a profile section, and you have 2 versions of this profile, the public version, and the private version. This versions have a lot of things in common in the view side, but when we are in public profile, all the links points to a link of a public section, while when on private profile, the links point to private sections.
The view on the partial (shared/header/month.html.erb) would be something like
Now, when we are on the public controller, the helper should behave like
And on the private controller, the helper should behave like
Here we are letting the polymorphism of the helpers solve the view repetition, by just providing a method that behaves differently depending on where we are standing.
Parametrize... ALWAYS
Programmers are lazy, and there is nothing wrong with that, but sometimes this laziness can give us some nasty moments, it all starts with: "why pass it as a parameter? Just access it via the current_user, or the @instance_variable and you won't have to pass parameters every time you invoke this helper/partial".
This will give you more problems than benefits at the end, just imagine what would happen if the helper method/partial would work for every user we would like to, but it only calls the current_user?. This is when refactoring comes along and we change the current_user for a parametrized user, the thing is that you call this refactored method like 150 times. There is when you say... "damn, it would be easier if I just passed the user as a parameter from the beginning". Always keep in mind that the more you use your global environment, the less reusable is your code.
Don't to use instance variables in the partials (change them with the :locals option), nor to use instance variables on the helper modules if they are not being used only in the module for private logic (pass the objects as parameters to the functions).
I hope this 3 tips can help you get a better start when coding views.
