violet_rails
violet_rails copied to clipboard
create guide on how to trace app functionality to code
https://team.restarone.solutions/api_namespaces/2/resources/188
@alis-khadka and @Pralish are often consulted by the team for finding which parts of the code to change, this is an opportunity to create a guide so that their methods are documented for posterity
I usually use following ways to get into the code that is used for the current page.
1.) Using url on the browser's address bar.
Let's see which controller, its action, the template file is being used for the following page:
From the above picture, the url path is /mailbox/message_threads/4. Now lets see the rails routes for that path (filtering with some keyword from the url: message_threads).

From the url http://localhost:5250/mailbox/message_threads/4, we know that 4 is some sort of id (parameter) we provide in the url and it is a GET request. From these clues, we can pin-point that the url is hitting mailbox/message_threads#show action.
Note: If something starts with : (example: :id, :message_thread_id), then it is like a parameter we need to provide in the url.
In the controller level, unless we see some explicit render or redirect_to, it will render the template file under the same path as the controller is with the action's name. So, in this case, it will use a template file under: mailbox/message_threads/show.html.haml.

2.) By inspecting the HTML content of the page.
Lets see how the following page is being served.

Try to look for something specific in the HTML body like: element id, element class or specific text.
In this case, we will use the text `we need your current password to confirm your changes`.
Now, let's search it through out codebase.
From the above, we get to know that it is using the `users/registrations/edit.html.erb` file.
From the path of template file, we get to know that it is hitting the users/registrations_controller#edit action.

But wait! The edit action has been commented out, right?
Now, look at the controller's intial statement;
class Users::RegistrationsController < Devise::RegistrationsController
It is inheriting from devise/registrations_controller. And, devise is a gem/library we are using.
Now, if we look into github repo for devise, we can find the implementation of edit action as follows;
3.) Using the console logs
Let's try to trace the code for the following page.
The moment you hit that url, the details of that request being processed is printed in the rails server's console.

The logs for start of a request looks something like in the above picture which has been highlighted.
A little bit below, we can see which controller is processing that request along with the different parameters that are passed along in that request.
From the logs, now, we know that api_forms_controller's edit action is handling that request.
From here on, we can trace the template file that is being used for this request like the way we did in 1) & 2).
OR!!!
We can further look down the logs!

The console logs provide us with many information. It displays the different SQL query that are used for this page along with time consumption for these queries. It shows the different partial template files, that are also used for this request.
Note: It is more of a personal choice which you will be following to debug your code. I generally tend to stick with a mix of 1) & 3) approach