Understanding the general structure of a Dash app

The following diagram shows what generally goes into creating a Dash app. We typically have a file called app.py, although you can name it whatever you want. The file is shown as the column on the right, with the different parts split by lines, just to visually distinguish between them, while on the left is the name of each part:

Figure 1.2 – The structure of a Dash app

Let's look at each app part in detail:

• Imports (boilerplate): Like any Python module, we begin by importing the required packages, using their usual aliases.
• App instantiation: A straightforward way to create the app, by creating the app variable in this case. The __name__ value for the name parameter is used to make it easy for Dash to locate static assets to be used in the app.
• App layout: The subject of this chapter, which we will focus on in detail. This is where we set the user-facing elements, or the frontend. We usually define a container element, html.Div in the figure, that takes a list of components for its children parameter. These components will be displayed in order when the app renders, each placed below the previous element. In the following section, we will create a simple app with a minimal layout.
• Callback functions: This is the subject of Chapter 2, Exploring the Structure of a Dash App, where we will go through how interactivity works in detail; this won't be covered in this chapter. For now, it's enough to know that this is where we define as many functions as needed to link the visible elements of the app to each other, defining the functionality that we want. Typically, functions are independent, they don't need to be defined within a container, and their order does not matter in the module.
• Running the app: Using the Python idiom for running modules as scripts, we run the app.

As I promised, we are now ready to start coding.