Dry-view is another view rendering system, built primarily for dry-web stack and to use alongside with dry-system, but being completely standalone, it can be considered as a replacement for another view rendering systems, such as cells, actionview, and built-in rendering systems of Sinatra and Roda.
For a brief example, let’s consider introducing the dry-view into a following traditionally oversimplified Sinatra application:
Our app has only 4 files:
Main application class:
config.ru to launch the app via rackup:
and our only template:
As everyone may understand from this code, the application only renders table with some fake data, i.e. table of usernames with their respective ids and occupation information.
Replacing Sinatra’s built-in renderer takes a few steps:
First, install dry-view:
Then, make the separate directories for view objects and templates(just like you may have seen in Hanami or Phoenix):
app.rb config.ru Gemfile Gemfile.lock templates/ views/
Remove Sinatra rendering from the app:
create UserIndexView functional object:
index.html.slim template. If we name it
index.slim, it wouldn’t be picked up by
tilt, which dry-view
uses underneath for the rendering purposes, because by default it relies on the file name structure consisting of three parts.
And this simply works.
So why in the world one need to use dry-view? Even in this simplest example, it can become obvious.
We don’t need the user fetching logic in the routes anymore - it can go into view object. The only thing we need to provide
to object when using
view.call is the input parameters from URL of forms. In our example users fetching logic goes
completely inside the view object.
And Sinatra route becomes only:
Dry-view approach not only removes logic from routing layer(in case of Sinatra or Roda) but also cleans up templates
and thus the view logic becomes much more testable. Remember the testing of Rails views or imagine a testing process of logic
embedded in Sinatra routing - both are a pain. When dealing with functional objects, we can use a unit-test approach or
test class’s outcome with given input. For example, if we assume, that
user objects are coming from the database:
Dry-view has also another notable use cases, and the most important of them is that it perfectly plays with dependency injection scenarios, but this is beyond the scope of the article.