DEV Community: Nick Pezza

Dynamic nested forms with Turbo

Nick Pezza — Sat, 04 Jun 2022 00:16:11 +0000

Prior to the advent of Turbo and Stimulus, my go-to for creating dynamic nested forms was Cocoon which has been around a while and uses jQuery. Tried and true.

Once Stimulus came out, Chris Oliver from GoRails re-implemented Cocoons functionality using Stimulus. This iteration was simplified and removed the dependency on Cocoon and jQuery.

Let's try a new implementation of dynamic nested forms without using any JavaScript!

Getting started

For this example, we'll make a checklist app that has projects and tasks.



rails new checklist
cd checklist
rails generate scaffold project description name
rails generate model task description project:belongs_to
rails db:migrate

To start, We need to update our Project model to accept attributes for tasks:



# app/models/project.rb
class Project < ApplicationRecord
  has_many :tasks
  accepts_nested_attributes_for :tasks, 
    reject_if: :all_blank, allow_destroy: true
end

With Project aware of tasks, let's modify the Project form to render any associated Task fields.



<%# app/views/projects/_form.html.erb %>
<%= form_with(model: project) do |form| %>
  <% if project.errors.any? %>
    <div style="color: red">
      <h2><%= pluralize(project.errors.count, "error") %> prohibited this project from being saved:</h2>

      <ul>
        <% project.errors.each do |error| %>
          <li><%= error.full_message %></li>
        <% end %>
      </ul>
    </div>
  <% end %>

  <div>
    <%= form.label :name, style: "display: block" %>
    <%= form.text_field :name %>
  </div>

  <div>
    <%= form.label :description, style: "display: block" %>
    <%= form.text_field :description %>
  </div>

  <h4>Tasks</h4>
  <div>
    <%= form.fields_for :tasks do |task_form| %>
      <%= task_form.hidden_field :id %>

      <div>
        <%= task_form.label :description, style: "display: block" %>
        <%= task_form.text_field :description %>
      </div>
    <% end %>
  </div>

  <div>
    <%= form.submit %>
  </div>
<% end %>

When we start up the rails server and go to http://localhost:3000/projects/new, no tasks get shown.
This is because, in our controller, when we instantiate a Project, we aren't building any associated Tasks. We can change that by altering the new action in the ProjectsController.



# app/controllers/projects_controller.rb
class ProjectsController < ApplicationController
  [...]
  def new
    @project = Project.new(tasks: [Task.new])
  end
  [...]
end

Once we reload the page, we now have see the fields for a Task being rendered.

To successfully submit this form, though, we need to modify our permitted parameters in the ProjectsController.



# app/controllers/projects_controller.rb
class ProjectsController < ApplicationController
  [...]
  private

  def project_params
    params.require(:project).
      permit(:name, :description, tasks_attributes: 
        [:id, :description, :_destroy])
  end
  [...]
end

When we added accepts_nested_attributes_for in our Project model, it created a method tasks_attributes=(attrs) that takes in a hash of tasks that it can then use to construct Task objects. We'll dive more into the structure of the attrs hash in a bit. You can read more about accepts_nested_attributes_for here.

Now when we submit this form, a new Project is created along with a new associated Task.

Next, we'll move the form inputs for Tasks into their own partial so we can reuse it later.



<%# app/views/tasks/_form.html.erb %>
<%= form.hidden_field :id %>

<div>
  <%= form.label :description, style: "display: block" %>
  <%= form.text_field :description %>
</div>

While updating the Project form to use the new Task form partial we are also going to add an id to the surrounding div so that we can target it in the future with turbo streams.



<%# app/views/projects/_form.html.erb %>
[...]
<h4>Tasks</h4>
<div id="tasks">
  <%= form.fields_for :tasks do |task_form| %>
    <%= render "tasks/form", form: task_form %>
  <% end %>
</div>
[...]

Child Index

Before going any further we have to understand how fields_for works, and how the tasks_attributes= method works.

We'll take a look at tasks_attributes= first.

Using the form submission parameters in our server log, we can see what the tasks_attributes parameter looks like.



Parameters: {"authenticity_token"=>"[FILTERED]", "project"=>
{"name"=>"project 1", "description"=>"first project", 
"tasks_attributes"=>{"0"=>{"description"=>"task 1"}}}, 
"commit"=>"Create Project"}

You might be thinking 'What's up with that "0" key?'. That is used as a way for Rails and Rack to uniquely identify each task in our form. When we are dynamically adding new tasks, they won't yet have database ids assigned to them so we need to assign them a temporary identifier to distinguish unique tasks sent to the server. In this case, fields_for uses a zero-based index.

If we were to have two tasks on our form (you can do this by updating the new action in our ProjectsController to build two Tasks on our Project instead of one) and submit the form you would see parameters that would look like:



{ "tasks_attributes"=>{"0"=>{"description"=>"task 1" }, 
"1"=>{"description"=>"task 2" } } }

Let's move over to look at fields_for now.
Calling f.fields_for :tasks do |task_form| in our form will call the tasks method on @project and then loop through each task creating a scoped form builder. With the scoped form builder we can output the inputs for a Task.

If we open our browser and inspect the tasks description text field we'll see it has a name of project[tasks_attributes][0][description]. For our Project fields the name looks something like project[name]. Calling fields_for will add the [tasks_attributes] scope and since Rails knows this is a has_many relationship it will add the index as another scope to uniquely identify specific tasks.

We can alter this index by passing in a child_index parameter on fields_for. In our Projects form partial if we update our fields_for call to be <%= form.fields_for :tasks, child_index: "FOOBAR" do |task_form| %> and inspect our description field, the fields name is now, project[tasks_attributes][FOOBAR][description].

With this knowledge, we can better understand how past implementations of this trick were done. We would render the task form inputs out somewhere hidden on the page, with an easily identifying child_index. Then when we want to add a new task, we copy the template, gsub the child_index for a unique number, and then paste the template into the DOM tree. For removing, we would hide all the inputs, find the _destroy hidden input, and set it to true.

Let's move on to adding the dynamic parts to our form.

Dynamically removing tasks

We'll start by wrapping the Tasks form inputs in a turbo_frame.



<%= turbo_frame_tag "task_#{form.index}" do %>
  <%= form.hidden_field :id %>

  <div>
    <%= form.label :description, style: "display: block" %>
    <%= form.text_field :description %>
  </div>
<% end %>

Using the child_index(found by calling index on the form object) in the turbo_frame id allows us to manipulate the fields for just that Task.

Next we are going to need a controller for Tasks so that we can remove one. Unlike normal resourceful routes, the route for removing a task requires we pass it the child_index since it identifies the turbo_frame we want to target.
We also need an optionally id parameter because when we are editing a Project we might want to delete an existing Task, in which case, we will need to pass the database id back to the server so it knows which Task to destroy.



# config/routes.rb
Rails.application.routes.draw do
  resources :projects

  resources :tasks, only: [], param: :index do
    member do
      delete '(:id)' => "tasks#destroy", as: ""
    end
  end
end

This creates the route:



Prefix Verb   URI Pattern                   Controller#Action
  task DELETE /tasks/:index(/:id)(.:format) tasks#destroy

In the controller we need to setup one Project and one Task.



# app/controllers/tasks_controller.rb
class TasksController < ApplicationController
  def destroy
    @project = Project.new(tasks: [Task.new])
  end
end

A Project needs to be setup because we are going to recreate the form with different inputs.



<%# app/views/tasks/destroy.html.slim %>
<%= fields model: @project do |form| %>
  <%= form.fields_for :tasks, child_index: params[:index] do |task_form| %>
    <%= turbo_frame_tag "task_#{task_form.index}" do %>
      <%= task_form.hidden_field :id, value: params[:id] %>
      <%= task_form.hidden_field :_destroy, value: true %>
    <% end %>
  <% end %>
<% end %>

This view recreates the Project form with a Task but this time there are a few differences.

We are using the fields method rather than the form_with method because we don't need to render the actual HTML form element we just need a form builder instance.
We pass the index param as the child_index.
We change the form inputs in the turbo frame to be just the id and _destroy inputs.

Now let's go back to the tasks form partial and add a button to trigger this.



<%# app/views/tasks/_form.html.erb %>
<%= turbo_frame_tag "task_#{form.index}" do %>
  <%= form.hidden_field :id %>

  <div>
    <%= form.label :description, style: "display: block" %>
    <%= form.text_field :description %>
  </div>

  <%= form.submit "destroy task", 
        formaction: task_path(form.index, form.object.id), 
        formmethod: :delete, 
        formnovalidate: true, 
        data: { turbo_frame: "task_#{form.index}" } %>
<% end %>

Here we take advantage of the formaction and formmethod attribute of submit buttons inside the form to submit a DELETE request over to our destroy action of Tasks, targeting this turbo frame.

After reloading the page, clicking this button removes our task from the form! Hooray! Now on to adding tasks.

Dynamically adding tasks

Just like removing, let's add a new route:



# config/routes.rb
Rails.application.routes.draw do
  resources :projects

  resources :tasks, only: [], param: :index do
    member do
      delete '(:id)' => "tasks#destroy", as: ""
      post '/' => "tasks#create"
    end
  end
end

Our new route looks like:



POST   /tasks/:index(.:format)       tasks#create

In this case, we don't have need the optional id parameter since this is always a brand new record.

Now let's add a button on our Project form to add new tasks.



<%# app/views/projects/_form.html.erb %>
[...]
<h4>Tasks</h4>
<div id="tasks">
  <%= form.fields_for :tasks do |task_form| %>
    <%= render "tasks/form", form: task_form %>
  <% end %>
</div>

<%= form.submit "Add task", 
      formaction: task_path(@project.tasks.size), 
      formmethod: :post, 
      formnovalidate: true, 
      id: "add-task" %>
[...]

We need an id on our submit button so we can replace the formaction with an updated index when we add a new task to the form.

Next, we'll move to our TasksController and setup our new method. Since it is going to be identical to our destroy method we can do some cleanup.



# app/controllers/tasks_controller.rb
class TasksController < ApplicationController
  before_action :setup_project

  def new
  end

  def destroy
  end

  private

  def setup_project
    @project = Project.new(tasks: [Task.new])
  end
end

Now for our create template. In this case we are going to use a turbo_stream template.



<%# app/views/tasks/create.turbo_stream.erb %>
<%= fields model: @project do |form| %>
  <%= form.fields_for :tasks, child_index: params[:index] do |task_form| %>
    <%= turbo_stream.replace "add-task" do %>
      <%= form.submit "Add task", 
            formaction: task_path(task_form.index.to_i + 1), 
            formmethod: :post, 
            formnovalidate: true, 
            id: "add-task" %>
    <% end %>

    <%= turbo_stream.append "tasks" do %>
      <%= render "form", form: task_form %>
    <% end %>
  <% end %>
<% end %>

The first stream replaces our Add task button with a new one that has a new formaction pointing to the next index.

The second stream, appends to the #tasks element a new task form.

If we reload the page and click the "Add task" button, BOOM! A new task is added to the form and we can then remove it.

How to paginate items using Turbo

Nick Pezza — Tue, 22 Dec 2020 23:43:08 +0000

Basecamp recently released Hotwire which includes Turbo. Using Turbo, we can quickly paginate a long list of items that can be asynchronously loaded without any javascript.

Let's say we have an app that lists credit card transactions. This list can become very long which we wouldn't want to load upfront due to the performance impact. To avoid loading all the transactions upon page load but, still allow our users to see all transactions, we will only render the first few transactions initially and then show a "Load More" link. The "Load More" link will grab more transactions, append them to the existing list of transactions, and then update our "Load More" link to point to a new URL for the next collection of transactions.

(Note: We are going to use Geared Pagination for pagination but this solution will work with any pagination solution so long as you know the current and next page numbers.)

Here's where our app currently stands:

# app/views/transactions_controller.rb
class TransactionsController < ApplicationController
  def index
    set_page_and_extract_portion_from(Transaction.all)

    respond_to do |format|
      format.html
      format.js
     end
  end 
end

<%# app/views/transactions/index.html.erb %>
<p id="notice"><%= notice %></p>
<div>
  <%= link_to 'New Transaction', new_transaction_path %>
</div>

<h1>Transactions</h1>

<div>
  <ul><%= render @page.records %></ul>

  <% unless @page.last? %>
    <%= link_to "Load More", transactions_path(page: @page.next_param), remote: true, id: "load-more" %>
  <% end %>
</div>

<%# app/views/transactions/index.js.erb %>
document.querySelector("ul").insertAdjacentHTML("beforeend", "<%= j render partial: @page.records, as: :transaction %>");

<% if @page.last? %>
  document.querySelector("#load-more").remove();
<% else %>
  document.querySelector("#load-more").href = "<%= transactions_path(page: @page.next_param) %>";
<% end %>

This solution works fine. Code is pretty concise and explicit, but we are using a separate js.erb view which we now also have to maintain along with the html.erb view for the index action.

Using Turbo we can remove app/views/transactions/index.js.erb and the respond_to block in the controller since we will only be responding to HTML.

In app/views/transactions/index.html.erb we will make the following changes inside the ul element:

<ul>
  <%= turbo_frame_tag "transactions-#{@page.number}" do %>
    <%= render @page.records %>
    <%= turbo_frame_tag "transactions-#{@page.next_param}" do %>
      <% unless @page.last? %>
        <%= link_to "Load More", transactions_path(page: @page.next_param) %>
      <% end %>
    <% end %>
  <% end %>
</ul>

If we reload our page and try it out, it works!

The trick to making this work is nesting the turbo-frames. On this first page, our outer frame has the id of transactions-1 and the inner one has the id of transactions-2. When we click the "Load More" link the server is going to respond with the inner HTML of the body element of what page 2 looks like. In that case, our outer frame has the id of transactions-2 and our inner one has the id of transactions-3. Once we get that response, Turbo will replace any frames that occur on the initial page and on the one sent back.

Since the transactions-1 turbo-frame doesn't appear on the second page, nothing happens to it. But there is a transactions-2 turbo-frame on both our first and second pages so that frame is replaced. That new frame will render the Transaction's on the second page right below the first page's transactions, and remove the first page's "Load More" and replace it with a "Load More" link to the third page. Our HTML would end up looking something like:

<ul>
  <%= turbo_frame_tag "transactions-1" do %>
    <%= render @page.records %> <%# page 1 records %>
    <%= turbo_frame_tag "transactions-2" do %>
      <%= render @page.records %> <%# page 2 records %>
      <%= turbo_frame_tag "transactions-3" do %>
        <%= link_to "Load More", transactions_path(page: 3) %>
      <% end %>
    <% end %>
  <% end %>
</ul>

Magic 🪄!

(Note: Styling could become an issue with this solution with elements being nested inside turbo-frame tags but so far I haven't run into any issues.)

RediSearch on Rails

Nick Pezza — Sat, 03 Aug 2019 21:31:37 +0000

If you are using Rails, chances are you are using Redis for something whether it is as a cache, ActionCable, or ActiveJob. So why not use it for one more thing?

Starting in v4 of Redis, Redis Modules were introduced which are add ons built to extend Redis' functionality. One of the first modules was RediSearch, a text search engine built on top of Redis. According to RediSearch.io:

Unlike other Redis search libraries, it does not use the internal data
structures of Redis like sorted sets. Using its own highly optimized data
structures and algorithms, it allows for advanced search features, high
performance, and low memory footprint. It can perform simple text searches, as
well as complex structured queries, filtering by numeric properties and
geographical distances. RediSearch supports continuous indexing with no
performance degradation, maintaining concurrent loads of querying and
indexing. This makes it ideal for searching frequently updated databases,
without the need for batch indexing and service interrupts.

Some of the headline features of RediSearch include:

Full-Text indexing of multiple fields in a document, including:
- Exact phrase matching.
- Stemming in many languages.
- Prefix queries.
- Optional, negative and union queries.
Distributed search on billions of documents.
Numeric property indexing.
Geographical indexing and radius filters.
Incremental indexing without performance loss.
A powerful auto-complete engine with fuzzy matching.
Concurrent low-latency insertion and updates of documents.
This benchmark against ElasticSearch!

Let's walk through how to get RediSearch integrated into your Rails app!

First, start out by installing Redis and RediSearch. Check out Redis.io for full installation instructions for Redis. If Homebrew is available you can brew install redis. As of v1.6, to build RediSearch do the following:

git clone https://github.com/RediSearch/RediSearch.git
cd RediSearch
make

Once RediSearch is built you will need to tell Redis to load the module. The best way is to add loadmodule /path/to/redisearch.so to your redis.conf file to always load the module. (On macOS the redis.conf file can be found at /usr/local/etc/redis.conf). Once the conf file has been updated restart Redis. For full instructions on installing RediSearch visit RediSearch.io.

Alternatively, you can run Redis and RediSearch with Docker using docker run -p 6379:6379 redislabs/redisearch:latest.

Once Redis and RediSearch are installed add the redi_search gem to your Gemfile:

gem 'redi_search'

and then run bundle install. Or you can install from the GitHub package registry.

Once installed we'll need to make an initializer to configure our Redis connection.

# config/initializers/redi_search.rb
RediSearch.configure do |config|
  config.redis_config = {
    host: "127.0.0.1",
    port: "6379"
  }
end

Now that we have RediSearch available in our app, let's use it to index a model. We'll use a User model with first and last attributes as an example.

class User < ApplicationRecord
  redi_search schema: {
    first: { text: { phonetic: "dm:en" } },
    last: { text: { phonetic: "dm:en" } }
  }
end

Calling the redi_search class method inside a model accepts one required named parameter called schema. This defines the fields inside an index and the attributes for those fields. RediSearch has text, numeric, geo, and tag fields. The phonetic option was passed above because we are indexing names and it makes it easier to search for names with similar sounds but spelled differently. The full list of available options for the different field types can be found here.

User.reindex

Calling the redi_search class method inside a model adds a couple of useful methods, including reindex which does a couple of things:

Creates the index if it doesn't exist
Calls the search_import scope to fetch all the records from the database
Converts those records to RediSearch Documents
Indexes all those documents into Redis

User.search("jak")

Now that we have all of our users indexed we can start searching for them. Querying is similar to the ActiveRecord interface where clauses and conditions can be chained together and the search is executed lazily. Some simple queries are:

# simple phrase query - jak AND daxter
User.search("jak").and("daxter")

# exact phrase query - jak FOLLOWED BY daxter
User.search("jak daxter")

# union query - jak OR daxter
User.search("jak").or("daxter")

# negation query - jak AND NOT daxter
User.search("jak").and.not("daxter")

Some more complex queries are:

# intersection of unions - (hello OR halo) AND (world OR werld)
User.search(User.search("hello").or("halo")).and(User.search("world").or("werld"))
# negation of union - hello AND NOT (world or werld)
User.search("hello").and.not(User.search("world").or("werld"))
# union inside phrase - hello AND (world OR werld)
User.search("hello").and(User.search("world").or("werld"))

All terms support a few options that can be applied.

Prefix terms: match all terms starting with a prefix. (Akin to like term% in SQL)

User.search("hel", prefix: true)
User.search("hello worl", prefix: true)
User.search("hel", prefix: true).and("worl", prefix: true)
User.search("hello").and.not("worl", prefix: true)

Optional terms: documents containing the optional terms will rank higher than those without

User.search("foo").and("bar", optional: true).and("baz", optional: true)

Fuzzy terms: matches are performed based on Levenshtein distance. The maximum Levenshtein distance supported is 3.

User.search("zuchini", fuzziness: 1)

Search terms can also be scoped to specific fields using a where clause:

# Simple field specific query
User.search.where(name: "john")
# Using where with options
User.search.where(first: "jon", fuzziness: 1)
# Using where with more complex query
User.search.where(first: User.search("bill").or("bob"))

Searching for numeric fields accepts a range:

User.search.where(number: 0..100)
# Searching to infinity
User.search.where(number: 0..Float::INFINITY)
User.search.where(number: -Float::INFINITY..0)

When searching, by default a collection of Documents is returned. Calling #results on the search query will execute the search, and then look up all the found records in the database and return an ActiveRecord relation.

Another useful method redi_search adds is spellcheck and responds with suggestions for misspelled search terms.

User.spellcheck("jimy")
  RediSearch (1.1ms)  FT.SPELLCHECK user_idx jimy DISTANCE 1
=> [#<RediSearch::Spellcheck::Result:0x00007f805591c670
    term: "jimy",
    suggestions:
     [#<struct RediSearch::Spellcheck::Suggestion score=0.0006849315068493151, suggestion="jimmy">,
      #<struct RediSearch::Spellcheck::Suggestion score=0.00019569471624266145, suggestion="jim">]>]
User.spellcheck("jimy", distance: 2).first.suggestions
  RediSearch (0.5ms)  FT.SPELLCHECK user_idx jimy DISTANCE 2
=> [#<struct RediSearch::Spellcheck::Suggestion score=0.0006849315068493151, suggestion="jimmy">,
 #<struct RediSearch::Spellcheck::Suggestion score=0.00019569471624266145, suggestion="jim">]

Next time you are looking for a search engine give RediSearch a try! You can read about more options and see more examples on the README:

npezza93 / redi_search

Ruby wrapper around RediSearch that can integrate with Rails

RediSearch

A simple, but powerful, Ruby wrapper around RediSearch, a search engine on top of Redis.

Installation

Firstly, Redis and RediSearch need to be installed.

You can download Redis from https://redis.io/download, and check out installation instructions here. Alternatively, on macOS or Linux you can install via Homebrew.

To install RediSearch check out https://oss.redislabs.com/redisearch/Quick_Start.html. Once you have RediSearch built, if you are not using Docker, you can update your redis.conf file to always load the RediSearch module with loadmodule /path/to/redisearch.so. (On macOS the redis.conf file can be found at /usr/local/etc/redis.conf)

After Redis and RediSearch are up and running, add the following line to your Gemfile:

gem 'redi_search'

And then:

❯ bundle

Or install it yourself:

❯ gem install redi_search

and require it:

require 'redi_search'

Once the gem is installed and required you'll need to configure it with your Redis configuration. If you're on Rails, this should…

View on GitHub

Using Minitest's seed value to track down order-dependent flaky tests

Nick Pezza — Thu, 18 Jul 2019 02:30:27 +0000

When you run your test suite, ever wonder why --seed ##### gets outputted? Let's check it out and see how it's a useful debugging tool.

We will start with a simple test suite:

require "minitest/autorun"
require "redis"

class Task
  class << self
    attr_accessor :total_completed
  end

  attr_accessor :completed

  def complete
    Task.total_completed ||= 0
    Task.total_completed += 1
    self.completed = true
  end
end

class TaskTest < Minitest::Test
  def test_global_tracking
    assert Task.total_completed.nil?
  end

  def test_complete
    task = Task.new
    task.complete
    assert task.complete
  end
end

This test suite has two tests, one checks that there are no completed tasks and the other tests completing a task. Let's run the suite a few times and see how our tests fair:

❯ ruby test/flaky_test.rb
Run options: --seed 3199

# Running:

..

Finished in 0.000709s, 2820.8743 runs/s, 2820.8743 assertions/s.
2 runs, 2 assertions, 0 failures, 0 errors, 0 skips

❯ ruby test/flaky_test.rb
Run options: --seed 40573

# Running:

.F

Failure:
TaskTest#test_global_tracking [test/flaky_test.rb:20]:
Expected false to be truthy.


Finished in 0.000956s, 2092.0506 runs/s, 2092.0506 assertions/s.
2 runs, 2 assertions, 1 failures, 0 errors, 0 skips

Sure enough, we have a flaky test. The first time running the suite everything passes but the second time it fails at assert Task.total_completed.nil?.

Minitest runs all your tests in random order by default to help prevent tests from becoming order-dependent. In the above example, the test failure is caused because we neglected to reset the shared global state between tests. If test_global_tracking is run first, the suite will be green but if it is not, we will have a failure. Since this suite is small the bug is easy to spot but when your suite grows to have many test cases, it can become difficult to reproduce the exact scenario that produced the failure.

One crude method I've used over the years to debug this is changing the assertion into an if. Then upon failure call pry or puts the current state of things and then run the test suite inside an infinite loop on the command line until a failure triggers. This method is less than ideal for apps with large suites since it can become quite a time-consuming process to get just the right order.

seed to the rescue.

You can use the seed value of failed run as a command line option to rerun your tests in that same order.

❯ ruby test/flaky_test.rb --seed 40573
Run options: --seed 40573

# Running:

.F

Failure:
TaskTest#test_global_tracking [test/flaky_test.rb:20]:
Expected false to be truthy.

Finished in 0.001082s, 1848.4287 runs/s, 1848.4287 assertions/s.
2 runs, 2 assertions, 1 failures, 0 errors, 0 skips

❯ ruby test/flaky_test.rb --seed 40573
Run options: --seed 40573

# Running:

.F

Failure:
TaskTest#test_global_tracking [test/flaky_test.rb:20]:
Expected false to be truthy.

Finished in 0.001134s, 1763.6684 runs/s, 1763.6684 assertions/s.
2 runs, 2 assertions, 1 failures, 0 errors, 0 skips

Whohoo 🎉! Now we can dive straight into debugging reliably and skip waiting for our test suite to be in just the right order.

Archipelago v3 is out!

Nick Pezza — Fri, 21 Dec 2018 20:09:23 +0000

Archipelago is a terminal inspired by Hyper. I started using Hyper as my default terminal while it was in beta and into v1. It was by far the coolest, best looking, minimal, and extensible terminal emulator I had used. But, I found it to be really slow, to the point where if I was going to run a command that I knew would have a lot of output, I would opt for using a different terminal. Along with that, occasionally buffers would overlap making the terminal unreadable and force me to restart.

At the time Hyper was using Hterm which was the culprit of all my issues, but then I heard about the the Xterm.js project which was being used by SourceLair and Microsoft was using it inside of VSCode. Xterm.js solved all the problems I had encountered so a little over a year ago I started making Archipelago. Some of the stand out features include:

Tabs (You can also disable tabs if you use a multiplexer like TMUX exclusively)
Panes that can be split and resized
Cross platform (macOS, Linux, and Windows)
Theming which can be saved to a profile
Easy setting configuration
Searching through the scroll-back
A visor window that can be called from anywhere
A suite of system tests

Visit archipelago.pezza.co to see more gifs or download now to give it a shot!