Table of Contents

• partition
• group_by
• detect / find
• tally
• max_by
• zip
• all-any-one-none
• filter_map
• to_h

partition

Documentation

What is it Splits a collection in two parts

When to use it You need to perform different operations on a collection’s subsets.

User = Struct.new(:name, :signed_up_at)
collection = [
  User.new(name: "Rumi", signed_up_at: Time.now),
  User.new(name: "Mira"),
  User.new(name: "Zoey", signed_up_at: 1.day.ago),
  User.new(name: "Jinu", signed_up_at: Time.now),
  User.new(name: "Mystery Saja")
]
signed_up_users, not_signed_up_users = collection.partition do |user|
  user.signed_up_at.present?
end

signed_up_users
#=> [#<struct User name="Rumi", signed_up_at=2025-10-09 11:55:38.009997 -0400>, #<struct User name="Zoey", signed_up_at=2025-10-08 15:55:38.010126000 UTC +00:00>, #<struct User name="Jinu", signed_up_at=2025-10-09 11:55:38.010603 -0400>]

not_signed_up_users
#=> [#<struct User name="Mira", signed_up_at=nil>, #<struct User name="Mystery Saja", signed_up_at=nil>]

group_by

Documentation

What is it Reorganizes a collection based on result.

When to use it You need to separate many different records into distinct groups

collection = [
  { name: "Rumi", demon: :maybe },
  { name: "Mira", demon: :no },
  { name: "Zoey", demon: :no },
  { name: "Jinu", demon: :yes },
  { name: "Gwi-ma", demon: :yes },
  { name: "Mystery Saja", demon: :yes },
  { name: "Bobby", demon: :no },
]

collection.group_by { |item| item[:demon] }
#=> {
#     maybe: [{ name: "Rumi", demon: :maybe }],
#     no: [{ name: "Mira", demon: :no }, { name: "Zoey", demon: :no }, { name: "Bobby", demon: :no }],
#     yes: [{ name: "Jinu", demon: :yes }, { name: "Gwi-ma", demon: :yes }, { name: "Mystery Saja", demon: :yes }],
#    }

Not a core Ruby Enumerable and there is also the Rails Enumerable#index_by. Unlike group_by it will only associate a single value to each key, so if you need an array associated to each key use group_by. Otherwise a 1-to-1 key value association can work well for index_by.

Enumerable#index_by

detect / find

Documentation

What is it Finds the first match in a collection

When to use it You need to return a record from a collection as soon as it is found

collection = [
  { name: "Rumi", demon: :maybe },
  { name: "Mira", demon: :no },
  { name: "Zoey", demon: :no },
  { name: "Jinu", demon: :yes },
  { name: "Gwi-ma", demon: :yes },
  { name: "Mystery Saja", demon: :yes },
  { name: "Bobby", demon: :no },
]

collection.detect { |item| item[:demon] == :maybe }
# => {name: "Rumi", demon: :maybe}

tally

Documentation

What is it Counts the total occurrences of each value. Akin to a frequency distribution of the available results.

When to use it You need to count the unique occurrences for each value in a collection.

character_ages = [40, 12, 32, 63, 32, 32, 11, 20, 12]
#=> [40, 12, 32, 63, 32, 32, 11, 20, 12]
character_ages.tally
#=> {40 => 1, 12 => 2, 32 => 3, 63 => 1, 11 => 1, 20 => 1}

max_by

Documentation

What is it Returns the object which is the greatest value in the collection

When to use it You have a numerical value associated to a record where you want the top value

collection = [
  { name: "Rumi", demon: :maybe, height: 62 },
  { name: "Mira", demon: :no, height: 70 },
  { name: "Zoey", demon: :no, height: 63 },
  { name: "Jinu", demon: :yes, height: 73 },
  { name: "Gwi-ma", demon: :yes, height: 240 },
  { name: "Mystery Saja", demon: :yes, height: 72 },
  { name: "Bobby", demon: :no, height: 65 },
]

collection.max_by { |item| item[:height] }
# => {name: "Gwi-ma", demon: :yes, height: 240}

# With parameter `2` for 2 results
collection.max_by(2) { |item| item[:height] }
#=> [{name: "Gwi-ma", demon: :yes, height: 240}, {name: "Jinu", demon: :yes, height: 73}]

zip

Documentation

What is it Merges two or more collections into a single collection which is zippered together

When to use it You have multiple datasets which need to be combined in a staggered style. Very useful for database imports.

names = ["Rumi", "Mira", "Zoey"]
demon_status = [:maybe, :no, :no]
heights = [62, 70, 63]

names.zip(demon_status, heights)
#=> [["Rumi", :maybe, 62], ["Mira", :no, 70], ["Zoey", :no, 63]]

all?, any?, one?, none?

all?
any?
none?
one?

What is it Detects when the block condition returns true for the element and returns boolean

When to use it

• all? Should be used when you MUST check every single element in the collection (will iterate all elements)
• any? Should be used when you want to return as early as the FIRST element that matches (will early return)
• one? Should be used when you MUST ensure that 1 and only 1 element matches the block (will iterate all elements)
• none? Should be used when you MUST check every single element in the collection to ensure it never matches (will iterate all elements)

collection = [
  { name: "Rumi", demon: :maybe, height: 62 },
  { name: "Mira", demon: :no, height: 70 },
  { name: "Zoey", demon: :no, height: 63 },
  { name: "Jinu", demon: :yes, height: 73 },
  { name: "Gwi-ma", demon: :yes, height: 240 },
  { name: "Mystery Saja", demon: :yes, height: 72 },
  { name: "Bobby", demon: :no, height: 65 },
]

collection.all? { |item| item[:demon] == :maybe }
# => false
# Conclusion:
# False! All results must have a key :demon that is equivalent to :maybe
# Returns early on FAILURE, otherwise must check all items

collection.any? { |item| item[:height] == 240 }
# => true
# Conclusion:
# True! There must be at least 1 result with a height of 240
# Returns early on TRUTHY; otherwise must check all items

collection.one? { |item| item[:demon] == :maybe }
# => true
# Conclusion:
# True! There must ONLY be a single result with a demon status of :maybe
# Returns early on FAILURE; otherwise must check all items

collection.none? { |item| item[:height] == 100 }
# => true
# Conclusion:
# True! There must not be a single height that is equal to 100
# Returns early on FAILURE; otherwise must check all items

filter_map

Documentation

What is it Maps and returns truthy elements

When to use it You need a subset of a collection without any nil items.

This is syntactical sugar for collection.map(&:method).compact

collection = [
  { name: "Rumi", demon: :maybe, height: 62 },
  { name: "Mira", demon: :no, height: 70 },
  { name: "Zoey", demon: :no, height: 63 },
  { name: "Jinu", demon: :yes, height: 73 },
  { name: "Gwi-ma", demon: :yes, height: 240 },
  { name: "Mystery Saja", demon: :yes, height: 72 },
  { name: "Bobby", demon: :no, height: 65 },
]

collection.filter_map { |item| item if item[:demon] == :yes }
#=> [{name: "Jinu", demon: :yes, height: 73}, {name: "Gwi-ma", demon: :yes, height: 240}, {name: "Mystery Saja", demon: :yes, height: 72}]

# Example of just using .map
collection.map { |item| item if item[:demon] == :yes }
#=> [nil, nil, nil, {name: "Jinu", demon: :yes, height: 73}, {name: "Gwi-ma", demon: :yes, height: 240}, {name: "Mystery Saja", demon: :yes, height: 72}, nil]

to_h

Documentation

What is it Interprets the collection as a Hash

When to use it You need to associate value pairs into key-value configuration

collection = [
  ["Rumi", { demon: :maybe, height: 62 }],
  ["Mira", { demon: :no, height: 70 }],
  ["Zoey", { demon: :no, height: 63 }],
  ["Jinu", { demon: :yes, height: 73 }],
  ["Gwi-ma", { demon: :yes, height: 240 }],
  ["Mystery Saja", { demon: :yes, height: 72 }],
  ["Bobby", { demon: :no, height: 65 }],
]

collection.to_h
# =>
# {
#   "Rumi" => { demon: :maybe, height: 62 },
#   "Mira" => { demon: :no, height: 70 },
#   "Zoey" => { demon: :no, height: 63 },
#   "Jinu" => { demon: :yes, height: 73 },
#   "Gwi-ma" => { demon: :yes, height: 240 },
#   "Mystery Saja" => { demon: :yes, height: 72 },
#   "Bobby" => { demon: :no, height: 65 },
# }

Find, zip, to_h, partitionnnn,
Fit check for my Enumerable era

Below we have a simplified variation of the problem I encountered. This uses the kicks gem to process published RabbitMQ messages.

class GroupCreateEventProcessor
  include Sneakers::Worker

  from_queue "group.create"

  def work(message)
    parsed_message = JSON.parse(message)

    creator = retrieve_creator(
      external_id: parsed_message[:external_creator_id]
    )
    group = Group.create(
      external_id: parsed_message[:external_id],
      name: parsed_message[:name]
      creator_id: creator.id
    )

    ack!
  end

  private

  def retrieve_creator(external_id:)
    User.find_by(external_id:)
  end
end

# app/models/user.rb
class User < ApplicationRecord
  has_many :created_groups

  # Additionally, email and external_id have a database level constraints of NOT NULL
  validates :email, presence: true
  validates :external_id, presence: true
end

class Group < ApplicationRecord
  belongs_to :creator, class_name: :User, foreign_key: :creator_id
end

What happens when we go to create a new Group, but the Creator (User) doesn’t yet exist?

You’ll end up with a validation error here since each Group above must reference a Creator. Our #retrieve_creator method can reasonably return nil in the above case. To fix this we can use find_or_create_by to adjust the method along with the required email field for the User model validations.

class GroupCreateEventProcessor
  include Sneakers::Worker

  from_queue "group.create"

  def work(message)
    parsed_message = JSON.parse(message)

    creator = retrieve_creator(
      external_id: parsed_message[:external_creator_id]
      email: parsed_message[:user_email] # Add additional message data from queue
    )
    group = Group.create(
      external_id: parsed_message[:external_id],
      name: parsed_message[:name]
      creator_id: creator.id
    )

    ack!
  end

  private

  # Ensure we create missing User records with `email` to satisfy the Model validations
  def retrieve_creator(external_id:, user_email:)
    User.find_or_create_by(external_id:) do |user|
      user.email = user_email
    end
  end
end

The above now functions as a self-healing flow for missing records that are required for newly created Groups. Now I knew about the block syntax for find_or_create_by which allows you to specify the creation attributes but what I learned about today was the create_with syntax.

Create_with

The create_with method allows for preemptively setting attributes for future created records. With this knowledge we can update our #retrieve_creator method signature to read a bit cleaner:

  def retrieve_creator(external_id:, user_email:)
    User
      .create_with(email: user_email)
      .find_or_create_by(external_id:)
  end

This preserves the record finding specificity to only query for external_id while instructing record creation to use the user_email coming from the RabbitMQ message. Now there are certainly arguments stylistically for the block syntax vs create_with syntax but one thing the block style syntax allows for is custom logic for generating values. Create_with does not provide as clean as a location for custom logic within a block.

If you want to learn more here is the documentation entry for ActiveRecord::QueryMethods#create_with

Includes the required interface for an object to interact with Action Pack and Action View, using different Active Model modules. It includes model name introspections, conversions, translations, and validations. Besides that, it allows you to initialize the object with a hash of attributes, pretty much like Active Record does.

• api.rubyonrails.org

I dug in a bit further and looked at the current implementation for ActiveModel::Model and it looks like the only current difference is the addition of the ActiveModel::Access module. For more information see the full documentation or the implementing pull request.

ZSH - An Enhanced Shell

First off, we’ll want to configure the base shell that our terminal will utilize. A lot of plugin ecosystems have strong integrations with Zsh so we’ll use that.

If you’re on Mac, congrats! Zsh is installed by default.

For Linux, you’ll need to install it, depending upon your distribution. Here are two popular distribution installation commands:

• Fedora - dnf install zsh
• Debian - apt install zsh

Once installed, configure your terminal to use ZSH as its shell with: chsh -s /bin/zsh. You can double check this is correctly setup by typing echo $SHELL to print the current shell environment.

Alright, we’ve got the foundation set for adding additional functionality in the form of plugins.

Antidote - A Zsh plugin manager

Antidote is a Zsh plugin manager designed to be efficient and minimal. It is the latest evolution of the Antigen -> Antibody -> Antidote ecosystem. Antigen was the original, but is no longer under active development. Antibody is written in Go and has been deprecated. Antidote is a return to form, being written in Zsh.

So first things first, let’s install it.

git clone --depth=1 https://github.com/mattmc3/antidote.git ${ZDOTDIR:-~}/.antidote

You’ll now have an .antidote folder within your Home directory. This is where Antidote functionality will live. We need to inform our shell where this is located. Add the following to the TOP of your .zshrc file. It is generally recommended to keep this at the top or near the top of your shell to ensure it loads plugins first and efficiently.

# source antidote
source ~/.antidote/antidote.zsh

# initialize plugins statically with ${ZDOTDIR:-~}/.zsh_plugins.txt
antidote load

Antidote also utilizes a plugins file in order to determine which plugins and libraries to load. To prepare for the next section, let’s go ahead and create our plugins file:

touch ~/.zsh_plugins.txt

Before we move on try running antidote --version to ensure it is installed correctly.

❯ antidote --version
antidote version 1.9.7 (9be3256)

Time to add some fancy plugins.

Zsh Plugins

First up, we’ll introduce several core Zsh plugins. Autosuggest, syntax highlighting, and completions. Our .zsh_plugins.txt file will accept references to the related repository for the plugin, so the following is all that is needed within the file.

# .zsh_plugins.txt
zsh-users/zsh-autosuggestions
zsh-users/zsh-syntax-highlighting
zsh-users/zsh-completions

After saving this, if you reload your terminal with source ~/.zshrc you’ll see Antidote load the new plugins. This is courtesy of the antidote load line. You can test these are working by testing the following:

• Typing an invalid command should highlight in red
• Typing a valid command should highlight in green
• Type a command. Try starting to type it again, and you should see a grayed out suggest for you to choose.

Something I like to add at this point are a couple useful aliases. These can be added to your .zshrc file inline or sourced from a separate file. Personally I like to have these in a separate directory ~/.config/zsh/.

# source antidote
source /path/to/antidote/antidote.zsh

# initialize plugins statically with ${ZDOTDIR:-~}/.zsh_plugins.txt
antidote load

##################
# Configurations #
##################

source ~/.config/zsh/zshrc_aliases

And to ensure the file exists run touch ~/.config/zsh/zshrc_aliases and add the following:

# Aliases
alias reload="exec zsh"
alias config="vim ~/.zshrc"
alias plugins="vim ~/.zsh_plugins.txt"

Resource your terminal again, and now you can simply type reload to source the terminal. config and plugins allow for easy editing of the .zshrc and .zsh_plugins.txt files, respectively.

Oh My Zsh - A Zsh framework

The most important benefit of using Antidote is being able to pick and choose which plugins you want to install. Oh My Zsh is a popular framework with a ton of functionality and plugins. However, many of the plugins you’ll never end up using. I much prefer having a simple, minimal configuration, which is where Antidote shines.

Oh My Zsh is a delightful, open source, community-driven framework for managing your Zsh configuration.

Oh My Zsh

Now, in order to cherry-pick specific plugins from other frameworks (Antidote can also grab plugins from Pretzo), you need to also include any related dependencies that those plugins require. This can add complexity, which we want to avoid. Thankfully, there is a recommended plugin which handles these dependencies called use-omz. Let’s start by adding that to our .zsh_plugins.txt file.

# .zsh_plugins.txt
zsh-users/zsh-autosuggestions
zsh-users/zsh-syntax-highlighting
zsh-users/zsh-completions

# Oh-my-zsh dependency management
getantidote/use-omz

This will ensure we don’t have to install separate dependencies for Oh My Zsh plugins. Now I really like several Oh My Zsh plugins such as: rails, git, and bundler along with their common library functions, but feel free to pick your own from the plugins page.

# .zsh_plugins.txt
zsh-users/zsh-autosuggestions
zsh-users/zsh-syntax-highlighting
zsh-users/zsh-completions

# Oh-my-zsh dependency management
getantidote/use-omz

# Make Zsh more featureful
# Git status is faster
# History and other enhancements
# See: https://github.com/ohmyzsh/ohmyzsh/tree/master/lib
ohmyzsh/ohmyzsh path:lib

# Oh-my-zsh plugins
ohmyzsh/ohmyzsh path:plugins/rails
ohmyzsh/ohmyzsh path:plugins/git
ohmyzsh/ohmyzsh path:plugins/bundler

Run reload to resource your terminal and watch the new plugins become installed.

You might be thinking, “Why didn’t we install any themes?”. We’ll superpower our terminal with powerlevel10k which has an amazing theme including additional functionality.

Powerlevel10k - A theme for Zsh

At first glance, Powerlevel10k is just a theme for Zsh. However, boiling it down to a simple theme doesn’t give it proper credit. It is so much more with several prominent features including:

• No prompt lag - Entering command immediately loads next prompt (documentation)
• Instant prompt - First prompt uses minimal (benchmarks)
• Prompt Segments - Notably the git vcs segment is incredibly useful

• Transient Prompt - Trims prompt extras to make previous commands easier to copy-paste and read.

• Font Glyphs - Technically this is separate from Powerlevel10k but is highly recommended in the installation instructions.

Convinced? If so, let’s install it.

Start off by adding to our plugins file for Antidote.

# .zsh_plugins.txt
romkatv/powerlevel10k

Install the recommended font to enable glyphs. You’ll need to download each of the four listed fonts and install them for your OS. Make sure to set your terminal application to utilize the newly installed font by setting “MesloLGS NF” as the default. If you’re unsure how to do this with your terminal, refer to the multitude of guides on the Powerlevel10k repository.

Now, reload your shell source with our reload alias.

Powerlevel10k comes prebaked with its own configuration utility. Run p10k configure to kick off the process. This will walk you through the different configuration options. Here are the ones I use:

• Prompt Style - Rainbow
• Character Set - Unicode
• Prompt Separator - Angled
• Prompt Head - Angled
• Prompt Height - One Line
• Prompt Spacing - Sparse
• Icons - Many Icons
• Prompt Flow - Concise
• Transient Prompt - Yes
• Instant Prompt Mode - Verbose

One manual change, I always do with Powerlevel10k, is to remove the truncation logic around git branch name. By default, the git branch displayed in the prompt segment gets truncated down to 32 characters. I often need to know the entire branch name and at times copy it, so removing this limitation is important.

We can adjust this by editing the underlying .p10k.zsh file. Run vim ~/.p10k.zsh and look for the following lines:

# Tip: To always show local branch name in full without truncation, delete the next line.
(( $#branch > 32 )) && branch[13,-13]="…"  # <-- this line

Following along with the suggestion, remove or comment the line out in order to return the fully qualified git branch name.

Now we have a supercharged terminal. Let’s take it one more step to use the excellent asdf version manager for dependency management.

One Version Manager to rule them all

Managing each tool’s version can be tiresome. Having a version manager specific to each tool’s version can be annoying. Having a single version manager to manage all your tool versions is excellent!

Mise and Asdf work as a version management framework for every programming language. Gone are the days of having to manage npm, rbenv, rvm, etc where as these will handle all languages. We can install the binary files and add them to our path to start adding programming languages.

Note: I’ve layed out both options mise and asdf. Until recently I was only using asdf but I’ve found mise to be superior in terms of UX and ease-of-use.

Mise - The front-end to your dev env

For Mac, you can use Homebrew to install Mise

brew install mise

If you are using Linux, the following will install and activate Mise for ZSH.

curl https://mise.run/zsh | sh

Mise actually has many different installation guides available which is quite nice for the various architectures.

Once installed, you can use the mise use ruby@3.4.2 style command to install both the Ruby plugin as well as the specific version. Mise makes this operation happen at the same time unlike asdf which you’ll see shortly.

The .tool-versions file is asdf’s config file and it can be used in mise just like mise.toml. It isn’t as flexible so it’s recommended to use mise.toml instead.

• Mise .tool-versions documentation

Alternatively, you can craft a mise.toml file which is much akin to ASDF’s .tool-versions file, and run mise install within the same directory to install all specified tools. Here’s my mise.toml file in my home directory:

[tools]
ruby = '3.4.2'
python = '3.13.2'
node = '22.13.1'

Helpfully, Mise has great UX with commands that are intuitive and just make sense. If you ever need to check which version of a tool you are running and from which directory it is being set from you can run the mise ls command to return all available versions. Here’s an example:

❯ mise ls
Tool    Version  Source        Requested
node    20.16.0
node    22.13.1  ~/.mise.toml  22.13.1
node    22.15.0
python  3.13.2   ~/.mise.toml  3.13.2
ruby    3.4.2    ~/.mise.toml  3.4.2

There are many other helpful commands that Mise provides which can be found here.

Asdf - The Multiple Runtime Version Manager

First off, if you’re on Mac then Homebrew is your goto installation delivery system.

brew install asdf

Otherwise, we’ll need to download the precompiled binary. Note that this is only one way of installing asdf there are several others but I’ve found this to be the most reliable. So find the binary based on your current OS from the GitHub releases page: https://github.com/asdf-vm/asdf/releases.

Next, create a new directory called .asdf and place the downloaded binary within the directory.

Finally, add the shims to the PATH environment variable

export PATH="${ASDF_DATA_DIR:-$HOME/.asdf}/shims:$PATH"

Reload your shell with the reload alias and type asdf list. This should be empty since we haven’t added any plugins yet.

If asdf list doesn’t work or returns a command not found, you might need to add the asdf binary to your path.

export PATH="${ASDF_DATA_DIR:-$HOME/.asdf}:$PATH"

Now obviously this next part depends on the programming languages that you use but for me I primarily use Ruby and Node.

asdf plugin add ruby
asdf plugin add nodejs

Eventually, the asdf list command might look something like below. This showcases the currently active version with an asterisk, along with all locally installed versions.

Now within your projects you can specify a .tool-versions file that contains a plugin name followed by its version (e.g. ruby 3.4.2). This tells asdf which version to focus the directory on. We can run asdf install to install all specified versions from the identified .tool-versions file, assuming the asdf plugin is also installed.

You can also directly install versions by typing something like: asdf install ruby 3.4.2. Don’t know which version to install? Asdf can list all available versions by running: asdf list all ruby. When installing / updating dependencies, it can be helpful to ensure the shimmed commands stay up-to-date. A shimmed command, is literally just a wrapper for an executable. Periodically these will need to be reshimmed when you update them. This can be done with the asdf reshim <name> <version> command.

Lastly, if you need to set a global fallback version for a programming language you can use the 0.16.x updated asdf set command. For example, to set the base level Ruby version we can run asdf set ruby 3.4.2 which will create a tool-versions file within our home directory.

Now we have version management configured as well!

Terminal Emulator

For me there are several important features that make for a good terminal emulator:

1. Quick access
2. Tiling
3. Tabs
4. Theming

From the above, there are two winners with similiar characteristics. Those are Kitty for Mac OSX and Ddterm for Fedora Workstation. Ideally I would love to use Kitty on both archictectures but the inability to use the quick access dropdown in Wayland makes it a no-go for my Linx machine.

ddterm - Another drop down terminal extension for GNOME Shell

For Gnome, there is the lovely Gnome Shell Extensions ecosystem along with the ddterm extension. The Shell Extensions page has hundreds of modifications you can install and further tweak. ddterm was built with Gnome and Wayland in mind, and as such works well. These can be directly installed from the Gnome Shell Extensions search page.

In order to configure the quick access hotkey, all that needs to be done is to set the Toggle Terminal Window within the Keyboard Shortcuts setting pane.

Kitty - The fast, feature-rich, GPU based terminal emulator

Kitty is my preferred terminal emulator. It has so many options which are controllable with configuration files making it easy to backup. It also looks great from a UI perspective.

It has tabs, panes, extendable plugins called kittens, and is performant. To install Kitty you need only run the following command:

curl -L https://sw.kovidgoyal.net/kitty/installer.sh | sh /dev/stdin

For Quick Access, there is a kitten called quick-access-terminal which is documented here. Linux and Mac OSX both require you to specify a window manager hotkey for Kitty.

Linux: “Simply bind the above command to some key press in your window manager”
Mac OSX: “…go to System Preferences->Keyboard->Keyboard Shortcuts->Services->General and set a shortcut for the Quick access to kitty entry.”

Conclusion

We now have a system configured with all the following tools:

• Shell - ZSH
• Plugin Manager - Antidote
• Version Manager - Mise
• Terminal Emulator - Kitty

What could be better than a perfect terminal? An automated one! I’m in the process of writing a follow-up post that disects two dotfile managers called RCM and Doot. They both help streamline nearly all of the above process.

More on those soon! Thanks for reading.

Before Rails 8

Previously, you would have to require the top level key :user in this case and then permit its keys with a secondary method call.

params.require(:user).permit(:name)

After Rails 8

With Rails 8+, you can now use a simpler syntax to achieve the same results.

expect is the preferred way to require and permit parameters. It is safer than the previous recommendation to call permit and require in sequence, which could allow user triggered 500 errors. expect is more strict with types to avoid a number of potential pitfalls that may be encountered with the .require.permit pattern.

• ActionController::Parameters#expect

The above require to permit are now contained within a single method call with well-structured arguments.

params.expect(user: [:name])

add_column :table, :column, :text, default: -> { "('prefix-' || md5(random()::text) || 'suffix')" }, null: false, if_not_exists: true

The default uses block syntax and string interpolation in order to add a prefix and suffix to a random string. The md5 and random functions come from PostgreSQL.

Know of any other tricks using functions within migrations? I’d love to learn about them in the comments below.

Thanks for reading!

after allows you to schedule work to be executed after a response (or prerender) is finished. This is useful for tasks and other side effects that should not block the response, such as logging and analytics.

• Next.js documentation

after runs after all other logic including when there is failure case. This means you can rely on it for things like tracking.

import { generateMatches } from "@/services/generate-matches-service";

export async function handleSubmit(
  prevState: any,
  formData: FormData
): Promise<SubmissionResponse> {
  try {
    const createdSearch = await prisma.search.create({ data: { ...formData } });

    // Runs after all other logic including the redirect below
    after(() => {
      generateMatches(createdSearch)
        .then((matches) => {
          console.log("Matches generated", matches);
        })
        .catch((error) => {
          console.error("Error generating matches", error);
        });
    });

    redirect(`/searches/${createdSearch.id}`);
  } catch (error) {
    console.log(error);
  }
}

Have you used after() yet? What has gone well when using it? What could be improved? Start the conversation below.

Prisma Schema

Prisma provides a schema to help define the model and database layers of your application. By definition it is mapping the concept of a Model to a database table. Now out-of-the-box if you were to create a new table your schema may look something like this. We’ll use an example of a blog application where a User can have many Posts.

model User {
  id            String    @id @default(uuid())
  email         String    @unique
  emailVerified DateTime?
  name          String?
  createdAt     DateTime  @default(now())
  updatedAt     DateTime  @updatedAt
}

model Posts {
  id        String   @id @default(uuid())
  title     String
  content   String?
  publishedAt DateTime?
  authorId  String
  author    User     @relation(fields: [authorId], references: [id])
}

Now migrating this schema you’d end up with a Users and Posts table with that casing. Generally this isn’t an issue but the general best practice is to use plural snake_case conventions for table names. Additionally, several of the columns like publishedAt, authorId, and emailVerified follow camelCase conventions which typically isn’t found at the database level.

The @map and @@map directives

Prisma provides two Schema directives that allow you to control the naming conventions of your table names along with column names. We can use the @map directive to control the column names to adhere to snake_case conventions.

@map: Maps a field name or enum value from the Prisma schema to a column or document field with a different name in the database. @@map: Maps the Prisma schema model name to a table (relational databases) or collection (MongoDB) with a different name.

Prisma Documentation

model User {
  id            String    @id @default(uuid())
  email         String    @unique
  emailVerified DateTime? @map("email_verified")
  name          String?
  createdAt     DateTime  @default(now()) @map("created_at")
  updatedAt     DateTime  @updatedAt @map("updated_at")
}

model Posts {
  id        String   @id @default(uuid()) @map("id")
  title     String
  content   String?
  publishedAt DateTime? @map("published_at")
  authorId  String @map("author_id")
  author    User     @relation(fields: [authorId], references: [id])
}

This has the benefit of connecting the model to the database table while preserving the correct naming conventions in both use-cases. The model can still utilize camelCase to interact at the JavaScript layer, while the database table uses the more commonly found snake_case equivlent.

For table naming, the @@map directive can be used in much the same way. We’ll use it to ensure that our database tables are named users and posts respectively.

model User {
  id            String    @id @default(uuid())

  @@map("users")
}

model Posts {
  id        String   @id @default(uuid())

  @@map("posts")
}

We now have SQL that uses database naming conventions while the Prisma models use camelCase conventions to better integrate with the JavaScript language.

Associations

This same approach can also be used for associations. For example, if there were a join table between Users and Posts, you could name the association with camelCase conventions. In this case, @map and @@map are not needed since Prisma provides a built-in mechanism to define the relationship. This relationship is virtual and does not exist in the database layer.

model User {
  id            String    @id @default(uuid())

  userPosts     Post[]
}

// Prisma used elsewhere in the codebase
// Collection of Posts associated with the User
user.userPosts

Conclusion

And with all of that you can keep both the Database and JavaScript layers focused on their own conventions.

Know about a trick with Prisma? Let me know in the comments below!

Our Example

First, let’s take a look at an example of a User listing page with pagination and actions. I find this example to be a great illustration of the power of ViewComponents while staying grounded in a real-world feature.

You don't need to be familiar with the Pagy gem. Just know that it allows us to paginate a collection of objects.

Pagy gem documentation

# users_controller.rb
class UsersController < ApplicationController
  USERS_PER_PAGE = 30

  def index
    @filters = {
      role: Role.all.select(:name)
    }

    @pagy, users = pagy(available_users, limit: USERS_PER_PAGE, page: params[:page])

    @users = users.map { |user| UserPresenter.new(user) }
  end

  private

  def filter_params
    params.permit(filters: :role)
  end

  def available_users
    if filter_params.present?
      User.where(role: filter_params)
    else
      User.all
    end
  end
end

# user_presenter.rb
class UserPresenter < SimpleDelegator
  def current_roles
    roles.map(&:name).to_sentence
  end

  def dropdown_actions
    [:edit, :destroy]
  end
end

<!-- index.html.erb -->
<%= render partial: "filters", locals: { available_filters: @filters } %>

<table class="bg-gray-300 p-4">
  <thead>
    <tr>
      <th>Name</th>
      <th>Roles</th>
      <th>Actions</th>
    </tr>
  </thead>

  <tbody>
    <% @users.each do |user| %>
    <tr>
      <td><%= user.name %></td>
      <td><%= user.current_roles %></td>
      <td>
        <%= render partial: "dropdown", locals: { resource: user, actions:
        user.dropdown_actions } %>
      </td>
    </tr>
    <% end %>
  </tbody>

  <tfoot>
    <tr>
      <td colspan="3">
        <p><strong>Pagination</strong></p>
        <%= pagy_nav(@pagy) %>
      </td>
    </tr>
  </tfoot>
</table>

How many responsibilities can you find spread between the Controller, Presenter, and View for this single page? Here’s the ones I quickly identified.

1. (Controller) Must understand how to set filters for the View
2. (Controller) Wraps every User within a UserPresenter for additional functionality outside standard Model.
3. (Controller) Must configure pagination values to prepare for View output
4. (View) Needs to understand the Filter partials interface to send the correct data
5. (View) Must know which table headers correspond to the User resource
6. (View) Must know how to render each individual User
7. (View) Must know which values to send to the actions’ dropdown, so has to understand the interface
8. (View) Must utilize the proper DSL from the Pagy gem in the table footer
9. (Presenter) Must know which dropdown actions to show for each User
10. (Presenter) Must convert a User’s roles into a human readable string

Now imagine a new feature requirement is requested to build a similar but slightly different page for a given User’s blog posts. You’d end up copying and pasting much of the above or creating additional partials to help abstract common functionality. ViewComponents offer a cleaner, isolated way of containing related View concerns in a single location. This includes building UI libraries with consistent CSS styling, reusable components, better testability, and more.

ViewComponents make the View layer awesome

ViewComponents have a number of advantages. From proper separation of concerns, to preview-ability and testing. They really feel like a total application changer once you start using them. Co-location is a great benefit of using them as it allows for a ViewComponent object to be related to specific component rendering view code. This helps to keep your UI components focusing on single concerns. Generally this would mean you’d have a my_component.rb and my_component.html.erb file, where the my_component.rb automatically renders the my_component.html.erb file.

A framework for creating reusable, testable & encapsulated view components, built to integrate seamlessly with Ruby on Rails.

https://viewcomponent.org/

Looking at the previous example let’s inject some ViewComponent goodness.

Filters Component

The least coupled concept are the Filters. For this example, we can assume that a filter allows the user to exclude records by enum columns to keep it simple. This means you might end up with a URL like: my-site.com/users?filters[role]=admin which would only return users with the admin role. Akin to executing the following SQL:

SELECT *
FROM users
INNER JOIN user_roles ON user_roles.user_id = users.id
INNER JOIN roles ON roles.id = user_roles.role_id
WHERE roles.name = 'admin'

We have a need of an Application-specific as well as General-purpose component as it needs to know which columns to show for the filters and filters could be reusable. ViewComponent’s best practices recommend seperating responsibilities between generic and specific use cases.

General-purpose ViewComponents implement common UI patterns, such as a button, form, or modal. Application-specific ViewComponents translate a domain object into one or more general-purpose components.

https://viewcomponent.org/best_practices.html#two-types-of-viewcomponents

For Filters, we can create a component for each of the use cases allowing us to resuse the common logic for future Filter related features.

Application-specific

We’ll start by creating a UsersFilterComponent to dictate how filters are built for this specific use case.

# Application-specific
# users_filter_component.rb
class UsersFilterComponent < ViewComponent::Base

  # You could also use dependency injection for more complex use cases with available roles
  def filters
    {
      role: Role.all.select(:name)
    }
  end
end

Notice how the corresponding component view for UsersFilterComponent actually is using the General-purpose FilterComponent during its rendering.

<!-- users_filter_component.html.erb -->
<%= render FilterComponent.new(available_filters: filters) %>

General-purpose

Since our Application-specific component utilizes the General-purpose component, we can have the FilterComponent accept a generic available_filters argument. Some of this is psuedo code to illustrate the concept of taking a collection of filters from a Hash and rendering them iteratively in the View.

# General-purpose
# filter_component.rb
class FilterComponent < ViewComponent::Base
  attr_reader :available_filters

  def initialize(available_filters:)
    @available_filters = available_filters
  end
end

<!-- Psuedo code to build links like: ?filters[role]=admin -->
<!-- filter_component.html.erb -->
<div>
  <% available_filters.keys.each do |filter_key| %> 
    <% available_filters[filter_key].each do |filter| %> 
      <%= link_to filter.name, params.merge(filter_key: filter.name) %> 
    <% end %> 
  <% end %>
</div>

We now gain some nice cleanup in our Controller and View layers:

# users_controller.rb
class UsersController < ApplicationController
  USERS_PER_PAGE = 30

  def index
    # - REMOVED -
    # @filters = {
    #  role: Role.all.select(:name)
    # }

    @pagy, users = pagy(available_users, limit: USERS_PER_PAGE, page: params[:page])

    @users = users.map { |user| UserPresenter.new(user) }
  end

 # ... Rest of Controller

<!-- index.html.erb -->
<!-- Removed <%= render partial: "filters", locals: { available_filters: @filters } %> -->
<%= render UsersFilterComponent.new %>

<table class="bg-gray-300 p-4">
  <thead>

We now have a User specific filters component and a general-purpose filters component to utilize on other pages. Next let’s dig into rendering the current User in the collection.

UserComponent

The primary section we are abstracting is the render loop from within the table body. I’ve added comments to show the section we’re looking at componentizing.

  <tbody>
    <% @users.each do |user| %>
      <!-- UserComponent -->
      <tr>
        <td><%= user.name %></td>
        <td><%= user.current_roles %></td>
        <td><%= render partial: "dropdown", locals: { resource: user, actions: user.dropdown_actions } %></td>
      </tr>
      <!-- End UserComponent -->
    <% end %>
  </tbody>

We’ll be pulling in our Presenter logic, as it now can completely live within our new UserComponent definition. With the upcoming change below, UserPresenter can be removed and our Controller slimmed down.

Updated Controller

# users_controller.rb
class UsersController < ApplicationController
  USERS_PER_PAGE = 30

  def index
    @pagy, @users = pagy(available_users, limit: USERS_PER_PAGE, page: params[:page])

    # - REMOVED -
    # @users = users.map { |user| UserPresenter.new(user) }
  end

# Also deleted the UserPresenter

Updated View index.html.erb

<!-- index.html.erb -->
  <tbody>
    <% @users.each do |user| %>
      <%= render UserComponent.new(user:) %>
    <% end %>
  </tbody>

New UserComponent

# New component
# user_component.rb
class UserComponent < ViewComponent::Base
  attr_reader :user

  def initialize(user:)
    @user = user
  end

  # Pulled directly from Presenter
  def current_roles
    user.roles.map(&:name).to_sentence
  end

  # Pulled directly from Presenter
  def dropdown_actions
    [:edit, :destroy]
  end
end

New UserComponent View

<!-- user_component.html.erb -->
      <tr>
        <td><%= user.name %></td>
        <td><%= user.current_roles %></td>
        <td><%= render partial: "dropdown", locals: { resource: user, actions: user.dropdown_actions } %></td>
      </tr>

Now depending on how far you want to isolate the different View responsibilities there are a few additional improvements you could take:

1. Create General-purpose components for Table, TableHeader, TableBody, TableCell
2. Refactor the “dropdown” partial to become the DropdownComponent. Great example of a General-purpose abstraction as dropdowns are common.
3. Further abstract Application-specific parts of the table for Users listing.

I’m going to skip 2, to focus on 1 and 3.

Slots and the UsersTableComponent

Following the abstraction to its next logical step, we can pull in several more View specific responsibilities into the ViewComponent layer. First we’ll start by moving the entire table tag into our new component. From here we can abstract the table headers into a ViewComponent method. Lastly, since we iterate over a collection of Users we can lean on ViewComponent’s slots.

Think of slots as a way to render multiple blocks of content, including other components.

https://viewcomponent.org/guide/slots.html

New UsersTableComponent

Since our UsersTableComponent will render an Application-specific component for User collections, we want each of the available users in the collection to be rendered by the singular UserComponent. We implement this by using the render_many slot to define a new collection called :users that renders with the UserComponent.

# users_table_component.rb
class UsersTableComponent < ViewComponent::Base
  renders_many :users, UserComponent

  def initialize(pagy:)
    @pagy = pagy
  end

  def headers
    ["name", "roles", "actions"]
  end
end

renders_many :users, UserComponent will give us a mechanism to define a collection of Users to render with the UserComponent.

New UsersTableComponent View

<!-- users_table_component.html.erb -->
<table class="bg-gray-300 p-4">
  <thead>
    <tr>
      <% headers.each do |header| %>
        <th><%= header %></th>
      <% end %>
    </tr>
  </thead>

  <tbody>
    <% users.each do |user| %>
      <%= user %> <!-- Will render with the UserComponent -->
    <% end %>
  </tbody>

  <tfoot>
    <tr>
      <td colspan="3">
        <p><strong>Pagination</strong></p>
        <%= pagy_nav(@pagy) %>
      </td>
    </tr>
  </tfoot>
</table>

Updated View index.html.erb

We’ll need to adjust our primary Controller view, to define the incoming collection of Users. Slots accomplish this with the DSL with_slot_name so for our case with_users. The with_users method call behaves exactly like the UserComponent class meaning that it can take the same arguments as the initializer. Think of with_users as equivalent to UserComponent.new.

<!-- Updated index.html.erb -->
<%= render UsersFilterComponent.new %>
<%= render UsersTableComponent.new(pagy: @pagy) do |users_table_component| %>
  <% @users.each do |user| %>
    <% users_table_component.with_users(user:) %>
  <% end %>
<% end %>

Our cleanup is really coming along nicely now. One thing we haven’t touched on is standardizing render styles. I added a Tailwind CSS class to the <table> tag which would be nice to have all our tables utilize. Obviously, this would be most benficial once we have more than a single use case but we’ll abstract this to illustrate the point.

TableComponent

Since we render <table class="bg-gray-300 p-4"> along with a header, body, and footer portion of the table we can start to abstract these in order to ensure consistent output style. Slots are a natural way of separating a Table into discrete pieces. Note that slots automatically create predicate methods in order to check if the slot contains data. This can be seen below with the if footer? conditional check, since not all Tables will have footers.

To test whether a slot has been passed to the component, use the provided #{slot_name}? method.

https://viewcomponent.org/guide/slots.html#predicate-methods

New TableComponent

# table_component.rb
class TableComponent < ViewComponent::Base
  renders_one :header
  renders_one :body
  renders_one :footer
end

New TableComponent View

<!-- table_component.html.erb -->
<table class="bg-gray-300 p-4">
  <thead>
    <tr>
      <%= header %>
    </tr>
  </thead>
  <tbody><%= body %></tbody>

  <% if footer? %>
    <tfoot><%= footer %></tfoot>
  <% end %>
</table>

Notice how we split the generic sections of a standard table into the new TableComponent. The concerns are separated based on the thead, tbody, and optional tfoot sections. Implementors for this component can now supply what they want to render and have it appear in the appropriate section based on the slot.

We can now adjust our users_table_component to utilize the general-purpose TableComponent. This ensure that all of our table follow the same styling from our UI library.

Updated UsersTableComponent

<!-- users_table_component.html.erb -->
<%= render TableComponent.new do |table_component| %>
  <% table_component.with_header do %>
    <% headers.each do |header| %>
      <th><%= header %></th>
    <% end %>
  <% end %>

  <% table_component.with_body do %>
    <% users.each do |user| %>
      <%= user %> <!-- Will render with the UserComponent -->
    <% end %>
  <% end %>

  <% table_component.with_footer do %>
    <tr>
      <td colspan="3">
        <p><strong>Pagination</strong></p>
        <%= pagy_nav(@pagy) %>
      </td>
    </tr>
  <% end %>
<% end %>

Customizing CSS Classes

One thing I like to add to components is a parameter to accept CSS classes for their top level element. This keeps the component opinionated but flexible enough to allow for customization when needed.

# table_component.rb
class TableComponent < ViewComponent::Base
  renders_one :header
  renders_one :body
  renders_one :footer

  attr_reader :classes

  def initialize(classes: "")
    @classes = classes
  end

  def component_classes
    "bg-gray-300 p-4 #{classes}"
  end
end

<!-- table_component.html.erb -->
<table class="<%= component_classes %>">
  <thead>
    <tr>
      <%= header %>
    </tr>
  </thead>
  <tbody><%= body %></tbody>
  <tfoot><%= footer %></tfoot>
</table>

<!-- Could be used with -->
<%= render TableComponent.new(classes: "flex bg-red-400") %>

<!-- Which would render: -->
<table class="bg-gray-300 p-4 flex bg-red-400">
  <thead>
    <tr>
      <%= header %>
    </tr>
  </thead>
</table>

The class_names TagHelper comes in handy here to conditionally toggle classes based on boolean values. With it we can more easily toggle the duplicate bg Tailwind classes.

# table_component.rb
class TableComponent < ViewComponent::Base
  renders_one :header
  renders_one :body
  renders_one :footer 

  attr_reader :classes

  def initialize(classes: "")
    @classes = classes
  end

  def component_classes
    class_names({
      "bg-gray-300" => classes.exclude?("bg-"), # Only use `bg-gray-300` if the `classes` argument does not include a Tailwind supported background color
      "p-4" => true,
      classes
    })
  end
end

There are additional concepts that can be added here such as variants which is a defined collection of styles based on a type. For example, a ButtonComponent could have a :critical variant to highlight the button in red. These are a great way to create different flavors of a component within a UI library ecosystem.

ApplicationComponent

You can even go one step further and create an ApplicationComponent that defines that each inheriting ViewComponent can pass CSS classes. I generally try to avoid this as it means that every subclass must properly call super to pass the classes argument to the ApplicationComponent. That’s additional information that could be surprising for implementors.

# application_component.rb
class ApplicationComponent < ViewComponent::Base
  attr_reader :classes

  def intialize(**keyword_arguments)
    @classes = keyword_arguments[:classes] if keyword_arguments.key?(:classes)

    super # Pass to ViewComponent::Base
  end
end

# table_component.rb
class TableComponent < ApplicationComponent
  renders_one :header
  renders_one :body
  renders_one :footer

  def initialize(**keyword_arguments, another_setting: "test")
    @another_setting = another_setting

    super(**keyword_arguments) # Pass to ApplicationComponent
  end

  def component_classes
    "bg-gray-300 p-4 #{keyword_arguments[:classes]}"
  end
end

This is a basic enhancement but gives you an idea for creating standard ViewComponent functionality.

Pagination

Lastly, we have several pagination related concerns that are currently burried within UsersTableComponent. Pagination is a common concern in regards to listing collections so abstracting this into a ViewComponent makes a lot of sense. This can give the added benefits of allowing more customized display logic around the previous / next buttons. Additionally, we will utilize conditional rendering with then #render? method to only show Pagination when the object responds to the appropriate underlying method.

Components can implement a #render? method to be called after initialization to determine if the component should render.

https://viewcomponent.org/guide/conditional_rendering.html

class PaginationComponent < ViewComponent::Base
  def initialize(pagination:)
    @pagination = pagination
  end

  private

  # Only render if the following returns true
  def render?
    @pagination.respond_to?(:pages)
  end
end

# users_table_component.rb
class UsersTableComponent < ViewComponent::Base
  renders_many :users, UserComponent
  renders_one :pagination, PaginationComponent

  # ... rest of file

<!-- users_table_component.html.erb -->
<%= render TableComponent.new do |table_component| %>
  <% table_component.with_header do %>
    <% headers.each do |header| %>
      <th><%= header %></th>
    <% end %>
  <% end %>

  <% table_component.with_body do %>
    <% users.each do |user| %>
      <%= user %> <!-- Will render with the UserComponent -->
    <% end %>
  <% end %>

  <% table_component.with_footer do %>
    <tr>
      <td colspan="3">
        <% if pagination? %>
          <%= pagination %>
        <% end %>
      </td>
    </tr>
  <% end %>
<% end %>

Updated index.html.erb

<!-- Updated index.html.erb -->
<%= render UsersFilterComponent.new %>
<%= render UsersTableComponent.new(users: @users) do |users_table_component| %>
  <% @users.each do |user| %>
    <% users_table_component.with_users(user:) %>
  <% end %>

  <% users_table_component.with_pagination(pagination: @pagy) %>
<% end %>

You may have noticed above I allowed the Pagination component to accept a generic pagination argument. This was to allow for the potential for multiple pagination engines. On its own in an application this wouldn’t be very useful since most applications utilize a single mechanism to generate pagination. BUT if this were instead within a UI library you could make the rendered pagination output the expected data to the library by checking this parameter.

class PaginationComponent < ViewComponent::Base
  def initialize(pagination:)
    @pagination = pagination # Could be Pagy, Kaminari, something else...

Also much like rendering a top-level component, ViewComponent slots allow you to pass arguments onto their underlying component definition when using Component slots.

# users_table_component.rb
class UsersTableComponent < ViewComponent::Base
  renders_many :users, UserComponent
  renders_one :pagination, PaginationComponent

<!-- index.html.erb -->
<%= render UsersTableComponent.new(users: @users) do |users_table_component| %>
  <% @users.each do |user| %>
    <% users_table_component.with_users(user:) %>
  <% end %>

  <% users_table_component.with_pagination(pagination: @pagy) %>
<% end %>

So the above will render the UsersTableComponent, with the Pagination slot, where the Pagination slot is defined by the PaginationComponent, and the PaginationComponent accepts the pagination argument.

We’ve now built upon several of the previous concepts leveraging: Generic slots, Component slots, Slot predicate methods, collection rendering, and conditionally rendered components. Two things we’ve yet to cover are Previewing and Testing. We’ll finish out the article with a brief summary of each.

Previewing

Like Rails Mailer previews, ViewComponents have preview functionality that works in much the same way. By creating a Preview file and visiting the appropriate route, you’ll have a playground to test out your component isolated from your application.

# test/components/table_component_preview.rb
class TableComponentPreview < ViewComponent::Preview
  # Route: /rails/view_components/table_component/default
  def default
    render TableComponent.new do |table_component|
      table_component.with_header do
        tag.th do
          "My Header Content"
        end
      end

      table_component.with_body do
        tag.td do
          "My Body Content"
        end
      end
    end
  end

  # Route: /rails/view_components/table_component/with_footer
  def with_footer
    render TableComponent.new do |table_component|
      table_component.with_header do
        tag.th do
          "My Header Content"
        end
      end

      table_component.with_body do
        tag.td do
          "My Body Content"
        end
      end

      table_component.with_footer do
        tag.td do
          "My Footer Content"
        end
      end
    end
  end
end

<!-- Default Preview -->
<table class="bg-gray-300 p-4">
  <thead>
    <tr>
      <th>My Header Content</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>My Body Content</td>
    </tr>
  </tbody>
</table>

<!-- With Footer Preview -->
<table class="bg-gray-300 p-4">
  <thead>
    <tr>
      <th>My Header Content</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>My Body Content</td>
    </tr>
  </tbody>
  <tfoot>
    <tr>
      <td>My Footer Content</td>
    </tr>
  </tfoot>
</table>

I highly recommend Lookbook as it provides additional functionality for changing the output of a component based on parameters.

Lookbook is a UI development environment for Ruby on Rails applications.

https://lookbook.build/

Testing

Testing ViewComponents is nearly as easy as testing a plain ole Ruby object. Generally there are two types of tests you’ll want to write: Unit and System. Our UserComponent defines several methods to be utilized within its corresponding View file. We can test these quite easily with either RSpec or Minitest.

UserComponent Unit Test

For our Unit test, we’ll only focus on the defined methods that are part of the Component. Think of this as testing a Presenter’s methods as it is a similiar context.

# spec/components/user_component_spec.rb
describe UserComponent, type: :component do
  let(:user) { create(:user)}
  let(:component) { described_class.new(user:) }

  describe "#dropdown_actions" do
    it "returns the correct actions" do
      expect(component.dropdown_actions).to eq([:edit, :destroy])
    end
  end

  describe "#current_roles" do
    it "returns the correct roles" do
      create(:role, name: "Admin", user:)
      create(:role, name: "User", user:)

      expect(component.current_roles).to eq("Admin, User")
    end
  end
end

UserComponent System Test

A system test, tests an end-to-end flow based on what the real world experience may look like. This is a great way to ensure that the component’s content, styles, and sometimes elements are rendered as expected.

# spec/components/user_component_spec.rb
describe UserComponent, type: :system do
  let(:user) { build_stubbed(:user, name: "Nic Cage") }

  it "renders the User within a Table row" do
    render_inline(UserComponent.new(user:))

    expect(page).to have_content(user.name)
    expect(page).to have_selector("tr")
  end
end

The above is a basic system test that uses Capybara under-the-hood to render and test the UserComponent’s html output. Anything that can be done with Capybara is fair to utilize here.

Conclusion

Now that we’ve abstracted several of the View concerns elsewhere, our top level interface for the Controller is much cleaner. It allows the Controller better focus on business logic giving us a natural place to introduce concepts like Service Objects, Query Objects, and Form Objects.

Here’s the end-result for our Controller & View interface:

# users_controller.rb
class UsersController < ApplicationController
  USERS_PER_PAGE = 30

  def index
    @pagy, @users = pagy(available_users, limit: USERS_PER_PAGE, page: params[:page])
  end

  private

  def filter_params
    params.permit(filters: :role)
  end

  def available_users
    if filter_params.present?
      User.where(role: filter_params)
    else
      User.all
    end
  end
end

<!-- index.html.erb -->
<%= render UsersFilterComponent.new %>
<%= render UsersTableComponent.new(users: @users) do |users_table_component| %>
  <% @users.each do |user| %>
    <% users_table_component.with_users(user:) %>
  <% end %>

  <% users_table_component.with_pagination(pagination: @pagy) %>
<% end %>

The next engineer now doesn’t need to worry about the various components of this View since they are isolated. This reduces the amount of mental overhead allowing them to focus on the feature requirements. We have dedicated locations for our Component logic, rendering, previewing, and testing.

I’ve only gone surface level with ViewComponents as there much more depth and nuance to them. If you’ve had success (or failures) with utilizing ViewComponents as your View layer, I’d love to hear about it in the comments below. Thanks for reading!

Keyboard

The first (and arguably most important) step of this guide is adjusting your modifier key mappings. This stems from my biggest gripe with Mac OSX. The Command (⌘) key is used for copying, pasting, switching workspaces, and all other Ctrl (^) key related functionality. I’ve grown accustomed to how Linux sets its key mappings, which flips these two keys.

Luckily, Mac OSX has the concept of custom modifier keys, which define actions for several keys. Using spotlight search or System Settings->Keyboard->Keyboard Shortcuts->Modifier Keys, you can access the modifier keys configuration page.

Once on the page, you can switch the Control (^) and Command (⌘) keys to their opposite settings. A further step that I take is to map the CapsLock key to also perform Command (⌘) modifier actions. Because when is the last time you actually used your CapsLock key? Pretty much never for me.

The great thing about changing the modifier keys, is that it applies everywhere system-wide. Previously, I’ve used tools like Karabiner-elements which give you granular control over application and system shortcuts, but that comes with lots of configuration and some idiosyncrasies.

Spotlight

• Show spotlight search — Control (^) + Space

Screenshots

• Copy Picture of selected area to clipboard — F13 (Printscrn)

Mission Control

Set movement of workspaces to utilize the newly mapped Control (^) key

With that, you have basic keyboard configuration setup. Next up let’s adjust the Mouse and Trackpad.

Mouse and Trackpad

My preference is to disable Natural Scrolling for both mouse wheel and trackpad. This means that scrolling up on the mouse wheel moves the scrollbar up the page instead of down.

Additionally, I like having the Trackpad respond from a single click to perform actions and the secondary click be set to the bottom right corner of the Trackpad. The single click to perform actions from my experience is on by default in several Linux distros.

Next up let’s update the Dock.

Desktop & Dock

The Dock is my favorite part of both Mac OSX and many Linux distributions. If you’re using Fedora Workstation or Elementary OS, the Dock in each of the these are fantastic. Mac’s Dock is pretty good by default as well. I like to get information out of the way unless I need it, so hiding the dock until the mouse hovers over it is a key change I make.

To accomplish this, you’ll need to enable “Automatically hide and show the Dock”. This hides the Dock until the mouse moves over it. Now by default this animation is rather slow. I believe it is trying to mimic a pressure reveal. However, I want this to be smooth and snappy. Luckily, some enterprising individuals have figured out the internal settings used to calculate both the delay for showing as well as the animation timing. Here is the result of making the change.

In order to configure this, you’ll need to open your Terminal and run the following lines. autohide-delay is how long to wait before starting the show/hide transition, while autohide-time-modifier is the animation timing. You can see that we set it to zero in order for it to immediately start transitioning states.

defaults write com.apple.dock autohide-delay -int 0
defaults write com.apple.dock autohide-time-modifier -float 0.4
killall Dock

Original source

Here are some additional Dock settings that I utilize for a better overall experience:

• Minimize windows using Scale Effect gives a more consistent animation transition experience.
• Enabling Minimize windows into application icon ensures that each application in the Dock provides all the open windows of itself. Otherwise, these open next to the Downloads and Trash Can for each window.

• Disabling “Show suggested and recent apps in Dock” helps to remove clutter in the Dock for a feature I never use.

App set to specific workspace

I like to have 4 Workspaces when programming: Browser, Editor, Git Gui, and Spotify. So after opening an application you can set the application to always open in a specific Workspace with the context menu in the Dock.

Control Center

Within here there are a couple of nice tweaks we can make in the Menu Bar Only section.

• Spotlight set to “Don’t show in Menu Bar”. Spotlight is more useful from a keyboard shortcut.
• Automatically hide and show the menu bar set to “Always”. This will hide your top menu bar and allow more focus on current work (as well as more screen real estate).
• Recent Documents, applications, and servers set to “None”. I prefer to have the quick open functionality focus only on what is currently open. So right clicking on a Dock icon will show me all the windows I have currently open without past open files.

Mission Control

Now on the same settings page under “Mission Control”, the first option “Automatically rearrange spaces based on use” should be disabled. This prevents your workspaces from changing their order based on usage. I have my workspaces setup in the following order: Browser & Slack, Editor, Git Merge Tool, and Spotify. This allows me a consistent development experience to easily move back and forth between tasks.

Much like the Dock’s show/hide timing, we can adjust Workspace switching by setting the following value:

defaults write com.apple.dock workspaces-swoosh-animation-off -bool YES
killall Dock

This can help, but there is still some slowness from switching spaces, depending on when you activate the keyboard shortcut to switch. I’m not aware of other methods to speed switching up further.

Next up are several general System Settings.

Appearance

Personally I prefer a dark theme as it is easier on the eyes. I do enjoy a good pop of color, so I select the Purple accent for the system.

Display

I use a laptop connected to a primary monitor. I’ve used a single monitor for years and years, so I don’t use the laptop for anything but powering the screen. Because of this, I’ve set my display mode to Mirror screen.

Homebrew

The defacto package manager for Mac. Get it as it is nearly guaranteed that at some point you’ll need it.

https://brew.sh/

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Applications

Over the years, I’ve come to use the following applications consistently. I won’t go into too much more detail around application configuration until a follow-up post, but here is the list of apps that I use. Coming from a Linux background, I have focused on apps which are free. The only fully paid app below is Magnet (window snapping) while Sublime Text, Sublime Merge, and Cursor have free versions with less functionality.

• 1Clipboard - For Clipboard management
• Brave Browser - For Ad-free web browsing
• Docker - For Containerization
• Giphy Capture - For recording short animated demos in Gif format
• Hidden Bar - For customizing the top bar application tray
• iA Writer - For focused writing
• Bruno - For API development
• Magnet - For enhanced application tiling
• MeetingBar - For meeting notifications and joining video calls
• Spotify - For vibes
• Slack - For chatting
• Sublime Merge - For Git Client
• Sublime Text and Cursor - For Code editing
• Tabby - For modern terminal

NoTunes

This is a nice quality of life change for how the media buttons interact with the default Mac audio applications. Specifically, it can be used to change the default program to something like Spotify instead of Music or Tunes.

NoTunes

1. Install - brew install --cask notunes
2. Right click or control-click the menu bar icon and click Hide Icon.
3. Replace with Spotify or other app - defaults write digital.twisted.noTunes replacement /Applications/Spotify.app

Conclusion

Now we’ve ironed out a bunch of rough edges for those of us coming from a Linux environment. Such smooth. Many nice. Stay tuned for a similiar post regarding my Fedora Workstation setup.

Got any Mac OSX tweaks or settings you use? Leave a comment below to get the discussion started.