In a full stack Hanami application, an incoming HTTP request goes through the , it instantiates and calls an action, which sets the status code and the headers for the response. The last bit is the body, which is set by the corresponding view’s output.

Hanami ships a generator for actions that creates a view and a template.

Looking at those file names, we have an action called (read about actions naming). Our view has a similar name: Web::Views::Dashboard::Index.

# apps/web/views/dashboard/index.rb
  module Views
    module Dashboard
      class Index
      end
    end
  end

That file begins with a module declaration which is similar to the action naming structure. The only difference is that we use Views module instead of Controllers. All the views are nested under it. This module is generated at the runtime for us, when the application starts.

For a given application named , views are available under Web::Views.

This symmetry is really important at run time. After the action has finished its job, control passes to the framework which looks for the matching view.

All the main Hanami components are mixins meant to be included. Because a Hanami Container can run multiple applications within the same Ruby process, the configurations of these different components should be kept separated.

In our example, we have a directive include Web::View. That means our view will behave according to the configuration of the Web application.

For a given application named Web, the view mixin to include is .