Split the Business Logic of Elm view Functions By Modeling the State
Up until this point, the 4 cards displayed in our dashboard each repeat the same information, so in this lesson, we will be splitting the state into different parts, showing an algebraic mindset and thinking how best represent the state of our app with our custom types.
We'll start by modeling the selected options in state as a List of a Menu and String. The next step is to actually update the internal state of our menus. We will update OptionPicked to receive a string and when it does receive an option, it will filter for just the selected option and append that to state. Finally we will display the options in the viewCard component that will filter for the menu that is being selected and in the case of an option selected display that option as a string.
Flavio Corpa: [0:00] Now every dropdown has its own state. That's awesome, but how do we display inside each card the selected options for each dropdown? We're going to need to represent that in our model by saying selected, which is a List of a Menu and a String of each options. We are going to represent by a list of tuples the menu and its separate options that that has been clicked.
[0:23] We initialize this [inaudible] , and now we need to change our OptionClick to drag down the menu from which we have selected an option. In an update function here is the menu, and here we're going to receive the string option that we have clicked.
[0:38] In the case it's nothing, we want to do nothing. In the case it's something, we want to do just option. Here we need the menu, and here we say if the model.selected contains any option which is exactly the same menu and option that I'm receiving, then we're going to say model, then the selected we're going to list.filter, the options that are different to that one, because we are removing that option from the list.
[1:04] Here, we say model.selected and we don't want to fire any command, and else, if the option we just clicked is not selected, we want to add it to the selection. We do so by prepending with a cons operator to the actual list that we already have. Again, we don't want any command to be fired. Perfect.
[1:25] When we are passing our OptionPicked menu, we also need to pass which menu we're picking from. Awesome. Each time we click an option now, we are firing message with the option click, we are updating our internal state.
[1:38] What we are going to do now is go to the card where we are displaying our hardcoded content and say case list filter of many. The many that we are iterating is equal to the menu that we receive an argument, model selected off.
[1:53] If we don't have any, we are going to display an empty card, but if we have some options selected for the specific card, we're going to do the following pipeline. We're going to take list.reverse because we're adding them to the beginning of the list and we want them to be displayed at the end.
[2:09] Then we say list.map and we tuple by the second because we don't care about the menu they belong. We just want this to be the option.
[2:16] We're going to join them by comma and finally, we're going to string.append(selected). Nice. As you see now, every time we select an option, our content is changing for each card, and every time we check an already checked option, it's removed from the list.
[2:33] Now its dropdown has its own state and also each card reflects the state of each dropdown. How cool is that?