Skip to main content

Explain the complete_list vs incomplete_list blocks

  def sort_lists(lists, &block)
       complete_lists, incomplete_lists = lists.partition { |list| list_complete?(list) }

       incomplete_lists.each { |list| yield list, lists.index(list) }
       complete_lists.each { |list| yield list, lists.index(list) }
  end

<ul id="lists">
      <% sort_lists(@lists) do |list, index| %>
          <li class="<%= list_class(list) %>">
               <a href="/lists/<%= index %>">
                    <h2><%= list[:name] %></h2>
                    <p><%= todos_remaining_count(list) %> / <%= todos_count(list) %></p>
               </a>
          </li>
      <% end %>

</ul>

We want the list to populate incomplete_list first then completed_list second. So we pass in the partition method that will create one array for values that return true, and another array for values that return false. The list_complete? method will return true if the list is complete.

so we call each on incomplete_list first , then yield the list itself in the first block argument, and index in the second block argument. Then we call complete_list second, this order will create the impression that incomplete_list comes first.

In the HTML , sort_list will yield incomplete_list first and complete_list second.

Comments

Popular posts from this blog

Problem Solving - Refactored

I am going to outline how I approach problem solving. The relative importance and the amount of effort/time required for each is stated as a percentage beside each topic. I borrowed some idea from George Polya's How to Solve It Thoroughly Understand the Problem (30%) When encountering hard problem , you need to deeply understand the problem at hand. Take a paper and list down all known facts and data and what the question is trying to find. Sketch out the problem if applicable. Visualize the problem in your head. A lot of times, we only have to understand the problem well, then the solution will obvious. Have a Plan (20%) You need to have an outline of how you are going to tackle the problem. You need to have a logical pathway that will ultimate produce outcome (nothing to do with coding syntax yet). Without a plan, you are just randomly poking around and got lucky. No hard problem ever gets solved without a plan. Plan using pseudo-code, pen & paper or flowchart. Use wh...

Static vs Relative vs Absolute vs Fixed

Static: the default position. Everything starts from top to bottom nicely according the document flow. Relative: still within normal flow of document. But accept offset position, relative to its original document flow position Absolute: out of normal flow. It doesn't interact with elements around it anymore. The reference point will be parent element that has relative positioning, if not, reference body element. Accepts offset position Fixed: out of normal flow. The element sticks to a corner of the page even if user scrolls. Reference the windows view.

Explain code

get "/" do pattern = File . join ( data_path , "*" ) @files = Dir . glob ( pattern ) . map do | path | File . basename ( path ) end erb :index end def data_path if ENV [ "RACK_ENV" ] == "test" File . expand_path ( "../test/data" , __FILE__ ) else File . expand_path ( "../data" , __FILE__ ) end end data_path will check if ENV hash with key "RACK_ENV" has the value of "test". If yes, then return the path from root to cms2/test/data folder. If not , then return the absolute path from root to the folder cms2/data Then, in get "/" block , join the data_path with * . If in development environment, then data_path is home/cms2/data then the return value is home/cms2/data/* We use File.join is good because it will detect the OS, then join with appropriate character.  With the pattern in place, we use Dir.glob to find the files. Here it return home/...