Ruby on Rails: Address lint issues in the Rails Basics section (#30474)

* fix: address lint issues in controllers.md

* fix: address lint issues in routing.md

* fix: address lint issues in views.md

* fix: edit the heading in controllers.md

* fix: fix formatting of a note box in routing.md

* fix: fix minor formatting in views.md

Author: goran1010

ruby_on_rails/rails_basics/controllers.md

@@ -116,7 +116,9 @@ The important distinction between the "scalar" parameter values like strings and
 
 <div class="lesson-note" markdown="1">
 
-  This used to be done in Rails 3 by setting `attr_accessible` in the model to allow attributes, so you will probably see that in a lot of Stack Overflow posts and earlier applications.
+#### Whitelisting "safe" attributes in Rails 3
+
+This used to be done in Rails 3 by setting `attr_accessible` in the model to allow attributes, so you will probably see that in a lot of Stack Overflow posts and earlier applications.
 
 </div>
 
@@ -164,15 +166,17 @@ So our `#create` action above can now be filled out a bit more:
 
 <div class="lesson-note lesson-note--warning" markdown="1">
 
-  Prior to Rails 8, strong parameters were handled differently. Instead of the `#expect` method, you had to call `#require` on the top level key name followed by calling `#permit` on the list of attributes. For example:
+#### Handling strong parameters before Rails 8
 
-  ```ruby
-  def allowed_post_params
-    params.require(:post).permit(:title, :body, :author_id)
-  end
-  ```
+Prior to Rails 8, strong parameters were handled differently. Instead of the `#expect` method, you had to call `#require` on the top level key name followed by calling `#permit` on the list of attributes. For example:
+
+```ruby
+def allowed_post_params
+  params.require(:post).permit(:title, :body, :author_id)
+end
+```
 
-  This way still works, but it has a couple of security flaws that motivated the development of `#expect`. But you will likely be exposed to this way of doing it through older projects, blog posts, and StackOverflow answers. Just know that this is serving the same function as the new `#expect` method.
+This way still works, but it has a couple of security flaws that motivated the development of `#expect`. But you will likely be exposed to this way of doing it through older projects, blog posts, and StackOverflow answers. Just know that this is serving the same function as the new `#expect` method.
 
 </div>
 

ruby_on_rails/rails_basics/routing.md

@@ -204,11 +204,13 @@ You should have a good sense of what's going on in the routes file by now but pr
 1. Read the [Rails Guides chapter on Routing](http://guides.rubyonrails.org/routing.html), sections 1-2.5, 3.1-3.4, 4.6, and 6.1
 1. Watch this [Wonderful explanation of how REST and HTTP works](https://www.youtube.com/watch?v=Q-BpqyOT3a8). You can follow the tutorial using `curl https://api.github.com`.
 
-<div class="lesson-note lesson-note--tip" markdown="1">
+   <div class="lesson-note lesson-note--tip" markdown="1">
 
-The Postman Chrome Extension shown in the video is deprecated. Use the native [Postman App](https://www.postman.com/downloads/) or use the web version.
+   #### Don't use the Postman Chrome Extension
 
-</div>
+   The Postman Chrome Extension shown in the video is deprecated. Use the native [Postman App](https://www.postman.com/downloads/) or use the web version.
+
+   </div>
 
 </div>
 

ruby_on_rails/rails_basics/views.md

@@ -31,15 +31,15 @@ So if a layout is basically just a shell around the individual page, how does th
 
 The other thing you've undoubtedly noticed is the odd HTML code that goes inside `<%=` and `%>` tags.  This is Embedded Ruby (ERB).  It's a special way of executing ruby code inside your HTML.  HTML is static, so you need to dial in some Ruby if you want to do anything dynamic like looping, `if` statements or working with variables.  ERB (and another similar language you might see called HAML) do exactly that.
 
-What those tags do is execute whatever you see inside them exactly as if it was normal Ruby.  So `<em><%= "I am emphasized" %></em>` will output an emphasized piece of text like <em>I am emphasized</em> and `<%= @user.first_name %>` might output `joe`.
+What those tags do is execute whatever you see inside them exactly as if it was normal Ruby.  So `<em><%= "I am emphasized" %></em>` will output an emphasized piece of text like *I am emphasized* and `<%= @user.first_name %>` might output `joe`.
 
 The difference between `<%` and `<%=` is that the `<%=` version actually displays whatever is returned inside the ERB tags.  If you use `<%`, it will execute the code but, no matter what is returned by that line, it will not actually display anything in your HTML template. `<%#` is used to comment and will not execute.
 
 Most of your tags will be `<%=` because you'll find yourself often just outputting important pieces of the instance variables that you received from your controller, like in the `<%= @user.first_name %>` example above.  You use the `<%` for purely code-related stuff like `if` statements and `each` loops, where you don't actually WANT anything displayed (the stuff you display will occur inside the loop).  
 
 If this is confusing, here's an example:  Say we want to display the first names of all the users in our application, but only if the current user is signed in.  This might look something like:
 
-~~~erb
+```erb
   <% if current_user.signed_in? %>
     <ul>
       <% @users.each do |user| %>
@@ -49,25 +49,25 @@ If this is confusing, here's an example:  Say we want to display the first names
   <% else %>
     <strong>You must sign in!</strong>
   <% end %>
-~~~
+```
 
 Remember to close your statements and loops with `<% end %>`!  (You'll forget a few times.)
 
 In the code above, if the user is signed in it will actually render to the web something like:
 
-~~~html
+```html
   <ul>
     <li>Bob</li>
     <li>Joe</li>
     <li>Nancy</li>
   </ul>
-~~~
+```
 
 If the user isn't signed in, it'll be the much shorter:
 
-~~~html
+```html
   <strong>You must sign in!</strong>
-~~~
+```
 
 In the above code, if we had accidentally used `<%=` in the loop line, e.g. `<%= @users.each do |user| %>` it would run the code fine, but because `each` returns the original collection, we'd also see a dump of our `@users` variable on our page (not very professional).  It'll happen to you several times and you'll learn quick.
 
@@ -87,12 +87,12 @@ Another nice thing you can do in Rails is break apart your views into partials.
 
 Pulling back a bit, partials are just HTML files that aren't meant to be complete but can be shared by other files.  You would call a partial by writing something like:
 
-~~~erb
+```erb
   # app/views/users/new.html.erb
   <div class="new-user-form">
     <%= render "user_form" %>
   </div>
-~~~
+```
 
 There are a couple of syntax oddities you need to pay attention to.  The view partial file is named with an underscore like `_user_form.html.erb` but gets called using just the core portion of the name, e.g. `user_form` in the example above.  
 
@@ -104,136 +104,137 @@ There's a lot you can do with partials and we won't dive into it all here, but o
 
 In the example above, you most likely want to pass the `@user` variable to the partial so your code can render the right kind of form. `render` is just a regular method and it lets you pass it an [options hash](https://stackoverflow.com/questions/18407618/what-are-options-hashes).  One of those options is the `:locals` key, which will contain the variables you want to pass.  Your code might change to look like:
 
-~~~erb
+```erb
   <%= render partial: "shared/your_partial", :locals => { :user => user } %>
-~~~  
+```  
 
-To use the variable in your partial file, you drop the `@` and call it like a normal variable. Note that you should use the `:locals` option if you're calling the `render` method with a `:partial` key. 
+To use the variable in your partial file, you drop the `@` and call it like a normal variable. Note that you should use the `:locals` option if you're calling the `render` method with a `:partial` key.
 
 There is a `render` shortcut that allows you to pass in variables without the need of using the `:locals` option:
 
-~~~erb
+```erb
   <%= render "shared/your_partial", :user => user %>
-~~~
-
+```
 
 ### Implicit partials
 
 As usual, there are some things you would end up doing so many times that Rails has given you a shortcut.  One of these is the act of rendering a model object like a User or a Post.  If you want a list of all your users, you could write out the HTML and ERB code for displaying a single user's first name, last name, email etc. many times directly in your `app/views/users/index.html.erb` file or you could keep that code in some sort of `each` loop.  
 
 But it's usually best to make the User into its own partial called `_user.html.erb` so you can reuse it in other cases as well.  The basic way of calling this might be something just like we saw above, which looks like:
 
-~~~erb
+```erb
   # app/views/index.html.erb
   <h1>Users</h1>
   <ul>
     <% @users.each do |user| %>
       <%= render "user", :locals => {:user => user} %>
     <% end %>
   </ul>
-~~~
+```
 
 And in your partial:
 
-~~~erb
+```erb
   # app/views/_user.html.erb
   <li><%= "#{user.first_name} #{user.last_name}, #{user.email}" %></li>
-~~~
+```
 
 It may seem strange to have only one line in a partial, but trust me that it usually doesn't stay that way for long so it's worth getting the hang of.
 
 So if that's the basic way, what's the magical Rails way?  Just tell it to render the User object directly, e.g.:
 
-~~~erb
+```erb
   # app/views/index.html.erb
   <h1>Users</h1>
   <ul>
     <% @users.each do |user| %>
       <%= render user %>     <!-- Lots less code -->
     <% end %>
   </ul>
-~~~
+```
 
 Rails then looks for the `_user.html.erb` file in the current directory and passes it the `user` variable automatically.
 
 What if you want to render a whole bunch of users like we just did?  Rails also does that for you the same way, saving you the trouble of writing out your own `each` loop like we did above. write:
 
-~~~erb
+```erb
   # app/views/index.html.erb
   <h1>Users</h1>
   <ul>
     <%= render @users %>
   </ul>
-~~~
+```
 
 In that situation, Rails not only finds the `_user.html.erb` file and passes it the correct `user` variable to use, it also loops over all the users in your `@user` collection for you. Pretty handy.
 
 ### Helper methods
 
 `render`ing partials isn't the only method you can call from within a view.  Rails has a bunch of really handy helper methods that are available for you to use in the view.  A few of the most common:
 
-#### `#link_to`
+#### #link_to
 
 `link_to` creates an anchor tag URL.  Instead of writing:
 
-~~~erb
+```erb
   <a href="<%= users_path %>">See All Users</a>
-~~~
+```
 
 You write:
 
-~~~erb
+```erb
   <%= link_to "See All Users", users_path %>
-~~~
+```
 
 It's the Rails way.  And recall that `users_path` generates a relative URL like `/users` whereas `users_url` generates a full URL like `http://www.yourapp.com/users`.  In most cases, it isn't an important distinction because your browser can handle both, but make sure you understand the difference.
 
 ### Asset tags
 
 As you may have seen in the application layout file we talked about above, Rails gives you helper methods that output HTML tags to grab CSS or JavaScript files.  You can also grab images.  These are called Asset Tags.  We'll get into the "Asset Pipeline" a bit later, but basically these tags locate those files for you based on their name and render the proper HTML tag.
 
-~~~erb
+```erb
   <%= stylesheet_link_tag "your_stylesheet" %>
   <%= javascript_include_tag "your_javascript" %>
   <%= image_tag "happy_cat.jpg" %>
-~~~
+```
 
 Will render something like:
 
-~~~html
+```html
   <link href="/assets/your_stylesheet.css" media="all" rel="stylesheet">
   <script src="/assets/your_javascript.js"></script>
   <img src="/assets/happy_cat.jpg">
-~~~
+```
 
 Note: in production, your stylesheet and JavaScript will all get mashed into one strangely-named file, so don't be alarmed if it's named something like `/assets/application-485ea683b962efeaa58dd8e32925dadf`
 
 ### Forms
 
 Rails offers several different helpers that help you create forms, and we'll go over those in-depth in upcoming lessons.
 
+### Conclusion
+
+Views in general make up the user-facing side of your app.  It can be a bit tricky at first to imagine how you choose which view to render, what to include in that view and how to use partials, but a few iterations of working with Rails will show you the conventions pretty quickly.  Views will become second nature to you.
+
 ### Assignment
 
 Now that you've got a taste of the high-level stuff, read through the Rails Guides for a more detailed look at things.  The chapter below will actually start in the controller, where you need to let it know WHICH view file you want to render.  The second half of the chapter gets more into the view side of things.
 
 <div class="lesson-content__panel" markdown="1">
 
-  1. Read the [Rails Guide chapter on Layouts and Rendering](http://guides.rubyonrails.org/layouts_and_rendering.html), sections 1 through 3.4.  You can certainly skim when they start going over all the many different options you can pass to a given function... it's good to know what they are and where you can find them, but you don't need to memorize all of them.  Usually you'll have something that you want to do, Google it, and find a Stack Overflow post that shows you the option you can use.
+1. Read the [Rails Guide chapter on Layouts and Rendering](http://guides.rubyonrails.org/layouts_and_rendering.html), sections 1 through 3.4.  You can certainly skim when they start going over all the many different options you can pass to a given function... it's good to know what they are and where you can find them, but you don't need to memorize all of them.  Usually you'll have something that you want to do, Google it, and find a Stack Overflow post that shows you the option you can use.
+
 </div>
 
-### Conclusion
+### Knowledge check
 
-Views in general make up the user-facing side of your app.  It can be a bit tricky at first to imagine how you choose which view to render, what to include in that view and how to use partials, but a few iterations of working with Rails will show you the conventions pretty quickly.  Views will become second nature to you.
+The following questions are an opportunity to reflect on key topics in this lesson. If you can't answer a question, click on it to review the material, but keep in mind you are not expected to memorize or master this knowledge.
 
-### Knowledge check
-This section contains questions for you to check your understanding of this lesson. If you’re having trouble answering the questions below on your own, review the material above to find the answer.
-
-* [How do you make sure a preprocessor runs on your view file?](#how-do-preprocessors-work)
-* [What is the difference between `<%`, `<%=` and `<%#`?](#preprocessors)
-* [What does including `<%= yield %>` in a layout do?](https://guides.rubyonrails.org/layouts_and_rendering.html#understanding-yield)
-* [Why do we use partials?](https://guides.rubyonrails.org/layouts_and_rendering.html#using-partials)
-* [What is the shortcut for rendering a collection as a series of partials?](https://guides.rubyonrails.org/layouts_and_rendering.html#rendering-collections)
-* [How do you dynamically link to another page of your Rails app?](#linkto)
+- [How do you make sure a preprocessor runs on your view file?](#how-do-preprocessors-work)
+- [What is the difference between `<%`, `<%=` and `<%#`?](#preprocessors)
+- [What does including `<%= yield %>` in a layout do?](https://guides.rubyonrails.org/layouts_and_rendering.html#understanding-yield)
+- [Why do we use partials?](https://guides.rubyonrails.org/layouts_and_rendering.html#using-partials)
+- [What is the shortcut for rendering a collection as a series of partials?](https://guides.rubyonrails.org/layouts_and_rendering.html#rendering-collections)
+- [How do you dynamically link to another page of your Rails app?](#linkto)
 
 ### Additional resources