DEV Community: Dale Zak

Advanced Heroku Settings For Rails

Dale Zak — Wed, 16 Feb 2022 18:51:33 +0000

Deploying your Rails app to Heroku is generally straight forward, however there's a lot of additional configuration needed to make sure things scalable and memory efficient. The following are some tips and recommendations on setting up your Rails app on Heroku.

Note, before setting these environment variables or adding the buildpacks, make sure you’ve first deployed your Rails app to Heroku. Adding these variables or buildpacks before can mess up the initial setup process.

Jemalloc Buildpack

jemalloc is a general purpose malloc implementation that works to avoid memory fragmentation in multithreaded applications. This buildpack makes it easy to install and use jemalloc on Heroku and compatible platforms.

You can add the jemalloc buildpack by running the following.

heroku buildpacks:add --index 1 https://github.com/gaffneyc/heroku-buildpack-jemalloc.git

Next you'll need to set the JEMALLOC_ENABLED environment variable on Heroku.

heroku config:set JEMALLOC_ENABLED=true

More information at elements.heroku.com/buildpacks/gaffneyc/heroku-buildpack-jemalloc.

Postgres Bouncer Buildpack

This is a Heroku buildpack that allows one to run pgbouncer in a dyno alongside application code. The primary use of this buildpack is to allow for transaction pooling of PostgreSQL database connections among multiple workers in a dyno.

Add the heroku-buildpack-pgbouncer buildpack by running.

heroku buildpacks:add https://github.com/heroku/heroku-buildpack-pgbouncer

Next, either add or update your Procfile, the below is assuming you are using Sidekiq.

web: bin/start-pgbouncer-stunnel bundle exec puma -C config/puma.rb
worker: bundle exec sidekiq -C config/sidekiq.yml

Important, in your config/database.yml ensure the following flags are set in your production environment.

advisory_locks: false
prepared_statements: false

More information at elements.heroku.com/buildpacks/heroku/heroku-buildpack-pgbouncer.

Set Rails Master Key

If you are using config/credentials.yml.enc, you'll need to set the RAILS_MASTER_KEY environment variable.

heroku config:set RAILS_MASTER_KEY=`cat config/master.key`

Change Service Timeout

You can specify request timeout by setting the RACK_TIMEOUT_SERVICE_TIMEOUT environment variable.

heroku config:set RACK_TIMEOUT_SERVICE_TIMEOUT=20

More information at devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server#timeout.

Set Sensible Defaults

If a Ruby application has the configuration variable SENSIBLE_DEFAULTS set, then the configuration variable WEB_CONCURRENCY will be defaulted to a value based on the dyno size.

heroku config:set SENSIBLE_DEFAULTS=enabled

More information at devcenter.heroku.com/changelog-items/618.

Enable Preboot

Preboot changes the standard dyno start behavior for web dynos. Instead of stopping the existing set of web dynos before starting the new ones, preboot ensures that the new web dynos are started (and receive traffic) before the existing ones are terminated. This can contribute to zero downtime deployments.

You can enable preboot functionality by running the following.

heroku features:enable preboot

More information at devcenter.heroku.com/articles/preboot.

Enable Runtime Heroku Metrics

To provide additional insights into memory health we offer optional language-specific runtime metrics. JVM, Go (public beta), Node.js (public beta), and Ruby (public beta) are currently supported.

heroku labs:enable "runtime-heroku-metrics"

More information at devcenter.heroku.com/articles/language-runtime-metrics.

Enable Ruby Language Metrics

To provide more visibility into the Ruby runtime, the Ruby language metrics feature surfaces additional language-specific time series metrics within Application Metrics. Ruby metrics include free and allocated heap object counts and number of free memory slots.

heroku labs:enable "ruby-language-metrics"

More information at devcenter.heroku.com/articles/language-runtime-metrics-ruby.

Set Ruby GC heap Growth Factor

When it comes to memory utilization you can control how fast Ruby allocates memory by setting RUBY_GC_HEAP_GROWTH_FACTOR. This value is different for different versions of Ruby. To understand how it works it is helpful to first understand how Ruby uses memory.

heroku config:set RUBY_GC_HEAP_GROWTH_FACTOR=1.03

More information at devcenter.heroku.com/articles/ruby-memory-use#gc-tuning.

Rails Autoscale Add-on

RailsAutoscale is one of the must have add-ons for Heroku. It lets you scale your web and worker dynos up and down based on queue time. So besides helping your application scale, it can also save you a lot or money.

More information at elements.heroku.com/addons/rails-autoscale.

Scout APM Add-on

Scout APM is another must have add-on for Heroku. It helps find N+1 queries, slow database queries, memory bloat and more.

More information at elements.heroku.com/addons/scout.

Choosing Your Dynos

I highly recommend you read How many Heroku dynos do you need, and which size—An opinionated guide from railsautoscale.com. Adam does a great job explaining and recommending different dyno types, as well as their ideal settings for scaling.

More information at railsautoscale.com/how-many-dynos/.

Heroku Commands

And finally some handy commands for Heroku.

Server Deploy git push heroku main
Server Logs heroku logs --tail
Server Restart heroku restart
Rails Console heroku run rails console
Postgres Info heroku pg:info
Postgres Diagnose heroku pg:diagnose
Maintenance On heroku maintenance:on
Maintenance Off heroku maintenance:off
Database Drop heroku pg:reset DATABASE
Database Migrate heroku run rake db:migrate
Database Seed heroku run rake db:seed

Are there other Heroku settings or optimization you like to make? I'd love to hear from you in the comments!

Bootstrap Modals Using Hotwire In Rails

Dale Zak — Wed, 16 Feb 2022 16:39:01 +0000

I recently implemented Bootstrap modals on RailsGems.com using Hotwire for showing Devise forms. However I ran into a few hurdles so wanted to share the lessons learned and the final implementation. 😎

One of my requirements was to show the modal by default, however when you open the link in a new tab it should still render the regular form inline. I really liked this fallback functionality, so let's see how I got it implemented.

However before diving in, I'd recommend reading How to build modals with Hotwire (Turbo Frames + StimulusJS) and Turbo Frames on Rails, both are excellent articles on using Hotwire. 😍

app/views/layouts/application.html.erb

You'll need to add an empty turbo_frame_tag with id modal to your application.html.erb. This is what we'll use to drop in the modal partial later.



<%= turbo_frame_tag "modal" %>

app/views/partials/_modal.html.erb

This partial is the Bootstrap modal, which takes title, body and footer locals, it also attached modal Stimulus controller.



<% 
  title ||= "Modal"
  body ||= ""
  footer ||= ""
%>
<div class="modal fade" tabindex="-1" data-controller="modal">
  <div class="modal-dialog">
    <div class="modal-content">
      <div class="modal-header">
        <%= tag.h5 title, class: "modal-title" %>
        <button type="button" class="btn-close" data-bs-dismiss="modal" aria-label="Close"></button>
      </div>
      <%= tag.div class: "modal-body" do %>
        <%= render body %>
      <% end if body.present? %>
      <%= tag.div class: "modal-footer" do %>
        <%= render footer %>
      <% end if footer.present? %>
    </div>
  </div>
</div>

Note, I wanted to pass multiple blocks to the partial, however couldn't find an elegant way to achieve this, so opted to simply pass the path to the partials.

app/helpers/application_helper.rb

Added a helper so it's convenient to render the partial in our views.



def render_modal(title: "", body: "", footer: "")
  render(partial: '/partials/modal', locals: { title: title, body: body, footer: footer })
end

app/javascript/controllers/modal_controller.js

This Stimulus controller handles auto showing the modal, removing the .modal-backdrop to avoid layering backdrops if we show another modal, plus removes the contents of the turbo_frame_tag after the modal has been hidden.



import {
  Modal
} from "bootstrap"
import {
  Controller
} from "@hotwired/stimulus"
export default class extends Controller {
  connect() {
    let backdrop = document.querySelector(".modal-backdrop");
    if (backdrop) {
      backdrop.remove();
    }
    this.modal = new Modal(this.element);
    this.modal.show();
    this.element.addEventListener('hidden.bs.modal', (event) => {
      this.element.remove();
    })
  }
}

app/controllers/application_controller.rb

Big thanks to David Colby for suggesting setting the variant for Turbo Frame requests, it works like magic! 🙌



before_action :turbo_frame_request_variant

def turbo_frame_request_variant
  request.variant = :turbo_frame if turbo_frame_request?
end

app/views/devise/sessions/new.html.erb

Nothing fancy here, just plain Bootstrap flavored card showing the sessions partial.



<div class="row">
  <div class="col-sm-10 col-md-8 col-lg-6 col-xl-4 offset-sm-1 offset-md-2 offset-lg-3 offset-xl-4">
    <div class="card mb-4">
      <div class="card-header">
        <h2 class="card-title">Sign in</h2>
      </div>
      <div class="card-body">
        <%= render "devise/sessions/new" %>
      </div>
      <div class="card-footer text-muted">
        <%= render "devise/shared/links" %>
      </div>
    </div>
  </div>  
</div>

app/views/devise/sessions/new.html+turbo_frame.erb

Because we set request.variant = :turbo_frame in the application_controller, Rails will automatically render this view if it's a Turbo Frame request, amazing! 😊



<%= turbo_frame_tag "modal" do %>
  <%= render_modal title: t('.sign_in'), body: "/devise/sessions/new", footer: "/devise/shared/links" %>
<% end %>

app/views/devise/sessions/_new.html.erb

The sessions partial which renders the login form, note I set data: { turbo: false } so it does a full post back when submitting the login form.



<%= form_for(resource, as: resource_name, url: session_path(resource_name), data: { turbo: false }) do |f| %>
  <div class="mb-3">
    <%= f.label :email, class: "form-label" %>
    <%= f.email_field :email, autofocus: true, autocomplete: "email", class: 'form-control' %>
  </div>
  <div class="mb-3">
    <%= f.label :password, class: "form-label" %>
    <%= f.password_field :password, autocomplete: "current-password", class: 'form-control' %>
  </div>
  <% if devise_mapping.rememberable? %>
    <div class="mb-3 form-check">
      <%= f.check_box :remember_me, class: 'form-check-input' %>
      <%= f.label :remember_me, class: 'form-check-label' %>
    </div>
  <% end %>
  <div class="mb-4 mt-4 text-end">
    <%= f.submit t('.sign_in'), class: "btn btn-primary" %>
  </div>
<% end %>

app/views/partials/_navbar.html.erb

When linking to new_user_session_path to login, it's important to set data: { turbo: true, turbo_frame: 'modal' }, this will set Hotwire know it's a Turbo Frame request.



<%= link_to "Sign In", new_user_session_path, data: { turbo: true, turbo_frame: 'modal' } %>

app/views/devise/shared/_links.html.erb

In your shared links for Devise, be sure to also set data: { turbo: true, turbo_frame: 'modal' }.



<%= link_to "Sign up", new_registration_path(resource_name), data: { turbo: true, turbo_frame: 'modal' } %>

And that's it! The login form should now be shown as a modal, however when you open the link in a new tab, it renders the regular inline form instead, which is nice fallback logic.

Also clicking the footer links for signup or forgot password, will also show those as modals, and thanks to our Stimulus controller it avoids multiple backdrops getting layer on top each other. 👍

You can checkout the full source code of RailsGems.com at github.com/dalezak/rails-gems. Enjoy!

Share The Gems You Love With RailsGems

Dale Zak — Tue, 15 Feb 2022 20:54:59 +0000

Have you ever wondered what gems other developers like to use? What about your favorite Rails developers, what gems do they like? I sure have!

That's why I built railsgems.com, an easy way to discover new gems, and share the gems you love.

You can browse gems sorted by the most liked. Or you can browse devs seeing the number of mutual gems you both like.

Getting started is easy, you can sign in via GitHub, or can create an account by email. Afterwards, just click the like button to start building a list of your favorite gems.

There are other sites out there like bestgems.org and ruby-toolbox.com, which are great for seeing statistics about gems like number of downloads, number of stars, etc.

However what makes railsgems.com different, is the ability to like gems and see related gems between you and other developers. Maybe you both like devise for authentication, but they prefer pundit where as you like cancancan for authorization.

I think you can gain some interesting insights here, and perhaps seeing these similar vs different gems might make you consider other options on your next project.

The project is open source, was scaffolded using Rails Blueprint, and build using Hotwire. If you have any feedback or suggestions, I'd love to hear from you!

Load More Pagination in Rails with Hotwire Turbo Streams

Dale Zak — Fri, 04 Feb 2022 13:58:15 +0000

Hotwire (aka HTML Over The Wire) is a great addition to Rails, allowing you to build modern web applications without using much JavaScript. However if you are just getting started, it can be tough to get your head around how Turbo Frames and Turbo Streams work.

In a recent project I have a grid of cards and wanted a Load More button to append the next set of cards to the grid. There are a few infinite scroll tutorials using Hotwire, but I ran into a few hiccups trying to make those work for my case.

For pagination I tend not to use gems like pagy or kaminari, instead implement this functionality just using limit and offset.

user_controller.rb

def index
  authorize! :index, User
  @search = params.fetch(:search, nil)
  @offset = params.fetch(:offset, 0).to_i
  @limit = [params.fetch(:limit, 12).to_i, 48].min
  query = User.for_search(@search)
  @users = query.limit(@limit).offset(@offset).order(created_at: :asc).all
  @users_count = query.count(:all) if request.format.html?
  respond_to do |format|
    format.html { }
    format.json { }
    format.turbo_stream { }
  end
end

In the controller I'm fetching @search, @offset, and @limit from the params, so I can use them in the views. The important line is format.turbo_stream { } so you can respond to turbo_steam requests.

index.html.erb

<div class="row row-cols-1 row-cols-md-2 row-cols-lg-3 row-cols-xl-4 g-4">
  <%= render partial: '/users/user', collection: @users, as: :user %>
  <div id="user_cards"></div>
</div>
<%= render partial: "/partials/load_more", locals: { count: @users_count, offset: @offset + @limit } %>

In the view, I'm using Bootstrap 5 Grid of Cards to handle responsive list of cards. Two important aspects in the view. One, the <div id="user_cards"></div> placeholder inside of the grid, we'll use Turbo Stream to replace this with the next set of cards. Two, rendering the load more partial passing the count and offset.

_user.html.erb

<div class="col">
  <div class="card h-100">
    <div class="card-body">
      <h5 class="card-title"><%= link_to user.name, user, data: { turbo_frame: "_top" } %></h5>
      <p class="card-text"><%= user.title %></p>
    </div>
  </div>
</div>

The user partial is just plain Bootstrap, although I opted to make all cards expand to fill their current row.

_load_more.html.erb

<% count ||= 0 %>
<% offset ||= 0 %>
<% url ||= url_for(request.params.merge(offset: offset)) %>
<% if count > offset %>
<div id="load_more" data-controller="turbo">
  <div class="d-grid my-4">
    <%= link_to "Load More", url, class: "btn btn-block btn-outline-secondary", data: { action: "click->turbo#getTurboSteam" } %>
  </div>
</div>
<% end %>

The load more partial has a full width Bootstrap button, but has three important elements. One, I default the url to the current URL updating the offset. So if the current path is users and the offset is 12, then the url will be users?offset=12 which will load the next set. Two, the if count > offset check will hide the load more button when there are no load results. Three, we're attaching a Stimulus action upon clicking the button, more on this below.

index.turbo_stream.erb

<%= turbo_stream.replace "user_cards" do %>
  <%= render partial: '/users/user', collection: @users, as: :user %>
  <div id="user_cards"></div>
<% end %>
<%= turbo_stream.replace "load_more" do %>
  <%= render partial: "/partials/load_more", locals: { total: @users.length, count: @users_count, offset: @offset + @limit } %>
<% end %>

In the Turbo Stream response, for the user_cards element we replace it with next set of cards plus the <div id="user_cards"></div> placeholder, so it works for the next offset. For the load_more element, we replace the partial with the new offset parameter.

At this point, I thought everything should work ok, however ran into one major hiccup. 😲

Currently, Hotwire only sends the text/vnd.turbo-stream.html header for POST requests, however my load button is making a GET request. 😩

One possible solution, is to add data: { turbo_method: :post } to the link_to that will turn it into a POST which triggers Hotwire to do its Turbo Stream magic. Another possible solution, is to change the link_to to a button_to which renders a form so the request by default will be a POST.

However I didn't want to go these paths, since my index route doesn't respond to POST requests. To make this work, I'd need to add post "search" route to all my resources, which would change the URL from users?offset=12 to users/search?offset=12. Not a terrible thing, but still preferred to just use the index route.

So rather than using button_to or data: { turbo_method: :post }, I instead used a Stimulus controller to append the text/vnd.turbo-stream.html header so that Hotwire handles it as a Turbo Stream request. 😎

turbo_controller.js

import { Controller } from "@hotwired/stimulus"
import { get, post } from '@rails/request.js'
export default class extends Controller {
  getTurboSteam(event) {
    event.preventDefault()
    get(event.target.href, {
      contentType: "text/vnd.turbo-stream.html",
      responseKind: "turbo-stream"
    })
  }
  postTurboSteam(event) {
    event.preventDefault()
    post(event.target.href, {
      contentType: "text/vnd.turbo-stream.html",
      responseKind: "turbo-stream"
    })
  }
}

In the Stimulus controller, the getTurboSteam will make a GET request with text/vnd.turbo-stream.html header, and the postTurboSteam makes POST request with text/vnd.turbo-stream.html header. In this case, we're using getTurboSteam but postTurboSteam is there if I need it later.

That's it, everything should be (hot)wired up! 👏

Big thanks to Konnor Rogers, Stephen Margheim, Marco Roth, Josh LeBlanc, Sean Doyle for helping debug this GET vs POST hiccup, the Rails community is awesome! 🙌

Rails Environment Variables Using Credentials

Dale Zak — Tue, 01 Feb 2022 13:34:54 +0000

In your Rails app, do you use ENV or Rails.application.credentials? Is there an easy way to use both? Lets find out.

I've been a long time fan of Figaro, a great gem that lets your store your environment variables in /config/application.yml. I've used it in most of my Rails apps for two reasons. One, it lets you easily define variables for your for development, staging, production environments. Two, it works well with Heroku since they also use ENV for storing and accessing environment variables, so things work the same locally while developing as well as after it's been deployed. However the downside with Figaro is that all your environment variables are exposed to the outside world, which is problematic if your repo is open source.

Rails.application.credentials helps solve this problem by encrypting your environment variables in config/credentials.yml.enc so they are only readable with the key providing a secure way to store them. However the downside, is your environment variables are now stored and accessed in two different ways, using Rails.application.credentials and ENV if you are also using Heroku.

It would be a lot more convenient, if you could define your variables in Rails.application.credentials so they are encrypted and secure, yet still access them using ENV so both local and remote environment variables are consistent.

You can do this easily by adding the following into /config/application.rb.

credentials.config.each do |key, value|
  if key.to_s == Rails.env
    value.each do |env_key, env_value|
      ENV[env_key.to_s.upcase] = env_value.to_s if ENV[env_key.to_s.upcase].blank?
      ENV[env_key.to_s.downcase] = env_value.to_s if ENV[env_key.to_s.downcase].blank?
    end
  elsif ['development', 'staging', 'test', 'production'].include?(key.to_s) == false
    ENV[key.to_s.upcase] = value.to_s if ENV[key.to_s.upcase].blank?
    ENV[key.to_s.downcase] = value.to_s if ENV[key.to_s.downcase].blank?
  end
end

Now you have the best of both worlds, security plus accessibility. You can now access all your environment variables via ENV whether they are defined in Heroku or in Rails.application.credentials.

ENV['HEROKU_APP_NAME'] # access Heroku defined variables
ENV['GITHUB_API_KEY'] # access variables from your credentials
ENV['git_api_key'] # also access variables in lowercase
ENV['rails_env_key'] # access environment specific variables

The snippet only sets the ENV if it's not already defined. It also handles global or environment specific variables in your Rails.application.credentials.

You can copy and paste the initializer above, or you can run the following template to add it to your project.

rails app:template LOCATION="https://railsbytes.com/script/Vp7s90"

A starter blueprint to help fast track a new Rails applications

Dale Zak — Fri, 07 Jan 2022 04:09:04 +0000

To help fast track setting up new Rails applications, I created a blueprint outlining steps for adding common functionality using some handy templates.

https://github.com/dalezak/rails-blueprint

To get started, simply clone the repo into a folder with the name of your application.

git clone https://github.com/dalezak/rails-blueprint.git my_app

Then move through the list in the README.md doing any of the sections your application needs, and skipping sections you don't need.

This is still a work in progress, so plan to add new sections as well as provide other options for existing sections. If there are sections you'd like to see, let me know.

Reusable Turbo-iOS Project Configured Entirely From Your Rails App

Dale Zak — Fri, 25 Jun 2021 04:54:46 +0000

Ever since I started building Rails app, I've dreamt about one day building mobile apps in Rails. Well, that day has finally arrived, thanks to Turbo-iOS!

With Turbo-iOS you can basically point an iOS app to your backend Rails app, it handles the native navbar functionality and pushing views however the content of those views is simply your backend web app.

Build high-fidelity hybrid apps with native navigation and a single shared web view. Turbo Native for iOS provides the tooling to wrap your Turbo 7-enabled web app in a native iOS shell. It manages a single WKWebView instance across multiple view controllers, giving you native navigation UI with all the client-side performance benefits of Turbo. - github.com/hotwired/turbo-ios

This is pretty amazing, however after playing with it a bit I soon discovered it still required a lot of custom Swift code and working in Xcode. For example if you wanted to show a tabbar in your app, or want to change your navbar colors. This is ok if you have some experience using Xcode and Swift, however it's a major barrier for everyone who hasn't used it before.

So this is why I created https://github.com/dalezak/turbo-ios-base, a Turbo-iOS base project that's driven entirely from your backend Rails app. Clone the project, follow the steps below and your iOS app will be driven entirely from your backend Rails app including navbar color, navbar buttons, tabbar color, tabbar tabs, triggering backend javascript and restricting functionality whether users are logged in or not.

I had five main goals for the Turbo-iOS Base Project:

reusable base project that can be pointed to any Rails app
app styling, tabs and navbar buttons driven from the server
handle both authenticated and unauthenticated users
all logic and functionality contained in a single Swift file
no need for other developers to write any Swift code

Disclaimer: It's been over six years since I've written anything in Objective-C, and I've never written any Swift prior to this project. So the code has lots of room for improvement, refactoring, cleanup, etc.

Important Note: This Turbo-iOS Base Project doesn't tie you to only using Turbo Frames. Although it should work well with it, you really can use whatever additional backend frameworks like Stimulus Reflex, etc. In fact, the app I built this for is using SR on the backend.

If you haven't already, I highly recommend you read the following articles about Turbo-iOS, they were all super helpful resources for me.

Clone Repo

Clone this repo locally to get started.

git clone https://github.com/dalezak/turbo-ios-base.git

Update Target Information

open App.xcodeproj
click on App project
select App under Targets
change Display Name to the name of your app
change Bundle Identifier to your reverse domain name

Update Info.plist URLs

open Info.plist file
expand TURBO_URL item
change development to your local environment
change production to your production environment

Replace Asset Images

visit https://appicon.co
upload 1024 x 1024 image
click Generate button
replace Assets.xcassets in the project with downloaded file

Add Turbo Gem

Add turbo-rails to your Gemfile.

gem "turbo-rails"

Add Turbo Javascript

If you are using Yarn, then run

yarn add @hotwired/turbo-rails

If you are using NPM, then run

npm add @hotwired/turbo-rails

Import Turbo Javascript

Add the following code to your application.js file.

import { Turbo } from "@hotwired/turbo-rails";
window.Turbo = Turbo;

Add any custom javascript to turbo/bridge.js in your javascript folder.

export default class Bridge {
  static sayHello() {
    document.body.innerHTML = "<h1>Hello!</h1>"
  }
}

Then import this in your application.js file.

import Bridge from "../turbo/bridge.js";
window.bridge = Bridge;

Add Rails Helpers

In your Rails app, add the following helpers to your application_helper.rb

def turbo?
  request.user_agent.include?("Turbo-")
end

def turbo_ios?
  request.user_agent.include?("Turbo-iOS")
end

def turbo_android?
  request.user_agent.include?("Turbo-Android")
end

Add Authenticated Header

Add the following metatag to your <head> so the app knows if a user is logged in or not.

<meta name="turbo:authenticated" content="<%= user_signed_in? %>">

Hide Page Navigation

Since Turbo-iOS handles the native navbar, you don't need to show your page navigation anymore. Add unless turbo? check around where you usually render your navbar in your Rails app.

<% unless turbo? %>
  <nav class="d-block">
    <%= render 'partials/navbar' %>
  </nav>
<% end %>

Add Turbo Controller

Add turbo_controller.rb which will return turbo.json used for rules and settings, here's a sample to get you started.

class TurboController < ApplicationController
  def index
    render json: {
      "settings": {
        "navbar": {
          "background": "#888888",
          "foreground": "#ffffff"
        },
        "tabbar": {
          "background": "#888888",
          "selected": "#ffffff",
          "unselected": "#bbbbbb"
        },
        "tabs": [
          {
            "title": "Home",
            "visit": "/",
            "icon_ios": "house",
            "protected": false
          },
          {
            "title": "Profile",
            "visit": "/profile",
            "icon_ios": "person",
            "protected": true
          }
        ],
        "buttons": [
          {
            "path": "/",
            "side": "left",
            "icon_ios": "line.horizontal.3",
            "script": "window.bridge.showMenu();",
            "protected": false
          },
          {
            "path": "/",
            "side": "right",
            "title": "Add",
            "visit": "/posts/new",
            "protected": true
          }
        ]
      },
      "rules": [
        {
          "patterns": [
            "/new$",
            "/edit$"
          ],
          "properties": {
            "presentation": "modal"
          }
        },
        {
          "patterns": [
            "/users/login"
          ],
          "properties": {
            "presentation": "modal"
          }
        },
        {
          "patterns": [
            "/users/logout"
          ],
          "properties": {
            "presentation": "replace"
          }
        }
      ]
    }
    end 
end

To see all the available iOS icons you can use for navbar buttons or tabbar icons, visit https://hotpot.ai/free-icons?s=sfSymbols.

Add Turbo Route

In your routes.rb add route pointing to turbo#index.

get 'turbo', to: "turbo#index", as: :turbo

Write Beautiful Ruby

And that's it! Everything should now be configured including the app colors, tabs, navbar buttons, etc which are all driven from the turbo.json returned from the turbo_controller.rb.

Now the app tabs and navbar buttons should appear according to the protected property if the user is authenticated or not. Your navbar buttons can either visit a page or trigger javascript on your server.

The best part is you shouldn't need to write any Swift code, so you can focus on your backend Rails application. This is something I've dreamt about ever since I first started using Rails, and it's now possible thanks to Turbo-iOS!

If you find this project useful or have suggestions on improvements, please let me know!

Git Aliases Are Like Superpowers

Dale Zak — Wed, 09 Jun 2021 04:32:51 +0000

Using Git Aliases can make you feel like you have superpowers!

It wasn’t until recently that I discovered Git Aliases, they are so handy that I seriously don’t know how I lived without them. These are two that I use every day now.

Git Add Commit Push

git config — global alias.add-commit-push '!git add -A && git commit -m "$1" && git push && git status'

Once the alias has been added you can now add, commit and push all on one line.

git add-commit-push "Add, commit, push in one line!"

Git New Branch

git config --global alias.new-branch '!git checkout -b "$1" && git add -A && git commit -m "$2" && git push -u origin "$1" && git status'

This alias adds, commits and pushes current changes to a new branch.

git new-branch "123-my-branch" "Checkout, add, commit, push!"

Checkout the Git documentation for other alias ideas. Enjoy!

GitHub Action to Attach Commits and Pull Requests to Trello Cards

Dale Zak — Tue, 27 Apr 2021 04:28:30 +0000

This GitHub Action lets you easily attach GitHub commits and pull requests to a Trello card simply by including the card number in your git commit message.

GitHub Issues is such a great tool for software development teams. However if the rest of your company is already using Trello, then you are faced with the decision whether to stick with Trello or switch to GitHub Issues.

The upside of sticking with Trello is that it’s already familiar for non-developers so it’s easy for other team members to submit bugs or feature requests. The downside of GitHub is the development team often works in a silo plus it adds another tool others need to become familiar with.

So for our team I decided to stick with Trello, however quickly noticed the disconnect between commits and Trello cards.

There are some GitHub Action out there that can mirror GitHub Issues to Trello Cards, however none really did want I wanted. So I ended up writing my own GitHub Action called GitHub-Commit-To-Trello-Card.

https://github.com/marketplace/actions/github-commit-to-trello-card

Here’s a sample of what the GitHub Action looks like.

name: GitHub Commit To Trello Comment

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - uses: dalezak/github-commit-to-trello-card@main
        with:
          trello-api-key: ${{ secrets.TRELLO_KEY }}
          trello-auth-token: ${{ secrets.TRELLO_TOKEN }}
          trello-board-id: ${{ secrets.TRELLO_BOARD }}
          trello-card-action: "Attachment"
          trello-list-name-commit: "Doing"
          trello-list-name-pr-open: "Reviewing"
          trello-list-name-pr-closed: "Testing"

And these are what each of the action variables are.

trello-api-key — Trello API key, visit https://trello.com/app-key for key
trello-auth-token — Trello auth token, visit https://trello.com/app-key then click generate a token
trello-board-id — Trello board ID, visit a board then append .json to url to find id
trello-card-action — Trello card action, either “Comment” or “Attachment”
trello-list-name-commit — Trello list name for new commit, for example “Doing”, “In Progress”, etc
trello-list-name-pr-open — Trello list name for open pull request, for example “Reviewing”, “In Review”, etc
trello-list-name-pr-closed — Trello list name for closed pull request, for example “Testing”, “Done”, etc

Now to use the action simply include the card number in the git commit message.

git add .
git commit -m "Added initial login form for #751"
git push

And voila! The commit message is magically attached to Trello card #751.

I also setup the action to automatically move cards between lists. For example, when a pull request is opened it can move a card to “Reviewing”, “In Review”, etc, and when the pull request is closed it can move the card to “Testing”, “Done”, etc according to the trello-list-name-pr-open and trello-list-name-pr-closed variables. Enjoy!

Rails Pattern For Including Nested Resources In API Responses

Dale Zak — Sat, 27 Mar 2021 13:49:29 +0000

This Rails pattern provides a flexible way for clients to specify whether they want nested resources includes in the API response simply by passing a flag as a parameter to the endpoint.

For example if you were building a simple blog, you would get Posts with Comments by calling posts.json?comments=true, however calling posts.json or posts.json?comments=false would return Posts without Comments.

posts.json?comments=false

posts.json?comments=true

This is incredibly powerful giving the client the flexibility to consume lighter weight responses by default or make less requests by including nested resources when needed.

The trick to avoid N+1 queries is to use a scope which calls includes(:comments) when the flag is true. To achieve this the Posts and Comments models would be something like this.

class Post < ApplicationRecord
 belongs_to :user, counter_cache: true
 has_many :comments, -> { order(created_at: :desc)}, inverse_of: :post, dependent: :destroy
 scope :with_comments, ->(include) { includes(:comments) if include.present? && include.to_bool }
end

class Comment < ApplicationRecord
 belongs_to :user, counter_cache: true
 belongs_to :post, counter_cache: true
end

The routes.rb would look something like the following.

Rails.application.routes.draw do
 resources :posts do
  resources :comments
 end
end

Your Posts controller would be as such.

class PostsController < ApplicationController
 def index
  comments = params.fetch(:comments, nil)
  @posts = Post.with_comments(comments).all
 end
end

Your _post.json.jbuilder would then look like the following.

json.extract! post, :id, :title, :body, :user_id, :created_at, :updated_at
if params.fetch(:comments, false).to_bool
 json.comments post.comments do |comment|
  json.partial! "comments/comment", comment: comment
 end
end

Finally I like to include the following to_bool.rb in my initializers so I can call to_bool throughout my code.

class Object
 def to_bool
  !!self
 end
end
class Integer
 def to_bool
  self == 1
 end
end
class String
 def to_bool
  if self == true || self =~ /(true|t|yes|y|1|on)$/i
   true
  elsif self == false || self.blank? || self =~ /(false|f|no|n|0|off)$/i
   false
  else
   false
  end
 end
end
class Symbol
 def to_bool
  self.downcase.to_s =~ /(true|t|yes|y|1|on)$/i
 end
end

I made the example overly simple so it was easy to follow, however this same pattern could be used for belongs_to resources or multiple has_many resources too.

It can also work with multiple level of nested resources. For example if you wanted to include User in the Posts and Comments, you would just need to add with_user scope to your models, update your controller to use this scope, then update your json.jbuilder to render User when the flag is set.

class Post < ApplicationRecord
 belongs_to :user, counter_cache: true
 has_many :comments, -> { order(created_at: :desc)}, inverse_of: :post, dependent: :destroy
 scope :with_user, ->(include) { includes(:user) if include.present? && include.to_bool }
 scope :with_comments, ->(include) { includes(:comments) if include.present? && include.to_bool }
end
class Comment < ApplicationRecord
 belongs_to :user, counter_cache: true
 belongs_to :post, counter_cache: true
 scope :with_user, ->(include) { includes(:user) if include.present? && include.to_bool }
end

In your Posts controller you’d need to call with_user scope.

class PostsController < ApplicationController
 def index
  user = params.fetch(:user, nil)
  comments = params.fetch(:comments, nil)
  @posts = Post.with_user(user).with_comments(comments).all
 end
end

Then update _post.json.jbuilder to include the User.

json.extract! post, :id, :title, :body, :user_id, :created_at, :updated_at
if params.fetch(:user, false).to_bool
 json.user post.user, partial: 'users/user', as: :user
end
if params.fetch(:comments, false).to_bool
 json.comments post.comments do |comment|
  json.partial! "comments/comment", comment: comment
 end
end

posts.json?comments=false&user=true

posts.json?comments=true&user=true

Just a note, if your nested resources have a lot of results, you may want to limit the number of resources being returned, for example only include the last 10 Comments.

json.extract! post, :id, :title, :body, :user_id, :created_at, :updated_at
if params.fetch(:comments, false).to_bool
 json.comments post.comments.limit(10) do |comment|
  json.partial! "comments/comment", comment: comment
 end
end

Or optionally use an integer instead of a boolean so you can pass the number of nested resources you’d like to receive. For example posts.json?comments=10 could return 10 most recent Comments.

I love this pattern because it doesn’t take a lot of work to setup in Rails yet still generates efficient queries but is incredibly flexible and powerful for the consuming client giving them the option to tailor the JSON responses based on their needs.

Would this pattern help your Rails project? Have you used a similar strategy before? I’d love to hear from you in the comments!

Using Tables In Quill.js With Rails and Stimulus

Dale Zak — Thu, 25 Mar 2021 15:45:13 +0000

This Stimulus controller will let you easily integrate Quill.js into your Rails project, including adding some missing table functionality.

I’ve used lots of different WYSIWYG editors in the past, most are clunky or produce messy HTML, but Quill.js is a pretty light weight option that actually works fairly well. The following will show how to use Stimulus to create a Quill editor as well as add some missing table functionality.

Add Quill Module

Note, the table module is only available in the upcoming 2.0.0 release, so you’ll need to add the latest dev version via yarn.

yarn add quill@2.0.0-dev.4

Or install it via npm.

npm install quill@2.0.0-dev.4

Create Quill Editor Partial

The partial has two important parts, the hidden field which will get updated via Stimulus so it can be submitted with the Rails form, and div container which will host the Quill editor that is initialized by Stimulus. It also is connecting Stimulus targets and actions.

<%= form.hidden_field :html, data: { quill: { target: "input" } } %>
<div style="min-height:500px;" data-quill-target="editor"></div>

Add Stimulus Controller

For the Stimulus controller, we have two targets editor and input so we can access both the hidden field as well as the div container.

In the connect method, we instantiate Quill passing in the theme and modules we’d like to use. Since we will be using the table feature, we enable that module. We also include the toolkit module passing in options for the buttons we want to show.

import ApplicationController from './application_controller';
import Quill from 'quill';
export default class extends ApplicationController {
 static targets = ["editor", "input"]
 connect() {
  this.quill = new Quill(this.editorTarget, {
   theme: 'snow',
   modules: {
    table: true,
    toolbar: [
     [{ header: [1, 2, 3, 4, 5, 6, false] }],
     ['bold', 'italic', 'underline'],
     [{ 'list': 'ordered' }, { 'list': 'bullet' }],
     [{ 'indent': '-1' }, { 'indent': '+1' }],
     [{ 'align': [] }],
     ['blockquote', 'link', 'image'],
     ['clean']
    ]
   }
  });
  this.quill.container.firstChild.innerHTML = this.inputTarget.value;
  this.quill.on('text-change', (delta, oldDelta, source) => {
   this.inputTarget.value = this.quill.container.firstChild.innerHTML;
  });
 }
 disconnect() {
  if (this.quill) {
   this.quill = null;
  }
 }
}

After instantiating Quill, we then set it’s content with the current value from the hidden field, this is important if you are editing an existing record that already has some content. Then we listen to the text-change event, setting the content from Quill back to the hidden field, so when the form is submitted the HTML content will get included.

And we should now have a working WYSIWYG editor!

Set Input Area Focusable

One issue I noticed was that clicking inside the input area does not always focus the control for typing. For example clicking the top area takes focus but clicking bottom area does not. So let's add Stimulus click action to set the focus.

<div style="min-height:500px;" data-quill-target="editor" data-action="click->quill#focus"></div>

focus() {
 this.quill.focus();
}

Add Table Functionality

The upcoming 2.0.0 release of Quill will have a table module, although currently there’s only a button for adding a table and no buttons for adding new rows or columns. So let’s add that functionality now.

In your toolbar options, add the following line which will show Quill’s table button as well as six of our own custom buttons.

['table', 'column-left', 'column-right', 'row-above', 'row-below', 'row-remove', 'column-remove']

Now inside your connect method, we get reference to the table module so we can call it later.

this.table = this.quill.getModule('table');

Next we connect the column-left button, including setting it’s icon to a SVG.

document.querySelectorAll('.ql-column-left').forEach(button => {
 button.innerHTML = '<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16" fill="currentColor" class="bi bi-caret-left-square" viewBox="0 0 16 16"><path d="M14 1a1 1 0 0 1 1 1v12a1 1 0 0 1-1 1H2a1 1 0 0 1-1-1V2a1 1 0 0 1 1-1h12zM2 0a2 2 0 0 0-2 2v12a2 2 0 0 0 2 2h12a2 2 0 0 0 2-2V2a2 2 0 0 0-2-2H2z"/><path d="M10.205 12.456A.5.5 0 0 0 10.5 12V4a.5.5 0 0 0-.832-.374l-4.5 4a.5.5 0 0 0 0 .748l4.5 4a.5.5 0 0 0 .537.082z"/></svg>'
 button.title = "Add column left";
 button.addEventListener('click', () => {
  this.table.insertColumnLeft();
 });
});

Now the same for the column-right button.

document.querySelectorAll('.ql-column-right').forEach(button => {
 button.innerHTML = '<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16" fill="currentColor" class="bi bi-caret-right-square" viewBox="0 0 16 16"><path d="M14 1a1 1 0 0 1 1 1v12a1 1 0 0 1-1 1H2a1 1 0 0 1-1-1V2a1 1 0 0 1 1-1h12zM2 0a2 2 0 0 0-2 2v12a2 2 0 0 0 2 2h12a2 2 0 0 0 2-2V2a2 2 0 0 0-2-2H2z"/><path d="M5.795 12.456A.5.5 0 0 1 5.5 12V4a.5.5 0 0 1 .832-.374l4.5 4a.5.5 0 0 1 0 .748l-4.5 4a.5.5 0 0 1-.537.082z"/></svg>';
 button.title = "Add column right";
 button.addEventListener('click', () => {
  this.table.insertColumnRight();
 });
});

Now the row-above button.

document.querySelectorAll('.ql-row-above').forEach(button => {
 button.innerHTML = '<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16" fill="currentColor" class="bi bi-caret-up-square" viewBox="0 0 16 16"><path d="M14 1a1 1 0 0 1 1 1v12a1 1 0 0 1-1 1H2a1 1 0 0 1-1-1V2a1 1 0 0 1 1-1h12zM2 0a2 2 0 0 0-2 2v12a2 2 0 0 0 2 2h12a2 2 0 0 0 2-2V2a2 2 0 0 0-2-2H2z"/><path d="M3.544 10.705A.5.5 0 0 0 4 11h8a.5.5 0 0 0 .374-.832l-4-4.5a.5.5 0 0 0-.748 0l-4 4.5a.5.5 0 0 0-.082.537z"/></svg>';
 button.title = "Add row above";
 button.addEventListener('click', () => {
  this.table.insertRowAbove();
 });
});

Next the row-below button.

document.querySelectorAll('.ql-row-below').forEach(button => {
 button.innerHTML = '<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16" fill="currentColor" class="bi bi-caret-down-square" viewBox="0 0 16 16"><path d="M3.626 6.832A.5.5 0 0 1 4 6h8a.5.5 0 0 1 .374.832l-4 4.5a.5.5 0 0 1-.748 0l-4-4.5z"/><path d="M0 2a2 2 0 0 1 2-2h12a2 2 0 0 1 2 2v12a2 2 0 0 1-2 2H2a2 2 0 0 1-2-2V2zm15 0a1 1 0 0 0-1-1H2a1 1 0 0 0-1 1v12a1 1 0 0 0 1 1h12a1 1 0 0 0 1-1V2z"/></svg>'
 button.title = "Add row below";
 button.addEventListener('click', () => {
  this.table.insertRowBelow();
 });
});

Now the row-remove button.

document.querySelectorAll('.ql-row-remove').forEach(button => {
 button.innerHTML = '<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16" fill="currentColor" class="bi bi-dash-square" viewBox="0 0 16 16"><path d="M14 1a1 1 0 0 1 1 1v12a1 1 0 0 1-1 1H2a1 1 0 0 1-1-1V2a1 1 0 0 1 1-1h12zM2 0a2 2 0 0 0-2 2v12a2 2 0 0 0 2 2h12a2 2 0 0 0 2-2V2a2 2 0 0 0-2-2H2z"/><path d="M4 8a.5.5 0 0 1 .5-.5h7a.5.5 0 0 1 0 1h-7A.5.5 0 0 1 4 8z"/></svg>';
 button.title = "Remove row";
 button.addEventListener('click', () => {
  this.table.deleteRow();
 });
});

Finally the column-remove button.

document.querySelectorAll('.ql-column-remove').forEach(button => {
 button.innerHTML = '<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16" fill="currentColor" class="bi bi-x-square" viewBox="0 0 16 16"><path d="M14 1a1 1 0 0 1 1 1v12a1 1 0 0 1-1 1H2a1 1 0 0 1-1-1V2a1 1 0 0 1 1-1h12zM2 0a2 2 0 0 0-2 2v12a2 2 0 0 0 2 2h12a2 2 0 0 0 2-2V2a2 2 0 0 0-2-2H2z"/><path d="M4.646 4.646a.5.5 0 0 1 .708 0L8 7.293l2.646-2.647a.5.5 0 0 1 .708.708L8.707 8l2.647 2.646a.5.5 0 0 1-.708.708L8 8.707l-2.646 2.647a.5.5 0 0 1-.708-.708L7.293 8 4.646 5.354a.5.5 0 0 1 0-.708z"/></svg>';
 button.title = "Remove column";
 button.addEventListener('click', () => {
  this.table.deleteRow();
 });
});

That’s it, you now have ability to add a table, add columns, add rows, remove columns and remove rows!

The icons don't perfectly match but you can easily change those icons to whatever SVGs you'd prefer instead.

Note, the console will show some warnings for your custom buttons, like quill:toolbar ignoring attaching to nonexistent format column-left. Hopefully when Quill.js 2.0.0 is released, it will include these toolbar buttons as options, but in the meantime you can still use this functionality. Enjoy!

You can find the full solution at https://gist.github.com/dalezak/834198114f414a79de355e0c2cb664d3.

Using CanCanCan With StimulusReflex In Your Rails App

Dale Zak — Tue, 23 Mar 2021 04:52:49 +0000

If you are using CanCanCan for authorization and also want to use the magic of StimulusReflex for reactive page updates, these strategies will help you check user abilities in your reflexes.

CanCanCan is a powerful authorization library that allows you to authorize! the current_user for an action, as well as restrict records only accessible_by their current_ability.

def index
 authorize! :index, Classroom
 @classroom = Classroom.accessible_by(current_ability)
end

Once you start using StimulusReflex, you’ll soon need to utilize the accessible_by in your reflexes to only obtain records permitted for the current_user as well. The following are strategies how to do this for both selector morphs and page morphs.

Selector Morphs With CanCanCan

For selector morphs, you have two options for using CanCanCan’s accessible_by in your reflex.

Option 1: create new ability for user

First delegate the current_user to your connection, then create a new ability passing that into the accessible_by call.

class ClassroomsReflex < ApplicationReflex
 delegate :current_user, to: :connection
 def change_school
  if element.value.present?
   user_ability = Ability.new(current_user)
   school = School.find(element.value)
   classrooms = school.classrooms.accessible_by(user_ability).order(:name)
  else
   school = nil
   classrooms = []
  end
  morph “#classrooms”, render(partial: “/classrooms/classrooms”, locals: { school: school, classrooms: classrooms })
 end
end

Option 2: delegate current_ability to controller

Another technique is to delegate the current_ability from the controller, passing that into the accessible_by call.

class ClassroomsReflex < ApplicationReflex
 delegate :current_ability, to: :controller

 def change_school
  if element.value.present?
   school = School.find(element.value)
   classrooms = school.classrooms.accessible_by(current_ability).order(:name)
  else
   school = nil
   classrooms = []
  end
  morph “#classrooms”, render(partial: “/classrooms/classrooms”, locals: { school: school, classrooms: classrooms })
 end
end

Note, one of the reasons selector morphs are faster than page morphs is because they don’t need to instantiate the controller. This means that the above will increase the response time adding 10–25ms hit on every reflex. So Option 1 is recommended when possible, although there might be some scenarios where this is still useful.

Page Morphs With CanCanCan

For page morphs, you can not delegate current_ability to the controller, due to the fact that both StimulusReflex and CanCanCan instantiate the controller internally. This causes an issue with the instance variables set in your reflex always being nil in the controller afterwards. So you have two options for page morphs instead.

Option 1: create new ability for user

Similar to the selector morph, you can delegate to current_user, then create a new ability and pass it into accessible_by.

class ClassroomsReflex < ApplicationReflex
 delegate :current_user, to: :connection

 def change_school
  if element.value.present?
   user_ability = Ability.new(current_user)
   @school = School.find(element.value)
   @classrooms = @school.classrooms.accessible_by(user_ability).order(:name)
  else
   @school = nil
   @classrooms = []
  end
 end
end

Option 2: move accessible_by calls to controller

Another option is to move the accessible_by calls out of the reflex and into the controller. This is not a very StimulusReflex-y way, although there are some scenarios where this could suffice so still worth noting.

class ClassroomsReflex < ApplicationReflex
 def change_school
  if element.value.present?
   @school = School.find(element.value)
  else
   @school = nil
  end
 end
end

class ClassroomsController < ApplicationController
 def index
  authorize! :index, School
  authorize! :index, Classroom
  @school ||= School.find(params[:school_id)
  @schools ||= School.accessible_by(current_ability).order(:name)
  @classrooms ||= @school.present? ? @school.classrooms.accessible_by(current_ability).order(:name) : []
 end
end

Model Based CanCanCan Abilities

If you’ve transitioned to using separate abilities per model, then the good news is Option 1 will work even better for you!

class ClassroomsReflex < ApplicationReflex
 delegate :current_user, to: :connection

 def change_school
  if element.value.present?
   classroom_ability = ClassroomAbility.new(current_user)
   @school = School.find(element.value)
   @classrooms = @school.classrooms.accessible_by(classroom_ability).order(:name)
  else
   @school = nil
   @classrooms = []
  end
 end
end

In this case, rather than creating abilities for all models you are only creating abilities for the Classroom model. This can especially help if you are using _ids queries in your abilities, since those other abilities won’t be executed. If you are interested in separate abilities per model, I’d recommend reading Lazy Load CanCanCan Abilities In Rails.

For more information regarding using CanCanCan with StimulusReflex, visit authentication section on the official documentation.

Big thanks to @theleastbad, @RogersKonnor and @marcoroth_ for helping debug the issues I was having using CanCanCan with StimulusReflex, which was the source of these above strategies. 🙏