DEV Community: Roland Studer

RailsWorld 2023: Hotwire Edition

Roland Studer — Sun, 08 Oct 2023 12:23:24 +0000

The very first RailsWorld conference, organized by the Rails Foundation, has concluded at the beautiful venue of Beurs van Berlage in Amsterdam, Netherlands. Approximately 700 attendees joined in to look at the future of Rails.

RailsWorld 2023 was in many ways a "Hotwire" edition

The opening keynote and six talks primarily revolved around Hotwire, or you could count it as seven if you include Jason Charnes' talk, "Don't call it a comeback." The prevailing message seemed to be: "Yes, while the Rails API/SPA approach exists, but the sane path forward is Hotwire." It was repeatedly underscored that Rails remains a one-person framework. Rails ~~was~~ is empowering and revolutionary.

Morphing and broadcasted refreshes come to Turbo

Turbo Drive, which currently replaces the HTML body by default, becomes more powerful. Soon Turbo will use morphing to make only minimal changes to the DOM, enhancing user experiences significantly. With this change, you can expect:

Seamless preservation of scroll position
Elimination of flickering
Application of smooth CSS transitions

Turbo also implements the concept of server-side-triggered refreshes, allowing you to broadcast instructions to refresh a view following a model change, or directly from a controller or job.

You can find a demo video and more information here:
https://github.com/hotwired/turbo/pull/1019

Morphing and the concept to do refreshes after broadcast are hardly new. Stimulus Reflex has employed morphing to update the page for years, and CableReady::Updatable, which allows listening to model requests for refreshes, has also been around for a while. But I am excited to see these concepts being adopted in Turbo and becoming more mainstream.

BTW: Be sure to check out and contribute to the Hotwire community hub at hotwire.io.

Most impactful talk wasn't technical

Ryan Singer's talk on "Shaping up in the real world" hit the mark. It addressed precisely the areas where I currently face challenges in our design and development process, leaving me with some homework to do.

Great community

The community was a delight! I can't even count how many people I connected with, and it was just great to meet people whom I had previously only interacted with online. Also got to meet a lot of those people who significantly contribute to the Rails ecosystem. Everyone I said hi to was more than willing to spare time and nerd out and share experiences. I was also thrilled to connect with Philip, who shares my enthusiasm for Phlex. He provided me with some exciting ideas for creating an even more crazy yet cohesive form object with Phlex.

Would I go again?

I attended because it was in Europe, offering proximity, and also providing an opportunity to meet my coworker living in Amsterdam. We have numerous great conferences here in Europe, so there's no need for long flights and the stress of adjusting to different time zones. Personally, a crowd of 700 people was a bit too much for me. I am going to try smaller gatherings in the future.

I'd also like to give a shout-out to Pelle, my coworker, for being an excellent host (though he might want to step up his game in the restaurant recommendation department ;-) ).

This article orginally was published on rstuder.ch

Supercharged table component built with ViewComponent

Roland Studer — Wed, 02 Aug 2023 07:05:54 +0000

When searching for examples of table components built with the ViewComponent gem, I was surprised to find none. After some inquiries, I came across examples that worked like this:

<%= render Table.new do |table| %>
  <%= table.with_header { "Name" } %>
  <%= table.with_header { "Description" } %>
  <% @products.each do |product| %>
    <%= table.with_row do |row| %>
      <%= row.with_cell { link_to product.name, product } %>
      <%= row.with_cell { product.description } %>
    <% end %>
  <% end %>
<% end %>

This approach is pragmatic, but personally, I prefer to think of tables in terms of columns. So, let's supercharge our table component to enable something like this:

<%= render TableComponent.new(data: @products) do |table| %>
  table.column("Name") { |product| link_to product.name, product }
  table.column("Description") { |product| truncate(product.description) } 
<% end %>

Introducing the table component

Let's dive into the implementation:

class TableComponent < ViewComponent::Base
  attr_reader :columns
  def initialize(data:)
    @data = data
    @columns = []
  end

  def column(label, &block§)
    @columns << Column.new(label, &block)
  end  

  private

  # By calling content, we ensure that the view component calls the block, and @columns get populated
  def before_render
    content 
  end

  class Column # a value object to hold the column definition
    attr_reader :label, :td_block

    def initialize(label, &block)
      @label = label
      @td_block = block
    end
  end
end

The corresponding erb file keeps things simple, omitting thead, tbody, or any styling:

<table>
  <% @columns.each do |column| %>
    <th><%= column.label %></th>
  <% end %>
  <% @rows.each do |row| %>
    <tr>
      <% @columns.each do |column| %>
        <td>
          <%= view_context.capture(row, &column.td_block) %>
          <%# the capture ensures, that we do not only return the return of the block, but all the html from the block, see below %>
        </td>
      <% end %>
    </tr>
  <% end %>
</table>

You may notice three peculiarities here that require explanation:

Why not use slots?

The main challenge is that the ViewComponent gem does not have an official way to render a table cell multiple times with different data each time. Meaning you can't pass that while rendering a slot like this:

<%= @rows.each do |row| %>
  <%= column(row) %>
<% end %>

There is no way to pass arbitrary data from the component (in our example, the rows of the table) to a slot block while rendering it. Therefore, we handle column definitions ourselves instead of using slots.

Using `before_render` to ensure the block is called

When you use the TableComponent like this, and don't call content at some point.

<%= render TableComponent.new(data: @products) do |table| %>
  table.column("Name") { |product| link_to product.name, product }
<% end %>

The ViewComponent gem won't actually call the block, and the column method calls won't happen. We use the before_render lifecycle method to ensure the block is called.

What is this `view_context.capture(row, &column.td_block)` doing?

If in erb you define a column like this:

<%= render TableComponent.new(data: @products) do |table| %>
  <%= table.column("Name") do |product| %>
    <div><%= link_to product.name, product } %></div>
    <div><%= truncate(product.description)%></div>
  <% end %>
<% end %>

The block will actually return only the last string, which is </div>. To capture the entire block's HTML content, we use view_context.capture(row, &column.td_block). This way, we ensure that all the HTML from the block is included.

So there you have it, an easy-to-use but highly flexible table component.

But this is just the beginning. You will be able to create more methods to handle special requirements and create title columns, image columns, and columns with action links.

<%= render TableComponent.new(data: @products) do |table| %>
  table.image_column :image, :featured_image
  table.title_column "Name", &:name
  table.column("Description", &:description)
  table.actions_column(:edit, :destroy)
<% end %>

You have the beginning of an abstraction here, that can be further extended. Stay tuned for more!

Disclaimer: This post was written entirely by Roland Studer, but revised with the help of chat gpt.

This post was originally posted on rstuder.ch

More expressive APIs for View Components

Roland Studer — Tue, 25 Jul 2023 23:22:28 +0000

View components offer two primary ways to interact with the component: passing arguments to the initializer and using slots:

render SomeComponent.new(some_params) do |component|
  component.with_some_slot(some_other_params) { "My slot content" }
end

Having worked with Phlex (the better way to build views in Ruby), I came to appreciate calling methods directly on the component. While the slot API offers a lot and is versatile, it can sometimes feel like you have to work around it rather than with it.

Let's consider a BreadCrumbsComponent as an example. Traditionally, one might pass in all the data using an array of hashes, like this:

BreadCrumbsComponent.new([
  {label: "Home", url: root_path},
  {label: "Settings", url: settings_path},
  {label: "Notifications", url: settings_notifications_path}
])

However, I prefer a more expressive API like this:

BreadCrumbsComponent.new do |bread|
  bread.crumb "Home", root_path
  bread.crumb "Settings", settings_path
  bread.crumb "Notifications", settings_notifications_path
end

Solution with lambda slots

To achieve the desired API using the ViewComponent gem, we can utilize lambda slots:

class BreadCrumbsComponent < ViewComponent::Base
  renders_many :crumbs, -> (label, url) { @paths << {label: label, url: url} }
end

With a lambda slot, you can create a similar API, though it forces you to use specific method naming, as you will need to call c.with_crumb("Home", root_path) in the template.

BreadCrumbsComponent.new do |c| 
  c.with_crumb "Home", root_path
end

However, there is an issue here. When iterating through the @paths supposedly set by the slot calls, you will notice that it doesn't work as expected. The with_crumb method did not have any effect.
Why? ViewComponent only calls the block if you make a call to the accessor method for those slots, in this case crumbs, which is what you do when in your template you are calling crumbs.each …. This means that even if you don't render the slots, you still need to call the accessor method for it, a hint that we are somewhat abusing slots in this scenario.

Better solution

My preferred approach would be to directly call an instance method on the component, like this:

class BreadCrumbsComponent < ViewComponent::Base
  def crumb(label, url)
    @paths << {label: label, url: url}
  end
end

Now this should work seamlessly:

BreadCrumbsComponent.new do |bread|
  bread.crumb "Home", root_path
end

However the same caveat applied. The block is not called.

To address this issue, I explored how I could call the block myself.
The block is stored
in @__vc_render_in_block, a very private looking instance variable.

Then I realized that a call to content would invoke the block.
The solution is to add a before_render lifecycle method.
This calls the block and like this the crumb method calls on the component will be performed as expected. So our component ruby file can look like this:

class BreadcrumbsComponent < ViewComponent::Base
  attr_reader :paths

  def before_render
    content # ensures that block is called
  end

  def initialize(&block)
    @paths = []
  end

  def crumb(label, url)
    @paths << {label: label, url: url}
  end
end

For further use, it would be a good idea to extract this into a module like ViewComponent::CallBlock (or a better named module), and to then simply include it.

While some may argue that passing this data directly might be a cleaner approach since it is essentially data, I wanted to explore if I could achieve this particular API with a view component.

In conclusion: With a small tweak you can, directly calling instance methods on the component to shape your component. This way you can offer a very expressive and straightforward API.

Originally posted here

Phlex is the ruby way to build your views

Roland Studer — Wed, 07 Jun 2023 21:02:08 +0000

Phlex is an incredibly refreshing gem created by Joel Drapper. It introduces a remarkable way to build views in pure Ruby, as exemplified below:

class Nav < Phlex::HTML
  def template
    nav(class: "main-nav") {
      ul {
        li { a(href: "/") { "Home" } }
        li { a(href: "/about") { "About" } }
        li { a(href: "/contact") { "Contact" } }
      }
    }
  end
end

Initially, you may wonder: Why? Why would you do that when HTML is already perfectly readable? Using Ruby here seems odd, detached from the underlying HTML I want to write.

However, let's examine a typical partial, such as the one from the .
rubygems.org search show page

The specific details aren't crucial; I'm only presenting an excerpt. Take note of the nested conditionals within.

<% @title = "search" %>
<% if @error_msg %>
  <div class="errorExplanation">
    <p><%= @error_msg %></p>
  </div>
<% end %>
<%= link_to t("advanced_search"), advanced_search_path, class: "t-link--gray t-link--has-arrow" %>
<% if @yanked_filter %>
  <% @subtitle = t('.subtitle', :query => content_tag(:em, h(params[:query]))) %>

  <% if @yanked_gem.present? %>
    ...

In this case, we find a significant amount of view logic nested within the HTML structure. To comprehend this template fully, one must examine both the HTML and the embedded Ruby code.

With Phlex, however, we can fundamentally transform how we perceive and write these views. We can easily isolate the logic from the HTML nesting, resulting in something like this:

class Searches::Show < Phlex::HTML
  def template
    error_messages
    if @yanked_filter
      yanked_search
    else
      header
      aggregations
      if @gems.any?
        search_results
      else
        suggestion_results
      end
    end
  end
end

The template method clearly displays the actual view logic of the full template. The appropriate instance methods provide the HTML. For me, Phlex isn't really about the HTML; in a way it is about everything else.

We can write ruby and Phlex provides us the html tag methods we need.

We have the freedom to choose the most suitable level of abstraction and refactor as we see fit. We have the elegance of Ruby at our disposal.

I am genuinely enthusiastic about Phlex. It has completely transformed how I approach views, paving the way for elegant abstractions this one for forms.

Working with your views as enjoyable as writing other ruby code.

this article first appeared on rstuder.ch

Delegated Types are an alternative to Single Table Inheritance

Roland Studer — Thu, 07 Jul 2022 18:06:03 +0000

Delegated types got quite a lot of attention when DHH was tweeting about it
But from what I heard from conversations with many people,
I believe they have been poorly understood.
By me in particular.
Too often they are mentioned as flavour around polymorphic associations.

While one could look at delegated types as convenience methods around polymorphic associations,
DHHs intention was a quite different one.

The API does not make sense for convenience around polymorphic associations

So let's have a look at what delegated types provide:

Given a model that has a polymophic association with some other models,
we can declare delegated types as such.
I will itentionally start with "misguided" example

class Recommendation < ApplicationRecord
  delegated_type :recommendable, types: %w[ Wine Winery ]
end

So a recommendation that can be for a wine or a winery.
Now we have access to methods like these:

Recommendation.wines        # => Recommendation.where(recommendable_type: "Wine")
@recommendation#wine?       # => true when recommendable == "Message"
@recommendation#wine        # => returns the wine record, when recommendable_type == "Wine", otherwise nil
Recommendation.wineries     # => Recommendation.where(entryable_type: "Comment")

Nice stuff.
However this kinda confusing, let's look at one example:

What does Recommendation.wines return? Since the method is called wines, I woud expect to get the wine records back. But that is not what happens. I get therecommendation records that are for wines, instead.

I found this API very confusing. So much so, that I proposed in a pull request to add aliases for some of the methods. Allowing calls like Recommendation.for_wines, which makes it more obvious that this is returning recommendation records, rather than wine records.

So what is going on here? Why is this so confusing?

I often wondered about the name, and talking with other people about the PR I realized something. I missunderstood the intention behind delegated types.

An extract from the documentation on delegated types:

You can get around the pagination problem by using single table inheritance, but now you're forced into a single mega table with all the attributes from all subclasses. No matter how divergent. If a Message has a subject, but the comment does not, well, now the comment does anyway! So STI works best when there's little divergence between the subclasses and their attributes.

Actually if you read the entire docs, it fully introduces delegated types not as convenience around polymorphic associations. They are presented as as an alternative to single table inheritance or multiple tables.

So if you have objects that you want to list / query together, delegated types are a good option.

So if you look at it that way the API and the name DelegatedType start to makea lot more sense. While Recommendation.wines will return records of the reccomendations table, it is because we declared wrongly that a recommendation for a wine is of type Wine, its delegated type is wine.

This will make way more sense, once I show the more reasonable example:

A fitting example

class Product
    delegated_type :purchasable, types: %w[Wine Bundle Voucher]
end

So let's say we build some kind of shop where we sell wine, bundles of wines, but also vouchers. We really want to be able to query them from one table, and paginate them, but they vary widely in terms of attributes, so STI (single table inheritance) is not a great solution.

This is where delegated types come in. We can have the shared attributes of the products table, like product_number, price, stock, published… But we can also have any attributes we need on the specific table: Maybe a Voucher has an expiration, a bundle will have multiple wines as an assocation…

So with delegated types we consider the wine record to be the "joined row" of the products table and the wines table.

Whatever we need to know from the product wine we either get from the product record or its delegated type, hence the name… The idea is to not actually instantiate a record from the wines table alone.

class Product < ApplicationRecord
  delegated_type :purchasable, types: %w[Wine Bundle Voucher]
  delegate :display_name, to: :purchasable
end

class Wine < ApplicationRecord
  def display_name
    name + vintage
  end
end

class Bundle < ApplicationRecord
  has_many :wines

  def display_name
    "#{name} (#{wines.count} wines)"
  end
end

class Voucher
  def display_name
    "#{amount}$ Voucher"
  end
end

So you will have some aspects on the Product, and more specific aspects on the delegated types. You can leverage OOP polymorphism and be way more flexible than you are with STI.

So delegated types can be a powerful tool, when you want something to live on one table, so it is easily queryable and sometimes more importantly you can make use of pagination with it.

first published on rstuder.ch

Custom Turbo Stream Actions

Roland Studer — Sun, 15 May 2022 22:29:27 +0000

Turbo Hotwire is neat, I really like the simplicity of Turbo frames. But after having used CableReady the turbo streams feel a bit limiting. I was surprised, when I could not find any gem/package that enhances turbo streams to create custom turbo actions.

Disclaimer: This post won't make much sense to you, if you are not familiar with Turbo streams and StimulusJS

Let's say if you want to redirect to a new page after some job is done, or you want to reset a form, there is no way to do that with a turbo stream action. With CableReady you could do
cable_ready.redirect_to(url: some_url) (docs).

So I was wondering how one would go about creating custom turbo stream actions. From how DHH (the original creator of Rails) has discussed turbo streams, it is unlikely that turbo will support more actions, there is a
pending PR but not much has moved.

So what can we do today?

Stimulus controllers to the rescue

We can mimic the pattern turbo streams use with StimulusJS. StimulusJS has a lifecycle method called connect, that is executed when a new element with a stimulus controller is added to the DOM.

For the redirect example, we can write something like this:


import { Controller } from "@hotwired/stimulus"

export default class extends Controller {
      // take a value as an argument where to redirect
    static values = { url: String } 
    connect() {
        // perform wanted behavior
        Turbo.visit(this.urlValue)
        // clean up after action is executed
      this.element.remove()
    }
}

So the following html added anywhere in the body would perform a redirect:

<template data-controller="redirect" data-redirect-url-value="<%= your_redirect_url %>"></template>

So with a turbo stream we can attach this to the body:

<%= turbo_stream.append_all "body" do %>
    <template data-controller="redirect" data-redirect-url-value="<%= your_redirect_url %>"></template>
<% end %>

And the browser will redirect, given this turbo stream response. BTW: We use append_all so we can append to the body, withouth having to rely on the presence of an element with a certain id.

Better developer experience

It's not the most elegant solution, but it works and has only little overhead. We can improve the developer experience by writing a helper to allow something like:

<%= turbo_stream_action :redirect, url: "http://www.rstuder.ch" %>

So we can write a helper that creates a turbo stream tag that will append to the body and convert a hash of values to values for a stimulus controller:

module TurboStreamHelper
  def turbo_stream_action(action, **values)
    controller_name = action.to_s.dasherize

    data_attrs = {
      "data-controller" => controller_name
    }

    data_attrs = values.each_with_object(data_attrs) do |(key, value), attrs|
      attrs["data-#{controller_name}-#{key.to_s.dasherize}-value"] = value
    end

    turbo_stream.append_all "body" do
      content_tag(:template, nil, data_attrs.merge)
    end
  end
end

So we got a simple API around some conventions, that gives us the power to create custom actions and invoke them with arguments from a turbo stream template.

Conclusion

Turbo streams with Stimulus Controllers give us enough power to achieve custom actions. Without further dependencies. If you use CableReady anyway, then have a look at
this package from the wonderful Marco Roth that enables you to use the cable ready operations with turbo streams.

ps: This post was originally published on rstuder.ch

Ruby refinements have a second good use case.

Roland Studer — Sun, 15 Nov 2020 23:04:13 +0000

According to Bradley Refinements have one good use case: Conversion Wrappers. I humbly present the second one.

Monkey patching in Ruby is a simple as:

class String
  def red
    "\e[#31m#{self}\e[0m"
  end
end

But what if you don't to pollute the String-class for users of your Gem? In the worst case you might actually overwrite a monkey patch provided by the developer. We faced this when we wanted to provide coloring of strings for our logger in StimulusReflex. We wanted our users to be able to write a configuration proc like this:

config.logging = proc { "#{timestamp.cyan} #{reflex_id.red}" }

Enter `refine`

With refinements we were able to monkey patch only where explicitly called for it:

module Colorize
  refine String do
    def red
      "\e[#31m#{self}\e[0m"
    end
  end
end

Now you can activate this monkey patch in whatever class you need it:

class Logger
  using Colorize
  def error
    "Ooops".red
  end
end

A complication

Procs are a convenient solution, however they get the binding/context of where they are defined, not of where they are called. Just calling the proc in our Loggerclass will not make use of the colorize-refinement, actually no method of the Loggerclass is available to the proc, because it was defined in a completely different context (in an initializer of the gem user).

So we made use of instance_eval

class Logger
  using Colorize
  def log
    puts instance_eval(&config.logging)
  end
end

See the commit for adding colorize and using instance_eval

Lightning fast reactive action with Stimulus Reflex partial morphs

Roland Studer — Tue, 22 Sep 2020 07:24:12 +0000

Stimulus reflex is an awesome way to build reactive single-page-like applications with Ruby on Rails, with minimal Javascript.

The newest update v 3.3.0 introduces partial morphs, that don't go through the controller action anymore, and it allows us to make reflexes lightning fast.

How does a reflex action work? (simplified)

You trigger a reflex on the client (by data attribute, or in a stimulus method).
Your server side Reflex executes, where you can trigger jobs, set instance variables, do db-stuff.
Then the original controller action is performed, but with the newly set instance variables and any updated state of the database.
The page on the client updates with morphdom over a websocket connection.

So this gives us a lot of convenience as we reuse all the logic of the original controller action that rendered a page initially.
However this convenience also means that every reflex can only be about as fast as the controller action it performs.

Introducing `morph :selector`

This release will introduce different morph modes
that allow you to skip the controller action and instead render a partial, a view_component or a string, that you then morph into the page.

Let us look at an example:

In my application I have a timeline with 21 days where I can add orders to those days. Executing the controller action and rendering takes around 180ms,
which is not horrible, but definitely not great.

To delete an item in the timeline we can have a simple reflex:

timeline_reflex.rb

def delete
  ScheduledOrder.destroy(element.dataset[:scheduled-order-id])
end

which is triggered from a simple button with the right data attributes

<button data-reflex="click->My::TimelineReflex#delete" data-scheduled-order-id="<%= order.id %>">

So simple, so slim, so convenient.

But every delete reflex action, will include those 180ms to execute the controller action, meh.

Speeding up with with partial morph.

Now we can leverage only doing a partial update.