ruby-on-rails ruby-on-rails-3.2

ruby on rails - Diferencia entre Render y Render Parcial y Rendimiento



ruby-on-rails ruby-on-rails-3.2 (3)

Lo he leído de las guías de Rails, he mirado el libro de Michael Hartel y ahora lo leo desde el libro de Rails View, pero todavía me confundo :(

Hay un archivo _footer.html.erb , por lo que es un "parcial" y en el código que ha escrito:

<%=render ''layouts/footer'' %>

así que mi entendimiento es que cuando ve esto, va e inserta el HTML para el archivo de pie de página aquí. Ok ... Ahora, unas pocas páginas después, está diciendo:

<%= render partial: ''activitiy_items/recent'' %>

¿POR QUÉ esta vez tenemos la palabra "parcial" aquí pero no la teníamos en la anterior?

Y en algún otro lugar veo <%= yield :sidebar %>

Entonces, ¿este yield también inserta HTML en su lugar? Bueno, ¿no era lo render estaba haciendo render ?

Esperaba que si otro programador en lugar de libros me explicara esto, quizás lo entendiera esta vez :)

Acerca de renderizar, renderizar: parcial y rendimiento

  • render: plantilla y render: parcial son dos archivos en rieles.

    render: la plantilla se crea principalmente según una acción con la sintaxis demo.html.erb

    render: partial son reutilizables y llamados desde diferentes vistas, se comparten entre muchas páginas en la aplicación y la sintaxis es _demo.html.erb

  • rendimiento y render ..

El rendimiento es una forma de llamar a un bloque de código con su salida, pero el procesamiento incluirá una plantilla de página parcial a la que se llama. En los rieles, el rendimiento se usa principalmente en el diseño, mientras que el procesamiento se usa en acciones o sus plantillas.

render y render partial:

  • render ''some_view'' es una abreviatura de render partial: ''some_view'' .
  • render file: ''view'' buscará un archivo view.html.erb y NO _view.html.erb ( .erb o cualquier otro renderizador que use)

  • render no aceptará variables locales adicionales para el parcial, necesita usar render partial: como sigue para eso:

    render partial: ''some/path/to/my/partial'', locals: { custom_var: ''Hello'' }

( http://guides.rubyonrails.org/layouts_and_rendering.html#passing-local-variables )

yield y contenido_para

  • yield se usa generalmente en diseños . Le dice a Rails que coloque el contenido de este bloque en ese lugar del diseño.
  • Cuando yield :something asociado con content_for :something , puedes pasar un bloque de código (view) para mostrar dónde está el yield :something está colocado (ver ejemplo a continuación).

Un pequeño ejemplo sobre el rendimiento:

En tu diseño:

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

En uno de tus puntos de vista:

<% content_for :sidebar do %> This content will show up in the sidebar section <% end %> <% content_for :javascript_head do %> <script type="text/javascript"> console.log("Hello World!"); </script> <% end %>

Esto producirá el siguiente 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>

Publicaciones que pueden ayudar :

Enlaces a documentación y guías :

Algunos desarrolladores piensan en redirect_to como una especie de comando goto, moviendo la ejecución de un lugar a otro en el código de Rails. Esto no es correcto. Su código deja de funcionar y espera una nueva solicitud para el navegador. Simplemente sucede que le has dicho al navegador qué pedido debe hacer a continuación, enviando un código de estado HTTP 302.

Considere estas acciones para ver la diferencia:

def index @books = Book.all end def show @book = Book.find_by(id: params[:id]) if @book.nil? render action: "index" end end

Con el código en esta forma, es probable que haya un problema si la variable @book es nula. Recuerde, un render :action no ejecuta ningún código en la acción del objetivo, por lo que nada configurará la variable @books que la vista del índice probablemente requiera. Una forma de solucionar esto es redirigir en lugar de procesar:

def index @books = Book.all end def show @book = Book.find_by(id: params[:id]) if @book.nil? redirect_to action: :index end end

Con este código, el navegador realizará una nueva solicitud para la página de índice, se ejecutará el código en el método de índice y todo estará bien.

El único inconveniente de este código es que requiere un viaje de ida y vuelta al navegador: el navegador solicitó la acción de mostrar con / books / 1 y el controlador encuentra que no hay libros, por lo que el controlador envía una respuesta de redireccionamiento 302 al navegador diciéndole que vaya a / books /, el navegador cumple y envía una nueva solicitud al controlador solicitando ahora la acción de índice, el controlador obtiene todos los libros en la base de datos y procesa la plantilla de índice, enviándola de nuevo al navegador que luego lo muestra en su pantalla.

Mientras que en una aplicación pequeña, esta latencia agregada puede no ser un problema, es algo en lo que pensar si el tiempo de respuesta es una preocupación. Podemos demostrar una forma de manejar esto con un ejemplo artificial:

def index @books = Book.all end def show @book = Book.find_by(id: params[:id]) if @book.nil? @books = Book.all flash.now[:alert] = "Your book was not found" render "index" end end

Esto detectaría que no hay libros con la ID especificada, llene la variable de instancia de @books con todos los libros en el modelo, y luego represente directamente la plantilla index.html.erb y la devuelva al navegador con un mensaje de alerta instantánea para decirle al usuario lo que sucedió.