DEV Community: Jacob Daddario

Disable-With Using StimulusJS

Jacob Daddario — Fri, 03 Sep 2021 23:08:12 +0000

DHH recently announced that Hotwire is going to be included in Rails 7 by default. Due to its incompatibility with Hotwire, Rails UJS is going to slowly be phased out of Rails. This affects more than just JS views and remote forms. It will also remove Rails’ disable UJS along with method on link tags and confirm. Thankfully, a simple implementation of disable can be re-created using Stimulus.

The tricky part of recreating the disable behavior is getting the interface to be as clean as the original. I actually opened a PR regarding a disable controller earlier this year, and the man himself said as much about the interface (I embarrassingly left the PR stale after getting swept up in my last semester of college).

A major problem was getting the assignment to be a one-liner. The implementation I made a PR with required the manual assignment of targets and actions.

I disliked the idea of manually assigning event listeners in the controller because this made it possible to leave them stranded outside the lifecycle of the Stimulus controller. My hope was that I could find a part or the Stimulus interface that allowed me to programmatically create an action. After some digging through the source code of Stimulus, I came to the conclusion that the only public interfaces in the library were the mutation observers and callbacks to those observers in other classes. As far as I can tell, Sam tried to keep the surface area of the library so small that this was the only entry-point.

With that backstory out of the way, I’ll begin explaining the disable_controller with the connect method.



import { Controller } from "stimulus"

export default class extends Controller {
  connect() {
    this.element.dataset['action'] = 'submit->disable#disableForm'
  }
}

Written this way, the connect method interacts with Stimulus seemingly the only way that we can, through data attributes. Actions are added to the parent element when the controller connects. The actions listen for a submit event, so this controller is only suitable for forms right now. Regardless, this allows us to achieve the one-liner behavior of the original library.

We can now add custom disable values by leveraging the Values API.



export default class extends Controller {
  static values = { with: String }

  connect() {
    this.element.dataset['action'] = 'submit->disable#disableForm'

    if (!this.hasWithValue) {
      this.withValue = "Processing..."
    }
  }
}

We even get a little syntactical sugar since the markup for our value will read disable-with-value in our markup. Plus, the custom default values allowed in Stimulus v3 will allow the new line in the connect method to be removed as well.

Now we can move to writing the action triggered by the submit event.



export default class extends Controller {
  static values = { with: String }

  connect() {
    this.element.dataset['action'] = 'submit->disable#disableForm'

    if (!this.hasWithValue) {
      this.withValue = "Processing..."
    }
  }

  disableForm() {
    this.submitButtons().forEach(button => {
      button.disabled = true
      button.value = this.withValue
    })
  }

  submitButtons() {
    return this.element.querySelectorAll("input[type='submit']")
  }
}

The code is fairly simple, it finds all of the submit inputs in the form, and it disables them. Then it replaces their text. Using a query selector isn’t super Stimulus-esque, but it helps maintain that one-liner interface for the controller.

Now the controller needs to be dropped in on the desired form. Thanks to what happens in the connect method, it takes just a one-liner to hook everything up.



<%= form_with model: registration, data: { controller: "disable", "disable-with-value": "Signing up..." } do |f| %>
  <div>
    <%= f.label :name %>
    <%= f.text_field :name %>
    <%= render "shared/error", record: registration, attribute: :name %>
  </div>
  <div>
    <%= f.label :email%>
    <%= f.email_field :email %>
    <%= render "shared/error", record: registration, attribute: :email %>
  </div>

  <%= f.submit class: "disabled:cursor-not-allowed" %>
<% end %>

And here's the result! A nice little one-liner that can be dropped in on forms in order achieve a bit of Rails magic that's incompatible with Hotwire.

With all that said, there's a couple of obvious problems with this implementation. I considered working these out before writing about this disable controller, but I decided that it would be best to get this out here first and solicit feedback from the community to see what advice people offer.

The first problem relates to Hotwire's frames and streams. In its current incarnation, this implementation works fine with frames that replace the context that the form is in. Where this falls flat is with frames that target other contexts and streams.

I think that this should be easily rectifiable by listening for the relevant Turbo events, but I won't have time to explore this until the Labor Day weekend.

The second problem is that this controller does not cover all of the applications that the original does. For instance, I believe this should work on a button that is properly dropped into a form. Where this won't work is on isolated buttons and links. The buttons should be easy to add functionality for, but I'm torn about the links.

So I wanted to pitch out a question to community members for that. Should link tags be able to be disabled? The disabled property is not native to links, and the original Rails UJS implementation uses custom attributes to track all this. Particularly, it uses JavaScript to intercept and cancel click events on link tags.

My intuition is that this goes against the spirit of "progressive enhancement" that is part of Hotwire. I'd like to hear your thoughts though, so let me know down in the comments of this post.

HEY-inspired Pop-ups Using Hotwire

Jacob Daddario — Wed, 28 Jul 2021 20:35:38 +0000

Disclaimer: It should be noted that the provided HTML fails to implement the necessary ARIA attributes required for accessibility. These attributes will need to be added to any implementation of this markup in order to be accessible to screen readers.

Anyone who's used Basecamp's email service, Hey.com, has probably noticed the technique they use for lazy-loading their menus.

Basecamp uses details and summary tags in order to achieve a pop-up behavior with native HTML. They use this in conjunction with a fancy Stimulus controller which seems to add a src attribute to the revealed turbo-frame. This loads in the menu asynchronously without having to manually manage AJAX requests.

Thanks to some additions to Turbo during its development, a slightly different approach can be used to achieve a similar result while omitting the complex popup-menu controller.

Although this solution omits the use of Basecamp's popup-menu controller, it still uses the two-part punch of StimulusJS and Turbo.

The first important element of this setup is the use of a toggle controller.

import { Controller } from "stimulus"

export default class extends Controller {
  static targets = [ "toggled" ]
  static classes = [ "toggle" ]

  toggle(event) {
    event.preventDefault()
    // Unblurring focused target if there is one
    if (event.target) {
      document.activeElement.blur()
    }

    this.toggledTargets.forEach(
      (toggled) => toggled.classList.toggle(this.toggleClass)
    )
  }
}

It's worth mentioning that much of this toggle code was lifted from Matt Swanson's excellent article on composing behaviors using StimulusJS. I highly recommend giving it a read if you haven't already.

This controller allows for a style to be toggled on elements when a given action occurs. In this case, it's used to toggle the visibility of our pop-up menu.

<div data-controller="toggle" data-toggle-toggle-class="hidden" class="relative">
  <%= button_to "#", data: { action: "click->toggle#toggle" } do %>
    Invite Member
  <% end %>
  <div data-toggle-target="toggled" class="hidden absolute top-10 right-0">
    <%= turbo_frame_tag "your-popup" do %>
      <div>
        <span>Loading...</span>
      </div>
    <% end %>
  </div>
</div>

The toggle controller is added to the HTML markup of a div containing a turbo-frame. When the button is clicked, the toggle action of the controller is triggered in order to make the div containing the turbo-frame visible.

This is where Turbo comes into play and a feature added to Turbo during its time in beta, lazy-loading based on visibility, can be used. First a controller action should be added that returns a turbo-frame matching the id of the turbo-frame that's in the HTML loaded with the toggle controller.

class ResourceController < ApplicationController
  def new
    @resource = Resource.new
  end
end

<%= # resources/new.html.erb %>
<%= turbo_frame_tag "your-popup" do %>
  <div>
    <%= # Your menu/form/content goes here %>
  </div>
<% end %>

In addition to this, we will have to add the special loading="lazy" attribute as well as a src attribute to the first turbo-frame.

<div data-controller="toggle" data-toggle-toggle-class="hidden" class="relative">
  <%= button_to "#", data: { action: "click->toggle#toggle" } do %>
    Invite Member
  <% end %>
  <div data-toggle-target="toggled" class="hidden absolute top-10 right-0">
    <%= turbo_frame_tag "your-popup", src: new_resource_path, loading: :lazy do %>
      <div>
        <span>Loading...</span>
      </div>
    <% end %>
  </div>
</div>

This ensures that when the pop-up is first toggled open, it will load the turbo-frame rendered by the new action. Every subsequent toggle will just reveal the already loaded pop-up. Without the use of the loading="lazy" attribute, the pop-up would be loaded after the initial page load regardless of its visibility. In that way, the loading="lazy" attribute provides the secret sauce that allows use to circumvent the use of the more-complex controller used by Basecamp in Hey.

Once fully styled, here's how the implementation could look for a form.

Let me know if you found this article helpful, and leave any suggestions for improvement below in the comments!