Différence entre Render et Render Partial et Yield

Je l’ai lu dans les guides Rails, J’ai regardé le livre de Micheal Hartel et je le lis maintenant dans le livre de Rails View, mais je rest confus 🙁

Il y a un fichier _footer.html.erb donc c’est un “partiel” et dans le code qu’il a écrit:

  

Donc, si je comprends bien, quand il voit cela, il va insérer le code HTML pour le fichier de pied de page ici. Ok … Quelques pages plus tard, il dit:

  

alors POURQUOI cette fois nous avons le mot “partiel” ici mais nous ne l’avions pas dans le précédent?

Et là ailleurs, je vois

Donc, ce yield insère aussi du HTML à sa place? Eh bien, n’est-ce pas ce que faisait le render ?

J’espérais qu’un autre programmeur au lieu de livres m’explique cela, peut-être que je le comprends cette fois-ci 🙂

render et render partial:

  • render 'some_view' est un raccourci pour render partial: 'some_view' .
  • render file: 'view' recherchera un fichier view.html.erb et NOT _view.html.erb ( .erb ou tout autre moteur de rendu que vous utilisez)
  • render n’acceptera pas de variables locales supplémentaires pour le partiel, vous devez utiliser render partial: comme suit pour cela:

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

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

yield et content_for

  • yield est généralement utilisé dans les dispositions . Il indique à Rails de placer le contenu de ce bloc à cet endroit dans la mise en page.
  • Lorsque vous yield :something associé à content_for :something , vous pouvez passer un bloc de code (vue) pour afficher où le yield :something est placé (voir exemple ci-dessous).

Un petit exemple de rendement:

Dans votre mise en page:

   <%= yield :javascript_head %>     

Dans l’un de vos points de vue:

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

Cela produira le code HTML suivant:

        

Des messages qui pourraient aider :

  • Ruby incorporé – Render vs. Yield?
  • Render @object et les locaux vs rendu: partiel
  • Rails newbie: sur le rendement

Liens vers la documentation et les guides :

À propos du rendu, rendu: partiel et rendement

  • render: template et render: partial sont deux fichiers dans les rails.


    render: les templates sont principalement créés en fonction d’une action avec la syntaxe demo.html.erb

    render: partial sont réutilisables et appelés à partir de différentes vues, sont partagés entre de nombreuses pages dans l’application et la syntaxe est _demo.html.erb

  • céder et rendre ..


Le rendement est un moyen d’appeler un bloc de code avec sa sortie, mais le rendu inclura un modèle de page partiel où il est appelé. Dans les rails, le rendement est principalement utilisé dans la mise en page, tandis que le rendu est utilisé dans les actions ou leurs modèles.

Certains développeurs pensent que redirect_to est une sorte de commande goto, déplaçant l’exécution d’un endroit à un autre dans votre code Rails. Ce n’est pas correct Votre code cesse de fonctionner et attend une nouvelle demande pour le navigateur. Il se trouve que vous avez dit au navigateur quelle requête il devrait faire ensuite, en renvoyant un code d’état HTTP 302.

Considérez ces actions pour voir la différence:

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

Avec le code sous cette forme, il y aura probablement un problème si la variable @book est nulle. Rappelez-vous qu’un render :action n’exécute aucun code dans l’action cible, donc rien ne définira la variable @books que la vue d’index nécessitera probablement. Une façon de résoudre ce problème est de redirect au lieu de rendre:

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

Avec ce code, le navigateur effectuera une nouvelle demande pour la page d’index, le code de la méthode d’index sera exécuté et tout ira bien.

Le seul inconvénient de ce code est qu’il nécessite un aller-retour vers le navigateur: le navigateur demande l’action show avec / books / 1 et le contrôleur constate qu’il n’y a pas de livres, le contrôleur envoie donc une réponse de redirection 302 au navigateur. lui demandant d’aller à / books /, le navigateur se conforme et envoie une nouvelle demande au contrôleur demandant maintenant l’action d’index, le contrôleur récupère alors tous les livres dans la firebase database et affiche le modèle d’index, le renvoyant au navigateur qui le montre ensuite sur votre écran.

Bien que dans une petite application, cette latence ajoutée ne soit pas un problème, il faut y penser si le temps de réponse est un problème. Nous pouvons démontrer une façon de gérer cela avec un exemple artificiel:

 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 

Cela permettrait de détecter l’absence de livres avec l’ID spécifié, de renseigner la variable d’instance @books avec tous les livres du modèle, puis de rendre directement le modèle index.html.erb, en le renvoyant au navigateur avec un message d’alerte flash à dire à l’utilisateur ce qui s’est passé.