First, we check our routes:

Then we edit the corresponding template:

Here is how Hanami handles an incoming request:

1. The router creates a new instance of and invokes #call.
2. The application creates a new instance of Web::Views::Dashboard::Index and invokes #render.

For a given action named , a corresponding view MUST be present: Web::Views::Dashboard::Index.

By default an action takes care of the HTTP status code and response header, but not of the body of the response. As seen above, it delegates the corresponding view to render and set this value.

Sometimes we want to bypass this process. For instance we want to return a simple body like . To involve a view in this case is a waste of CPU cycles.

If we set the body of the response from an action, our application will ignore the view.

Here is how Hanami handles an incoming request in this case:

1. The router creates a new instance of Web::Controllers::Dashboard::Index and invokes #call.
2. The application detects that a body is already set and doesn’t instantiate the view.

If the response body was already set by an action, the rendering process is bypassed.

With direct body assignment, we can safely delete the corresponding view and template.

Actions are instantiated for us by Hanami at the runtime: for each incoming request, we’ll automatically get a new instance. Because actions are objects, we can take control on their initialization and eventually . This is a really useful technique for unit testing our actions.

There is a limitation that should always be kept in mind:

The following initializers are valid: