know why **Spaghetti Code** is less than ideal<br/>
**spaghetti code** is difficult to read, maintain, and scale, and for those reasons and more, we need a better approach to architecting our applications.

Solution to Shopping List App:
```
$(function(){
  $('#js-shopping-list-form').submit(function(event) {
    event.preventDefault();
    const listItem = $('.js-shopping-list-entry').val();

    $('#shopping-list-entry').val('');

    $('.shopping-list').append(
      `<li>
        <span class="shopping-item">${listItem}</span>
        <div class="shopping-item-controls">
          <button class="shopping-item-toggle">
            <span class="button-label">check</span>
          </button>
          <button class="shopping-item-delete">
            <span class="button-label">delete</span>
          </button>
        </div>
      </li>`);
  });

  $('.shopping-list').on('click', '.shopping-item-delete', function(event) {
    $(this).closest('li').remove();
  });

  $('.shopping-list').on('click', '.shopping-item-toggle', function(event) {
    $(this).closest('li').find('.shopping-item').toggleClass('shopping-item__checked');
  });

});
```
it's important to develop good coding habits and a sense of what makes for good code architecture. So with no further ado, here are some of the deficiencies with this solution:

**You have to read every line of code to understand how the app works.**<BR/>
The app is composed entirely of a single, anonymous document ready function that has jQuery event listeners for submit and click events that in turn call additional anonymous functions, which appear to do something to the DOM, but without inspecting the HTML, it's hard to know what they do.

**It's difficult to reason about the shopping list data**<br/>
The problem is that the data for the shopping list itself is stored entirely in the DOM. The only way you can understand the overall state of the shopping list at any time is by inspecting each list item in the DOM. And to make matters worse, the problem you're trying to diagnose involves the DOM being wrong about displaying the list! Ideally, we need to establish** one part of our code for storing the underlying data for our shopping list**, and **then have a different part of our code deal with how that code is rendered in the DOM**. This will allow us to ask and answer questions about how what the DOM is displaying corresponds (or doesn't) to the data model.

**Spaghetti code doesn't scale**

Our shopping list app is about as simple as apps come in terms of what users can do with it: they can read a shopping list, add items to it, delete them, and check and uncheck them.
Now imagine a complex app like Facebook or Gmail implemented in a single document ready function. The fact is that neither Facebook nor Gmail would be working apps if they were built with spaghetti code.

### Clearly describing your application with user stories  <br/>
Before opening your text editor, it's critical to get a clear picture of what you're building. That means coming up with clear, concise statements that describe what the app you're building will do. These statements will tell you what you need to build and when a particular feature of the app is complete. They also provide a common language for speaking with non-technical stakeholders on a project.

Here's how we could break down our shopping list:

* A shopping list should be rendered to the page
* You should be able to add items to the list
* You should be able to check items on the list
* You should be able to delete items from the list
These statements are examples of user stories, which are short, plain language descriptions of what a user should be able to do with an app. User stories can be written by and discussed by technical and non-technical stakeholders. Notice that these user stories don't say anything about **how** the app is to be implemented. Instead they focus on **what** the app should do. Recall that we made a similar observation about how well-named, small functions allow a coder to quickly understand what an app does without having to look at how each function is implemented. This happy coincidence is one we can take advantage of as we start architecting our application.

### From user stories to function stubs with pseudocode <br/>
We're going to write function stubs. These functions will have names but inside of each one, we won't add any working code. Instead, we'll just add a description of what the code should do. We'll also go ahead and hook these functions up to a document ready function, since we know we'll definitely need that.
```
function renderShoppingList() {
  // this function will be repsonsible for rendering the shopping list in
  // the DOM
  console.log('`renderShoppingList` ran');
}
function handleNewItemSubmit() {
  // this function will be responsible for when users add a new shopping list item
  console.log('`handleNewItemSubmit` ran');
}
function handleItemCheckClicked() {
  // this funciton will be reponsible for when users click the "check" button on
  // a shopping list item.
  console.log('`handleItemCheckClicked` ran');
}
function handleDeleteItemClicked() {
  // this function will be responsible for when users want to delete a shopping list
  // item
  console.log('`handleDeleteItemClicked` ran')
}
function handleShoppingList() {
  // render the shopping list
  // handle when a new item is submitted
  // handle when an item is deleted
  // handle when an item is checked/unchecked
}
```

Now lest fully implement the `handleShoppingList` function:
```
function renderShoppingList() {
  // render the shopping list in the DOM
  console.log('`renderShoppingList` ran');
}
function handleNewItemSubmit() {
  // listen for users adding a new shopping list item, then add
  // to list and render list
  console.log('`handleNewItemSubmit` ran');
}
function handleItemCheckClicked() {
  // listen for users checking/unchecking list items, and
  // render them checked/unchecked accordingly
  console.log('`handleItemCheckClicked` ran');
}
function handleDeleteItemClicked() {
  // Listen for when users want to delete an item and
  // delete it
  console.log('`handleDeleteItemClicked` ran')
}
function handleShoppingList() {
  renderShoppingList();
  handleNewItemSubmit();
  handleItemCheckClicked();
  handleDeleteItemClicked();
}
$(handleShoppingList);
```
Perform console.log on the above code and in browser [developer tools] this proves that everything is wired up correctly.


### Modeling our data <br/>
What we need is a single source of truth about the state of our shopping list. We want to be able to store that data some place, and what the user sees in the DOM should ultimately be a reflection of the current state of our data model.
Specifically, we need a way of modeling a shopping list. How can we best store data about a shopping list?
The name shopping list itself already implies that we'll probably want to use a JavaScript array. That would allow us to store multiple list items, add items, and delete them.
Each item on the list needs at least two attributes: the item name, and whether or not it is currently checked. We say "at least two" because there's arguably a third attribute we need: each item needs a unique identifier that we can use to choose a specific item and delete or check/uncheck it. But since we're using an array, we can use each item's array index as its id (for instance, the first item in our shopping list array will be at index 0).
```
const STORE = [
  {name: "apples", checked: false},
  {name: "oranges", checked: false},
  {name: "milk", checked: true},
  {name: "bread", checked: false}
];
```
`STORE` is a constant and that does **NOT** mean that the shopping list array itself should not be altered, that would be useless for our app...it's OK to alter the underlying array, it's NOT ok to reassign the variable name to a new value.
// okay
`STORE.push({name: "chocolate", checked: true});`

// not okay!
`STORE = {foo: 'bar'};`

A final note about `STORE`. In JavaScript, complex data types (aka, objects and arrays) are passed by *reference*, not by *value*. That means that if you pass an array or object to a function as an argument, and the function mutates it, the value of the original variable outside of the function will also be mutated.