DEV Community: Mansa Keïta

Using Turbo Streams with Kredis

Mansa Keïta — Sat, 23 Jul 2022 10:23:00 +0000

When using Turbo Streams, we usually want to trigger WebSockets updates from our domain models using the Turbo::Broadcastable methods included in ActiveRecord.

But what if we want to add a feature which only uses Redis to persist data? How can we broadcast Turbo streams when the value of a Redis key changes?

Let's anwser those questions by making a simple live counter with Turbo Streams and Kredis.

Making a counter with Turbo Streams and Kredis

Let's generate a Rails 7 app without ActiveRecord (and with Tailwind just to make our counter look good):

$ rails new hotwire-counter --css tailwind --skip-active-record
$ cd hotwire-counter

To use Kredis, we need to uncomment gem "kredis" in our Gemfile and install it:

$ bundle
$ bin/rails kredis:install

Let's generate a controller:

$ rails g controller counter show

And define our actions:

# app/controllers/counter_controller.rb
class CounterController < ApplicationController
  def show
    render :show, locals: {
      counter_count: counter_count.value
    }
  end

  def increment
    counter_count.increment

    respond_to do |format|
      format.turbo_stream { render_partial_update }

      format.html { redirect_to root_url }
    end
  end

  def decrement
    counter_count.decrement

    respond_to do |format|
      format.turbo_stream { render_partial_update }

      format.html { redirect_to root_url }
    end
  end

  private
    # We use Kredis to store and retrieve the counter's state
    def counter_count
      @counter_count ||= Kredis.counter "counter:count"
    end

    def render_partial_update
      render turbo_stream: turbo_stream.update("counter-count",
        counter_count.value
      )
    end
end

Let's add our routes:

Rails.application.routes.draw do
  root to: "counter#show"

  post "/increment", to: "counter#increment", as: :increment
  post "/decrement", to: "counter#decrement", as: :decrement
end

Let's update app/views/counter/show.html.erb:

<div class="flex flex-col items-center mx-auto my-0 mb-4 text-lg gap-2">
  <div>
    <span id="counter-count">
      <%= counter_count %>
    </span>
  </div>

  <div class="flex gap-2">
    <%= button_to "+", increment_path, class: "px-8 py-4 text-white bg-black rounded" %>
    <%= button_to "-", decrement_path, class: "px-8 py-4 text-white bg-black rounded" %>
  </div>
</div>

Let's start the server:

$ bin/dev

Now we should be able to use our counter in the browser:

Broadcasting Turbo streams

Since we're not using ActiveRecord, we won't be able to use the Turbo::Broadcastable methods to broadcast updates.

But this won't be a problem because we can use the Turbo::StreamsChannel directly with methods like Turbo::StreamsChannel.broadcast_update_to (defined in the Turbo::Streams::Broadcasts module).

It works with the turbo_stream_from helper used in the views to subscribe to the Turbo::StreamsChannel and receive updates from specific streams.

Let's try to use Turbo::StreamsChannel.broadcast_update_to in our controller to broadcast updates:

# app/controllers/counter_controller.rb
class CounterController < ApplicationController
  ...
  def increment
    ...
    respond_to do |format|
      format.turbo_stream do 
        render_partial_update

        broadcast_update
      end
      ...
    end
  end

  def decrement
    ...
    respond_to do |format|
      format.turbo_stream do 
        render_partial_update

        broadcast_update
      end
      ...
    end
  end

  private
    ...
    # This will broadcast the following Turbo stream:
    # <turbo-stream action="update" target="counter-count" >
    #   <template>counter_count.value</template>
    # </turbo-stream>
    def broadcast_update
      Turbo::StreamsChannel.broadcast_update_to "counter",
        target: "counter-count"
        content: counter_count.value
    end
end

We also need to use turbo_stream_from in app/views/counter/show.html.erb to receive the updates:

<%= turbo_stream_from "counter" %>
...

Now let's open our page in two separate tabs:

Nice, it worked!

But hold on! There's a problem with our approach. Can you figure out what it is?

Our controller shouldn't be responsible for broadcasting page changes. That's because they can't be transmitted if we use the counter directly from the back end. It means we won't see the result on the page if we increment the count from the console, for example.

Can you think of a better solution?

A better approach would be to model our counter by including Kredis::Attributes and using the kredis_counter macro with an after_change callback:

# app/models/counter.rb
class Counter
  include Kredis::Attributes

  kredis_counter :count,
    key: "counter:count",
    after_change: :broadcast_update

  class << self
    def count
      new.count
    end
  end

  def broadcast_update
    Turbo::StreamsChannel.broadcast_update_to "counter",
      target: "counter-count",
      content: count.value
  end
end

Now that we moved the broadcasting logic in the Counter model, we can broadcast updates whenever the count changes. It means we can update the count from the console and see the result on the page.

Let's continue by refactoring the #counter_count method in our controller:

# app/controllers/counter_controller.rb
class CounterController < ApplicationController
  ...
  private
    def counter_count
      @counter_count ||= Counter.count
    end
end

Now let's open the console and update the count:

Et voilà, there you have it!

Wrap up

We can use the Turbo::StreamsChannel with Kredis::Attributes to broadcast Turbo streams when the value of a Redis key changes.

Adding a simple Hotwire ping tool in a Rails application

Mansa Keïta — Sat, 16 Jul 2022 12:38:30 +0000

In this tutorial, we will make a simple ping tool with Stimulus and Turbo Drive.

Wait, what's a ping?

You may have seen the word ping used as a synonym for latency in online games or network speed tests. But a ping is a program that sends a request to a server to check its availability. It's like calling someone and waiting for them to call us back when they are available.

Using a ping, we can measure the network latency. We can do this by saving the request and response time to compute the difference between the two and display the result in milliseconds.

Usually, a ping uses ICMP (Internet Control Message Protocol), where the request is called ECHO_REQUEST and the response ECHO_REPLY. But we can still use HTTP to ping the server with a GET request and send a plain text response with "PONG", for example.

Ok, but why is it relevant?

With Hotwire, we can build server-side rendered applications. That means the server is responsible for delivering page changes when the client asks for them or in response to events occurred on the server (like when a user sends a message on a chat). The page changes will still have to go through the network to be delivered, whether they get triggered by events on the client or the server.

That's why the network latency is crucial here. The latency is essentially the time it takes for the client to receive a response from the server. It directly influences the time it takes to see the result of an action, so it directly impacts the user experience (especially in server-side rendered applications). The lower latency, the more responsive the pages will feel (and the happier your users will be, hopefully).

The network latency depends on factors like the server load and location. Turbo helps us reduce the server load by allowing us to update the dynamic parts of our pages while efficiently caching the static ones. But this alone is not enough. Even if your application takes advantage of all the features of Turbo, a user connected to a server located in San Francisco from Sydney will still have latency issues. Thankfully, we can use platforms like Fly.io that make it easy to deploy applications close to our users, thus, allowing them to experience the responsiveness of Hotwire applications wherever they are.

Using a ping, we can measure the network latency to help us improve the responsiveness of our Hotwire applications.

Sounds cool, but how are we going to do that?

We will make a ping tool to display the network latency each second on a page. To achieve that, we need to:

Ping the server by sending a GET request
Save the request time
Send the response to the client
Save the response time
Compute the difference between the response and request time
Display the result in milliseconds on the page
Repeat the process a second later

So let's dive in!

Pinging the server

To ping the server, we can submit a form that sends a GET request to /ping. Then we can render a
plain text response to the client with "PONG" in the body.

Let's generate a PingController:

$ rails g controller ping

Let's add a #pong action which renders a plain text response with "PONG":

class PingController < ApplicationController
  def pong
    render status: :ok, body: "PONG"
  end
end

Let's add a /ping endpoint routed to the #pong action:

Rails.application.routes.draw do
  ...
  get "/ping", to: "ping#pong", as: "ping"
end

Let's create a partial for the form:

# app/views/shared/_ping.html.erb
<%= form_tag ping_path, method: :get do %>
  <%= button_tag "Ping" %>
<% end %>

Let's add the partial to the home page for example:

$ rails g controller home show

# config/routes.rb
Rails.application.routes.draw do
  root to: "home#show"
  ...
end

# app/views/home/show.html.erb
<%= render "shared/ping" >

Let's submit the form and inspect the response:

We have successfully pinged the server. Now we need to measure the network latency.

Measuring the network latency

We can measure the network latency by using Turbo Drive events to:

Listen to the turbo:before-fetch-request event to pause the request with event.preventDefault()
Save the request time right after the request is sent
Resume the request with event.detail.resume()
Listen to the turbo:submit-end event to save the response time and measure the network latency

Let's generate a stimulus controller:

$ rails g stimulus ping

Let's define the getters and setters we will need:

export default class extends Controller {
  // We will write our code here

  get requestTime() {
    return this._requestTime
  }

  set requestTime(requestTime) {
    this._requestTime = requestTime
  }

  get responseTime() {
    return this._responseTime
  }

  set responseTime(responseTime) {
    this._responseTime = responseTime
  }

  get latency() {
    return this._latency
  }

  set latency(latency) {
    this._latency = latency
  }
}

Let's connect the Stimulus controller and define an action to pause the request when the form is submitted:

# app/views/shared/_ping.html.erb
<div data-controller="ping">
  <%= form_tag ping_path, method: :get, data: { action: "turbo:before-fetch-request->pauseRequest" } do %>
    ...
  <% end %>
</div>

The pauseRequest() method should:

Pause the request using event.preventDefault()
Save the request time right after the request is sent using setTimeout()
Resume the request with event.detail.resume()

# app/javascript/controllers/ping_controller.js
export default class extends Controller {
  pauseRequest(event) {
    event.preventDefault()

    setTimeout(() => this.saveRequestTime() )

    event.detail.resume()
  }

  saveRequestTime() {
    this.requestTime = new Date().getTime()
  }
  ...
}

Note: We used an arrow function to ensure that this resolves to the current controller.

Now let's add an action to measure the network latency when the form is submitted:

# app/views/shared/_ping.html.erb
<div data-controller="ping">
  <%= form_tag ping_path, method: :get, data: { action: "... turbo:submit-end->measureLatency" } do %>
    ...
  <% end %>
</div>

The measureLatency() method should:

Save the response time
Compute the difference between the response and request time
Display the result

export default class extends Controller {
  ...
  measureLatency() {
    this.saveResponseTime()

    this.latency = this.responseTime - this.requestTime

    console.log(`${this.latency} ms`)
  }

  saveResponseTime() {
    this.responseTime = new Date().getTime()
  }
  ...
}

Let's try to submit the form and open the console to see if it works:

Nice, it worked!

Note: If we inspect the request on Chrome, we can see that the result is close to the total time recorded by the browser. But in other browsers (especially Firefox) we can see that the results can be quite different for some reason.

Displaying the latency each second

To ping the server each second, we can set a timer in measureLatency() to submit the form a second later after the latency is displayed.

First, let's register the form as a Stimulus target:

# app/views/shared/_ping.html.erb
<div data-controller="ping">
  <%= form_tag ping_path, method: :get, data: { ..., "ping-target": "pingForm" } do %>
    ...
  <% end %>
</div>

Then set our timer with setTimeout():

export default class extends Controller {
  static targets = ["pingForm"]
  ...
  measureLatency() {
    ...
    setTimeout(() => this.ping(), 1000)
  }
  ...
  ping() {
    this.pingFormTarget.requestSubmit()
  }
}

Note: We're using form.requestSubmit() because form.submit() doesn't dispatch submit events.

Let's submit the form and open the console:

It worked! Now let's display the result on the page rather than on the console:

# app/views/shared/_ping.html.erb
<div data-controller="ping">
  ...
  <span data-ping-target="latency"></span>
</div>

export default class extends Controller {
  static targets = ["pingForm", "latency"]
  ...
  measureLatency() {
    ...
    this.displayLatency()
  }
  ...
  displayLatency() {
    this.latencyTarget.textContent = this.latency + " ms"
  }
}

Let's submit the form again:

Et voilà, there you have it! Our homemade Hotwire ping tool!

Discussion

Now that you know how to make a ping tool with Hotwire, you can go further by adding a feature to pause and resume the ping process, for example. You can also try to improve the measurement in all modern browsers, as it seems to work better with Chrome than other browsers (especially Firefox).

See you next time with more Hotwire magic!

Modeling semi-structured data in Rails

Mansa Keïta — Wed, 27 Oct 2021 20:11:11 +0000

Relational databases are very powerful. Their power comes from their ability to...

Preserve data integrity with a predefined schema.
Make complex relationships through joins.

But sometimes, we can stumble accross data that don't fit in the relational model. We call this kind of data: semi-structured data.
When this happens, the things that makes relational databases powerful are the things that gets in our way, and complicate our model instead of simplifying it.

That's why document databases exist, to model and store semi structured data. However, if we choose to use a document database, we'll loose all the power of using a relational database.

Luckily for us, relational databases like Postgres and MySQL now has good JSON support. So most of us won't need to use a document database like MongoDB, as it would be overkill. Most of the time, we only need to denormalize some parts of our model. So it makes more sense to use simple JSON columns for those, instead of going all-in, and dump your beloved relational database for MongoDB.

Currently in Rails, we can have full control over how our JSON data is stored and retrieved from the database, by using the Attributes API to serialize and deserialize our data. So let's see how we can model semi-structured data in a more convenient way.

Use case: Dealing with bibliographic data

Let's say that we are building an app to help libraries build and manage an online catalog. When we're browsing through a catalog, we often see item information formatted like this:

Author:        Shakespeare, William, 1564-1616.
Title:         Hamlet / William Shakespeare.
Description:   xiii, 295 pages : illustrations ; 23 cm.
Series:        NTC Shakespeare series.
Local Call No: 822.33 S52 S7
ISBN:          0844257443
Series Entry:  NTC Shakespeare series.

But in the library world, data is produced and exchanged is this form:

LDR 00815nam  2200289 a 4500
001 ocm30152659
003 OCoLC
005 19971028235910.0
008 940909t19941994ilua          000 0 eng
010   $a92060871
020   $a0844257443
040   $aDLC$cDLC$dBKL$dUtOrBLW
049   $aBKLA
099   $a822.33$aS52$aS7
100 1 $aShakespeare, William,$d1564-1616.
245 10$aHamlet /$cWilliam Shakespeare.
264  1$aLincolnwood, Ill. :$bNTC Pub. Group,$c[1994]
264  4$cÂ©1994.
300   $axiii, 295 pages :$billustrations ;$c23 cm.
336   $atext$btxt$2rdacontent.
337   $aunmediated$bn$2rdamedia.
338   $avolume$bnc$2rdacarrier.
490 1 $aNTC Shakespeare series.
830  0$aNTC Shakespeare series.
907   $a.b108930609
948   $aLTI 2018-07-09
948   $aMARS

This is what we call a MARC (Machine-Readable Cataloging) record. That's how libraries describes the ressources they own.

As you can see, that's really verbose! That's because in the library world, ressources are described very precisely, in order to be "machine-readable".

For convenience, developers usually represent MARC data in JSON:

{
  "leader": "00815nam 2200289 a 4500",
  "fields": [
    { "tag": "001", "value": "ocm30152659" },
    { "tag": "003", "value": "OCoLC" },
    { "tag": "005", "value": "19971028235910.0" },
    { "tag": "008", "value": "940909t19941994ilua 000 0 eng " },
    { "tag": "010", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "92060871" }] },
    { "tag": "020", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "0844257443" }] },
    { "tag": "040", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "DLC" }, { "code": "c", "value": "DLC" }, { "code": "d", "value": "BKL" }, { "code": "d", "value": "UtOrBLW" } ] },
    { "tag": "049", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "BKLA" }] },
    { "tag": "099", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "822.33" }, { "code": "a", "value": "S52" }, { "code": "a", "value": "S7" } ] },
    { "tag": "100", "indicator1": "1", "indicator2": " ", "subfields": [{ "code": "a", "value": "Shakespeare, William," }, { "code": "d", "value": "1564-1616." } ] },
    { "tag": "245", "indicator1": "1", "indicator2": "0", "subfields": [{ "code": "a", "value": "Hamlet" }, { "code": "c", "value": "William Shakespeare." } ] },
    { "tag": "264", "indicator1": " ", "indicator2": "1", "subfields": [{ "code": "a", "value": "Lincolnwood, Ill. :" }, { "code": "b", "value": "NTC Pub. Group," }, { "code": "c", "value": "[1994]" } ] },
    { "tag": "264", "indicator1": " ", "indicator2": "4", "subfields": [{ "code": "c", "value": "©1994." }] },
    { "tag": "300", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "xiii, 295 pages :" }, { "code": "b", "value": "illustrations ;" }, { "code": "c", "value": "23 cm." } ] },
    { "tag": "336", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "text" }, { "code": "b", "value": "txt" }, { "code": "2", "value": "rdacontent." } ] },
    { "tag": "337", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "unmediated" }, { "code": "b", "value": "n" }, { "code": "2", "value": "rdamedia." } ] },
    { "tag": "338", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "volume" }, { "code": "b", "value": "nc" }, { "code": "2", "value": "rdacarrier." } ] },
    { "tag": "490", "indicator1": "1", "indicator2": " ", "subfields": [{ "code": "a", "value": "NTC Shakespeare series." }] },
    { "tag": "830", "indicator1": " ", "indicator2": "0", "subfields": [{ "code": "a", "value": "NTC Shakespeare series." }] },
    { "tag": "907", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": ".b108930609" }] },
    { "tag": "948", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "LTI 2018-07-09" }] },
    { "tag": "948", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "MARS" }] }
  ]
}

By looking at this JSON representation, we can see that the data is...

Nested: A MARC record contains many fields, and most of them contains multiple subfields.
Dynamic: Some fields are repeatable ("264" and "948"), and subfields too. The first fields don't have subfields nor indicators (they're called control fields).
Encapsulated: The meaning of subfields depends on the field they're in (take a look at the "a" subfield for example).

All those characteristics can be grouped into what we call: semi-structured data.

Semi-structured data is a form of structured data that does not obey the tabular structure of data models associated with relational databases or other forms of data tables, but nonetheless contains tags or other markers to separate semantic elements and enforce hierarchies of records and fields within the data. Therefore, it is also known as self-describing structure. - Wikipedia

A perfect example of that is HTML documents. An HTML document contains different types of tags which can nested in multiple ways. It wouldn't make sense to model HTML documents with tables and columns. Imagine having to access nested tags through joins, considering the fact that we could potentially have hundreds of them on a single HTML document. That's why we usually store this kind of data in a text field.

In our case, we're using JSON to represent MARC data. Luckily for us, we can store JSON data directly in relational databases like Postgres or MySQL:

# config/initializers/inflections.rb
ActiveSupport::Inflector.inflections(:en) do |inflect|
  inflect.acronym "MARC"
end

$ rails g model marc/record leader:string fields:json
$ rails db:migrate

We can then create a MARC record like this:

MARC::Record.create leader: "00815nam 2200289 a 4500", fields: [
  { "tag": "001", "value": "ocm30152659" },
  { "tag": "003", "value": "OCoLC" },
  { "tag": "005", "value": "19971028235910.0" },
  { "tag": "008", "value": "940909t19941994ilua 000 0 eng " },
  { "tag": "010", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "92060871" }] },
  { "tag": "020", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "0844257443" }] },
  { "tag": "040", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "DLC" }, { "code": "c", "value": "DLC" }, { "code": "d", "value": "BKL" }, { "code": "d", "value": "UtOrBLW" } ] },
  { "tag": "049", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "BKLA" }] },
  { "tag": "099", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "822.33" }, { "code": "a", "value": "S52" }, { "code": "a", "value": "S7" } ] },
  { "tag": "100", "indicator1": "1", "indicator2": " ", "subfields": [{ "code": "a", "value": "Shakespeare, William," }, { "code": "d", "value": "1564-1616." } ] },
  { "tag": "245", "indicator1": "1", "indicator2": "0", "subfields": [{ "code": "a", "value": "Hamlet" }, { "code": "c", "value": "William Shakespeare." } ] },
  { "tag": "264", "indicator1": " ", "indicator2": "1", "subfields": [{ "code": "a", "value": "Lincolnwood, Ill. :" }, { "code": "b", "value": "NTC Pub. Group," }, { "code": "c", "value": "[1994]" } ] },
  { "tag": "264", "indicator1": " ", "indicator2": "4", "subfields": [{ "code": "c", "value": "©1994." }] },
  { "tag": "300", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "xiii, 295 pages :" }, { "code": "b", "value": "illustrations ;" }, { "code": "c", "value": "23 cm." } ] },
  { "tag": "336", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "text" }, { "code": "b", "value": "txt" }, { "code": "2", "value": "rdacontent." } ] },
  { "tag": "337", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "unmediated" }, { "code": "b", "value": "n" }, { "code": "2", "value": "rdamedia." } ] },
  { "tag": "338", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "volume" }, { "code": "b", "value": "nc" }, { "code": "2", "value": "rdacarrier." } ] },
  { "tag": "490", "indicator1": "1", "indicator2": " ", "subfields": [{ "code": "a", "value": "NTC Shakespeare series." }] },
  { "tag": "830", "indicator1": " ", "indicator2": "0", "subfields": [{ "code": "a", "value": "NTC Shakespeare series." }] },
  { "tag": "907", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": ".b108930609" }] },
  { "tag": "948", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "LTI 2018-07-09" }] },
  { "tag": "948", "indicator1": " ", "indicator2": " ", "subfields": [{ "code": "a", "value": "MARS" }] }
]

And access it this way:

record = MARC::Record.first
field = record.fields.find { |field| field["tag"] == "245" }
subfield = field["subfields"].first
subfield["value"]
=> "Hamlet"

It works, but...

It's not very convenient to access nested data this way.
We cannot easily attach logic to our JSON data without polluting our model.

What if we could interact with our JSON data the same way we do with ActiveRecord associations ? Enters ActiveModel and the AttributesAPI!

First, we have to define a custom type which...

Maps JSON objects to ActiveModel-compliant objects.
Handles collections.

To do that, we'll add the following options to our type:

:class_name: The class name of an ActiveModel-compliant object.
:collection: Specify if the attribute is a collection. Default to false.

class DocumentType < ActiveModel::Type::Value
  attr_reader :document_class, :collection

  def initialize(class_name:, collection: false)
    @document_class = class_name.constantize
    @collection     = collection
  end

  def cast(value)
    if collection
      value.map { |attributes| process attributes }
    else
      process value
    end
  end

  def process(value)
    document_class.new(value)
  end

  def serialize(value)
    value.to_json
  end

  def deserialize(json)
    value = ActiveSupport::JSON.decode(json)

    cast value
  end

  # Track changes
  def changed_in_place?(old_value, new_value)
    deserialize(old_value) != new_value
  end
end

Let's register our type as we gonna use it multiple times:

# config/initializers/type.rb
ActiveModel::Type.register(:document, DocumentType)
ActiveRecord::Type.register(:document, DocumentType)

Now we can use it in our models:

class MARC::Record < ApplicationRecord
  attribute :fields, :document,
    class_name: "MARC::Record::Field",
    collection: true

  def at(tag)
    fields.find { |field| field.tag == tag }
  end
end

class MARC::Record::Field
  include ActiveModel::Model
  include ActiveModel::Attributes
  include ActiveModel::Serializers::JSON

  attribute :tag, :string
  attribute :value, :string
  attribute :indicator1, :string
  attribute :indicator2, :string
  attribute :subfields, :document,
    class_name: "MARC::Record::Field::Subfield",
    collection: true

  # Control fields don't have subfields
  def attributes
    if control_field?
        {
          "id" => id,
          "tag" => tag,
          "value" => value
        }
      else
        {
          "id" => id,
          "tag" => tag,
          "indicator1" => indicator1,
          "indicator2" => indicator2,
          "subfields" => subfields
        }
      end
  end

  def control_field?
    /00\d/ === tag
  end

  def at(code)
    subfields.find { |subfield| subfield.code == code }
  end

  alias [] at

  # Used to track changes
  def ==(other)
    attributes == other.attributes
  end
end

class MARC::Record::Field::Subfield
  include ActiveModel::Model
  include ActiveModel::Attributes
  include ActiveModel::Serializers::JSON

  attribute :code, :string
  attribute :value, :string

  def ==(other)
    attributes == other.attributes
  end
end

Let's test this in the console:

record.at("245")["a"].value
=> "Hamlet"

record.changed?
=> false

record.at("245")["a"].value = "Romeo and Juliet"
record.at("245")["a"].value
=> "Romeo and Juliet"

record.changed?
=> true

Et voilà! Home-made associations!

Luckily, you won't need to implement this yourself, as this gem does it for you (and even more).

Here's how we can simplify our models:

class MARC::Record < ApplicationRecord
  include ActiveModel::Embedding::Associations

  embeds_many :fields

  # ...
end

class MARC::Record::Field
  include ActiveModel::Embedding::Document

  # ...

  embeds_many :subfields

  # ...
end

class MARC::Record::Field::Subfield
  include ActiveModel::Embedding::Document

  # ...
end

We can then code our views with nested attributes support out-of-the-box:

# app/views/marc/records/_form.html.erb
<%= form_with model: @record do |record_form| %>
  <% @record.fields.each do |field| %>
    <%= record_form.fields_for :fields, field do |field_fields| %>

      <%= field_fields.label :tag %>
      <%= field_fields.text_field :tag %>

      <% if field.control_field? %>
        <%= field_fields.text_field :value %>
      <% else %>
        <%= field_fields.text_field :indicator1 %>
        <%= field_fields.text_field :indicator2 %>

        <%= field_fields.fields_for :subfields do |subfield_fields| %>
          <%= subfield_fields.label :code %>
          <%= subfield_fields.text_field :code %>
          <%= subfield_fields.text_field :value %>
        <% end %>
      <% end %>
    <% end %>
  <% end %>

  <%= record_form.submit %>
<% end %>

We can even use validations:

class MARC::Record < ApplicationRecord
  # ...

  validates :fields, presence: true
  vallidates_associated :fields
end

class MARC::Record::Field
  # ...

  validates :subfields, presence: true, unless: :control_field?
  validates_associated :subfields, unless: :control_field?
end

class MARC::Record::Field::Subfield
  # ...

  validates_presence_of :code, :value
end

record = MARC::Record.new
record.valid?
=> false

record.fields = [{ tag: "245" }]
record.valid?
=> false

record.at("245").subfields = [{ code: "a", value: "Ruby on Rails" }]
record.valid?
=> true

We can use custom collections if we need to add custom behaviour:

class MARC::Record::FieldCollection
  include ActiveModel::Embedding::Collecting
  include Enumerable

  def at(tag)
    find { |field| field.tag == tag }
  end

  def repeated?(field)
    # ...
  end

  # ...
end

class MARC::Record < ApplicationRecord
  include ActiveModel::Embedding::Associations

  embeds_many :fields, collection: "FieldCollection"

  delegate :at, :repeated?, to: :fields

  # ...
end

record = MARC::Record.first
record.at("245")["a"].value
=> "Hamlet"

record.repeated?("245")
=> false

record.repeated?("264")
=> true

We can use custom types if we need to cast the elements of a collection:

class MARC::Record::FieldType < ActiveModel::Type::Value
  def cast(value)
    # ...
  end
end

class MARC::Record < ApplicationRecord
  include ActiveModel::Embedding::Associations

  embeds_many :fields, cast_type: "FieldType"

  # ...
end

So the next time you need to model semi-structured data in your Rails application...

Give this gem a try!
Or use the Attributes API.