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

My Burnout Experience

I want to share with you my experience of burning out. After registering with Launch School, I am extremely excited about my programming journey. I studied for 10 to 12 hours a day, memorizing fact, trying out practice problems, understanding programming concepts. It was fun and exciting and I love seeing myself growing from nothing in programming to something more. After about 3 months, thing starts to change. I started noticing myself paying less attention to details. I find myself skimming through the course material. I skip "Further Exploration" in the practice problem. I am more interested to study just to pass the assessment rather than truly mastering the concept. It was a gradual burning out process but I continue to study for 10 to 12 hours a day through sheer grit. It felt like doing house chore or working a day job that you don't like. One particular morning I woke up, and I remember this deep feeling of dread because I can anticipate that the next 10 to 1

Sharing my Weakness

It makes sense to know about your weakness and do something about it. Here are my known weaknesses uncovered during my time in Launch School. 1. I don't like to refactor my code   - Your first draft will not be perfect. It works but it may not be efficient/readable/best practices. You final code will almost always be better than your first draft. - It is easier to separate the task between writing code that works and refactor later to make it efficient/readable/best practices. - If you refactor your code often, over time you will discover your bad habits and change it. 2. I don't like to read other people's code - There are more good programming practices in other people than in you (especially for beginners like me). - To be good , you need to know more than one pathways to solve a programming problem (and there are always more than one way). Then you can judge their merit. - Reason for dislikes    1. It is considerably harder to read code than to write one (be