Introducing Dyny
Dyny is a tiny framework for writing dynamic Rails views directly in Ruby. Typically, Rails views, are written in ERB, HAML or Slim. However there are situations where you'd prefer to write regular ruby code without having to cope with Tag Helpers at every call. This is where Dyny comes in.
A quick and trivial example: Having MessagesController
and an action
hello_world
, you can write a file app/views/messages/hello_world.html.dyny
with the contents:
h1 'Hello world'
div class: 'card mb-3' do
div class: 'card-body' do
para "I'm inside a Bootstrap card."
end
end
- Use directory structures similar to ERB views
- The file extension is
.html.dyny
- Call HTML elements as methods and nest them using blocks. There are three special cases:
- Since the method name
p
is already taken, usepara
to generate a<p>
tag. - Since the method names
label
andselect
are taken by Rails, usetag.label
andtag.select
instead.
- Since the method name
- Arguments given to Dyny HTML helper methods are passed to the Rails
tag
helper, for instanceclass
in the example above. - If you don't want a HTML tag, but output plain text, use
concat
. See examples below.
Dyny was tested with Rails 7.
But dynamic views are bad?
Rails views are meant to merely display data that was already pre-processed elsewhere, such as helpers or controller actions. However, as your application gets very complex, there may be situations where adhering to that principle leads to code scattered all over your application. Also, for rapid prototyping, you might wanna start writing your first proof-of-concept code directly into the view. This is where dyny jumps in to fill the gap and lets you write views directly in Ruby.
Dyny does not prevent you from writing most of your views in ERB or HAML. The
file name ending of the view decides which processor is used. If your file ends
with .html.erb
, you write ERB HTML; if it ends with .html.dyny
, you can
write plain Ruby with the help of Dyny.
Installation
- Add the gem to your Gemfile:
gem 'dyny'
- Run
bundle
to install it.
Usage
In a template
Simply have the file name of your view end with .html.dyny
and write plain
ruby in it, as shown in the example above.
In render
or render_to_string
You may speficy type: :dyny
in your render call to have Rails process your string with Dyny. Using inline
, you may supply a string containing ruby.
As an example: in your controller, you may call:
render_to_string(
type: :dyny,
locals: { foo: :bar },
inline: <<~RUBY
h1 'Hello world'
RUBY
)
Examples
A trivial index page
h1 'All users'
ul do
@users.each do |current_user|
li current_user.name
end
end
Working with simple_form and bootstrap
This illustrates working with Bootstrap and the popular
[SimpleForm](https://github.com/heartcombo/simple_form)
gem. For a better
overview, we first save the HTML generated by simple_form_for
into the local
variable form_html
and use concat
to output it later.
div class: 'card card-body' do
form_html = simple_form_for :test do |f|
concat(f.input(:fun))
div(f.input(:stuff), class: 'mb-3')
concat f.submit
end
concat form_html
end
The result is a form with two fields and a submit button.
Differences to the Arbre gem
This project aims to replace Arbre which has similar intentions. The key differences to Arbre are:
- Dyny is much smaller and simpler than Arbre but achieves the same features.
- Dyny supports using controller instance variable in views while Arbre does not
- Dyny properly uses the
ActionView
buffer, supporting calls toconcat
orcapture
. This means that Dyny fully supports gems making use of these features, such as SimpleForm, while Arbre breaks such gems because it uses its own buffer. - Where Arbre uses
text_node
, Dyny lets you use the native Rails methodconcat
to output raw text. - Arbre has its own
Context
concept while Dyny does not. To have Dyny generated HTML saved to a string variable, use Rails'render_to_string
method instead, see example above.
Contributing
You are welcome to contribute to this project via the regular fork and pull request procedure.