Difference Between Render and Yield in Rails

Difference between Render and Render Partial and Yield

render & render partial:

  • render 'some_view' is a shorthand for render partial: 'some_view'.

  • render file: 'view' will look for a file view.html.erb and NOT _view.html.erb (.erb or any other renderer you use)

  • render can pass local variables for the partial if you do not use collections or layouts, like

     render 'some/path/to/my/partial', custom_var: 'Hello'
  • Passing local variable guides
  • Rendering the default case

yield & content_for

  • yield is typically used in layouts. It tells Rails to put the content for this block at that place in the layout.
  • When you do yield :something associated with content_for :something, you can pass a block of code (view) to display where the yield :something is placed (see example below).

A small example about yield:

In your layout:

<html>
<head>
<%= yield :html_head %>
</head>
<body>
<div id="sidebar">
<%= yield :sidebar %>
</div>
</body>

In one of your view:

<% content_for :sidebar do %>
This content will show up in the sidebar section
<% end %>

<% content_for :html_head do %>
<script type="text/javascript">
console.log("Hello World!");
</script>
<% end %>

This will produce the following HTML:

<html>
<head>
<script type="text/javascript">
console.log("Hello World!");
</script>
</head>
<body>
<div id="sidebar">
This content will show up in the sidebar section
</div>
</body>

Posts that might help:

  • Embedded Ruby -- Render vs. Yield?
  • Render @object and locals vs render :partial
  • Rails: about yield

Links to documentation & guides:

  • http://guides.rubyonrails.org/layouts_and_rendering.html#passing-local-variables
  • http://apidock.com/rails/ActionView/Helpers/CaptureHelper/content_for
  • http://apidock.com/rails/ActionController/Base/render

Embedded Ruby -- Render vs. Yield?

render is used for invoking a partial page template whereas yield is used a placeholder where you want the output of your templates to yield their content. So you use render when building up the content, and yield to show the content in essence.

As a general rule of thumb, yield is used in the 'layout' level templates (in the most basic example, the application.html.erb in the /app/views/layout directory). Render is used in your resource/action specific templates.

Also take a look at the content_for tag (block) and how you can use it to further break up your application-level templates into sections.

Obligatory guides@rubyonrails.org link: http://guides.rubyonrails.org/layouts_and_rendering.html

render partial vs template vs render vs yield

Try using <%= render partial: "/test_results/shared/header" %> instead of <%= render partial: "/test_results/shared/_header" %>. This is because of Rails naming conventions. http://guides.rubyonrails.org/layouts_and_rendering.html#using-partials

Rails what is the difference between content_for and yield?

yield is how you specify where your content areas is going to go within a layout. You might have something like this:

<div>
<h1> This is the wrapper!</h1>
<%= yield :my_content %>
</div>

content_for is how you specify which content is going to be rendered into which content area. You might have something like this:

<% content_for :my_content do %>
This is the content.
<% end %>

The result would be

<div>
<h1> This is the wrapper!</h1>
This is the content.
</div>

They are opposite ends of the rendering process, with yield specifying where content goes, and content_for specifying what the actual content is.

Is there a generally accepted best practice?

The best practice is to use yield in your layouts, and content_for in your views. There is a special second use for content_for, where you give it no block and it returns the previously rendered content. This is primarily for use in helper methods where yield cannot work. Within your views, the best practice is to stick to yield :my_content to recall the content, and content_for :my_content do...end to render the content.

Rails: about yield

Without any arguments, yield will render the template of the current controller/action. So if you're on the cars/show page, it will render views/cars/show.html.erb.

When you pass yield an argument, it lets you define content in your templates that you want to be rendered outside of that template. For example, if your cars/show page has a specific html snippet that you want to render in the footer, you could add the following to your show template and the car_general layout:

show.html.erb:

<% content_for :footer do %>
This content will show up in the footer section
<% end %>

layouts/car_general.html.erb

<%= yield :footer %>

The Rails Guide has a good section on using yield and content_for: http://guides.rubyonrails.org/layouts_and_rendering.html#understanding-yield

The API documentation for content_for is helpful too and has some other examples to follow. Note that it's for Rails 3.1.1 , but this functionality has not changed much since 2.3, if at all and should still apply for 3.0.x and 3.1.x.

rails partial's layouts with named yield - why is yield block never used?

The workaround would be to wrap your layout into an helper method using blocks (which should be able to yield correctly).

You may want to fil a bug about the original problem.

Rails 4 content_for and yield displays blank page

Why are you rendering partials as the views for your actions?

def manage_accounts
@accounts = Account.order('id').page(params[:page]).per(15)
render partial: 'manage_accounts'
end

Calling render partial like this will only render the content of the partial and will not load the layout. If you want the layout (and it certainly sounds like you do) then rename this file to a normal view app/views/administrators/manage_accounts.html.erb and then remove the render call from your action altogether.

I would also advise splitting each of these manage routes out into their own controllers, so instead you would have app/views/admin/accounts/index.html.erb, which would become the new view to manage accounts. I suggest this because it falls in line with the more traditional CRUD design of a Rails application.



Related Topics



Leave a reply



Submit