Skip to main content

sort list in todos apps

todo.rb  
def sort_lists(lists, &block)
    incomplete_lists = {}
    complete_lists = {} 
    
    lists.each_with_index do |list, index|
      if list_complete?(list)
        complete_lists[list] = index
      else
        incomplete_lists[list] = index
      end
    end
    
    incomplete_lists.each(&block)
    complete_lists.each(&block)
  end
So here, this is under the helpers block. Code in the helpers block is accessible in erb view template and the main ruby files. "sort_lists" takes a lists object and a block. A lists object is a array that contains the hash object {name: "work" , todos: [] }. So now our objective is to break the lists into those that is incomplete list first, then completed second.

so we iterate through the lists's array, one by one, which yielded the list hash. Then we pass the list hash into the list_complete? method. Which select list hash who has at least one item in the todos array and also those list who has all completed list. Then , we store the list object in a complete_list's hash with the list hash as a key and the index as a value. If not completed, then those are stored in the incomplete_list hash.

Then we yield the incomplete_list hash first to the block , then we yield the second complete_list to the block.

lists.erb
<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>

The sort_list will pass those list in the  incomplete_list hash first to the block , then only the completed list hash into the block.

the sort_list will yield the list one by one. The list_class method will return the string "complete" if the list_complete? returns true. list_complete? will return true if  todos array count is more than 0 and todos_remaining_count is zero.

  def list_class(list)
    "complete" if list_complete?(list)
  end

  def todos_remaining_count(list)
    list[:todos].select { |todo| !todo[:completed] }.size
  end

todos_remaining_count will take a list hash, then it will access the todos array in the list hash , then select those todo that has a completed = true value. A todo object look like this {name: "work1" , completed: true }





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...

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 (...

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.