Dan LeGrand

Quick note, some of the documentation for some Ruby version managers (such as chruby which I use) instruct users to store the string literal "ruby-x.x.x" with the version in the .ruby-version. If you get an error like:

[!] There was an error parsing `Gemfile`: Illformed requirement ["ruby-3.x.x"]. Bundler cannot continue.

it means you probably have the string in there. Just update your .ruby-version to ONLY have the version and not the "ruby-" string prefix.

I use Heroku, so had to use the fallback File.read() approach, which really isn't that much of a fallback IMO, only requires a few more character.

I can't believe I never thought about this! So simple once you see it. Now I have a singular source of truth for my Ruby version :)

Chruby readme reference:
https://github.com/postmodern/chruby?tab=readme-ov-file#default-ruby

Awesome! Would actually love to see more videos on extending Trix. I've been using Froala Editor for my production applications, because Trix felt like it was lacking a lot of core functionality. My use case was having an editor capable of writing emails with styles users were familiar with, such as Gmail and Outlook, and Trix simply didn't have what I needed and the docs to customize it seem a bit sparse. Features like image resizing, font/background colors, etc... I'd love to use the quasi-official Rails HTML editor, but it needs some work before it can compete with other rich editors IMO.

Great episode! Is there any convention or recommendation for managing the JS code instead of throwing it all in the application.js? Something like app/javascript/stream_actions/console_log.js, etc, and then having an import statement that loads the entire folder?

Is there any benefit to using the constant for the base URL instead of just using a method and overwriting it in each inherited client? Looking forward to the generator episode! I've been playing around with Rails generators recently to build out my own Rails template so I can stop copying/pasting code every time I start a new project.

Note to others, running Rails 7.0.4.1 with dartsass-rails for your SASS compiling, you may run into segmentation violation (SEGV) errors when running the dartsass:watch command in your Procfile.dev (valled via bin/dev by default in Rails 7+) on ALPINE Linux base images.

I tested on the standard ruby:3.1.2 vs ruby:3.1.2-alpine, and the standard image works fine but Alpine has SEGV errors. Not sure if there's an Alpine dependency that's missing that may resolve, but since I was working on local development, I didn't investigate too much and just went with the base ruby:3.1.2 image. Maybe I'll circle back once the Rails 7.1+ updates implement a default Docker setup, hopefully some folks more knowledgeable about Docker and images have resolved it for us all :)

Hey Chris, is there any major difference between the newish Active record signed IDs in Rails 6.1 vs the Global ID signed IDs? A quick glance leads me to think the only real difference is that AR signed IDs can only be used for a single model, whereas signed global IDs can be used for any model, but wasn't sure if you knew about any other differences practically speaking. Great episode, this will help me reduce several extra DB columns I have for various one-time use tokens like password resets!

Great video, Chris, thanks!

Hey Chris, thanks for going over Turbo and StimulusJS 2.0 changes, I'm really excited about using them in my projects!

One really big thing that would be great to cover is using dialogs/modals with Turbo.

In several of my projects, users really like having dialogs/modals that can show information or allow them to edit information via forms without losing context in the app.

One issue with that, however, is that you can't bookmark or link to a "show" action dialog because it's displayed via JS. In my case, I can have multiple dialogs on top of each other, and each dialog is dynamically appended to the body, which is different from the approach of having a single <div id="dialog">...</div> hidden on the page and just updating content (because you can't have multiple).

With regards to dialogs and forms, I've gone the route of remote: true on all the forms and using create.js.erb to execute JS code on the client. As an example:

# posts_controller.rb
def create
  @post = Post.new(post_params)

  if @post.save
    # create.js.erb
  else
    render :form_validation_error # js.erb file
  end
end

# posts/create.js.erb
Dialog.hide("#new-post-form")
Snackbar.create("Post successfully created")

# posts/form_validation_error.js.erb
# Using jQuery syntax for example of what I'm doing
$("#new-post-form .dialog-content").replaceWith("<%=j render(partial: 'posts/form') %>")

I've been looking at Turbo with its turbo-forms and turbo-streams, and it looks like the core team is headed in a different direction, since they don't want to execute arbitrary JS as a response anymore and instead recommend StimulusJS callbacks (read that in one of the guides for either StimulusJS or Turbo, can't remember which).

But the core issue is making Turbo play nicely with multiple dialogs/modals on a page, some of them just showing info and some of them actually forms that submit data.

My current solutions "work", but it looks like I'll need to do a significant amount of refactoring to make them play nicely with the direction Turbo is going.

Chris, from what you mentioned in the video about stimulus_reflex, it would re-run an #index action (original page) after a reflex is executed. Wouldn't this be executing a lot of extra DB queries and thus using a lot more memory on servers?

I'm building something similar to a calendar app that displays a variety of events, and when I create a new event, I just need to insert that 1 record onto the page. If I re-ran the entire #index page, that would result in at least 5+ extra queries in most production applications (retrieve current_user, retrieve any user-specific items, query the #index action and possibly any secondary lookups, etc). From my experience the DB is the slowest part of most Rails apps, followed by the view rendering.

My approach currently is to use custom js.erb files with partials (and now view_components from Github) to dynamically update or insert my new events onto the calendar day. This means I only run the minimum DB queries necessary to insert the new record into the DB, and then spit back a little JS to the page that dynamically updates itself.

If the #index pages have a decent amount of content and thus would run several DB queries, is there really a benefit to stimulus_reflex since it automatically re-renders pages?

I can see cable_ready being useful, as it provides a nicer websocket interface to dynamically updating select portions of the page, and thus minimizing unnecessary DB queries.

BTW, I'd love to see some videos on Github's view_components, and get your thoughts on them! I started using them in a few places and I do like the ability to quickly test my views without having to load the entire app via system tests.

@Chris, since stimulus reflex is using action_cable behind the scenes which relies on a redis DB, do you have any idea if there are scale limitations for using stimulus reflex? ie, 1,000 concurrent users probably fine, but 100,000+ it starts crawling because redis is backed up, etc...

My understanding is that the default action_cable implementation had some scale concerns, and that's why any_cable (https://github.com/anycable/anycable) re-wrote some of the API in a faster language (I think they're using Go-lang?). I haven't encountered these scale issues in my own apps, so my knowledge is only "what the experts say", not based on real numbers.

I'm curious about the "production" viability of stimulus reflex before considering implementing in some of my systems.

Awesome video as always, and I'm looking forward to seeing more videos on stimulus reflex, keep them coming!

@Chris, I know this episode is a little old, but this is still something I'm dealing with today.

I understand the rationale behind the move to get rid of jQuery in web apps: jQuery was from a time when we needed cross-browser compatability, when vanilla JS didn't provide functionality, that vanilla JS is now good and fast, etc...

And I agree with many of the points.

However, in almost evey project I've written in the last 2 years that doesn't use jQuery, one of the first things I find myself doing is writing a JS class that has a lot of helper functions that look very similar to jQuery.

This is easiest to see with dynamically appending elements to the document using something like Rails' <action>.js.erb format.

Writing this:

const fragment = document.createRange().createContextualFragment("<%= j render(partial: '...') %>")

document.querySelector("#some-selector").appendChild(fragment)

Seems a lot more painful than this:

$("#some-selector").append("<%= j render(partial: '...') %>")

I end up writing a class like the below where I throw in all my helper functions, essentially mimicking jQuery:

# JS helper class attached to window.Global (using webpack)
export default class Global {
  static append(selector, html) {
    const fragment = document.createRange().createContextualFragment(html)
    document.querySelector(selector).appendChild(fragment)
  }
}

I understand if someone is using a framework like React/Angular/VueJS then they wouldn'd use jQuery, but that's because they're using another framework which abstracts complexity.

Do you find that you and other developers are writing your own helper functions to abstract some of the complexity of vanilla JS away? How do you handle trying to write less code that is easier to maintain with the move away from jQuery?

After some more digging and some answers on SO, I realized I've been thinking that the way I did things in sprockets can transfer to webpacker, which is not true.

Sprockets essentially combines all my required JS files into a single file with a global namespace, which is why I could reference classes/functions right after they were required (thus the order of files mattered).

Webpacker also creates a single pack file of JS code (or as many packs as you have), but the pack is not a combined file of JS, but rather a combination of es6 modules, such that each module is completely namespaced and separate from others. Thus, to reference my Datepicker class in another es6 module, I have to manually import Datepicker from "datepicker_file" in each separate class (noting that webpacker will ensure only 1 copy of the JS code is actually included).

That means only the bare minimum of entry-level JS code needs to go in the webpacker pack files. For instance, if I use the environment.js ProvidePlugin to make jquery global, you don't actually need to require("jquery") in the pack file.

And since my Datepicker class includes the pikaday library, I don't need to add pikaday at all to my pack file because webpacker will eventually include pikaday because it's a dependency.

I think webpacker will be better overall when I finally understand it, but it is going to require a LOT of refactoring for several of my applications, because they were written on the assumption that if a file was required it was accessible in the global namespace.

@Chris,

Can you shed any light on how the require or import in the pack manifest file works?

Here's a real-life example from a project I'm upgrading to Rails 6 with webpacker to manage the assets.

I'm using the pikaday JS library for a calendar, wrapped with a Datepicker JS class (to make refactoring easier if I someday change the calendar library), and this class is used in a StimulusJS controller.

Because the controller file imports the Datepicker class, and the Datepicker class imports the Pikaday library, I don't need to import/require pikaday or my Datepicker in the application.js pack file at all, and I'm curious why that is?

Also, if I import Datepicker from "custom/datepicker" in the application.js pack file, why can't I reference Datepicker in other classes I import in the manifest, such as the controllers? Why do the controllers have to manually import Datepicker in order to reference it?

It seems like theres a lot of manually importing classes when I switched to webpacker...in the asset pipeline, I could reference these classes anywhere without having to manually import them all the time. Was it because they were somehow automatically being added to a global namespace?

I understand the principles behind avoiding over-populating the global namespace, but having to manually import every single class I want to use in every single file seems a little overkill. Have you happened upon anything that can help with this? (I've looked at webpacker's ProvidePlugin, and it doesn't seem to help with instantiating new classes, only if you're referencing the global itself, such as $ or jQuery).

app/javascript/packs/application.js

require("controllers") // loads the default index.js which loads all JS files in directory

app/javascript/controllers/assignment_form_controller.js

import { Controller } from "stimulus"
import Datepicker from "custom/datepicker"

export default class extends Controller {
  initialize() {
      new Datepicker(document.getElementById("some_id"))
    }
}

app/javascript/custom/datepicker.js

import Pikaday from "pikaday"

export default class Datepicker {
  constructor(element, options) {
    if (options == null) { options = {} }

    // Store DOM element for reference
    this.element = element

    // Do not re-run on elements that already have datepickers
    if (this.element.datepicker === undefined) {
      options = Object.assign({},
        this.defaultOptions(),
        options
      )

      const picker = new Pikaday(options)

      // Store picker on element for reference
      this.element.datepicker = picker

      return picker
    } else {
      console.log("Datepicker already attached")
      return
    }
  }

  // Overridden by `options` in constructor
  defaultOptions() {
    return {
      field: this.element,
      format: "M/D/YYYY",
      bound: true,
      keyboardInput: false,
      showDaysInNextAndPreviousMonths: true
    }
  }
}

I'm currently upgrading from Rails 5.2 to 6.0.1 and this gem was one of the blockers for me since it has a dependency on Rails 5.2. Really the only problem is that Rail's built-in store persists these values as strings and this gem typecasts the values for you. Once you handle that, you don't need this gem anymore and can write your own module or small gem.

See below for working version that doesn't use the gem. Obviously I haven't addressed null values and defaults, but those are fairly simple. Once I have a working module I may update this comment with the code so others can use it.

I don't think it's worth making a gem to add a few lines of code, so I tend to store something like this in a lib/modules/typed_store.rb file and then include TypedStore in my model file to use it.

Code from the typed_store gem (from my live project)

typed_store :recurring_rules, coder: DumbCoder do |s|
    s.integer :recurring_interval, default: 1, null: true
    s.string :recurring_frequency, default: "day", null: true
    s.integer :recurring_days, array: true, default: nil, null: true
    s.integer :recurring_day_of_month, default: nil, null: true
  end

Using built-in Rails store

If you're using PG with jsonb column types, you can use store_accessor directly and don't have to use the store method.

Just override the accessor methods to handle typecasting; that's also where you would handle defaults, nulls, etc...

store_accessor :recurring_rules,
    :recurring_interval,
    :recurring_frequency,
    :recurring_days,
    :recurring_day_of_month

  def recurring_interval
    super.to_i
  end

  def recurring_frequency
    super.to_s
  end

  def recurring_days
    super.to_a.map(&:to_i)
  end

  def recurring_day_of_month
    super.to_i
  end

I didn't even though about using the custom route names but then pointing them to separate controllers to keep the code clean. I got too stuck in the "all or none" mindset of only doing it one way.

Thanks for the input!

Chris,

These actions mostly touch the milestone model, but they update children associations (ie, when a milestone is activated, it's children task records are activated as well).

There is no separate Activation or Completion record, those were just names I gave to the actions I was taking on a milestone.

I also found that Github and Stripe both seem to use custom actions, so it made me feel a little better about moving to that approach.

Specifically with activate/deactivate, I have 10+ separate resources it can apply to, and it was much easier for me to remove those 10 separate controller files and just put the methods on the already-existing controllers.

It's always good to get input from folks in the community I look to for helping establish "best practices"!

I have a milestone resouce that can be activated/deactivated as well as completed/reopened.

Rails pushes the standard 7 actions in your controllers: index, new, create, show, edit, update, destroy.

These 7 actions work great for most things, but my use case didn't strictly fit into those 7 REST actions. I read an article a while back that some respected Rails developers follow REST conventions by creating resources such as:

• activate => POST /milestones/:id/activations
• deactivate => DELETE /milestones/:id/activations
• complete => POST /milestones/:id/completions
• reopen => DELETE /milestones/:id/completions

I used this approach for a while but I've found it to be difficult to work with.

It adds additional files, which sometimes leads to more complexity since there is now more to manage.

The biggest problem I encountered was it didn't make logical sense that the reopening of a milestone record was at the endpoint DELETE /milestones/:id/activations. It made more logical sense to me that it would be PUT /milestones/:id/reopen, since it is something we are doing to the milestone record.

I've been contemplating moving these non-standard actions to the milestones_controller.rb file itself and updating my routes accordingly.

I wanted to get some thoughts on these 2 different approaches and see how others had solved this problem of custom actions on resources?

Hey Chris,

I've noticed that some of your recent videos about testing are using Minitest.

What are your current thoughts on Minitest vs rspec? I've been a fan of rspec for many years, but I'm considering using Minitest instead, since it's built-in and is thus the default.

One of the big considerations for me to move to Minitest is the addition of integration tests (a while back), but since I haven't tried it out yet I'm not aware of any "gotchas" with Minitest.

I always look forward to your videos!

Hey Chris,

Awesome episode as usual! Few quick questions:

1. Since ActionText is storing a global_id reference to records in order to display the updated partial at render time, does that mean it's making a separate DB query to retrieve each of those records? For instance, if I @mention 10 separate users, will it make 10 separate calls? Especially if I'm creating a commenting system that allows @mentions, and there could be 10-20 comments, each with several @mentions, etc...
2. I notice you used Zurb Tribute for the @mention library; you've done an episode before using AtJs, any benefits to Tribute over AtJs, or just preference?

I really do like the concept of storing a reference to the partial instead of the hard-coded HTML. I'm actually in a situation where I stored the HTML snippets in the text itself and now want to change it, but am struggling with how to do that using the Froala editor. I'll eventually migrate to ActionText in a few months after Rails 6 has been vetted in the wild.

Always appreciate your timely and very applicable videos!

Chris, at the 3min mark you talk about using subdomains such as reply.gorails.com instead of the root gorails.com to process incoming emails.

What's the concern or downside of not using a subdomain? Is it to avoid situations where you have an email like admin@gorails.com that you do not want processed by the application?