How do response_to and response_with work in rails?

Question

When there is

def some_action respond_to do |format| format.html {} format.js {} format.json { respond_with @objects} end end 

It seems that the html line and js line automatically feed / call the file corresponding to the action name. Both html and js serve one or the other, not both. Is it correct?

Json is called if you have an ajax call in js that received the call and it is requesting data and they need data to respond, right? Do I need to respond to json and js, or just one?

If you do not respond to name and omit all types, does it respond by default to html and js?

When I respond in the controller, and not in the response_to block in each action, does respond_with @objects any argument (: thml ,: js ,: xml ,: json, etc.)?

Alternative syntax:

 class TheController < ApplicationController respond_to :html, :js, :json, only: [:some_action, :other_action] def some_action respond_with @objects end end 

How does alternative syntax work?

If you use alternative syntax, can you not respond differently to different types of queries? Do you need to do alternative syntax response_to block isntead if you want to react differently? How each of these cases addresses competent degradation in html?

Answer 1

respond_with

For this controller action, response_with generates an appropriate response based on the mime type requested by the client.

This basically means that your controller will send the appropriate data based on the request - for example, if you did the following:

 #app/controllers/articles_controller.rb Class ArticlesController < ApplicationController def show @article = Article.find params[:id] respond_with @article end end 

This will basically respond with data from @article every time you submit a request. If the request is in json type mime-type, it will be returned as a JSON object; if it is an HTML request, it will return with an HTML object in the show view

-

respond_to

Basically allows you to customize specific responses to different mime types. If you send a JS request, you can control the JS response, etc.

respond_to blocks inside controller actions are very cumbersome and are intended only for specific changes / corrections of the response itself.

A simpler way to handle respond_to is to declare it at the top of the controller file, essentially telling Rails that each action will use the parameters defined in this method:

 #app/controllers/your_controller.rb Class YourController < ApplicationController respond_to :js, :json, :html #-> the same as using respond_to block for each action end 

Answer 2

note that in Rails 4 respond_with function was extracted in the gem 'responders' ( https://github.com/plataformatec/responders ).

Answer 3

Cases when you need / do not need each line format.*whatever* .

Usually you do not need it. Rails by default searches for an html file (aka template) corresponding to the action name in the view folder corresponding to the controller name.

I'm not sure when / why json and html sometimes connect together (as in the code generated by the scaffold). Possibly json line for turbolinks (please confirm / correct this). But I know that you use a respond_to with different types of format strings when you want each type to behave differently (for example, process every 10 results through js, but more results through html).

The js format is necessary if you use remote: true in a form or link. This is due to the fact that with the help of this remote control: true disconnects the html template from the service and instead searches for the js file corresponding to the action name and executes / displays this file. You really don't need to respond to the json string if you are doing something only in js.

Bonus: if your js files have js.erb, you can access the instance variables (what about local variables? Please confirm / correct this) that you set in your action. This makes sense because your *.js.erb file is technically a representation. Views can access their variables with appropriate actions (hmm, but what about when vies get rendered from another controller?). Therefore, if you already have access to your action variables in your js file, this may eliminate the need to make ajax calls or json calls in many situations.

Actually, I'm not sure when you need a json string, when you also use remote: true / javascript. explicit calls to jQuery.ajax (), which want the json data to guarantee a response to the json string.