Rails Params: where do they come from?

Rack

To understand how Rails interprets params, you will have to understand the basics of Rack and how Rails interacts with it. According to the document of the rack:

Rack provides a minimal interface between web servers that support Ruby and Ruby frameworks. To use Rack, provide an “app”: an object that responds to the call method, taking the environment hash as a parameter, and returning an Array with three elements:

1. The HTTP response code
2. A Hash of headers
3. The response body, which must respond to each

Basically, the Rack will be between the web server and your Rails application.

• It receives the request from the web server, converting it into an env (Ruby hash) variable that Rails can understand
• Rails takes that env variable, does what it needs with it, and returns a simple array back to the Rack with HTTP response code , headers and response body .
• Rack takes that array, converts it back into the appropriate HTTP response, and delivers it to the browser for display.

What is “params”?

To better understand where params comes from, we need to better understand it. Is it a Hash ? Method ? What else?

The best way to find this out is to put binding.pry in a controller action and try to find out what it has.

Take 1 Example:

After submitting a test form

Continue to learn:

1. params is a method of class ActionController::StrongParameter .
2. Although params is expressed as a hash , it is actually an instance of the ActionControll::Paramameter class.

If you are not familiar with ActionControll::StrongParameter , this is the class that gives us more security and is used to restrict the input parameters. If you have used this syntax before, you can thank ActionContoder::StrongParameter :

Inside the source code ActionControll::StrongParameter , you will find the params in it.

As you can see, the params is a getter method of the ActionContoder::StrongParameter class and it returns the instance variable @_params , which is an instance of the ActionContoder::Paramameter class.

At first glance, this may not seem like much help, but this explains why params are available to us in our controllers. Examining your console will tell you why.

We have access to the params because our controller is descendants of ActionContoder::StrongParameter and inherits all its instance methods !

While this explains the ubiquitous params mystery, it doesn’t explain how it gets to it. If you’re like me, you want to know the whole story. For example, what is request.parameters? Where does it come from?

Where does params come from

After learning more about Rails, I saw ActionControll::Metal . Basically, ActionControll::Metal is a khung xương version of ActionControll::Base .

If you look at its source code , you will find some documentation regarding the request as well as a set of methods related to params .

At this point I should mention that, to go deeper into Rails, I have included a stack trace recorder.

The reason I mention this is because you will see all the methods called when Rails receives an env variable from Rack – and there is a LOT of. If you want to see everything happening behind the scenes, check this out.

Although this log is impressive and bizarre, there are only a few lines we need to worry about params and ActionContoder::Metal .

The relevant lines are highlighted in blue

ActionController :: Metal # dispatch

ActionController :: Metal :: action

What this stack trace says is that after Rails is initialized with the env variable, that variable is passed via Rails. At some point, it points to the class method ActionControll::Metal::action . Inside this method, ActionContoder::Metal creates a new instance of itself and calls #dispatch , which sets @_request be a new instance of the ActionDispatch:: Request class.

ActionDispatch::Request is the Rails interface used to interact with HTTP request (env) originating from Rack. One of the methods this API provides is #parameters .

This is the origin of request.parameter !