In this chapter, we learned how to properly manage data flow in our apps by following the Elm Architecture which boils down to three fundamental concepts: model, view, and update.
A model represents the state of our app. The view function takes a model and returns a list of HTML functions. The virtual DOM converts those functions into real HTML nodes and renders them on a screen. When the user generates an event by interacting with an HTML element, the Elm Runtime sends a message to the update function. After processing the message, the update function returns a new model back to the Elm Runtime which sends the new model to view to render it again. This cycle continues until the app is terminated.
To keep the purity of our application code intact, the Elm Runtime manages all side effects for us. If we need to perform an operation that causes a side effect such as generating a random number or fetching data from a remote HTTP server, all we need to do is create a command and hand it over to the runtime. The runtime will figure out how to execute that command and will notify the update function in our app with the result.
There is one more piece to the Elm Architecture puzzle: subscription. We’ll have to wait until chapter 8 to find out how subscriptions work. In the next chapter, we’ll learn how to send and receive data from an HTTP server using commands.