Configuration is essentially stored in two places--the database (by default, the active configuration storage, and YAML files (the true source of the configuration).

Here is an example of a simple configuration YAML file:

my_string: 'Hello!'
my_int: 10
my_boolean: true
my_array:
 my_deep_string: 'Yes, hello!'

The name of this file is given by the ID you need to use with the configuration API to read this data.

In addition to the actual data, you can have a dependencies key under which you can list what this configuration item depends on:

dependencies:
  module:
    - views
  theme:
    - bootstrap
  config:
    - system.site

There are three types of dependencies--modules, themes, and other configuration items.

If you remember in Chapter 2, Creating Your First Module, we created a configuration object with the hello_world.custom_salutation ID in which we stored a simple value:

salutation: 'Whatever the user set in the form'

We did so programmatically through our form. This indicated that our code for displaying the salutation did not depend on this configuration item existing or having a value of some kind. Had it been mandatory for our code to work, we could have created it upon module installation. There are two ways this can be done.

The most common way is statically. Inside the config/install folder of a module, we can have YAML configuration files that get imported when the module is installed. However, if the values we need to set in this configuration are unknown (they need to be retrieved dynamically), we can do so in a hook_install() implementation (remember those from Chapter 3, Logging and Mailing?). There, we can try to get our value and create the configuration object containing it. Keep in mind that when it comes to installing modules, they will not be installed if they have configuration items in their config/install folder, which define some unmet dependencies.

As a bonus, you may also be able to provide configuration files with your module that should only be imported if certain dependencies are met. Otherwise, they would not be imported and the module would be installed and work just fine--in other words, optional configuration. These go inside the config/optional folder of the module and typically have some dependencies described in them.