DEV Community: Giorgos Tsiftsis

The process of upgrading gems

Giorgos Tsiftsis — Sat, 27 Jun 2020 14:48:28 +0000

Through the years, I have contributed to various Rails projects, from huge Rails apps like Skroutz.gr to fresh Rails 6 projects like Tefter.io and I have come to the following rules regarding Ruby gems and their upgrade process.

Let Bundler do its job. Do not use specific versions unless it is really needed.
If you want to set a specific version, be pessimistic. Use the twiddle-waka operator.
Do not host forked gems. Prefer to create PRs. If it is absolutely necessary to do this, set a goal to release your work to the public soon.
Be patient when new gem versions are released, except for security updates. Choose monthly or bi-monthly periods for updates and stick with them.
Use tools like Github's Dependabot alerts and protect your code as fast as possible. Better safe than sorry.
Do not update your gems blindly. Use tools like gemdiff to inspect the changes or at least the commit messages. Try to get an idea of what changes will be introduced to your repo.

Migrate an existing app to Turbolinks

Giorgos Tsiftsis — Fri, 08 May 2020 21:00:38 +0000

A few months ago we decided at Tefter to use Turbolinks with our main Ruby on Rails app, so we can take advantage of its features for better SPA look & feel and faster page loading - at least from the user perspective. Back then we had some Javascript files and we relied heavily on jQuery.

About Tefter

Before going into more detail about the specifics of the migration, let's talk about Tefter first. It's a tool aiming to optimize your web surfing routine, a combination of personal search-engine, a social bookmarking tool, and a place to archive stuff to read later and write notes. One would interact with Tefter through the Web app, the browser extension, the mobile, and the desktop apps or Slack!

Installation

The main repo has a ton of documentation that explains everything. Also, this post from the Hobeybadger team help us a lot at the beginning of the migration.

In our Gemfile we added:

gem 'turbolinks'

And installed it with Yarn:

yarn add turbolinks

Then in our packs/application.js file we import and start Turbolinks:

import Turbolinks from "turbolinks"
Turbolinks.start()

Migration

The steps we did for migration to work were the following:

We changed all document.ready with turbolinks:load events.

// Old
$(document).ready(function() { ...

// New
$(document).on('turbolinks:load', function() { ...

And all DOMContentLoaded events with turbolinks:load
We moved all logic from window.onload events to turbolinks:load
We did the same with window.resize events.
We made sure to clear Turbolinks cache before ajax requests

// Clear Turbolinks cache before ajax requests
document.addEventListener('ajax:before [data-remote]', () => {
  Turbolinks.clearCache();
});

We disabled Turbolinks for Facebook, Google, Slack, and Github omni-oauth sign up pages.
We disabled Turbolinks from other 3rd parties calls like Pocket authorization and Slack installation.
We noticed that we had problems with rendering some Javascript components like modals or tooltips (we use for example Micromodal and tippy). For those cases, we explicitly opted out from Turbolinks:

<div class="modal" data-turbolinks="false">

<%= link_to '#', class: 'tippy', data: { turbolinks: false } do %>

We experienced some rendering issues with views with different layouts. We should investigate these issues further but because there was only a simple case (our Readable view) we decided to opt out Turbolinks from it.
We had some hard times dealing with event listeners loaded inside turbolinks:load functions. We ended up using Stimulus and handle them inside connect() functions
In one case we wanted to make an ajax call and we discovered that we should add the security token.

$.ajax({
        url: someUrl,
        method: 'POST',
        beforeSend: function(xhr) { 
                     xhr.setRequestHeader('X-CSRF-Token', 
                     $('meta[name="csrf-token"]').attr('content'))
                    },

We found some inconsistencies when we use turbolinks:onload and async javascript loading. We switched to defer.

Feelings

We have a small JavaScript codebase but the overall migration and bug fixing took us some time mainly due to our inexperiences with the Turbolinks architecture and its expectations. Overall the sign is positive. If you have an existing codebase be patient, there will be plenty of small bugs. Fortunately, one should get quickly familiar with solving them.

What you should consider next

Dealing with hex colors

Giorgos Tsiftsis — Tue, 21 Apr 2020 11:24:56 +0000

At Tefter we are a small team of two, mainly backend developers. Our good friend built the design of our service and a few months later we ended up with various hex colors here and there without knowing which one to choose for the next element. Of course, we have Sass so we started grouping our colors in variables.

We decided to name our codes using Colorhexa. We extracted all colors in a file named themes.scss, like this:

$cyan: #5fbec9;
// etc
// etc

When we found more than one color with the same name we took the approach of adding an inc number suffix without special order or hierarchy.

$very-dark-grey: #474747;
$very-dark-grey2: #666666;

After a couple of hours, we ended up with a list of our colors. First of all, we got a better understanding of our color palette. We found some colors that did not fit in our design, for example, we had a vivid blue somewhere in an input focus. From all 77 color variations, the most used are variations of grey and we took the opportunity to reduce some of them.

The next step was to start working on theming our product. We took a very simple approach. We had the named color variations and we wanted to associate the main components with these colors. So we used a hash map like this:

$colors: (
  // General
  h2: $very-dark-grey,
  h3: $very-dark-grey,
  background: $mostly-white,
  p: $very-dark-grey,
  hr: $light-greyish-blue3,

  // This is the default link color
  link: $black,
  link-before: $very-dark-grey,
  link-hover: $very-dark-grey,
  link-span: $dark-grey3,

  // Secondary link element
  secondary-link: $dark-grey,
  secondary-link-hover: $very-dark-grey,
  ...
  ...
  ...

We took a simple approach of converting these colors to css variables and providing a simple function to get the right color for each component using the prefers-colors-scheme. We decided to do this in order to prepare for dark mode theme in the near future. So in the same themes.scss file we added the following two functions:

// Converts scss variable into css variable
:root {
  @each $name, $color in $colors{
    --color-#{$name} : #{$color};
  }
  --theme: 'light';
}

// Creates a function to get color instead of using css varible
@function getColor($color-name){
  @return var(--color-#{$color-name});
}

And all we had to do is for each element that we have in our $colors map to associate it with the corresponding color. For example,

body {
  background: getColor(background);
  ...
  ...
}

Note that we did this only for the main components that have meaning to be part of the theme. This is not always straightforward and we did some back and forths in order to have a balance and a smaller color map to handle.

Conclusions

I am not a front-end developer and this was my first try of such CSS refactoring. In the end, we have all our colors in one file, we could start playing with different variations and provide different themes or working on dark theme easier and we could decide immediately which color to experiment with for our next component.

Maybe in larger codebases, this process will be endless but in smaller ones, it seems to work just fine!