DEV Community: Mike Rogers ✈️

Moving From Tailwind To Vanilla-er CSS

Mike Rogers ✈️ — Wed, 12 May 2021 18:24:48 +0000

I've been playing around with Tailwind CSS a lot since it's release, and so far it's been really impressive to see its growth over the last few years, along with some of the neat things people are making with it.

Overall I've been pretty happy with it, I even purchased a licence for Tailwind UI to help me develop with it more quickly. However, sometimes I find myself a little frustrated at it, so I decided it would be fun to rebuild the frontend on my Ruby Calendar project to see if I can pinpoint my annoyances.

What I love about Tailwind CSS

The documentation! Seriously Adam Wathan done a fantastic job with it. Often when I just want to check how to do something in plain CSS, I use their documentation as a reference point.
Responsive utility variants are very cool. Being able to apply a CSS class to just big screens by using lg: before my class names is super lovely!
Using @apply within my regular CSS. It feels like such a concise way to write CSS, I'm a big fan of it.
Less context switching between CSS & HTML files. I didn't realise how much cognitive load I had from jumping between different file types all day. Being able to just look at a single file for everything I was working on helped me get into that awesome "hyper focus" zone a lot more easily.
The examples I can copy & paste (which look the same in my project), is a massive time saver. It feels like I can very quickly cobble together a frontend MVP for a project without too much effort.

What I don't love

Preflight. I always find it's super aggressive, this is probably because I come from a background where I've used normalize.css a lot. Having to setup base styling for semantic HTML feels tedious.
JavaScript Dependencies. I had a project on Tailwind V1 which used React, which I upgraded to V2. Unfortunately I had an out of date library which made upgrading harder then I expected. In the end, I was deep in JavaScript code trying to figure out why my CSS wasn't working. It made me feel super unproductive.
Other developers use it inconsistently. I've picked up a few projects using Tailwind, and it takes a lot time to feel "at home" in the codebase. In one project, I felt like the other developer just used every class everywhere, which made it very hard to achieve that "Happy Developer" moment.
CSS Purging. I've been caught out in the past by setting up the purging, then moving a few files around to only discover I quietly broken a few pages in production. I think better CI tooling could solve this, but I'm also feeling I'd rather avoid the risk to start with.
Staying visually consistent. I'm the worst for using all the sizing & colour variants available to me, I need a limitations to avoid making an inconsistent monster.

Replacing it with vanilla-er CSS

My plan was to remove Tailwind over a weekend, using a mix of normalize.css, CSS Variables & mixins, all combined into a single CSS file using PostCSS.

I had already started converting my CSS to follow the BEM approach using @apply, so I was able to take my purged CSS & break it into smaller files. I then went through and moved all the things like spacing, fonts & colours I was using into CSS Variables.

Why vanilla-er CSS?

I wanted to be as close to simple vanilla CSS as possible, the reason is I worked on a project which hadn't had the styling touched in about 5 years, and then when I edited the styles.css file...it just changed what I expected it to. It was a really interesting "Oh? Would you look at that!" type experience.

Obviously, I do like a few low touch tools to help reduce duplication. But I do want to aim for a codebase where in 5 years time, it'll be easy to pickup. I think the best way to do that is by keeping things as simple as possible.

Naming CSS Variables

Naming was pretty hard! For my fonts & spacing, I ended up copying the approach of using numbered a scale which is often used in Tailwind.

/* variables/fonts.css */

:root {
  --fonts-serif: ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont,
    'Segoe UI', Roboto, 'Helvetica Neue', Arial, 'Noto Sans', sans-serif,
    'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol', 'Noto Color Emoji';

  --font-size-1: 0.75rem;
  --font-size-2: 0.875rem;
  --font-size-3: 1rem;
  --font-size-4: 1.125rem;
  --font-size-5: 1.25rem;
  --font-size-6: 1.5rem;
  --font-size-7: 1.875rem;
}

/* variables/spacing.css */

:root {
  --spacing-1: 0.25rem;
  --spacing-2: 0.5rem;
  --spacing-3: 0.75rem;
  --spacing-4: 1rem;
  --spacing-5: 1.25rem;
  --spacing-6: 1.5rem;
}

Naming Colours

Naming the colours was a tad harder. I've never been a fan of calling a variable "blue", then making it the colour blue. The reason is often in the future that "blue" may end up not being blue, which makes things messy.

Instead I copied the approach of Bootstrap of having "Primary", "Secondary" & "Tertiary" colours, however I explicitly named the variables to hint that the colour is intended to be used as a background or text.

/* variables/colours.css */

:root {
  --background-primary: #3c2aaa;
  --background-secondary: #1d2938;
  --background-secondary-lightest: #3f4a5b;
  --background-secondary-light: #232c39;
  --background-secondary-dark: #0f192c;
  --background-tertiary: #d0d5dc;
  --background-tertiary-light: #ffffff;

  --text-primary: #f9fafb;
  --text-primary-darker: #a1a1ab;

  --link-primary: #c5d1ff;

  --border-primary: #273241;
}

I did also add *-light & *-dark variations of these colours (For use within hovers & whatnot), though I do want to come back and improve the suffixes I chose.

Ideally I want to achieve variable names which make other developers say out loud "This is so obvious, I know exactly what this is for". If anyone has any ideas please let me know :)

Media Queries

I wanted a way to pre-define the common screen sizes I'd use when building out my responsive designs.

To solve this I used postcss-preset-env, which allowed me to define a "custom-media" with the name --viewport-lg and the value (min-width: 1024px). As postcss-preset-env also supported nested CSS this allowed for some pretty readable CSS.

/* components/footer.css */

.footer {
  padding: var(--spacing-4);
  padding-bottom: var(--spacing-6);
  text-align: center;

  @media (--viewport-lg) {
    text-align: left;
    grid-template-columns: repeat(2, minmax(0, 1fr));
  }
}

Mixins

Pretty soon I did feel like I was duplicating CSS & mixing utility classes with my semantically named classes within my HTML.

However, I found the solution was to use mixins via postcss-mixins.

/* mixins/list-inline.css */

@define-mixin list-inline {
  list-style: none;
  margin-left: calc(var(--spacing-2) * -1);
  margin-right: calc(var(--spacing-2) * -1);
  padding: 0;

  > li {
    display: inline-block;
    padding: 0 var(--spacing-2);
  }
}

/* components/navbar.css */

/**
 * @markup
 *  <ul class="navbar__links">
 *    <li><a href="/groups">All Groups</a></li>
 *    <li><a href="/add-event">Add Event</a></li>
 *  </ul>
 */
.navbar__links {
  @mixin list-inline;
  margin-top: 0;
  margin-bottom: 0;
  display: none;

  @media (--viewport-md) {
    display: block;
    margin-left: auto;
  }
}

This allowed me to have semantic looking class names which included common CSS snippets, while being able to override things as required. It also gave me the potential to programmatically generate a styleguide from the comments within my CSS file, which I'm wildly excited about.

Easier Importing

As my project grew, I found I could glob import files via postcss-import-ext-glob, which made my index.css file much more maintainable:

/* index.css */

@import-glob "variables/*.css";

/* External Libraries imported from node_modules */
@import-glob 'normalize.css';

@import-glob "base/*.css";
@import-glob "components/*.css";
@import-glob "utilities/*.css";

Final Thoughts

Overall, I'm very happy with this CSS & HTML approach. I can look at a snippet of HTML, see the CSS classes being used & know exactly which files I need to edit to change them. I feel very in control of the CSS I'm writing as a result of that.

While reviewing my new HTML & CSS, I really like that I'm not staring at a wall of CSS class names any more. Plus if I wanted to make any changes to the colours, spacing or fonts, I feel confident that I won't need to change lots of files to see the desired visual change. Instead I can open the variables/ folder, then the appropriately named file & edit just a few lines of CSS.

I also found the final size of the generated CSS was about the same as before, so I'm very happy with that.

I did come to appreciate how much time Tailwind had saved me while I was prototyping my design (and how it made me think more in a component mindset), but I think it's also a very sharp tool which requires a lot of discipline to use effectively on projects.

Finally, I think I'd still be happy to work on a Tailwind based project. However, I totally feel a bit more confident in saying "We could just use CSS Variables & Mixins instead if we wanted".

How To Handle Special Actions In Ruby on Rails Controllers?

Mike Rogers ✈️ — Fri, 19 Mar 2021 00:00:00 +0000

Imagine you have a table called crops in your database, which contains a column named harvested_at. You'd like to allow a user to click a button to change the value of this button from NULL to the current time.

Pretty simple right? I'm pretty sure you can think of a few ways to do this. I'm going to focus on how you should approach this at the controller level, as I've never seen a consistent solution to how the controllers should be setup.

In this post I'm going to go through the approaches you might discover in the wild and explore which option is the best. I'm going to write my examples in Ruby, but this is applicable to other languages.

Approaches

RESTful actions over custom actions

For this approach we'd create a nested controller which would extend from a parent controller, thus inheriting all the setup (e.g. setting the @crop value from the id parameter) for each action type.

# app/controllers/crops/harvests_controller.rb
class Crops::HarvestsController < CropsController
  # CropsController has a before_action for setting @crop
  # for the update method which we inherit.

  # PATCH /crops/1/harvest
  def update
    @crop.touch(:harvested_at)

    redirect_to crop_path(@crop)
  end
end

I really like this approach as it keeps controllers fairly standardised. The other advantage is if we want to add any authorisation for this action, we could just add it & we'd have a high level of confidence it wouldn't affect any other user stories.

It's also how Basecamp & Cookpad encourage writing their controllers, so that does give this approach a nice dash of credence.

The only downside to this approach is I often can't decide whether to use create or update. In the above example, I used update as I was updating the @crop model, however I could also technically be creating a "Crop Harvest" event so create would be more suitable.

RESTful actions over custom actions (With concerns)

This is an alternative to the above approach, instead of inheriting from CropsController, you can inherit from ApplicationController and then use a concern to share the setup logic.

# app/controllers/concerns/crop_scoped.rb
module CropScoped
  extend ActiveSupport::Concern

  included do
    before_action :set_crop
  end

  private

  def set_crop
    @crop = Crop.find(params[:crop_id])
  end
end

# app/controllers/crops/harvests_controller.rb
class Crops::HarvestsController < ApplicationController
  include CropScoped

  # PATCH /crops/1/harvest
  def update
    @crop.touch(:harvested_at)

    redirect_to crop_path(@crop)
  end
end

I saw DHH Tweet about this approach back in 2014. I've never worked with it in production, but I think it's a pretty cool approach.

The only drawback to this approach is you may need to explicitly set the resource parameter in the routes & it that could be a bit messy if the parameter is reused, but I do like it.

Custom actions

This is a pretty common pattern and I've used it a few times in the past. Pretty much, you just add an extra method in your controller & hook it up to a route.

# app/controllers/crops_controller.rb
class CropsController < ApplicationController
  before_action :set_crop, only: [:edit, :update, :delete, :destroy, :harvested]

  # PATCH /crops/1/harvested
  def harvested
    @crop.touch(:harvested_at)

    redirect_to crop_path(@crop)
  end
end

It's ok, but not great. What I've found is as more & more custom actions are added to your controller, the more you'll need to jump around the file to understand what is truly going on.

The end result of using this approach is you'll end up with lots of very long controllers, which will each behave very inconsistently in comparison to each other.

Single Resource Controllers

In this approach, all your resources will only get basic CRUD actions & nothing else, all handled by a single controller for each resource.

So to set our harvested_at field, we'd submit a form with just the one field set as a parameter, then handle it using the same method we'd use for when the user is updating other fields via a different form.

<!-- app/views/crops/show.html.erb -->
<%= button_to "Harvest Crop", crop_path(@crop), method: :patch, form: { crop: { harvested_at: Time.zone.now } } %>

# app/controllers/crops_controller.rb
class CropsController < ApplicationController
  # PATCH /crops/1
  def update
    if @crop.update(crop_params)
      redirect_to crop_path(@crop)
    else
      render :edit
    end
  end

  private

  def crop_params
    params.require(:crop).permit(:name, :description, :harvested_at)
  end
end

This is my least favourite approach, whenever I see it I usually just want to set fire to all the code. It's unspecific, which I think will lead to fragile code.

For example, if an exception occurred within my update method, it could be a large number of actions the user was performing which got them to that code. This would make debugging the exception a much slower experience.

Furthermore, it could render the test code coverage metric unreliable. A developer may not realise our harvested_at use case doesn't have a test around it, but we could have 100% code coverage due to another loosely related test touching that line of code. This could lead to a lack of confidence in the application test suite.

It's also really easy for a developer to forget about adding authorisation, and a user to adjust the value of a field mischievously with this approach.

Which one is best?

I really like the "RESTful actions over custom actions" approach the most. I'm pretty confident that it leads to code which is quite easy to reason about, and write specific tests around.

Persist Scroll Positions with Hotwire Turbo

Mike Rogers ✈️ — Wed, 03 Mar 2021 17:20:43 +0000

Persisting the scroll position of an element is a nice way to keep users not get lost on your website. In this tutorial I go through how to implement a persisted scroll position using Hotwire Turbo.

We do this by hooking into the lifecycle events of Hotwire Turbo, then cache the current scroll position of each element we want to persist.

<!--
src/_components/navbar.liquid

We added the "data-turbo-permanent" attribute to this element, along with a unique ID.
-->
<nav class="navbar__nav" data-turbo-permanent id="navbar">
  {% for i in (1..10) %}
    <ul>
      <li>Item {{i}}</li>
      <ul>
        <li><a href="/">Home</a></li>
        <li><a href="/about/">About</a></li>
        <li><a href="/posts/">Posts</a></li>
      </ul>
    </ul>
  {% endfor %}
</nav>

// frontend/javascript/turbo-scroll.js
// This JavaScript saves the scroll position of each element with the "data-turbo-permanent" attribute.
// When the next page is renders, we restore the scroll position.
(function(){
  var scrollPositions = {};

  addEventListener("turbo:before-render", function(){
    document.querySelectorAll("[data-turbo-permanent]").forEach(function(element){ 
      scrollPositions[element.id] = element.scrollTop;
    });
  });

  addEventListener("turbo:render", function(){
    document.querySelectorAll("[data-turbo-permanent]").forEach(function(element){ 
      element.scrollTop = scrollPositions[element.id];
    });
  });
})();

How To Encrypt Fields in Ruby on Rails with Lockbox

Mike Rogers ✈️ — Tue, 09 Feb 2021 17:27:18 +0000

If you're storing any sensitive data such as API Keys, or personal data you should probably be encrypting it within your database. A fantastic gem to do this with is lockbox.

While the best defence against losing sensitive data is to not save it in the first place, you may have a scenerio where you require it later on. From this perspective, it's ideal to make sure you make it as hard for the evil people as possible.

Examples of data you might want to consider encrypting are:

API Credentials, for example the tokens you receive from an OAuth request.
Email & Postal Address
Personally Identifiable Information (PII)

The code

Start by generating a key using Lockbox.generate_key, store the results as the ENV LOCKBOX_MASTER_KEY.

# .env
LOCKBOX_MASTER_KEY="Generate with Lockbox.generate_key"

Create a migration for the field you'd like to encrypt. Once you've decided on the accessor, append _ciphertext to that name.

class AddApiKeyCiphertextToPosts < ActiveRecord::Migration[6.1]
  def change
    add_column :posts, :api_key_ciphertext, :text
  end
end

Lastly, use the encrypts magic within your model to give you a setter & getter which stores its value in that *_ciphertext column as an encrypted value.

# app/models/post.rb
class Post < ApplicationRecord
  # Stored in api_key_ciphertext but encrypted 🤯
  encrypts :api_key
end

Fixing "sqlite3 gem which is not supported on Heroku"

Mike Rogers ✈️ — Sun, 31 Jan 2021 15:21:38 +0000

When I first tried to deploy my Ruby on Rails app to Heroku, I ran into a really annoying error which said:

Failed to install gems via Bundler.
Detected sqlite3 gem which is not supported on Heroku:
https://devcenter.heroku.com/articles/sqlite3

The solution, was to change my apps database to use Postgres instead of Sqlite3. In rails there in a terminal command you can run which will do this for you:

$ bundle exec rails db:system:change --to=postgresql

But why do I have to do this?!

Heroku uses an Ephemeral filesystem, which means anything you write to disk won't be persisted between instances of you app. This makes a lot of sense for as you start scaling your app up & need multiple machines to handle requests. But as a result, it's best to treat your apps filesystem as if it's read-only.

The issue is Sqlite3 writes your database to disk, on your local dev machine it's probably stored in db/development.sqlite3. If you had to sync that file between multiple servers running your app, it would be really hard!

So instead we use Postgres which lives on another machine in Heroku world & can share easily offer shared access between multiple instances of our app.

Review Emails with ActionMailer::Preview

Mike Rogers ✈️ — Sun, 24 Jan 2021 20:40:58 +0000

Rails is one of my favourite frameworks, I think because it ships with a little known feature called ActionMailer::Preview, which I really want every Rails developer to know about :D

It renders your mailers & lets your preview them in the browser, which means if you want to tweak some code or totally redesign it, you can just visit http://127.0.0.1:3000/rails/mailers on your local development machine & get building.

Code Sample

# spec/mailers/previews/user_mailer_preview.rb
# Preview all emails at http://localhost:3000/rails/mailers
class UserMailerPreview < ActionMailer::Preview

  def user_welcome_notification
    UserMailer.user_welcome_notification(user)
  end

  private

  def user
    @user ||= FactoryBot.build(:user)
  end
end

FactoryBot For Sample Data

I used to use User.first as the starting point for my sample data, but I think a better approach is to use the FactoryBot factories. The main advantage is it encourages me to write better factories & increases the value for money they offer.

Resize Images with Active Storage in Rails

Mike Rogers ✈️ — Wed, 06 Jan 2021 14:48:45 +0000

We used to have to use gems like Carrierwave & Paperclip to upload files & manipulate images in Ruby on Rails. However we now have a fantastic library built into Rails called Active Storage which handles that for us.

Setting up Active Storage

The first thing you need to do is run the install script, which will create a migration to add the Active Storage tables to your database.

$ rails active_storage:install
$ rails db:migrate

Uploading a file

All Active Storage upload need to be connected to a model. To tell rails "We'd like to have a method called avatar on this model, which is a file attachment" we use the method has_one_attached method like this:

class Post < ApplicationRecord
  has_one_attached :avatar

  validates :title, presence: true
end

From there, we can pass a file object to that field & it'll save to the database.

Resizing an Image

The awesome thing about Active Storage, is we can create new versions of an image on the fly. This means Rails won't perform the resize until the user requests that image, and after the transformation is complete it will cache the results for future use.

The documentation is a little unclear as to what options as can passed into the variant method, but I found the arguments link to the methods found on the ImageProcessing::MiniMagick Documentation.

Here is a cheat sheet I put together for transforming images:

<!-- Change the format of the image -->
<%= image_tag @post.avatar.variant(format: :jpg) %>

<!-- Rotate the image 45° -->
<%= image_tag @post.avatar.variant(rotate: [45, background: '#0F0']) %>

<!-- Saver - compress the image -->
<%= image_tag @post.avatar.variant(saver: { quality: 10 }) %>

<!--
  resize_and_pad: Image will be resized to 500x500 while keeping the original aspect ratio.
  Any remaining space (e.g. if the image was originally 50x10, so will scale up to 500x100) will be filled in with the colour we pick in 'background'
  We use Gravity to define where the left over space will be, so "north" will anchor the original image at the top of the new resized image.
-->
<%= image_tag @post.avatar.variant(resize_and_pad: [500, 500, gravity: 'north', background: '#000']) %>

<!--
  Resizes the image to fill the specified dimensions while retaining the original aspect ratio.
  If necessary, will crop the image in the larger dimension.
-->
<%= image_tag @post.avatar.variant(resize_to_limit: [500, 500]) %>

<!--
  Resize the image to fit within the specified dimensions while retaining the aspect ratio of the original image.
-->
<%= image_tag @post.avatar.variant(resize_to_fill: [500, 500, gravity: 'north']) %>

<!--
  Resizes the image to fit within the specified dimensions while retaining the original aspect ratio.
  Will downsize the image if it's larger than the specified dimensions or upsize if it's smaller.
-->
<%= image_tag @post.avatar.variant(resize_to_fit: [500, 500]) %>

References

How To Setup A Secondary Archive Account On GitHub

Mike Rogers ✈️ — Mon, 04 Jan 2021 11:53:33 +0000

If you're anything like me, you probably have a GitHub account where you've collected a lot of repositories over time, most of which you probably won't update any time soon.

You probably also want to make you sure GitHub profile is an amazing example of your best work, where a potential employer isn't going to be distracted by an old irrelevant project.

To solve this, I setup a GitHub Organisation specifically for my projects which I probably won't maintain (it's @mikerogers0-youtube if you want to see it in action). It's nothing fancy, just an account where I can store stuff which is a bit out of the way.

It was really cool to do, so I wanted to share how I done it encase anyone else wanted to do the same :D

Automating It With Ruby

Manually moving the repos felt laborious, so I wrote a script in Ruby to use the GitHub API semi-automate it:

# Run: gem install octokit
require 'octokit'

## Generate a token at:
# https://github.com/settings/tokens
# 
# Make sure it has a scope of:
# - Full control of private repositories 
#
# Put the token in here:
PERSONAL_ACCESS_TOKEN = ""

## The account name you're going to transfer things off to:
NEW_ACCOUNT_NAME = "MikeRogers0-YouTube"

# Connect to GitHub
client = Octokit::Client.new(access_token: PERSONAL_ACCESS_TOKEN, auto_paginate: true)

# Load all the repos in the users account
repositories = client.repositories(client.user.login)

# Filter the list of repos you're going to transfer
repositories.select! do |repository|
  ## Options include:
  # repository.fork?
  # repository.private?
  repository.name.include?('Sample')
end

# Tell us what repos we're about to move
puts "You're going to transfer:"
puts repositories.collect(&:full_name)

# This stopped me accidentally breaking everything, remove the
# "return" line to actually perform the transfers.
puts 'Remove the next line to perform the change:'
return

# Start transferring the accounts to the new account
repositories.each do |repository|
  client.transfer_repository(repository.full_name, NEW_ACCOUNT_NAME, {
    accept: Octokit::Preview::PREVIEW_TYPES[:transfer_repository]
  })
end

It took me a few tries to get my filters about right, but once I was happy with the repositories I was transferring I removed the return line & let it do the transfer.

I got a bunch of emails confirming the repos had been moved, but overall it took a few seconds to transfer everything.

What happened next?

After I transferred everything, I was worried I'd have to update a bunch of old links online, but I noticed GitHub made 301 redirects from my old projects to the new ones. This was awesome!

I feel really positive about having a digital clean out, I'd totally encourage everyone to consider it :D

Inline Editing With turbo_frame_tag (hotwire-rails)

Mike Rogers ✈️ — Tue, 29 Dec 2020 17:22:24 +0000

One of my favourite Single Page Application (SPA) tricks is allowing the user to edit something (like a comment) without having to leave the page they're on, a little bit like on Reddit.

Using the turbo_frame_tag helper from the hotwire-rails gem, I was able to achieve this in about 4 lines of code! I also didn't have to touch any JavaScript or change my existing controller code.

The code

<!-- app/views/comments/_comment.html.erb -->
<%= turbo_frame_tag dom_id(comment) do %>
  <blockquote>
    <%= comment.body %>

    <footer>
      <%= link_to 'Edit', [:edit, comment.post, comment] %> | <%= l comment.updated_at, format: :long %>
    </footer>
  </blockquote>
<% end %>

<!-- app/views/comments/edit.html.erb -->
<h1>Editing Comment</h1>

<%= turbo_frame_tag dom_id(@comment) do %>
  <%= render 'form', comment: @comment %>
<% end %>

<%= link_to 'Show', url_for([@comment.post, @comment]) %> |
<%= link_to 'Back', url_for([@comment.post]) %>

How does the tag work?

The turbo_frame_tag helper method will wrap your block of code in a <turbo-frame id="comment_1"> tag (which is like a div, but magic!).

When a link within that tag is clicked, Turbo will perform an AJAX type request to the requested page looking for a <turbo-frame> tag with a matching ID, if it finds one, it'll replace the content with the new content.

Real-Time Partial Updates in Ruby on Rails using hotwire-rails

Mike Rogers ✈️ — Tue, 22 Dec 2020 23:17:55 +0000

The hotwire-rails was just released today by Basecamp. It's a collection of JavaScript & Ruby libaries which allows for making some pretty rich user experiences.

The big thing I like, was how easy it is to create real-time partials in Ruby on Rails.

Now we just the need code:

# app/models/post.rb
class Post < ApplicationRecord
  # We're going to publish to the stream :posts
  # It'll update the element with the ID of the dom_id for this object,
  # Or append our posts/_post partial, to the #posts <tbody>
  broadcasts_to ->(post) { :posts }
end

Then within the views, having:

<!-- app/views/posts/index.html.erb -->
<%= turbo_stream_from :posts %>

<table>
  <thead>
    <tr>
      <th>Title</th>
      <th>Body</th>
      <th colspan="3"></th>
    </tr>
  </thead>

  <tbody id="posts">
    <%= render @posts %>
  </tbody>
</table>

<!-- app/views/posts/_post.html.erb -->
<tr id="<%= dom_id post %>">
  <td><%= post.title %></td>
  <td><%= post.body %></td>
  <td><%= link_to 'Show', post %></td>
  <td><%= link_to 'Edit', edit_post_path(post) %></td>
  <td><%= link_to 'Destroy', post, method: :delete, data: { confirm: 'Are you sure?' } %></td>
</tr>

How to Make Rails Work Offline (PWA)

Mike Rogers ✈️ — Mon, 14 Dec 2020 17:45:00 +0000

I've been experimenting a lot lately with allowing Ruby on Rails to work offline, by this I mean having a sensible fallback for when the network unexpectedly drops out (e.g. the user is underground on a train).

The main way to achieve this is by making our app a Progressive Web App (PWA) via a Service Worker. In the past I've always associated PWA's with Single Page Applications and having to have a very JavaScript heavy codebase. However with tools such as Webpacker, we can add a Service Worker while keeping a traditional Ruby on Rails application approach (i.e. server side rendering & Turbolinks).

Screencasts

I've put together a few screencasts so you can see everything in action.

What is a service worker?

A Service Worker is a JavaScript file you serve to the browser, which will intercept future network requests to your website. The result is you can control how a request will react if the network is down, or if you want to always serve requests from the cache.

Service Worker Limitations

When researching this topic, I found Service Workers do have some drawbacks you should be aware of:

The URL of your service worker must stay the same (e.g. /service-worker.js), so it can be tricky to get it working with the Asset Pipeline & Webpacker.
If you serve your service worker from a different port (i.e. via bin/webpacker-dev-server) it won't intercept HTTP requests as you'd expect.
The amount of data you can cache is pretty varied between browsers & devices. I'd recommend keeping your usage under 25MB.

Libraries

Service Workers have been around a few years, as a result there is quite a few libraries which make them a lot easier to work with. Here is a quick summary of the main ones to know about.

The serviceworker-rails Gem

The serviceworker-rails gem will work pretty nicely for most use cases, it works with the Asset Pipeline (Sprockets) & has a very nifty generator for automated setup.

The only downside of this approach is because it's using the Asset Pipeline, it defaults to a verbose vanilla JavaScript approach. This makes using the new libraries out there which can cut down some of the boilerplate a little tricky.

webpacker-pwa library

One of the biggest drawbacks with webpack is it's quite tricky to configure if you're not working with it regularly. The webpacker-pwa library makes adding the extra configuration a lot easier.

The awesome result of this library, is you can write your service workers JavaScript in modern JS, then it'll be served from your /public directory from a file that doesn't have a content hash.

Workbox

The vanilla Service Worker JavaScript is pretty verbose. While I was initially exploring approaches to allowing Rails to work offline, I was finding the JavaScript was getting pretty hard to explain.

Then I was shown Workbox, which allows the Service Worker JavaScript to be boiled down to something more concise:

// app/javascript/service_workers/service-worker.js
import { registerRoute } from 'workbox-routing';
import { NetworkFirst, StaleWhileRevalidate, CacheFirst } from 'workbox-strategies';
import { CacheableResponsePlugin } from 'workbox-cacheable-response';
import { ExpirationPlugin } from 'workbox-expiration';

// Loading pages (and turbolinks requests), checks the network first
registerRoute(
  ({request}) => request.destination === "document" || (
    request.destination === "" &&
    request.mode === "cors" &&
    request.headers.get('Turbolinks-Referrer') !== null
  ),
  new NetworkFirst({
    cacheName: 'documents',
    plugins: [
      new ExpirationPlugin({
        maxEntries: 5,
        maxAgeSeconds: 5 * 60, // 5 minutes
      }),
      new CacheableResponsePlugin({
        statuses: [0, 200],
      }),
    ],
  })
);

// Load CSS & JS from the Cache
registerRoute(
  ({request}) => request.destination === "script" ||
  request.destination === "style",
  new CacheFirst({
    cacheName: 'assets-styles-and-scripts',
    plugins: [
      new ExpirationPlugin({
        maxEntries: 10,
        maxAgeSeconds: 60 * 60 * 24 * 30, // 30 Days
      }),
      new CacheableResponsePlugin({
        statuses: [0, 200],
      }),
    ],
  })
);

I think this JavaScript is very approachable compared to the library free approach.

Strategies

There are 3 main approach for caching and serving content which I settled on using.

NetworkFirst

This is kind of the best default choice for any page which might change between page loads.

As the name hints, it'll try to request the resource from the webserver (caching it if it's successful), or falling back to its cached copy if the server is unreachable.

CacheFirst

This is the best choice for assets such a CSS, JavaScript & Images.

This approach will initially request the file, then cache the response. For subsequent requests it'll serve the cached file.

StaleWhileRevalidate

This is the quirky option! It serves the cached content, but then in the background it'll make a request to the server to update its cache.

Eager-Caching Assets

It's possible to preload assets into your cache. You can do this from within your service-worker.js, however I found I'd reach for mixing ERB & JavaScript when I took this approach. Instead I eager-cached my assets by parsing my DOM when the service worker was registered:

// app/javascript/service_workers/index.js
if ('serviceWorker' in navigator) {
  window.addEventListener('load', function() {
    navigator.serviceWorker.register('/service-worker.js', { scope: "/" })
      .then(function(registration) {
        console.log('[ServiceWorker Client]', 'registration successful with scope: ', registration.scope);

        registration.addEventListener('updatefound', function() {

          // Cache a few popular pages ahead of time.
          caches.open('documents').then(function(cache) {
            let links = document.querySelectorAll('a[href^="/"]:not([rel="nofollow"])');
            cache.addAll( Array.from(links).map(elem => elem.getAttribute("href")) );
            cache.addAll( [document.location.pathname] );
          });

          // Cache all the CSS & JS assets on the page.
          caches.open('assets-styles-and-scripts').then(function(cache) {
            let stylesheetLinks = document.querySelectorAll('link[rel="stylesheet"][href^="/"]');
            cache.addAll( Array.from(stylesheetLinks).map(elem => elem.getAttribute("href")) );

            let scriptLinks = document.querySelectorAll('script[src^="/"]');
            cache.addAll( Array.from(scriptLinks).map(elem => elem.getAttribute("src")) );
          });
        });

      }, function(err) {
        console.log('[ServiceWorker Client]','registration failed: ', err);
      });
  });
}

I didn't make a video on this approach as I wasn't able to validate anyone else doing it, but I did like it.

Conclusions

After I added a Service Worker to my Rails app, it was able to fallback to a read-only view when the network was down, This was pretty awesome! Especially as I didn't have to change any of my standard "Rails rendering the HTML" & Turbolinks making things feel a bit snappier approach.

I think most apps could benefit from a Service Worker being added for the small performance win it can offer, plus I think having a read-only fallback for if your server is unreachable a pretty cool trick.

One thing I didn't figure out, is how to detect if a response was returned from the cache on the current page, i.e. to show the user a notification saying "Hey, you're offline".

Is reset_column_information a code smell?

Mike Rogers ✈️ — Sun, 01 Nov 2020 20:50:00 +0000

If you've worked with Ruby on Rails you've probably written a migration at some point that made use of the reset_column_information method. It's often used when you're intending to tweak some data around the table or column you've just modified.

What's wrong with using it?

Migrations should only concern themselves with changing the structure of the database. Once they start add or removing data they will become super flaky, which will lead to a scenario where new developers are unable to run bin/setup (or rails db:setup) when setting up a project. Instead they'll be forced to use a database provided to them, often this will be a backup of production (which is a big data leak risk).

What should you look out for?

Lets say you create a model called JobLevel & populate some data e.g:

class CreateJobLevels < ActiveRecord::Migration[6.0]
  def up
    create_table :job_levels do |t|
      t.string :name
    end

    JobLevel.reset_column_information
    JobLevel.create(name: 'executive')
    JobLevel.create(name: 'manager')
  end
end

The big "oh no" aspect of this, is you're now requiring every future developer to run this migration to populate the job_levels table in their database. If a developer doesn't run the migration, they'll have to find another way to add the data. Furthermore if the validation around the name field changes, the developer won't be able to run from a blank slate.

Here is another example which is quite common, but also problematic:

class AddEnabledToJobLevels < ActiveRecord::Migration[6.0]
  def up
    add_column :job_levels, :enabled, :boolean, default: false, null: false
    JobLevel.reset_column_information
    JobLevel.update_all(enabled: true)
  end
end

In both examples, if the JobLevel model was renamed the migration would be unable to run again.

What are the better approaches?

SQL via `execute`

Using the execute method you can run arbitrary SQL during your migrations, e.g:

class AddEnabledToJobLevels < ActiveRecord::Migration[6.0]
  def up
    add_column :job_levels, :enabled, :boolean, default: false, null: false
    execute('UPDATE job_levels SET enabled = TRUE')
  end
end

I really like this as they run with the constraints of the database at the point of the migration, instead of the current to the state of the app. So if I was to delete the JobLevel model, I'd still be able to re-run this migration in the future.

Seeds!

One thing I've started to quite like doing is during a release running migrations, then running the seeds. I like it because it means my development & production can both have their required data be setup in the same way, which encourages writing decent seeds e.g:

# db/seeds.rb

# Seed all the job levels, if it exists it won't add a new one.
JobLevel.find_or_create_by!(name: 'manager')

Why put unchanging data in the database?

To really get the dev/prod parity down to zero, I've started thinking about if some bits of data belong in the database at all & if they'd be better of as Plain Old Ruby Objects e.g.

JobLevel = Struct.new(:name, :enabled, keyword_init: true) do
  alias enabled? enabled

  def self.find(name)
    all.find { |job_level| job_level.name == name }
  end

  def self.all
    @all ||= [
      new(name: 'executive', enabled: true),
      new(name: 'manager', enabled: true),
    ]
  end
end

This approach is my favourite because instead of querying the database with a piece of unchanging data, we can just store it in memory. Plus it comes with a strong grantee that it'll be the same across all environments.

So is reset_column_information a code smell?

I think so! I think it's an indicator of "The next few lines of code are going to bite you in the future", and in most cases there is a more reliable approach which can be taken.

While I don't think a Rubocop warning is suitable, I am going to try to avoid using it going forward.

DEV Community: Mike Rogers ✈️

Moving From Tailwind To Vanilla-er CSS

What I love about Tailwind CSS

What I don't love

Replacing it with vanilla-er CSS

Why vanilla-er CSS?

Naming CSS Variables

Naming Colours

Media Queries

Mixins

Easier Importing

Final Thoughts

How To Handle Special Actions In Ruby on Rails Controllers?

Approaches

RESTful actions over custom actions

RESTful actions over custom actions (With concerns)

Custom actions

Single Resource Controllers

Which one is best?

Persist Scroll Positions with Hotwire Turbo

How To Encrypt Fields in Ruby on Rails with Lockbox

The code

Fixing "sqlite3 gem which is not supported on Heroku"

But why do I have to do this?!

Review Emails with ActionMailer::Preview

Code Sample

FactoryBot For Sample Data

Resize Images with Active Storage in Rails

Setting up Active Storage

Uploading a file

Resizing an Image

References

How To Setup A Secondary Archive Account On GitHub

Automating It With Ruby

What happened next?

Inline Editing With turbo_frame_tag (hotwire-rails)

The code

How does the tag work?

Real-Time Partial Updates in Ruby on Rails using hotwire-rails

How to Make Rails Work Offline (PWA)

Screencasts

What is a service worker?

Service Worker Limitations

Libraries

The serviceworker-rails Gem

webpacker-pwa library

Workbox

Strategies

NetworkFirst

CacheFirst

StaleWhileRevalidate

Eager-Caching Assets

Conclusions

Is reset_column_information a code smell?

What's wrong with using it?

What should you look out for?

What are the better approaches?

SQL via execute

Seeds!

Why put unchanging data in the database?

So is reset_column_information a code smell?

SQL via `execute`