DEV Community: Thomas Lombart

How to Make Slack Feel Calm and Productive

Thomas Lombart — Mon, 03 Jan 2022 06:58:27 +0000

Slack is one of the most popular communication tools in tech. As a developer, I use it every day to collaborate with my peers. This tool is packed with lots of features and does its job: making communication easy in a company or community. But there's one downside: Slack is designed to be an instant communication tool. And that is a disaster when you want to focus. You get mentioned in channels, you receive many direct messages, you catch up on threads, you see red dots everywhere. In the end, you are addicted to Slack and you end up with the bad habit of clicking on notifications or checking Slack every five minutes.

Don't worry, we've all been there before. There are lots of ways to make Slack calmer and we'll discover them right away. Let's get your focus back.

Get rid of notifications

Yeah, that one is obvious. If you're annoyed by the Slack notification sound, well get rid of notifications. They're a major source of distractions, which we can't afford as knowledge workers. You don't need to have a notification every time someone mentions you or uses a @here though the message is not that important.

Leave or mute useless channels

Maybe you're in of these channels that get lots of messages though you're inactive. Or maybe you joined a channel just for a one-time question or message.

Don't bother staying in these channels if you don't find any important messages and leave them. If leaving them sounds too extreme, you can also just mute them. The goal is to focus on channels that matter to you, not to know everything happening in your Slack workspace.

Quit Slack when focusing

Developers make work happen by building, fixing, or shipping stuff. And this happens mostly during focus, not in Slack. A simple solution to get your focus back is to quit Slack when you need to focus. That way, you're 100% sure you won't get disturbed by notifications or unread messages.

It can be disturbing at first since Slack excels at making you feel FOMO. But you get used to it. If you're too stressed about it, start small. Don't quit Slack for 2 hours, but 15 minutes. Then, increase the duration and adjust it to the amount of time needed to focus. Yes, you won't answer people but they often adjust to your response time to a certain extent.

If you don't feel comfortable quitting Slack, you can turn on Do Not Disturb (DND) mode by clicking on your profile and then Pause notifications. That would work as well. As a personal note, I prefer quitting Slack so I'm not tempted to switch to it during my focus periods.

Note: make sure the persons you're working with are OK with this, though. We don't all have the chance to work in an environment of trust. If it's impossible for you, use the Do Not Disturb mode.

Customize Slack

Slack has lots of customization options and that's a good thing to reduce the noise you get by default.

Group channels into sections

If there are too many channels and you get lost in them, you can use sections for a better organization. Here are two possible organizations:

Group channels by category: team, company, skills (front-end, back-end, product for example)
Group channels by priority: high priority, medium priority, low priority.

I like to use the latter organization. I have a section called Priority for all important channels, another section called End of day for channels I want to check at... the end of the day. I don't check often the rest of the channels unless I'm looking for something really specific.

This feature is only for Slack paid subscriptions. You may not be able to use it depending on your workspace.

Note that you can also show only unread conversations for certain sections. That way, you have a clearer view of channels and messages to catch up with when you come back on Slack after a focus session.

Change the colors

I find Slack's default UI to be aggressive on the eye. Luckily, it's possible to change the colors by going to the preferences in the theme section:

That is perfect, especially for one thing: the mention badge. You see, I'm the kind of person who doesn't like having unread notifications. And this red badge makes me want to click it every time I see it. Reducing the contrast makes them less visible and makes me more OK in not clicking it directly. Here's a comparison:

After customizing the mention badge:

Communicate better

Use threads and reactions

Slack's channels are sometimes used as an instant conversation between channel members. That's the perfect recipe to add noise to the channel and make information harder to find. For that reason, it's better to use threads. This makes topics more scannable and people who are not interested in the original message don't have to read unwanted messages. Nice and clean.

Note: threads are great to reduce channel messages. But when you're mentioned in one, you get notifications for the upcoming replies. Like channels, you can mute threads. Think of it in case of heated discussions.

Slack has another neat feature to reduce noise: reactions. They're great for saving you all kinds of messages and making the workspace calmer. So, instead of saying something like "OK for me", you can just react with a checkmark (✅). Another example, instead of saying "I’m taking a look", you can add the eyes emoji (👀)

Write longer messages

We've seen so far how to make Slack calm with some of their tools. We can go further. Indeed, a big part of the noise created comes from the way you communicate with your teammates.

It's common to receive messages from people who type as they think, the kind of person who makes your mention badge go from 1 to 9+ in the blink of an eye.

We can't blame them after all! Slack has decided to use a one-line input instead of a multiline one for writing messages. No wonder everyone thinks in terms of one-line messages!

Take instead the habit of writing longer, cleaner messages. It doesn't mean that you need to write great walls of text, though. You want to aim for a message that goes straight to the point and gives all the required information to reduce back and forth.

A good technique to write a clean yet detailed message is to use the BLUF (Bottom Line Up Front) approach: put the critical information at the beginning, then follow with the context and details.

Let's take an example. You encounter a bug that you don't know how to fix. So, you write a message asking for help:

Hey everyone! I worked on project X this morning and something surprised me while I was testing stuff. I went to this page, I clicked on this button and I got an error. I don't understand why it happens since I can't reproduce it in my local environment. My guess is that maybe something happens during the build but I'm not entirely sure of that. Can someone help me? It would be greatly appreciated!

As you can see, it's hard to find the message's purpose and details. Let's take the BLUF approach to make it clearer:

Can someone help me with a bug I can't reproduce locally happening on this page?

I worked on project X this morning and I found a bug happening on this page when clicking on that button. I haven't been able to reproduce it in my local environment. I guess something goes wrong during the build, but I'm not entirely sure of that.

I'm available for a pair-programming session this morning from 10 AM to 11 AM if someone's up for the challenge.

Now, we directly get what's the person asking which is better to make a channel more scannable.

Writing better is a large topic. Instead of making this article way longer than it needs to be, here's a resource I highly recommend on how to write better at work: How to Write For the Way Your Coworkers Actually Read.

Record videos

Sometimes, it's hard to explain things by writing them. Maybe you need to support your message with images or demos, or maybe it's just a complex topic that can be hard to deconstruct. In this case, why not send async videos? They're perfect for these use-cases and can even spare you a few meetings. In case you're wondering, Slack has a built-in tool to send videos:

You're not limited to Slack only. There are other great apps to do recordings like Loom, CleanShot, or simply your OS's built-in tool.

Use a Slack status

People are more likely to send you messages if you're marked as available. Think of using Slack statuses so that others know what you're up to. This has two benefits:

Maybe, they'll get back to you later when you'll be available for chatting.
They'll know what you're doing and see that you have a good reason for not answering.

A nice integration you can put into Slack is the Google Calendar app if you use it. This app syncs your meetings with your status so that others know when you're in a meeting or not. Handy!

Conclusion

Sure, Slack is an instant messaging tool at its core but it's possible to reduce all the noise you get: by controlling your notifications, customizing Slack, or simply writing with an asynchronous-first mindset. Hopefully, these tips will make your Slack workspace a more focused place.

Reverse-Engineering Airbnb’s Internationalization Library

Thomas Lombart — Fri, 26 Nov 2021 19:28:14 +0000

This post has originally been written in 2019. I wanted to migrate it to DEV.to so you may stumble upon outdated things 😊

Curiosity is one of the most essential developer's assets. By being curious and experimenting with things, you make sure you're continually learning and upgrading your skills. A while ago, I had to implement internationalization for an app I was working on. I chose to use Polyglot because of its simplicity. It's also created by Airbnb, a company with many great open sources libraries.

When I used Polyglot, I wondered what was going on under the hood. So I decided to do a little bit of reverse-engineering by diving into the source code. And here I am, sharing with you what I've learned along the way.

You'll find many code snippets below. Most of them come from the source code of Polyglot itself. This article aims to give you more explanations about that code, its purpose, and its use.

Recap about the library

But first, let's do a recap about the library. Basically, Polyglot handles the internationalization of your app including interpolation and pluralization. You give it a set of translated phrases and you retrieve the ones you want using a special function called t:

const polyglot = new Polyglot({
  phrases: {
    hello: "Hello",
    morning: "Morning",
    auth: {
      login: "Login",
      register: "Register",
    },
  },
});

polyglot.t("hello"); // Hello
polyglot.t("morning"); // Morning
polyglot.t("auth.login"); // Login

Notice how Polyglot handles nested objects.

If you want to add more phrases to the Polyglot instance, you can use the extend method:

Polyglot.extend({
  bye: "Bye!",
});

Polyglot supports interpolation. Roughly speaking, it consists in replacing some placeholders in your phrase by a real value:

polyglot.extend({
  welcome: "Welcome %{name}",
});

polyglot.t("welcome", { name: "Thomas" }); // Welcome Thomas

If you don't provide one of the interpolation value, Polyglot will return your placeholder as-is. It can be useful if you want to do partial interpolation:

Polyglot.extend({
  user: "My name is %{name}. I love %{hobby}!",
});

polyglot.t("user", { name: "Thomas" }); // My name is Thomas. I love %{hobby}

You can also provide your own interpolation syntax:

const polyglot = new Polyglot({
  interpolation: { prefix: "{{", suffix: "}}" },
});

polyglot.extend({
  city: "You live in {{city}}",
});

polyglot.t("city", { city: "London" }); // You live in London

Finally, Polyglot handles pluralization, that is to say, express a sentence in the plural form. To make it work properly, Polyglot needs a locale (which is en by default):

polyglot.locale(); // 'en'
polyglot.extend({
  thing: "There is %{smart_count} thing |||| There are %{smart_count} things",
});

polyglot.t("thing", { smart_count: 1 }); // There is 1 thing

Giving a number as a second argument also works:

Polyglot.t("thing", 4); // There are 4 things

If you need to set the locale, you have two choices:

Call the locale method with its corresponding code
Provide the locale during the instantiation

polyglot.locale("fr");
// OR
const polyglot = new Polyglot({ locale: "fr" });

What's great is that Polyglot supports many locales, dozens of locales!

And then the less-used features:

unset to remove a key from Polyglot's phrases
clear to remove all the phrases from the Polyglot instance
replace to replace the current phrases with others
has to check if a translation exists for a given key

polyglot.unset("hello");
polyglot.unset({
  hello: "Hello",
  auth: {
    register: "Register",
  },
});

polyglot.replace({
  hello: "Hey!",
  bye: "Bye-bye",
});

polyglot.clear();

polyglot.has("hello"); // true

You may think that the translation itself is easy to do. In fact, it's just returning a value of an object based on a key. But what about nested key objects? The interpolation feature? Or the pluralization? And handling the pluralization for all the locales? 🤔

Don't worry, we'll figure it out right away.

Translate a simple phrase

Let's start with the simplest feature: translate a simple phrase. It's as easy as getting a key from an object. Internally, when you create an instance of Polyglot, an empty phrases object is created. You can then extend it by providing some phrases in the options object:

function Polyglot(options) {
  var opts = options || {};
  this.phrases = {};
  this.extend(opts.phrases || {});
  // ...
}

We instanciate Polyglot like this:

const polyglot = new Polyglot(); // phrases -> {}
const polyglot = new Polyglot({ phrases: { hello: "Hello" } }); // extend({hello: 'Hello'}) is called

Polyglot makes use of short-circuit evaluation. This complicated term means JavaScript takes advantage of logical operators such as || (OR) to evaluate just what's necessary. Thus, if options is undefined or null, JavaScript will assign {} to opts as the first operand evaluates to false. But if options is set, it won't even look at the rest of the expression and assign options to opts.

Polyglot uses extend to map a given key to a given phrase in its internal phrases object. We'll come back to it in a few moments.

Other things happen when you instanciate Polyglot including this:

function Polyglot(options) {
  var opts = options || {};
  // ...
  this.currentLocale = opts.locale || "en";
  // ...
  this.tokenRegex = constructTokenRegex(opts.interpolation);
}

The currentLocale is set to a given locale or en and a mysterious tokenRegex is created. These properties are important for interpolation and pluralization.

Then, when we'll call t with a given key, Polyglot will search its associated value in the internal phrases object. Once found, it will apply to the phrase some transformations (interpolation and pluralization) and return it:

Polyglot.prototype.t = function (key, options) {
  var phrase, result;
  var opts = options == null ? {} : options;
  if (typeof this.phrases[key] === "string") {
    phrase = this.phrases[key];
  }
  // ...
  if (typeof phrase === "string") {
    result = transformPhrase(phrase, opts, this.currentLocale, this.tokenRegex);
  }
  return result;
};

"What an odd way to declare a method", you might say. Why not simply use the class keyword?

Because JavaScript is continuously evolving. When this library was written, there were no such things as classes (as well as const and let). It was only introduced in 2015. So we had to create classes by using constructor functions.

But, functions being functions, it's not efficient to put all methods inside a constructor function. That would mean that every function inside the constructor function would be created at each instantiation!

That's why there is a prototype property inside every function: by putting a method in the prototype property, you share it across all instances of your function. Check out this resource to learn more about prototypes.

By the way, classes in JavaScript are also constructor functions. Go ahead and define a class. You'll see its type is Function. Interesting, isn't it?

Extend

The most attentive of you will think "But what if our phrases object has inner objects? I don't see how t handles the nested objects? It only transforms the phrase if the type of the phrase is a string, right?"

That's a legit question. As said in the recap, Polyglot handles nested phrases objects. Under the hood, It uses the extend method to add new phrases to the instance. This method recursively processes all the keys in the object passed as an argument and puts them at the root level of the internal phrases object. Each nested key is concatenated with the one that's one level above it using the dot notation:

var forEach = require("for-each");

// ...

Polyglot.prototype.extend = function (morePhrases, prefix) {
  forEach(
    morePhrases,
    function (phrase, key) {
      var prefixedKey = prefix ? prefix + "." + key : key;
      if (typeof phrase === "object") {
        this.extend(phrase, prefixedKey);
      } else {
        this.phrases[prefixedKey] = phrase;
      }
    },
    this
  );
};

Note: Polyglot uses a package called for-each to iterate over both objects and arrays. It acts as a polyfill so that Polyglot doesn't require added methods like Array.prototype.forEach. Suppose you wonder what the third this argument passed to forEach is. In that case, it allows specifying what is this in the callback function (the second argument). In our case, this refers to an instance of Polyglot.

Let's see what happens if you call extend like this:

polyglot.extend({
  hello: "Hello",
  auth: {
    login: "Login",
    register: "Register",
  },
});

For the hello key, prefix will be undefined so prefixedKey = hello. The corresponding phrase (Hello) is a string, so we map Hello to hello in the internal phrases.
For auth, there is still no prefix, so prefixedKey = auth. However, phrase is an object, so we'll recursively call extend with phrase and prefixedKey: this.extend({ login: 'Login', register: 'Register' }, 'auth').
For login, there is a prefix which is auth, so prefixedKey = auth.login. Here phrase is a string so we map Login to auth.login in the internal phrases.
It's exactly the same behavior for register.

That way, you make sure you traverse all your objects and map every key to a string value in the flattened phrases object. After calling extend, your phrases look like this:

{
  hello: 'Hello',
  auth.login: 'Login',
  auth.register: 'Register'
}

Note that extend actually extends the phrases object and doesn't replace it. The only things that can be replaced are the conflicting keys. For example, if you call extend with an object with a hello key and that key already exists in phrases, the old key will be replaced with the new one.

Interpolation

Let's come back to transformPhrase, shall we? You may remember that we use it in the t function to transform the phrase we get via our key:

if (typeof phrase === "string") {
  result = transformPhrase(phrase, opts, this.currentLocale, this.tokenRegex);
}

We'll dive into its code to understand how one can build the interpolation feature.

Here, the interpolation feature consists of replacing a generic word with another one in an object. What's great is that String.prototype.replace does most of the work for us. Indeed, according to MDN, The replace method returns a new string with some or all matches of a pattern replaced by a replacement. You just need to define a regular expression to capture what you need to replace and fetch the corresponding word in the options object.

var has = require("has");

// ...

var replace = String.prototype.replace;

// ...

var defaultTokenRegex = /%\{(.*?)\}/g;

function transformPhrase(phrase, substitutions, locale, tokenRegex) {
  // ...

  var result = phrase;
  var interpolationRegex = tokenRegex || defaultTokenRegex;

  var options =
    typeof substitutions === "number"
      ? { smart_count: substitutions }
      : substitutions;

  result = replace.call(
    result,
    interpolationRegex,
    function (expression, argument) {
      if (!has(options, argument) || options[argument] == null) {
        return expression;
      }
      return replace.call(options[argument], dollarRegex, dollarBillsYall);
    }
  );

  return result;
}

This is how interpolation is done under the hood. Not less, not more. But you may be unfamiliar with things like call or String.prototype.replace.

Three essential things are done before calling transformPhrase:

We require the has package which is a shortcut for Object.prototype.hasOwnProperty.call.
We cache the String.prototype.replace method.
We create the defaultRegexToken used to match the generic words in our phrases. Basically, this regex means "match anything that is included inside %{}". Note that this regular expression is lazy (.*?) instead of greedy (.*). In other words, it means this regexp will capture the smallest group possible.

That being said, we can learn how transformPhrase behaves.

It takes four parameters: phrase, substitutions, locale and tokenRegex. We won't need locale for now as it's needed for pluralization. Then, we assign to interpolationRegex the regex that will be used for the replacements. It can be a custom regex (remember the mysterious tokenRegex in the constructor?) or the defaultTokenRegex explained above.

Beforehand, we assign to options the value of substitutions. The typeof check is done for pluralization. You don't have to care about it for now.

Then, we actually replace the phrase using the regular expression. As the replace function is cached, we need to use the call method to specify on which string we want to invoke the replace function, that is to say, result. If using call confuses you, it's the same as:

result = result.replace(interpolationRegex, function (expression, argument) {
  if (!has(options, argument) || options[argument] == null) {
    return expression;
  }
  return replace.call(options[argument], dollarRegex, dollarBillsYall);
});

The second argument of replace can either have the form of a string or a function. Here we use the function because we need to retrieve the eventual generic word's value in the options. This function will be run on every match with the following arguments:

expression: refers to the match itself, %{name} for example.
argument: refers to the captured group ((.*?)), that is to say, everything inside the interpolation syntax. By default, it is everything inside %{}.

If the captured string is a property of the options object passed to t and is different than null, then we return its associated value otherwise, we return the expression itself. The returned value will be used as a replacement for the match.

Let's apply it on an example to fully understand it:

Polyglot.extend({
  user: "Hi, your name is %{name}. You are a %{job} and you like %{hobby}.",
});

polyglot.t("user", {
  name: "Thomas",
  hobby: "traveling",
});

We assume we haven't provided any custom interpolation syntax to Polyglot. Then, interpolationRegex is equal to /%\{(.*?)\}/g.

We call replace on the phrase 'Hi, your name is %{name}. You are a %{job} and you like %{hobby}.'. We'll have three matches: %{name}, %{job} and %{hobby}. For every match, we run replace's callback function:

expression = %{name}, argument = name. Is name in the options object? Yes, then return the associated value: Thomas.
expression = %{job}, argument = job. Is job in the options object? No, return the expression: %{job}.
expression = %{hobby}, argument = hobby. Is hobby in the options object? Yes, then return the associated value: traveling.

The result of the translation is: Hi, your name is Thomas. You are a %{job}, and you like traveling. That's not rocket science, after all! 😉

Custom interpolation syntax

We saw how to implement interpolation. Let's see how to customize the interpolation syntax. Indeed, Polyglot allows you to customize the prefix and the suffix so that you can use {{name}} or |name| instead of %{name}.

"Easy", you might think. "Just change the regex!". And you would be right. That's what Polyglot does. It uses a custom regex called tokenRegex that is built when you create an instance of Polyglot:

function Polyglot(options) {
  var opts = options || {};
  // ...
  this.tokenRegex = constructTokenRegex(opts.interpolation);
}

This tokenRegex is then passed to transformPhrase when you call t on a key. It is assigned to interpolationRegex if it holds a value:

function transformPhrase(phrase, substitutions, locale, tokenRegex) {
  // ...
  var interpolationRegex = tokenRegex || defaultTokenRegex;
  // ...
}

constructTokenRegex is a fairly simple function. Its purpose is to return a new regex based on the given prefix and suffix:

var delimiter = "||||";

// ...

function escape(token) {
  return token.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
}

function constructTokenRegex(opts) {
  var prefix = (opts && opts.prefix) || "%{";
  var suffix = (opts && opts.suffix) || "}";

  if (prefix === delimiter || suffix === delimiter) {
    throw new RangeError(
      '"' + delimiter + '" token is reserved for pluralization'
    );
  }

  return new RegExp(escape(prefix) + "(.*?)" + escape(suffix), "g");
}

There are two things to consider, though:

It's not possible to choose a prefix or a suffix that is equal to |||| as it's used for pluralization.
We must escape the prefix and the suffix. But why is that? Well, you'll probably use special characters such as {, or [ or maybe *. However, these symbols are special regex characters, so we need to escape them with a backslash. That's the responsibility of the escape function. It will replace the regex symbol with a backslash followed by the matched symbol (corresponds to $&).

As an example, constructTokenRegex({ prefix: '[[', suffix: ']]' }) returns /\[\[(.*?)\]\]/g (and not /[[(.*?)]]/g ⚠️).

Smart count and plural groups

Now the second part of transformPhrase: pluralization. That one can be tough to build. Indeed, you have to make it possible for Polyglot to choose a phrase among others both based on a number and a locale. But a language can be radically different from another, plural forms included. For example, did you know that there are no plural forms in Chinese, but there are six in Arabic? Or that in French, zero is singular while it's plural in English? To make pluralization happen, we need to take account of all these rules.

Note: If you're interested, here are the other plural rules.

Roughly speaking, here's what Polyglot does:

Reference all possible rules and map them to the corresponding locales.
When you translate a phrase that need to be pluralized (with the smart_count option), split it in multiple phrases based on a delimiter. Thus, you get an array of phrases (more precisely, all the plural forms of the phrase).
Retrieve the rule associated with the locale given to Polyglot. This rule takes a number as a parameter and returns another number indicating which plural form to choose.
Returns the correct phrase using the number returned by the rule (which acts as an array index).

We are going to detail this step by step.

First, here is an extract of all the rules and their corresponding locales:

var russianPluralGroups = function (n) {
  var lastTwo = n % 100;
  var end = lastTwo % 10;
  if (lastTwo !== 11 && end === 1) {
    return 0;
  }
  if (2 <= end && end <= 4 && !(lastTwo >= 12 && lastTwo <= 14)) {
    return 1;
  }
  return 2;
};

var pluralTypes = {
  arabic: function (n) {
    // http://www.arabeyes.org/Plural_Forms
    if (n < 3) {
      return n;
    }
    var lastTwo = n % 100;
    if (lastTwo >= 3 && lastTwo <= 10) return 3;
    return lastTwo >= 11 ? 4 : 5;
  },
  bosnian_serbian: russianPluralGroups,
  chinese: function () {
    return 0;
  },
  croatian: russianPluralGroups,
  french: function (n) {
    return n > 1 ? 1 : 0;
  },
  german: function (n) {
    return n !== 1 ? 1 : 0;
  },
  // ...
};

var pluralTypeToLanguages = {
  arabic: ["ar"],
  bosnian_serbian: ["bs-Latn-BA", "bs-Cyrl-BA", "srl-RS", "sr-RS"],
  chinese: [
    "id",
    "id-ID",
    "ja",
    "ko",
    "ko-KR",
    "lo",
    "ms",
    "th",
    "th-TH",
    "zh",
  ],
  croatian: ["hr", "hr-HR"],
  german: [
    "fa",
    "da",
    "de",
    "en",
    "es",
    "fi",
    "el",
    "he",
    "hi-IN",
    "hu",
    "hu-HU",
    "it",
    "nl",
    "no",
    "pt",
    "sv",
    "tr",
  ],
  french: ["fr", "tl", "pt-br"],
  // ...
};

You can see, for example, that for a german rule (which includes English), we return the plural form if the number is different than one, otherwise, we return the singular form.

Now we can focus on the pluralization part of transformPhrase. Here we will take account of the locale parameter. The currentLocale value of Polyglot is passed to transformPhrase when calling t:

if (typeof phrase === "string") {
  result = transformPhrase(phrase, opts, this.currentLocale, this.tokenRegex);
}

To make pluralization happen, you need to add a smart_count in your options (substitutions object). Note that you can also pass a number instead of an options object. Polyglot will take that shortcut and transform it back to an options object with a smart_count property.

var trim = require("string.prototype.trim");

// ...

var split = String.prototype.split;

// ...

var delimiter = "||||";

// ...

function transformPhrase(phrase, substitutions, locale, tokenRegex) {
  // ...

  if (substitutions == null) {
    return phrase;
  }

  var result = phrase;

  var options =
    typeof substitutions === "number"
      ? { smart_count: substitutions }
      : substitutions;

  if (options.smart_count != null && result) {
    var texts = split.call(result, delimiter);
    result = trim(
      texts[pluralTypeIndex(locale || "en", options.smart_count)] || texts[0]
    );
  }

  // Interpolation code...

  return result;
}

Step two. If we do have a smart_count option, we split the phrase into multiple parts thanks to the delimiter (||||). As we are caching split, we need to invoke the result function thanks to the call method. For example:

var phrase = "I have one thing |||| I have many things";
phrases.split("||||"); // ['I have one thing ', ' I have many things']

Then, step 3. We need to retrieve the rule associated with our locale. This happens thanks to the pluralTypeIndex function.

Basically, pluralTypeIndex takes a locale and a count. It invokes one of the functions defined in pluralTypes with count as a parameter. It can be arabic(3), for example.

function pluralTypeIndex(locale, count) {
  return pluralTypes[pluralTypeName(locale)](count);
}

Nevertheless, we need to know beforehand which language rules our locale refers to. That's what pluralTypeName does.

function langToTypeMap(mapping) {
  var ret = {};
  forEach(mapping, function (langs, type) {
    forEach(langs, function (lang) {
      ret[lang] = type;
    });
  });
  return ret;
}

function pluralTypeName(locale) {
  var langToPluralType = langToTypeMap(pluralTypeToLanguages);
  return (
    langToPluralType[locale] ||
    langToPluralType[split.call(locale, /-/, 1)[0]] ||
    langToPluralType.en
  );
}

After building the map that associates a locale to the correct plural rule, we lookup in this map for the value of the given locale.

You have to deal with one edge case here. Indeed, the locale can sometimes be composed and missing in the corresponding map. In that case, we first try to return the rule associated with the first part of the locale. Otherwise, we return the one associated to en (german).

If you struggle to see what the langToPluralType map looks like, here is an extract:

{
  ar: 'arabic',
  'bs-Latn-BA': 'bosnian_serbian',
  'bs-Cyrl-BA': 'bosnian_serbian',
  'srl-RS': 'bosnian_serbian',
  'sr-RS': 'bosnian_serbian',
  id: 'chinese',
  'id-ID': 'chinese',
  // ...
  'th-TH': 'chinese',
  zh: 'chinese',
  hr: 'croatian',
  'hr-HR': 'croatian',
  fa: 'german',
  da: 'german',
  de: 'german',
  en: 'german',
  // ...
}

Let's say we have fa as a locale. Invoking pluralTypeName will lookup in the map above if fa is mapped to a value. It turns out it is, so it will return german.

However, in the case of en-US, it doesn't correspond to anything in the map, so it will split this locale based on -, and will retrieve the first part of it: en. Thus, we have a locale to look for in the map.

Finally, in pluralTypeIndex, we can invoke the correct language rule to the function with the count. The result of that function will be trimed as there may be some whitespaces between the end (or beginning) of the phrase and ||||.

Note: We are thinking in terms of indexes. It implies that your phrases should be delimited in ascending order and that you should be exhaustive on the possible plural forms your phrase may take. Otherwise, Polyglot may just return the first phrase.

Let's recap pluralization on an example:

const polyglot = new Polyglot();
polyglot.extend({
  thing: "There is %{smart_count} thing |||| There are %{smart_count} things",
});

polyglot.t("thing", { smart_count: 1 });

We haven't provided a locale to polyglot, so it's en by default.

Is there a smart_count on the options or is it a number? Yes, let's know which phrase to return.
Split the phrase in multiple phrases: ['There is %{smart_count} thing ', ' There are %{smart_count} things']
After building the langToPluralType map, we retrieve the plural rule associated to en, that is to say german.
Let's invoke the german function with the correct count: german(1)
The german rule checks the following: n !== 1 ? 1 : 0. Here, 1 is not different from 1, then return 0.
Select the first phrase (index 0) from the multiple phrases and trim it: There is %{smart_count} thing.
Interpolation: replace smart_count in the phrase: There is 1 thing.

Another example:

const polyglot = new Polyglot({ locale: "fr" });
polyglot.extend({
  thing: "Il n'y a rien |||| Il y a plein de choses",
});

polyglot.t("thing", 4);

Here the locale is fr.

Is there a smart_count on the options or is it a number? Yes, let's know which phrase to return.
Split the phrase in multiple phrases: ["Il n'y a rien ", " Il y a plein de choses"]
After building the langToPluralType map, we retrieve the plural rule associated to fr, that is to say french.
Let's invoke the french function with the correct count: french(4)
The french rule checks the following: n > 1 ? 1 : 0. Here, 4 is greater than 1, then return 1.
Select the second phrase (index 1) from the multiple phrases and trim it: Il y a plein de choses.

Other features

Are you still with me? Great. The next methods are pretty easy to understand. They act more as utilities instead as a feature on their own.

Unset

unset is quite similar to extend code-wise. It takes a parameter that can either be a string or an object. If it's a string, delete the key from the internal phrases object. If it's an object, iterate over the keys of the object passed and remove them if the associated value if it's not an object. Otherwise, apply the unset function on the associated object value:

Polyglot.prototype.unset = function (morePhrases, prefix) {
  if (typeof morePhrases === "string") {
    delete this.phrases[morePhrases];
  } else {
    forEach(
      morePhrases,
      function (phrase, key) {
        var prefixedKey = prefix ? prefix + "." + key : key;
        if (typeof phrase === "object") {
          this.unset(phrase, prefixedKey);
        } else {
          delete this.phrases[prefixedKey];
        }
      },
      this
    );
  }
};

Clear

As you have an internal phrases object that contains all your keys and phrases, clear is fairly simple. Just empty the object:

Polyglot.prototype.clear = function () {
  this.phrases = {};
};

Replace

replace allows you to replace your current set of phrases by another one. So you just need to clear the current phrases and extend it with the other set:

Polyglot.prototype.replace = function (newPhrases) {
  this.clear();
  this.extend(newPhrases);
};

Has

As we already require an has package that checks for a key in an object, we just have to apply the has function on the internal phrases with a given key:

Polyglot.prototype.has = function (key) {
  return has(this.phrases, key);
};

Locale

The locale method has two behaviors:

If a new locale is provided, set the internal currentLocale to it.
Otherwise, return the current locale.

Polyglot.prototype.locale = function (newLocale) {
  if (newLocale) this.currentLocale = newLocale;
  return this.currentLocale;
};

What I've learned

We're done with the code! Reverse-engineering a library is a great way to upgrade your skills. By diving into the code source of Polyglot, I had the opportunity to enhance my knowledge of:

How to handle the internationalization in an application
Prototypes, the prototype chain, and closures
Regular expressions and their use in String.prototype.replace
Using call to apply a function to another object
The plural rules specific to each language

I'm convinced that the most effective way to learn is by learning from real-world examples and practicing. The theory is great to a certain extent. I highly encourage you to do more reverse-engineering, and I hope that this article gave you the will to do so.

How the Github CLI Saves Me Time Every Day

Thomas Lombart — Thu, 08 Oct 2020 12:03:35 +0000

What if I told you it's possible to manage your GitHub repository within the CLI? No more pointing and clicking on a user interface, just commands. That would mean faster work with less context-switching, right? Brace yourself. GitHub's official command line is right here for you.

Triaging issues, creating or checking out pull requests, releasing packages, forking repos, even creating gists can now be done from your terminal. And we all know its power and how fast it can be. Using GitHub CLI has been a real win for my workflow. Want to learn more? It all happens down here. 👇

Getting started

First things first, installing GitHub CLI. If you're a macOS user, run brew install gh. If you're a Windows user, you can install it via scoop or Chocolatey. As for Linux, you have great installation instructions here: Installing gh on Linux.

It's installed? Good. As said previously, GitHub CLI aims at managing your workflow directly from the terminal. But it needs to have access to your account for that:

gh auth login

You'll be prompted to configure your preferred Git protocol, pick whatever suits you here. If you choose SSH, make sure you added a SSH key to your account.

Finally, set your preferred editor. In my case, I mostly work with VS Code. Thus, I ran:

gh config set editor "code --wait"

Note: The --wait option is essential here. Indeed, when you are prompted to enter a longer message (such as a pull request's body), the CLI needs to have a signal you're done, such as closing a VS Code window.

You're now good to go.

Commands

What can GitHub CLI do for you? Good question. As with most CLIs, you have a dedicated help command for that:

➜ gh help
Work seamlessly with GitHub from the command line.

USAGE
  gh <command> <subcommand> [flags]

CORE COMMANDS
  gist:       Create gists
  issue:      Manage issues
  pr:         Manage pull requests
  release:    Manage GitHub releases
  repo:       Create, clone, fork, and view repositories

ADDITIONAL COMMANDS
  alias:      Create command shortcuts
  api:        Make an authenticated GitHub API request
  auth:       Login, logout, and refresh your authentication
  completion: Generate shell completion scripts
  config:     Manage configuration for gh
  help:       Help about any command

FLAGS
  --help      Show help for command
  --version   Show gh version

EXAMPLES
  $ gh issue create
  $ gh repo clone cli/cli
  $ gh pr checkout 321

...

That's quite helpful. Most of the time, you'll use core commands. Use the --help option to know what you can do with each of them. Here's an example with the issue command:

➜ gh issue --help
Work with GitHub issues

USAGE
  gh issue <command> [flags]

CORE COMMANDS
  close:      Close issue
  create:     Create a new issue
  list:       List and filter issues in this repository
  reopen:     Reopen issue
  status:     Show status of relevant issues
  view:       View an issue

FLAGS
  -R, --repo OWNER/REPO   Select another repository using the OWNER/REPO format

INHERITED FLAGS
  --help   Show help for command

ARGUMENTS
  An issue can be supplied as argument in any of the following formats:
  - by number, e.g. "123"; or
  - by URL, e.g. "https://github.com/OWNER/REPO/issues/123".

EXAMPLES
  $ gh issue list
  $ gh issue create --label bug
  $ gh issue view --web

...

Now, I don't want to explain to you each command. On the official GitHub CLI website, you can find a well-explained manual of all these commands. Instead, I'm going to show you examples of how this CLI can improve your workflow in your everyday developer's life.

Examples

Create a PR

Let's say you work on a brand new feature for your company or open-source project. You finished the work and want to create a PR on GitHub. Usually, you would have gone to github.com to open the PR, right? Well, now, you can do exactly the same with gh pr create:

➜ gh pr create
? Where should we push the 'feat/signup' branch? company/repo

Creating pull request for feat/signup into master in company/repo

? Title feat(signup): Add signup screen
? Body <Received>
? What's next?  [Use arrows to move, type to filter]
> Submit
  Continue in browser
  Add metadata
  Cancel

As you can see, this command is interactive. I provided the title, the body in VS Code, and then submitted the PR in a snap.

Suppose you were to provide some metadata such as the reviewers, assignees, or labels. In that case, you could also do it by selecting Add metadata:

? What's next? Add metadata
? What would you like to add?  [Use arrows to move, space to select, <right> to all, <left> to none, type to filter]
  [ ]  Reviewers
> [x]  Assignees
  [ ]  Labels
  [ ]  Projects
  [ ]  Milestone

See relevant pull requests

It's common for a developer to have many tasks at once: your review is requested on a piece of code, you fix a bug while waiting for a review on one of your feature PRs. In that case, you may want to know the statuses to know your next actions:

> gh pr status

Relevant pull requests in company/repo

Current branch
  #234  fix(homepage): Avatar is not shown if account created with Google [fix/avatar]
  - Checks pending - Review required

Created by you
  #234  fix(homepage): Avatar is not shown if account created with Google [fix/avatar]
  - Checks pending - Review required
  #224  feat(signup): Add signup screen [feat/signup]
  ✓ Checks passing - Review required

Requesting a code review from you
  #231  docs(onboarding): Add docs on how to deploy on production [docs/onboarding]
  ✓ Checks passing

How convenient this command is. I know at a glance what's going on with your PRs:

Current branch: I'm working on a fix
Created by you: My fix has some checks pending, and I didn't get any reviews yet. I also have another opened PR that passes the checks, but I haven't received any reviews.
Requesting a code review from you: A PR on documentation has passed the checks and I need to give my review.

If I were to review the docs PR, I could simply type gh pr view 231, and view the PR on the terminal or on the web using the --web option.

Waiting for Travis

Let's say your PR is already opened and you got some review comments. You worked through your comments, pushed your code, and wanted to know if you can merge the PR. Maybe you've set up Travis CI, and you're waiting for the build to pass:

> gh pr checks

➜ gh pr checks
All checks were successful
0 failing, 1 successful, and 0 pending checks

✓  Travis CI - Pull Request  5m26s  https://travis-ci.com/github/comp...

(Let's be honest, one of our favorite tasks, as developers, is to wait for Travis, isn't it? 😄)

If everything's OK, you can also merge the PR right from your terminal:

gh pr merge

Testing a colleague's changes

Developers, when reviewing code, tend to focus on the code only. It's indeed faster, but perhaps it's worth it to check out the changes live. It allows you to have a better vision of what the code really implies and its value.

Now, you can check out your colleague's branch with GitHub CLI. Use the pr checkout along with the pull request's number, and you're good to go:

gh pr checkout 6838

As a front-end developer, I often use it to make sure the UI changes properly work.

Note that you can find an example of this command on GitHub directly:

src="/save-time-github-cli/github-open.png"
alt="A screenshot of GitHub's button open with"
/>

Your next issue

You're maintaining an open-source project, and you want to know what's the next thing you can work on. Then, you can browse your issues with the issue command:

> gh issue list

Showing 15 of 15 open issues in testing-library/eslint-plugin-testing-library

#227  [await-async-utils] false p...  (bug)                           about 23 days ago
#222  [await-async-query] Support...  (help wanted)                   about 1 month ago
#219  feature request: no-await-f...                                  about 1 month ago
#202  Support eslint fix command ...  (enhancement)                   about 2 months ago
#198  Move custom render function...  (BREAKING CHANGE)               about 18 days ago
#187  Autogenerate configs from r...                                  about 3 months ago
:

Maybe you don't have much time and you want to fix a bug. Then, filter them with the --label option:

> gh issue list --label bug

Showing 2 of 2 issues in testing-library/eslint-plugin-testing-library that match your search

#227  [await-async-utils] false positive pr...  (bug)  about 23 days ago
#141  Lint RenderResult when returned from ...  (bug)  about 2 months ago

There are lot of other filtering options. Don't hesitate to run gh issue list --help to know more.

Quick approval

Someone at your company spotted a bug in production and needs to quickly ship a small fix. Let's say its PR is the number #211. You can approve it in just two commands:

Visualize the changes: gh pr diff 211
Approve the PR gh pr review 211 --approve

Your colleague gets a fast approval and you don't fully interrupt your workflow. I call that a win-win.

Contributing to an open-source project

At the time of writing, it's the 2020 edition of Hacktoberfest. Maybe you want to make a contribution to open-source. Usually, that includes forking a repo:

➜ gh repo fork organization/repo
- Forking organization/repo...
✓ Created fork user/organization/repo
? Would you like to clone the fork? Yes
Cloning into 'repo'...
...
✓ Cloned fork

Some maintainers label issues as good first issue for the newcomers. Then, you can search through them from the CLI:

gh issue list --label "good first issue"

Note: if you're considering contributing to a project? Please don't spam them with meaningless contributions such as adding "Amazing project" next to a title or similar. Open source maintainers are working hard on their beloved repos. ❤️

Using both GitHub and GitHub CLI

As you can see, GitHub CLI is powerful and can improve your workflow. It has already become a tool I'm using every day. Approving a pull request, finding an issue on which I can work, quickly see if a build pass, it's a real time-saver, and it has become a tool I'm using every day.

It doesn't mean you should use only GitHub CLI as of now. Don't forget the UI. For example, I still find it useful to do a complete review or browsing issues. Use what suits your needs best.

How to Become a Front-End Developer

Thomas Lombart — Mon, 28 Sep 2020 06:10:19 +0000

A few years ago, I became a software engineer, and I took the front-end path. Don't get me wrong, front-end development is not just HTML and CSS, far from it! You also have to know JavaScript, Git, performance, accessibility, design, and much more. Building an excellent front-end application is a challenging task.

The path to getting a job as a front-end developer is not an easy one. But you're lucky. I've been there, and I know what works and what doesn't to get hired! There are four main steps in this journey:

Getting the knowledge
Building projects
Searching for a job
Succeeding the interview

My goal with this post is to clarify how you can become a front-end developer and a good one. Without further ado, let's start with the knowledge and the resources to achieve this goal!

Getting the knowledge

Nowadays, front-end development is overwhelming. There's so much to learn! Maybe you think that you'll never get there. Trust me. You won't know it all. The good news is that you have to focus on learning the right things. However, you'll need to practice. Be active in your learning journey; it's the key to mastery!

You'll find below the required knowledge of front-end developers to have a successful career. I added some resources, how you could put your skills to practice, and the blog posts I wrote on this (because why not self-promoting? 😏)

Note: there's no partnership with the resources I included. I just found them well made.

HTML and CSS

HTML represents the structure of a web page, and CSS its layout. You'll use these two technologies every day, so you need to get comfortable with this!

Resources: You can check out freeCodeCamp, especially the basic HTML and basic CSS sections.
Practice: build a simple page. Maybe a landing page or a cooking recipe.
Blog posts: Writing Blazing Fast HTML Code, How to Get Better at Writing CSS and How to Make a Responsive Grid With Only Three Lines of CSS.

JavaScript

That's what powers up your apps. It's a programming language that is important to any web app. JavaScript is being used everywhere: for the servers, for desktop applications, or even for mobile apps! It's an essential skill for a front-end developer.

Resources: You can continue with freeCodeCamp on this one, or you can also check out a course from Wes Bos: Beginner JavaScript. If you're practice-oriented, I highly recommend JavaScript 30 from Wes Bos as well.
Practice: You should be able to build a first small app, such as a to-do app or a countdown.
Blog posts: What You Should Know About JavaScript Arrays and Object and Array Destructuring in JavaScript

CSS Framework

Pure CSS is good. But it's not always easy to write some. Try to learn a CSS framework like TailwindCSS, Bulma or Bootstrap. Such frameworks are often used in companies, and it's important to get familiar with them.

Resources: Tailwind CSS as a set of screencasts if you're interested. Generally just, reading the docs of the CSS frameworks is enough.
Practice: improve the page you build while learning HTML and CSS or the app you created with JavaScript. It's your choice!

Version control (Git & GitHub)

Version control is useful for working together on the same project. You can't escape it, so get comfortable with git commit, git push, or branches. You also need to learn how to work with a source code management platform such as GitHub, GitLab

Resources: Guides from GitHub especially the beginner one.
Practice: Create an account on GitHub. Add the previous projects you made (landing page, to-do app, or anything code-related you did). It'll make you practice the famous git status git add, git commit, git push.

JS Framework

Most companies don't work with pure JS. They use a framework that allows them to be more productive and write great apps. There are three leading solutions on the market right now: React, Vue, and Angular (though it tends to be less used). React and Vue are the most popular, so I strongly recommend learning one of them to optimize your chances of getting hired.

By learning a JS framework, you'll learn package managers such as npm and yarn. You'll also learn some tooling and how to interact with APIs. Don't worry. The resources I included below cover all of this.

Resource: An excellent React course from Tyler McGinnis. Once finished, you can also take the React hooks one to learn the latest technologies. Alternatively, there's Andrei Neagoie, who created a complete course: Complete React Developer. On the Vue side, you can rely on Vue Mastery or Vue School, especially The Vue.js Master Class.
Practice: you can build a more advanced app here. Maybe a weather app, a movie search app, or if you want, you can make a second version of a to-do app.
Blog posts: Getting Started with Vue and How to Create an App with Vue CLI. Check them out to have a taste of Vue if you're learning React. I also wrote a post related to tooling for React: How to Setup ESLint and Prettier for Your React Apps.

Modern CSS

CSS is back again! Now that you know how to build an app with a JS framework, you need to get advanced CSS skills: Flexbox, Grid, preprocessors, the whole thing! It may be interesting to look into CSS-in-JS solutions like Emotion.

Resource: Advanced CSS and Sass from Jonas Schmedtmann. You'll learn how to build well-designed pages on top of it!
Practice: remember the landing page you built? Revamp it with your new shiny CSS skills. It may also be a good time to build the first version of your portfolio.

Trust me or not, but that's all you need to know to get hired as a junior front-end developer. Most companies know that you can't know everything. They're also interested in your career path. They know you'll gain more and more knowledge as time goes by.

However, the skills above are not sufficient to be in the top front-end developers. You'll find below other skills to get if you want to get more comfortable in front-end development. You'll inevitably encounter them in your career.

Advanced JavaScript

If you're sick of JavaScript, I don't have good news for you. Indeed, you may know how to use JavaScript to build cool apps, but that's not all. You should also know how it works under the hood and the advanced JavaScript mechanisms, such as the event loop, closures, asynchronous stuff, or the prototype chain.

Resources: You can go on Frontend Masters and watch a course from Will Sentance entitled JavaScript: the hard parts. You can also check out a course from Tyler McGinnis: Advanced JavaScript.
Blog posts: Reverse-Engineering Airbnb's Internationalization Library and Over 20 Resources to Advance Your JavaScript Skills
Practice: practicing advanced JS is a bit hard to do. It's more of a long-term thing. The more you'll code, the better you'll get. So just practice JS here!

Testing

When building apps, there's always a point when you're not confident when it comes to deploying it or adding a new feature. Knowing how to test your front-end apps is an excellent asset in your toolset. The Testing Library ecosystem will be your best friend when it comes to testing.

Resources: Kent C. Dodds is the go-to guy when it comes to testing. He has built a great course called Testing JavaScript.
Practice: Test one of your apps. Start small. You don't need to write elaborated tests right off the box! The goal is to get comfortable with tests.
Blog posts: How to Test JavaScript With Jest, The Complete Beginner's Guide to Testing React Apps

Accessibility

You need to know how to build apps with accessibility in mind. Developers often forget accessibility, but it shouldn't be the case. Think of all your users, including those who may be blind, colorblind, or use a voice reader.

Resources: Another course from Frontend Masters by Marcy Sutton: Accessibility in JavaScript applications
Practice: make an accessibility audit in one of your previous apps. Spot the problems and replace them with accessible solutions.

Performance

Our world moves fast. We want everything right now. That's the same for apps; users can't stand a slow app. On top of that, it's terrible for your business. Learn how you can build performant apps.

Resources: Yet another course from Frontend Masters by Steve Kinney: Web Performance
Blog posts: 3 Easy Ways to Boost Your Web Application Performance

SEO

Without search engines, you can't find anything on the internet. SEO is about optimizing your sites so that anyone can quickly discover your website with the right keywords.

Resources: Ahrefs, one of the reference tool for SEO, has some great guides such as the following: SEO Basics: Beginner’s Guide to SEO Success
Practice: if you already have a portfolio, improve its SEO.

SSR

As of today, there are two main ways of rendering an application: on the client or the server. React and Vue render on the client by default, but that's not good for SEO. Lots of companies are looking into apps that render on the server like Next or Nuxt.

Resources: Wes Bos created a great course that's both on React, Next.js, and GraphQL: Advanced React. It'll make you build an online store app!

TypeScript

TypeScript is JavaScript but with types. More and more developers, especially in medium to large companies, appreciate the additional safety layer that TypeScript provides. Knowing it is a solid point for getting hired!

Resources: Did I already mention Frontend Masters? There's a course from Mike North on it called TypeScript 3 Fundamentals. If you want the quick option, you can check out: TypeScript in 5 minutes from the official docs.

UI/UX Design

Usually, this is not your job. These skills are for designers mostly. Designers create mockups, and it's your task to make them fully interactive. However, It's worth it to know how to build a mockup and play with colors, shadows, spacing, or components.

On top of that, start-ups can't always afford a designer. Thus, knowing how to design, even if it's not much, is a big +1 for them!

Resources: Refactoring UI is a great book on design. I've heard lately of Shift Nudge for getting the best UI skills. It's pricey, but it's worth it, in my opinion.
Practice: design is like any skill. The more you'll practice, the better you'll get, period. For that, you can tackle the Daily UI challenge.
Blog posts: How to Suck Less at Colors as a Developer and Why Learning Design Is Important for Front-End Developers

Databases and servers

Once again, this won't be your job. However, it's also up to you to integrate into your front-end app the data you get from the server. It may be worth it to know how you can build a basic API to understand better what a back-end developer does in his day-to-day job.

Pheeeew! That's all for the skills. There are still skills to get like learning how to build PWAs, static site generators like Gatsby, GraphQL or Docker but that post would get too long 😅

Side projects

You have the required knowledge and built some small apps or web pages, that's great! Now it's time to put your skills to practice and to create some projects.

One crucial thing to remember here: one big project is better than a hundred small projects.

Indeed, when you apply for a company, they need to know if they can trust you and pay you for your work. Building a project from scratch, even if it's not perfect, is a great way to show that. Making a hundred small projects won't reveal how far you can go. Sure, It shows that you are passionate, but not that you're skilled! That's a common mistake you shouldn't fall into.

Building an app

Here are the steps to start with a side project:

Find an app/project idea. Read this post if you need help with finding ideas (self-promotion, again 🙃).
Build the project if it's feasible. Use the technologies and skills you learned (front-end framework, CSS skills, etc.) and put your code on GitHub. You may be asked by companies to show how you code, and GitHub is great for that.
Don't quit! Yes, your project will reach a point when the codebase becomes ugly, but that's the same for everyone, even for large companies.
Deploy the project. Make it available for everyone. Netlify or ZEIT Now will be your best friends for that.

Project ideas:

A Twitter clone
An app to manage the movies and series you watch
A chat app
A Todoist clone
Anything you think of?

If you don't feel confident in your back-end skills, look into Firebase. It's a powerful tool that is relatively easy to use.

Technical blog

It's also a great idea to start a blog and learn to write technical posts, even if you're not an expert in your field. Having such a blog shows both your writing and technical skills. On top of that, you reinforce your learning!

You can create a blog with Gatsby, in particular, with this blog starter. In terms of post ideas, it's up to you. The world is your oyster here. Pick a topic and write about it.

Portfolio

Finally, build a portfolio with:

A description
Your skills
Your projects
Your technical posts if you have some
How we can contact you or a contact form

Job search

Let's recap:

✅ You have the knowledge
✅ You built one or two big projects or even a blog
✅ You have a portfolio

Now is the time to find a job. That's a tough one because many companies are all looking for developers with at least five years of experience. Here are some tips for you:

If a company is looking for a developer with at least one or two years of professional experience, apply! Some companies put these kinds of criteria to have an entry barrier. You may be a great fit, so apply.
You don't have to match every skill the company is looking for. Really. If they list TypeScript and you don't know TypeScript, that's OK. You can still apply.
If you need to craft a motivational letter, personalize it. The more you craft it for the company, the more it will have an impact.
Attend meetups in your city or online. That's where you'll get contacts and exchange with other developers, product managers, or designers. Companies usually sponsor meetups to hire more people.

For the job search itself, you may find opportunities on LinkedIn, so you'll have to create a profile on it and put your projects there!

Interview

So you've been selected, and you have an interview? Awesome. But you don't know what to expect. You are not confident. Maybe you think that it's not possible, they will make a mistake by hiring you, you're an imposter. Don't think that way. Lots of developers believe they are not ready for the job. That's not the case. You built projects, you know how the technologies work, and that's valuable. Sure, you don't know it all, but nobody does.

I don't know what's the exact interview process for all companies. But I know how it usually goes:

You apply to a job or someone contacts you, usually someone from the Human Resources department.
You have a phone call, or you meet in person the HR. You talk about your previous experiences, who you are, what you're searching for, the company, etc.
You have a technical test, usually with a company's front-end developer, a tech lead, or the CTO. You'll have to answer technical questions. It's also possible that you have a take-home project to do and then give the company's source code. If that's the case, polish it!
You meet the founders of the company or persons leading the company. They usually want to know whom they hire, so you'll discuss the company, your motivations, etc. Depending on the company's size, it may not happen.
If all goes well, you get an offer! Don't necessarily take the company with the best offer. Salary is an essential part of the job, but your happiness, how you feel in the company, and your career path matters too!

Let me warn you: sometimes, the process can be quite long.

Here are some advice for you to succeed:

Be professional but stay relaxed. You're not interviewing for a bank. The first time I went to an interview, I was surprised at how chill the persons were. So, no pressure (Don't be too chill though, find the sweet spot 😄)
Show you're motivated by the project. Unfortunately, getting hired for a first job is hard because you don't have previous experiences. However, you can show how much you want the job and contribute to the company.
Adapt your speech to the person you're speaking to. Don't get too much in technical details if you talk to someone whose job is related to business.
Don't underestimate soft skills. The interviewer will try to see if you can fit for the job and whether he can work with you or not, especially the persons in tech! Show how great it would be to work with you: communicate, smile, and stay humble. If you need to know which soft skills to get, I wrote a post on the soft skills every developer should have.
Don't lie during interviews. If you don't know something, then you don't know. It's no big deal if you can't answer all the questions. Experienced developers don't like bull-shit developers.
Developers always make trade-offs. There's rarely a one-size-fits-all solution. Show that you are aware of that and think about what brings value to the company. It demonstrates that you have deep thoughts, and it's much appreciated.

OK, that was a long one. As said previously, becoming a developer is a long but rewarding path! I hope it gave you some insights into how you get a job.

How to Build an Accessible Toggle Switch with Vue 3

Thomas Lombart — Wed, 26 Aug 2020 10:15:13 +0000

There are a lot of different UI components you can find on an app. The ones you'll find the most will probably be buttons, inputs, forms, or images. They are so common that HTML even provides default elements for them! However, it's not rare to encounter lesser-known components that you have to build by yourself.

I worked lately on a switch/toggle component lately, something that looks like this:

At first, it seems like a simple UI component. But building it can be tricky when you need to consider all the different states, its accessibility, and its reusability.

Well, lucky you! Today I'm going to share with you how you can do the same.

Note: though I'm building it with Vue, the concepts can easily be applied to another framework such as React. Also, I'm using Vue 3 but don't be scared. There are not many differences with Vue 2 here! 😉

A bit of conception

Before jumping straight to your keyboard and start coding, you have few things to consider, especially the switch's purpose. Indeed, a switch can be used in two ways:

To turn on or off something (as you would do with a light switch)
To select between two choices (a theme switcher, for example)

It's essential to know which use case is the right one for you because it impacts the underlying implementation. In our case, we're going to go for the first use case.

Additionally, we want to label a toggle switch so that the user knows what is going to happen if he toggles the switch.

Let's look at a real-world example where a user would choose to receive a newsletter. You can think of a first implementation where you would use a checked prop, a label prop and a toggle event:

<Switch
  :checked="shouldReceiveNewsletter"
  @toggle="toggle"
  label="Receive newsletter"
/>

That's good. But we can achieve the same result by using v-model like so:

<Switch v-model:checked="shouldReceiveNewsletter" label="Receive newsletter" />

If you're familiar with Vue, you might be surprised with the use of v-model in the example above. That's one of the changes introduced by Vue 3: you can now use an argument name directly on the template. The code above passes a checked prop to <Switch> that you can update by emitting an update:checked event.

Build the template

Whenever you have to choose HTML elements, you need to select the ones that make sense semantically. In our case, we'll have to use an input as we're building a control. Remember, there are two use cases for a switch:

Switch a setting on/off: we need a checkbox
Switching between one option and another (like a light/dark theme): we need two radio buttons

We also need to make sure our input is labeled correctly. One way of doing so is to wrap an <input> in a <label> and add some text.

Finally, we can also add an empty <span> that we're going to use later to build our toggle switch. Go ahead and create a Switch.vue file in which you can paste the following:

<template>
  <label>
    <input type="checkbox" />
    <span></span>
    <span>{{ label }}</span>
  </label>
</template>

Props and v-model

We need to pass two props to the Switch: label which is a string and checked which is a boolean. Remember that the checked prop comes from v-model:checked:

<template>
  <label>
    <input
      type="checkbox"
      :checked="checked"
      @change="$emit('update:checked', $event.target.checked)"
    />
    <span></span>
    <span>{{ label }}</span>
  </label>
</template>

<script>
  export default {
    name: "Switch",
    props: {
      label: {
        type: String,
        required: true,
      },
      checked: {
        type: Boolean,
        required: true,
      },
    },
  };
</script>

There's a problem with the input above. Indeed, the root element is different than the underlying input. We have to create an additional prop for any other attribute we want to pass to the input (disabled, for example).

To fix it, we need to put a v-bind="$attrs" on the input and disable attribute inheritance on the root element:

<input
  v-bind="$attrs"
  type="checkbox"
  @change="$emit('update:checked', $event.target.checked)"
  :checked="checked"
/>

<script>
  export default {
    name: "Switch",
    inheritAttrs: false,
    /* ... */
  };
</script>

Style the component

The container and the label

So far, our switch should look like this:

Let's face it, it's ugly as hell. To make it prettier, we'll add CSS classes to the different elements:

<template>
  <label class="container">
    <input
      v-bind="$attrs"
      class="input"
      type="checkbox"
      :checked="checked"
      @change="$emit('update:checked', $event.target.checked)"
    />
    <span class="switch"></span>
    <span class="label">{{ label }}</span>
  </label>
</template>

We'll do them one by one. First, the .container. We know the text will be on the right of the switch, and we want it to be perfectly centered. We also want the whole toggle to be clickable so let's add a pointer cursor to it:

<style scoped>
  .container {
    cursor: pointer;
    display: flex;
    align-items: center;
  }
</style>

We also need to give a prettier color to the label and give some space from the checkbox:

.label {
  margin-left: 12px;
  color: #1a202c;
}

Then, though we use the <input> for semantic reasons, it won't be useful to us in terms of visuals. We need to hide it visually but still keep it in the DOM for accessibility reasons:

/* Visually hide the checkbox input */
.input {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border-width: 0;
}

Note: the properties are inspired by the .sr-only class from Tailwind CSS

The switch

The switch is composed of a rounded container element with a circle inside of it. This circle moves to the left or to the right depending on whether the input is checked or not.

If you look at the screenshot, you can see that the inner circle is roughly half the size of the container element. The container width has twice the size of its own height. Let's make use of CSS custom properties for that:

.switch {
  --switch-container-width: 50px;
  --switch-size: calc(var(--switch-container-width) / 2);
}

To create the inner circle, we're going to use the ::before element trick. To make it inside the container, we'll need to give the container a relative position and the inner circle an absolute position.

Additionally, the inner circle should be nearly the size of --switch-size but it shouldn't overflow the container. We'll use the calc function to adjust it:

.switch {
  --switch-container-width: 50px;
  --switch-size: calc(var(--switch-container-width) / 2);

  /* Vertically center the inner circle */
  display: flex;
  align-items: center;
  position: relative;
  height: var(--switch-size);
  flex-basis: var(--switch-container-width);
  /* Make the container element rounded */
  border-radius: var(--switch-size);
  background-color: #e2e8f0;
}

.switch::before {
  content: "";
  position: absolute;
  /* Move a little bit the inner circle to the right */
  left: 1px;
  height: calc(var(--switch-size) - 4px);
  width: calc(var(--switch-size) - 4px);
  /* Make the inner circle fully rounded */
  border-radius: 9999px;
  background-color: white;
}

Here is the result:

That's nice, but if you click on the switch nothing happens. At least, visually. Indeed, the input is checked correctly, but your switch isn't connected to it!

To reflect these changes, you'll need to use the CSS adjacent sibling selector, which is +, to style the switch according to the different input states. For example, when your checkbox is checked, the :checked pseudo-class is added. Let's make use of that then:

.input:checked + .switch {
  /* Teal background */
  background-color: #4fd1c5;
}

.input:checked + .switch::before {
  border-color: #4fd1c5;
  /* Move the inner circle to the right */
  transform: translateX(
    calc(var(--switch-container-width) - var(--switch-size))
  );
}

The way the switch moves from one state to another isn't smooth. We need to add transitions to transform and background-color to fix it:

.switch {
  /* ... */
  transition: background-color 0.25s ease-in-out;
}

.switch::before {
  /* ... */
  transition: transform 0.375s ease-in-out;
}

The focus and disabled states

Right now, you should have a switch that works. But the work isn't entirely done yet! Indeed, there are still different states to an input that we haven't implemented here. For example, if you press the Tab key to focus the switch, you don't have any visual feedback that it's properly focused. The same goes for disabled inputs.

As a first step, we're going to add additional CSS custom properties to .switch and replace the hardcoded colors:

.switch {
  /* ... */

  --light-gray: #e2e8f0;
  --gray: #cbd5e0;
  --dark-gray: #a0aec0;
  --teal: #4fd1c5;
  --dark-teal: #319795;

  /* ... */
  background-color: var(--light-gray);
}

.input:checked + .switch {
  background-color: var(--teal);
}

.input:checked + .switch::before {
  border-color: var(--teal);
  /* ... */
}

Note: the colors come from Tailwind CSS in case you're wondering.

Let's tackle the focus state. We're not going to do anything complicated UI-wise, we'll just have to add a border on the inner circle:

.switch::before {
  /* ... */
  border: 2px solid var(--light-gray);
}

Here, we chose the same color as the background of the switch container. Indeed, initially, we want the inner circle border color to confound with the background color. That way, when we adding a different border-color for the focus state, we'll be able to see it. We're going to add a darker border-color when the input is focused:

.input:focus + .switch::before {
  border-color: var(--dark-gray);
}

.input:focus:checked + .switch::before {
  border-color: var(--dark-teal);
}

Here's how it looks:

For the disabled state, we're going to fill the inner circle with gray and make the switch container darker to indicate that you can't do anything on it:

.input:disabled + .switch {
  background-color: var(--gray);
}

.input:disabled + .switch::before {
  background-color: var(--dark-gray);
  border-color: var(--dark-gray);
}

Here's what our disabled switch looks like:

The switch's responsiveness

We have one last thing to check. Look at the screenshot below:

If you have a long label, you can see that the text overflows on the switch and may take multiple lines. That's not responsive, is it? Let's make sure our switch can't shrink, and the label doesn't take more than one line:

.switch {
  /* ... */
  /* In case the label gets long, the toggle shouldn't shrink. */
  flex-shrink: 0;
}

.label {
  /* ... */
  /* Show an ellipsis if the text takes more than one line */
  overflow: hidden;
  text-overflow: ellipsis;
  white-space: nowrap;
}

Now, our switch is responsive:

Voilà! We're done for the switch. The switch is a small piece of UI, but it's not that easy to implement. Here are the main takeaways when building such a component:

Think of your component's API beforehand and its use cases. You'll have a better vision of what you want to build.
Don't forget to think of the different constraints of a UI component: its accessibility, its various states, its responsiveness, etc.
Build your component step by step. You should have an iterative approach with these kinds of components.

In case, you want to have the full code, I put it in a GitHub Gist that you can find below. How nice is that? 😄

How do you find time for your side projects?

Thomas Lombart — Mon, 18 May 2020 17:33:10 +0000

It's common for a developer to have side-projects, whether it's a blog, an app to build, an open-source library to maintain, or a course to watch or read. Aside from a full-time job, it can be hard to dedicate time to them.

Often, I like to get up one hour early and work on it. I often find myself working on Saturday morning if I feel like it. What about you? What are your strategies, tips and tricks to manage your time for your side projects?

Over 20 Resources to Advance Your JavaScript Skills

Thomas Lombart — Mon, 04 May 2020 16:39:55 +0000

JavaScript has never been more used than today. It's a real asset to get good at it. When discovering JavaScript, you first learn variables, if statements, loops, arrays, objects, functions! Maybe you even know what is this and how to use async/await.
But that's just the tip of the iceberg. There's more to JavaScript you need to learn.

To better understand JavaScript, you need to deeply understand its foundations and how it works under the hood. That can be a daunting task. But don't worry, I got your back!
I read and watched many resources to get better at JavaScript, and I want to share that with you today.

Topics to learn

To level-up your JavaScript skills, you'll need to know:

What is JavaScript

Multi-paradigm, dynamically typed, single-threaded, ECMAScript specification. You need to know what makes JS JS. Kyle Simpson explained it in the first chapter of You Don't Know JS Yet.

How the JavaScript engine works

To run code, you need an engine to run it. Lydia Hallie explained it well in this post about the JavaScript engine. You'll realize how typing JavaScript can make it more performant for v8.

The dreaded event loop

Did you know that JavaScript executes synchronously? But then how can you make API calls and still not block the page? Introducing the event loop and browser APIs. There are two excellent videos on that: In The Loop from Jake Archibald and What the heck is the event loop anyway from Philip Roberts.

Execution context, hoisting, scopes and closures

You need to know what JavaScript actually does when running a program. For that Tyler Mc Ginnis got your back with an awesome post on execution context, hoisting, scopes and closures.

Coercion

What actually happens when JavaScript interprets "1" == 1? Hint: coercion. Alexey Samoshkin wrote a guide on JavaScript coercion that's really interesting!

Prototypes in JavaScript

This is a JavaScript pillar that you can't escape, so you better learn what it means. I found two useful posts on that: Prototypes in JavaScript from Rupesh Mishra and A Beginner's Guide to JavaScript's Prototype from Tyler McGinnis. Hopefully, with these articles, the prototype chain, __proto__ and objects won't be scary anymore.

This, call, apply and bind

Ah, this. With a misunderstanding of this, you can often get common errors like Cannot read property 'name' of undefined or greet is not a function in your programs. Tania Rascia broke down these concepts for you in her post Understanding This, Bind, Call, and Apply in JavaScript.

Promises and async/await

ES2015 made JavaScript developers' lives more comfortable by bringing promises that allowed you to write simpler asynchronous code. Learn what they mean by reading What is a Promise? from Eric Elliott or JavaScript Promises for Dummies on Scotch.io. You can also watch a great talk from Wes Bos on Async/Await.

Modules

What are ECMAScript modules? Common JS? A module bundler? Find the answers in yet another post from Tyler Mc Ginnis on JavaScript Modules. I also highly recommend that you check out this course on Webpack 4 fundamentals from Sean Larkin.

Functional programming

We already know that JavaScript is a multi-paradigm language. One paradigm supported in JavaScript is functional programming since functions are first-class citizens. Andrea Bertoli made an excellent post on the basics of functional programming. You'll see the power of composition.

Courses

There are many resources for learning JavaScript, as you saw above, and it may be overwhelming. Don't worry. If you prefer to get a single course, I got your back too:

Advanced JavaScript from Tyler Mc Ginnis: I used many resources from him previously. That's because he has a whole course on that. It'll make you, for sure, a more proficient JavaScript developer.
Advanced JavaScript Concepts from Andrei Neagoie: he has released many popular courses before this one. You'll find anything you need to know to become an advanced JS developer.
JavaScript Visualized from Lydia Hallie: she wrote many posts on JavaScript concepts with remarkable visual explanations. I highly recommend it.
JavaScript: the Hard Parts from Will Sentance. This great workshop will make the hard parts of JavaScript easier for you. To go further, you can watch the following two workshops from Will too: JavaScript: The Hard Parts of Object-Oriented JavaScript and JavaScript: The New Hard Parts

When you have to learn new concepts, you need to space your learning in time, read or watch different resources and practice a lot. Using this strategy allows you to truly master a topic. That's why I recommended various posts and courses. Don't wait and start to get better at JavaScript!

How to Suck Less at Colors as a Developer

Thomas Lombart — Mon, 27 Apr 2020 10:29:16 +0000

This post has been co-written with Esther Boulanger who is UI designer. Many thanks to her for helping me with the content and the drawings!

What comes first to your mind when you think about design? The first thing that pops into my head is colors. Colors are everywhere and essential for design.

Working with colors seems simple. At least, until you have to design a user interface and choose your color palette. At that moment, you have writer's block but applied for design. You try to do stuff, but nothing ever looks good. After a while, you think that, who cares? You're not one of these design magicians. You just suck at design. I've been there.

However, it's useful to know at least the fundamentals of what makes a user interface great. And, whether you like it or not, colors are an essential component of it. Without further ado, let's look at how you can use colors in your UI and much more!

Color formats

There are a lot of formats for colors. The most popular ones are Hex, RGB, HSB, and HSL. Let me explain the differences between them and which one you should use. 🧐

Hex and RGB

RGB and Hex are the most common formats for representing colors.

RGB gives us the intensity of red, green, and blue of one color. Intensity is a number that can go from 0 to 255. As an example, you could define a light purple color with 164 of red, 43 of green, and 217 of blue:

.color {
  color: rgb(164, 43, 217);
}

Hex stands for hexadecimal. It's similar to RGB, only the format changes: #RRGGBB.

As with RGB, R is for the intensity of red, G for green, and B for blue. These values can go from 00 to FF (which means 0 to 255 if you convert it to decimal). For example, #FF0000 represents a pure red. Indeed, #FF means red is at its highest intensity (255), and the others are at their lowest.

I'll say it upfront, those two formats aren't the best when you have to pick colors. Indeed, let's say you want your app to have a blue primary color. You won't have only one blue, right? You'll have to make a lighter blue or a darker blue. Well, good luck doing that with RGB and Hex!

Note: RGB and Hex are not suitable for picking colors, but you can still use them for representing colors.

That being said, let me introduce you to HSB, HSL, and their differences. Let's begin with HSB.

HSB

HSB means hue, saturation, and brightness.

H stand for Hue. It's a number measured in degrees that is between 0 and 360. The following drawing speaks for itself:

If you have a visual memory and want to pick a color, this drawing will be your best friend.

What about saturation and brightness? For that, let's take a look at the following drawing:

These 4 circles all have the same hue (210°), but still, they look different. Well, that's because of saturation and brightness.

S stands for Saturation. It's a percentage representing how vibrant color is. 0% means you have no saturation, while 100% means you have the maximum. If you choose to add a blue to your UI with a hue of 210° and saturation of 0%, you'll get a gray color. High saturation, vibrant color. Low saturation, dull color.

To better visualize the saturation for color, here is the blue we saw above with different variations:

B stand for Brightness. It's a percentage representing how bright a color is. Basically, the higher is the brightness, the more your eyes will suffer in the dark. If the brightness is at 0%, you'll get black no matters the hue or saturation.

However, you can get two different results for brightness at 100% depending on the saturation:

If the saturation is at 0%, you'll get pure white.
If you have a saturation different than 0%, you'll just get a highly-bright color that is more or less vibrant.

The most perceptive of you will think that, OK, HSB is great, but you can't work with HSB in CSS. Instead, CSS supports HSL. Let's see it right away.

HSL

HSL means hue, saturation and lightness. Thus, the only difference compared to HSB here is the lightness.

Lightness represents how close a color is to black or white.
0% lightness is equal to black (like the brightness), BUT 100% lightness is equivalent to white no matter the hue or the saturation. This is the big difference between brightness and lightness.

Let's take a value example with HSB and HSL. We'll take a hue of 250° (darker blue) and a saturation of 75% (very vibrant).

For HSB, you'll get:

H=250, S=75%, B=0% → black
H=250, S=75%, B=100% → very bright blue

For HSL, you'll get:

H=250, S=75%, L=0% → black
H=250, S=75%, L=50% → very bright blue (the same as with HSB)
H=250, S=75%, L=100% → white

There's something I find weird with HSL while designing. When I move the lightness up or down and convert it to HSB, the saturation isn't the same. For that reason, I prefer to work with HSB that seems easier to me.

In the end, it doesn't matter if HSB is not available in CSS. What you can do is to pick your colors upfront with HSB and convert them to hexadecimal values.

You know about color formats. Great. Let's deep dive into the exciting stuff.

Color variation

Don't trust the tools that magically gives you a palette with 4-5 different colors, it won't work. What you need to learn instead is how to make color variations. Trust me, with gray and a primary color, you can already make pretty good UIs. Look at the apps and websites around you; they usually have one primary color, and still, they look good.

To create color variations, you first have to play with the hue. Indeed, there are 360 shades of colors different in the color wheel. You can get a lot of colors just with the hue. Let's take an example of green color with a saturation of 100% and a brightness of 70% (very vibrant and bright).

Here are the different values of these three circles:

First circle: H=120°. I get green.
Second circle: H=156°. I get a green that tends towards the blue.
Third circle: H=80°. I get a green that tends towards the yellow.

Play with different colors and see what works well or not. Indeed, in design, you have to TRY many things to determine what you really want, what is best for you.

OK. So hue allows us to modify the tone of the color, what about saturation and brightness?

Create lighter or darker colors with saturation and brightness

Most of the time, you'll want to use saturation and brightness to create lighter or darker colors. Let's start with a darker color.

In your opinion, what would you have to do to have a darker color? You'd probably think we would just have to tune the brightness down, right?

Well, let's try that on an example:

This is what you can get by using this method. Take a look at the last two greens. They're way too dark! Indeed, by only decreasing the brightness, your color also gets less colorful. We can fix it by increasing the saturation:

Let's try again:

Look at these new shades of green: that's way better!

For a lighter color, you need to do all the contrary: increase the brightness and decrease the saturation.

Let's take an indigo color and create lighter variations:

By increasing the brightness and decreasing the saturation, you get lighters blue.

So, remember:

Darker color = saturation up, brightness down
Lighter color = saturation down, brightness up

Congratulations, you just unlocked the power of color variations! 😎

You can also move the hue up or down along saturation and brightness to get lighter or darker colors. There are no magical formulas for creating color variations. The key is to adjust your values until it looks good to you. I know, easier said than done, but at least you know how to easily make a color darker or lighter. 😏

Choosing colors

Don't get me wrong, as of today, I still struggle with colors. However, I learned some things along the way. You'll find below a handful of color tips that I think will be useful to you.

Gray

When you design UIs, you need to understand that gray is essential. Before choosing colors, you need to design your applications only with different shades of gray.

Once done, you can think of colors. However, don't paint your whole app, only apply colors where that's necessary: for the navigation bar, buttons, backgrounds, maybe on some words but not everywhere! The more I look at stunning designs, the more I realize they're really subtle.

Picking colors

You probably ask yourself how to pick colors. You're not going to like this answer, but it depends. Usually, you can consider that one or two colors are enough! Stick with them and use them sparingly.

If you already have a logo, you can pick its primary color since it's your brand's main color. For example, facebook's logo is a blue F. Let's take a look at their UI:

You can notice that the same blue is used everywhere but with different variations. One color and it looks good! Note also that the rest of the app is made of gray. 😉

Blue is a great starter color. Be careful though, it tends to be overused. We saw above that Facebook uses blue, but it's not the only one, far from it. Twitter also uses it as an example!

Choose your colors according to your brand and your audience. For example, if you're designing a bank app, you'll probably want to choose sober colors since it inspires professionalism. On the contrary, if you want to make your app playful, such as the famous Duolingo, choosing vibrant colors (saturation, remember?) will be a great choice:

Note: the content is in French, but nevermind we're looking at the UI, right?

Don't make the obvious choice. It's not because you're designing for ecology that you have to choose green colors. Sometimes, selecting original colors can make your app stand out!

Gradients

If you’re not satisfied with a particular color, you can use gradients. Here are different gradients:

It's not that hard to create one. Choose a color and make the second one lighter or darker. I also find gradients to look better when the second color has a different hue. So, when creating gradients, it's fine to tune everything: hue, saturation and brightness.

Here's an example of a design made by Walid Beno on Dribbble. He makes use of gradients on the background and buttons. The result is stunning:

Secondary colors

Most of the time, you'll still want to have a secondary color in your application. Something that works great is to associate a cold color with a warm color: purple with orange, red with blue, yellow, with blue, whatever! Here's an example of a design made by Sight Setyo Nugroho for OWW on Dribbble:

Dark interfaces

You may want to go with a dark interface. Obviously, your app will be filled with black or dark gray. In this situation, choose colors that are highly-contrasted with dark (so, high saturation). Usually, yellow, orange, or purple (but not too dark) look great. Here's an example by DStudio on Dribbble:

Design isn't easy. Picking colors isn't easy. Even creating color variations isn't easy. The more you design, the better you get. There are rules in design that you can leverage to build great UIs, as we saw with color variations. But, it won't magically make you a design master. At first, you will suck. But after producing dozens of designs and lots of color variations, you'll start to get better at it.

Why Learning Design Is Important for Front-End Developers

Thomas Lombart — Mon, 20 Apr 2020 11:09:22 +0000

A few months ago, I decided to learn UI and UX design. I've always been impressed at stunning mockups I saw on Dribbble. So, I thought it would be great to get a glimpse of what you need to do to achieve great designs. I made this decision with pure curiosity. Along the way, I learned about colors, spacing, typography, and more!

By reflecting on what I learned, I realized something: learning design is essential for front-end developers. In the end, it's our task to give life to mockups, to make them interactive. Thus, why not learning how to design the user interface itself?

Let's see what learning design can bring you in terms of benefits.

Better value in your team

There's a standard workflow you can find across tech companies (especially start-ups). They have product owners and managers, a design team, a development team (both front-end and back-end). The product owners think of the new features with the team. The designer produces mockups. The back-end developers provide the endpoints to call. You, front-end developers, are responsible for making the mockups alive.

In an ideal world, you have a design team, and they think of all the edge cases you can encounter:

When you have no data to display (empty state)
When you have an error
When an input gets really long.
Etc.

In real life, you don't necessarily have a design team, and when you have one, they're not always available because they have a lot of work. In this case, you can sometimes be blocked. It may be because the mockups are missing or because you want the opinion of one of your fellow designers that are not available at the moment.

Knowing design is a considerable value for your team. It doesn't mean you have to replace the designer's work. On the contrary, it can even be complementary. You can build a basic design if you need to do a proof of concept for something your company wants to test. Or, if your designer forgets an edge case, you can also handle it without waiting for their input.

It also means you're more efficient when building UIs. You are quicker and more detailed. I often see developers who blindly copy-paste the values they get from Zeplin or InVision mockups. The thing is, these values can be incorrect, and it results in inconsistencies in your app. When you know how it's actually made off, you don't fall into these traps.

Furthermore, knowing to design can be a great asset in case of negotiation. You can bring up the fact that you can cover the technical part of a project and the design part, which, ultimately, results in fewer costs for the company and higher benefits for you. It's what we call a win-win.

Better side-projects design

That's the most important thing for me: designing for side-projects. Whether it's an app, a blog post, open-source work, videos, or whatever I can think of, there's always a time when you need to do design work.

For example, I was able to do all the design of this blog by myself. It's not incredibly beautiful, but I think it looks good and does the work. Without design in my toolbelt, I'm not sure it would have been the same.

Knowing how to code and how to design also makes you more independent. You can basically handle your whole website/app in terms of how it looks. It's like unlocking new powers because not only can you build something useful and interactive, but you can also make it look great!

Better communication with designers

Communication in a team is vital. I've already written about it in a previous blog post about soft skills. A front-end developer will have to communicate with its colleagues, back-end developers, product owners, managers, and designers! When you go along with a designer and that you truly work together, it can do wonders in your team.

Indeed, I'm sure you already got a stunning mockup that was really complex to build. If it ever happens, please, don't complain. Don't shout out loud that the designer is dumb, is not realistic, and knows nothing about code. Instead, cooperate and think of an alternative solution.

Once, I told a designer an alternative solution to a feature, and his reaction was, "Oh, it's actually possible to do this? I didn't go with this in the first place because I thought it was too hard for you". Being proactive and using your design skills in these situations can save time and, consequently, money (and companies like you when you're saving money for them).

Another case when you can use both your communication and design skills is when you have to build a design system. You can work hand-in-hand with a designer and create something consistent with your brand, powerful, and easy to use.

What to learn

Ok, so now you're sold on the fact that you need to learn design. What should you learn then? Here is a non-exhaustive list of topics to explore:

Learn a design tool: Sketch, Figma or Adobe XD
Whitespace
Alignment
Shadows
Typography
Colors
Typography
Icons
Base components: buttons, inputs, headers, cards, and more.
Etc.

Task Estimation for Developers

Thomas Lombart — Mon, 13 Apr 2020 09:04:11 +0000

🙂 Tuesday 11AM. You sit down with your team in a meeting room to plan your next tasks. New features, improvements, and bugs are introduced to you. The product owner (or product manager or engineering manager, whatever!) shows you the mockups and the requirements. You discuss them, and then, for one feature, he asks you the dreaded question:

"Can you estimate how long this task is going to take?"

Confidently, because you’re a bad-ass rockstar developer, you answer:

"Hum. Let me think. Yeah, this is not really complex. Two days, not more, not less."

Great, your product owner is happy. We’re going to ship the next sprint. This is huuuuge!

Once the meeting’s over, you start your task, everything’s going well. After a few hours, you scratch your head. You didn’t pay attention to the endpoint you called. Some data’s missing! You talk with a back-end developer, and you find a solution. That’s a bummer. You wasted a few hours.

😓 Wednesday, 10AM. during the daily meeting, you say:

"Yesterday, I worked on feature X. I had a problem because some data was missing. I’m nearly done. I’ll finish it today."

In reality, you hope you’ll finish it today because you’ve done half the job and you also have two meetings you can’t escape! But hey, things are going to be alright.

During the day, you work on the feature, and then you realize something, the mockups we gave you don’t cover the whole thing. What do we show to the user when there’s no data? And what if an error occurs while I’m calling that endpoint? Thus, you gather with the design team, discuss it, and handle new things.

It’s 6PM. You’re tired, you can’t think. Ok, you’re a little late, but tomorrow you’ll finish the task.

😥 Thursday, 10AM. Daily meeting time:

"I’m nearly done on feature X. I had to talk to the design team because, in this edge case, we didn’t know what to show to the user. We figured it out, and I’ll finish it today."

During the day, you work on the feature, and everything’s done! Let’s tackle the tests. You struggle with tests, in particular, mocking a function. The whole team is busy, and you’re on your own for this. After a while, you find a solution. git add , git commit, git push. You wait for the review and fix a bug while waiting.

😨 Friday, 10AM. Daily meeting. Your product owner asks you if the feature is shipped. He wants to test it as soon as possible because he needs it for a presentation. This feature is critical for the business! You’re embarrassed, but that was not your fault, after all. You answer:

"Yes, sorry. I’m nearly done with it. I wasted a few hours on a test, but it’s in code review. It should be good today. In the meantime, I’ll work on bug Y."

In the morning, one developer reviews your code and finds some quirks. He requires you to change some functions. Furthermore, you didn’t document your feature correctly. And on top of that, you architectured the feature weirdly. He shows you a smart way to do so. This is not going to take long, is it? Let’s get back at work.

It’s 5PM. It’s been a long week, you’re tired, and you chat with your colleagues. You have some good laughs. You’re done. You’ll finish the feature once and for all on Monday.

😰 Monday, 10AM. As usual, daily meeting:

"Yeaaaah, so Friday… My code was reviewed, and I had to revamp the feature because I could not use our new functions. Also, I had to do a bit of documentation. I’m going to finish that this morning and let’s ship it this afternoon!"

Empowered by the start of a new week, you are productive and finish that in the morning. You git push it, your pull request is reviewed, merged, and deployed. You test your feature in staging, and you realize something’s wrong even if everything’s fine locally! You investigate that, and you find the bug at the end of the day. You'll fix it tomorrow.

😱 Tuesday, 10AM. Daily meeting:

"Yesterday, I thought I was done on feature X. But something was weird on the staging environment. I did some investigations, and I discovered that Y was causing the bug. I’ll write the fix this morning!"

You write the fix on a new branch. git add , git commit, git push. Open PR. Waiting for your review. Review. Merged. Deployed. Fingers crossed, let’s hope everything’s good. You test it in staging and… it works 🎉

Both relieved and embarrassed, you tell your product owner the feature is shipped. Wow. What should have taken two days actually took one week.

Did you recognize yourself in this story? If yes, don’t worry, it happened to lots of developers. Don’t blame yourself for this. Instead, focus on what to do to avoid this situation. When it comes to working for someone else, you mainly have to do two things: underpromise and overdeliver.

Indeed, you won’t disappoint anyone by underpromising, and by overdelivering, you will even make them happier. If you think about it, if we ask you to estimate your code, it’s because there are some deadlines to meet, a plan to follow. By doing wrong estimations, you force others to reconsider the plan. However, if your estimations are right, the plan can go on safely even if they seem exaggerated.

Thus, when you’re asked to estimate a task, consider these elements:

You need all the details required to perform the task, and it is clear to you. The endpoints you need to call are ready and functional. The mockups are complete. The acceptance criteria for your tasks are also clear.
You usually have to do extra tasks such as documentation or testing (even if I think testing shouldn’t be an « extra task » but anyway).
You won’t focus on your task only. Aside from your task, you’ll maybe have to do code reviews, to fix a bug in production, to assist to some meetings.
If you haven’t done the same kind of tasks before, you may have extra difficulties doing it. Maybe you’ll need the help of one of your teammates who’s not always available!
If there’s code review in your team (which I strongly recommend for enforcing quality code), you may be asked to add extra tests, modify your code or other demands.
Technical problems can happen along the way. They can be blocking. It’s worse if these technical problems don’t depend on you!

You may have heard that when you’re being asked to estimate a task, you need to double it. That’s true. If you think of all these elements above, you can easily double it.

Yes, your boss/manager/product owner will think it’s exaggerated. Still, they usually don’t know in detail how it works under the hood. The sooner you do your task, the better it is for them to always ask if you can deliver fast.

To be honest, I don’t really like estimating tasks. There are too many factors to rely on. I do the best I can, and I’ll ship the code when it’s ready. But sometimes (even often) you don’t have the choice. You will need to estimate tasks. Thus, I hope this post will help you to estimate front-end tasks like a pro. 🚀

Boost Your Workflow in VS Code with User Snippets

Thomas Lombart — Mon, 06 Apr 2020 14:16:37 +0000

Typing every single character of your code can feel cumbersome. How many times did you declare a function? Created an object? Imported a module? Created a for loop? Created a component if you're a React or Vue developer? I don't even know how many times I did it, but I think the numbers would be pretty scary 😱

Luckily for us, our favorite code editor, VS Code, can provide us user snippets to avoid typing all this code manually. For example, you can download these snippets as package extensions and then, you're able to write code in no time! But what if you find yourself typing a code that no extension provides? What if you have specific conventions or objects you use in your team? Do you have no other choice than to do this chore?

No. You can define custom user snippets, and that's an easy task! 😌

Create a snippet

To do so, press Ctrl + Shift + P or Cmd + Shift + P if you're a macOS user and type user snippets:

Select the language for which you're going to create a snippet file. Here we're going to do one for javascript:

VS Code should open a new file with some information on how to create a snippet. How nice is this? With this first example, you learn that:

A snippet has a name, a prefix, a description and a body. The prefix represents the characters you need to type to trigger the snippet.
The body is an array, each element defining a line.
You need to use $0, $1, $2 for your different variables ($0 is the final position and $1 and $2 are tab stops).
If you want to provide a default value for the variables, you can define placeholders: ${1:placeholder}

Console snippet

Let's see a first snippet for logging the content of a variable:

console.log("something", variable);

Here, you have two variables: the information you want to log and the variable.
You'll probably want to start a new line after logging. To create such a snippet, go to the javascript.json file and add the following:

{
  "Print to console": {
    "prefix": "csl",
    "body": ["console.log('$1', $2);", "$0"],
    "description": "Logs something to the console"
  }
}

Here, we defined two lines in body:

The first line (first array element) has two variables: $1 for the information to log and $2 for the variable.
The second line has just $0 to indicate your final cursor position so that you can go to a new line.

Voilà! You already have a first snippet that works. And that's just the beginning of what you can do with snippets.

Try/catch snippet

Let's do another one: writing some code wrapped in a try/catch statement!

{
  "Try catch": {
    "prefix": "try",
    "body": ["try {", "\t$0", "} catch (${1:err}) {", "\t$2", "}"],
    "description": "Outputs a try/catch statement"
  }
}

That one is a little bit trickier to define:

The first line of the body only has the try statement
The second line has a tab character (\t) to add some whitespaces and $0 since this is where you'll finally write your code.
The third line has the catch statement: Here, we use placeholders to pre-define the alias of the error variable ${1:err}.
The fourth line allows to write the code in the catch statement

Improved console snippet

One cool thing you can do is to give multiple choices for a placeholder, the syntax being: ${1|one,two,three}.

For example, you can create an improved console snippet by choosing which method of console (log, info, warn, etc.) you want to call:

{
  "Print to console": {
    "prefix": "csl",
    // highlight-next-line
    "body": ["console.${1|log,info,warn,err|}($2)", "$0"],
    "description": "Logs something to the console"
  }
}

Test snippet

From here, you can do a lot of powerful stuff in your editor. Bootstraping files can be much quicker than before!

For example, I use react-testing-library for my tests, and I have custom render methods in it. Writing a new test file can be quite long, so I can automate it with a snippet:

{
  "New React test file": {
    "prefix": "rtl:customRender",
    "body": [
      "import React from \"react\"",
      "import { screen } from \"@testing-library/react\"",
      "",
      "import { ${1|renderWithRouter,renderWithRouterAndProviders|} } from \"$2\"",
      "import $3 from \"./$3\"",
      "",
      "describe(\"$3\", () => {",
      "\ttest(\"$4\", () => {",
      "\t\t$1(<$3/>)",
      "\t\t$0",
      "\t})",
      "})"
    ],
    "description": "Creates a new React test file with custom render"
  }
}

By using the variable $3 multiple times, I can write once at different places in the code. It's really handy for the component name.
I am also able to choose which render method to use from a test utils file

By defining all kinds of snippets, you can definitely improve your workflow and save time!

If you're working in a team of many developers, it's a great idea to share these snippets across your team. In VS Code, you can do so by including these snippets in a .vscode folder with a .code-snippets extension! 😎

Object and Array Destructuring in JavaScript

Thomas Lombart — Mon, 30 Mar 2020 06:05:29 +0000

When ES2015 (also known as ES6) got released, powerful new features saw the day like the destructuring assignment syntax. In short, it allows us to unpack values from arrays or properties from objects quickly and straightforwardly.

Consider this post as a quick reference when you want to check out something on destructuring in JavaScript. ☺️

Let's say you have a user object with different properties like the name, the age, the email address. You want to assign variables to these different properties, here is how to do it with and without destructuring:

// The old way: a bit verbose
const name = user.name;
const age = user.age;
const email = user.email;

// Using destructuring
const { name, age, email } = user;

Short and clear: that's the power of destructuring.

Now, let's say your user also has an address property, itself composed of a street, city, country, and postal_code properties. You can also use destructuring to handle nested objects:

// Assign the name, email, city and country
const {
  name,
  email,
  address: { city, country },
} = user;

But what if you would like to assign the city and country variables while keeping the whole address object? That's still possible:

// Destructure city, country and keep the address object as-is
const {
  address,
  address: { city, country },
} = user;

Sometimes when you retrieve data from an API, the variable names can be quite different. Imagine that the user object has an user_id property, and you want to rename it just id. It's useful in these cases to rename variables while destructuring using:

// Destructure user_id and rename it to id
const { user_id: id } = user;

The power of destructuring doesn't stop here. You can assign default values to properties in case they're not defined. For example, if your user were to have a favorite theme (light or dark) property, you could default it to light mode:

// If `theme` isn't defined, use the light mode by default
const { name, theme = "light" } = user;

Note that everything said above also works for function arguments. For example, you could imagine a displayAddress function taking a user object argument:

// Destructure the user object and set the country to France by default
function displayAddress({ name, address: { city, country = "France" } }) {
  // Note the use of template literals, another ES2015 feature
  return `${name} lives in ${city}, ${country}`;
}

If you're using React, it can also be useful when creating functional components:

const User = ({ name, age, email }) => (
  <div>
    <p>
      {name}, {age} years old
    </p>
    <p>{email}</p>
  </div>
);

Note that it's also possible to destructure some properties of an object and still save the rest of the properties using the rest parameter:

// Assign the name and the email of the user and store the other properties in userInfos
const { name, email, ...userInfos } = user;

It can also be handy in React if you need some props and need to pass down the other props.
Here's an example applied to routing in React:

const PrivateRoute: React.FC<Props> = ({ component: Component, ...rest }) => {
  // Get the user's authentication status
  const { isAuthenticated } = useAuth();

  return (
    <Route
      // Pass all the props to Route except `component`
      {...rest}
      render={(props) =>
        // if the user is authenticated, render the component otherwise redirect him to the signin screen
        isAuthenticated ? <Component {...props} /> : <Redirect to="/signin" />
      }
    />
  );
};

// Can be used that way:
// <PrivateRoute path="/create" component={CreatePost} />

Wait, wait, wait. The next one is even cooler. You can make use of dynamic destructuring by using computed property keys. Imagine that you have a users object and you want to normalize it by user ID (meaning that the key is the user ID). You can do that with destructuring:

const users = [
  { id: "afb4d", name: "Mike", age: 27 },
  { id: "fea4i", name: "Emma", age: 38 },
];

const normalizedUsers = users.reduce((usersById, user) => {
  return {
    // Assign the user object to its ID...
    // highlight-next-line
    [user.id]: user,
    // ... and return the whole normalized users object
    ...usersById,
  };
}, {});

/* 
normalizedUsers is now
{
  afb4d: { id: 'afb4d', name: 'Mike', age: 27 },
  fea4i: { id: 'fea4i', name: 'Emma', age: 38 }
}
*/

Destructuring also works for arrays. Let's say you retrieve a list of users (let's call it mostActiveUsers) sorted by the number of comments a user posted. You only want to display the first three users:

// Retrieve the first three most active users
const [first, second, third] = mostActiveUsers;

What if you'd like to get only the fourth user from this list? Well, it's also possible to skip items:

// Skip the first three most active users
const [, , , fourth] = mostActiveUsers;

You could also get the first three most active users and still store the other users with the rest parameter:

const [first, second, third, ...otherUsers] = mostActiveUsers;

Let's recap. You saw how to destructure objects (with nested objects), rename variables, assign default values, how destructuring applies to function arguments (and thus to components in React). You also saw dynamic destructuring, destructuring arrays, skipping array items and how to use the rest parameter with both objects and arrays.
You're now ready to unlock the full potential of destructuring in your app! 😎