Forem: PROTOTYP

Load fonts asynchronously & handle FOUT with my Gatsby plugin

Adrian Bece — Tue, 03 Nov 2020 06:42:35 +0000

In the past few weeks I was familiarizing myself with Gatsby and I was making a list of plugins that are good-to-have while working on a project. I went through the SEO plugins, SVG plugins, data source plugins, and finally, I wanted to check out some font loader plugins when I noticed something strange.

Here are the top two Gatsby plugins for fonts.

Top two font plugins for Gatsby

And if we open any of those two, we are greeted by the following message and README .

Oh no... this isn't good

Most-used plugins are abandoned, deprecated and not actively maintained.

Don't get me wrong, it's totally okay for authors and companies to back down from developing and maintaining an open-source repo. I think it would be better to transfer the ownership to someone who wants to continue the development beforehand rather than leaving it as is and archiving it.

Asynchronous font loading

That missing support for the most-used plugins was my primary motivation to develop the font loader plugin, but what do font loaders even do?

In short, font loaders help eliminate render-blocking resources, in this case, fonts and their respective CSS files. I've gone into more detail about render-blocking resources in one of my previous articles.

Improving website performance by eliminating render-blocking CSS and JavaScript

Adrian Bece for PROTOTYP ・ Aug 31 '20

#javascript #webdev #css #tutorial

When a website document is loaded, it automatically starts downloading high-priority resources that are needed before displaying the page - CSS, JavaScript, images, iframe, videos, fonts... Depending on how we instruct the browser, we can load some of those resources after the page has been displayed (rendered). By doing this, we are displaying the content as fast as possible to the user and loading all non-critical resources afterward to speed up the loading process.

This is especially true for web fonts, like Google fonts for example. During our page load, we are requesting a font CSS file from Google servers which also requests additional font files from Google CDN. Our page is not displayed until this chain of request resolves which can take some time depending on the CDN performance and user's internet connection.

With asynchronous loading, we can give a low priority to the font file and CSS and load it after the page is displayed. Although this has improved site performance, we have created a minor visual issue - Flash of Unstyled Text (FOUT).

Flash Of Unstyled Text (FOUT)

If the font is loaded after page content is displayed, we can see the moment the font changes between the fallback (default) font and the main web font that has been loaded asynchronously. This event is called Flash Of Unstyled Text or FOUT, for short. This change might even affect the page layout, size of some elements and even cause some visual bugs because the page is styled with web font in mind.

This isn't all that bad considering the performance gain, but it is very noticeable

What we can do to make this effect much less noticeable is:

Choose the fallback font that looks as closely as possible to the web font that is being loaded asynchronously
Adjust font size, line height, letter spacing and word spacing to match the web font as closely as possible

After adjusting the fallback font CSS, we get the following result.

We've adjusted the style (line-height, letter spacing, word spacing) of fallback font and the change looks nicer

You might be asking: how can we detect when the font has been download and applied to the document?

We'll have to use JavaScript to detect that event. In case of Gatsby, I've written a plugin that both loads the web font asynchronously and it listens to font load event and applies a CSS class to HTML body element to handle FOUT.

Gatsby omni font loader plugin

During the past week, I've been working on creating a Gatsby plugin that will use the recommended way of loading fonts and enable devs to handle FOUT easily.

And few days ago, I've published Gatsby Omni Font Loader that can work with both web fonts and self-hosted fonts, add preload and preconnect on SSR, add font asynchronously, and handle FOUT. All in one small, neat package.

You can check out the source code on Github. Feel free to submit issues, feature requests and pull requests. Support and contribution are very much appreciated!

codeAdrian / gatsby-omni-font-loader

Font loader optimized for maximum performance. Removes render-blocking font resources and loads them asynchronusly. Handle FOUT & FOUC with font loading status watcher. Supports both local-hosted fonts and web fonts.

Gatsby Omni Font Loader v2

Simple way to add webfonts or custom fonts to Gatsby project
Performant asynchronous font loading can be enabled
Font loading listener can be enabled
Flash Of Unstyled Text (FOUT) handling support

Features

Supports web fonts & self-hosted fonts
Preloads the files & preconnects to the URL
Loads fonts asynchronously to avoid render blocking
Implemented with fast loading snippets
Loading status listener for avoiding FOUT
Small size & minimal footprint

Install

npm install gatsby-omni-font-loader react-helmet

yarn add gatsby-omni-font-loader react-helmet

Configuration

Add the following snippet to gatsby-config.js plugins array.

{
  /* Include plugin */
  resolve: "gatsby-omni-font-loader",
  /* Plugin options */
  options: {

    /* Font loading mode */
    mode: "async",

    /* Enable font loading listener to handle FOUT */
    enableListener: true,

    /* Preconnect URL-s. This example is for Google Fonts */
    preconnect: ["https://fonts.gstatic.com"],

    /* Self-hosted fonts

…

View on GitHub

Installation

Start by installing the plugin with NPM or Yarn.

npm install --save-dev gatsby-omni-font-loader

yarn add --dev gatsby-omni-font-loader

Configure the plugin

In gatsby-config.js file, reference the gatsby-omni-font-loader plugin in the plugins array and configure it.

Below is the sample config and explanation for each of the options available.

{
  /* Include plugin */
  resolve: "gatsby-omni-font-loader",

  /* Plugin options */
  options: {

    /* Enable font loading listener to handle FOUC */
    enableListener: true,

    /* Preconnect URL-s. This example is for Google Fonts */
    preconnect: ["https://fonts.gstatic.com"],

    /* Self-hosted fonts config. Add font files and font CSS files to "static" folder */
    custom: [
      {
        /* Exact name of the font as defied in @font-face CSS rule */
        name: ["Font Awesome 5 Brands", "Font Awesome 5 Free"],
        /* Path to the font CSS file inside the "static" folder with @font-face definition */
        file: "/fonts/fontAwesome/css/all.min.css",
      },
    ],

    /* Web fonts. File link should point to font CSS file. */
    web: [{
        /* Exact name of the font as defied in @font-face CSS rule */
        name: "Staatliches",
        /* URL to the font CSS file with @font-face definition */
        file: "https://fonts.googleapis.com/css2?family=Staatliches",
      },
    ],
  },
}

Handling FOUT

When enableListener: true is set in plugin config in gatsby-config.js, HTML classes are being added to <body> element as the fonts are being loaded.

HTML class name format will be in the following format

wf-[font-family-name]--loaded

You can use the Font Style Matcher to adjust the perfect fallback font and fallback CSS config and use the styles from there.

Here is the example of how body element will look like after all fonts are being loaded (depending on the config).

<body class="wf-font-awesome-5-brands--loaded wf-font-awesome-5-free--loaded wf-staatliches--loaded">

So the CSS will look something like this

body {
 font-family: "Merriweather", Georgia, sans-serif;
 /* default styles */
}

body:not(.wf-merriweather--loaded) {
 /* fallback font (Georgia) CSS config */
 /* line-height, letter spacing, font-size... */
}

body:not(.wf-merriweather--loaded) h1 {
 /* fallback font (Georgia) CSS config */ 
 /* line-height, letter spacing, font-size... */
}

.wf-merriweather--loaded {
 /* web font CSS config */ 
 /* line-height, letter spacing, font-size... */
}

.wf-merriweather--loaded h1 {
 /* web font CSS config */ 
 /* line-height, letter spacing, font-size... */
}

These articles are fueled by coffee. So if you enjoy my work and found it useful, consider buying me a coffee! I would really appreciate it.

Thank you for taking the time to read this post. If you've found this useful, please give it a ❤️ or 🦄, share and comment.

The thing about service workers...

Sebastijan Dumancic — Fri, 25 Sep 2020 08:10:43 +0000

For years, service workers have promised us a feeling of a native app straight in the browser. While specific parts of it are true, such as access to device hardware (gyroscope, orientation sensor, etc.) or background sync, we're still far cry from the native feel in areas such as push notifications, which don't work at all in iOS, and especially offline support. While it's fun to have options and experiment on private, small projects, we can't really consider technologies to be production-ready when they don't support half the devices out there.

With that in mind, service workers also come with a lot of baggage. And we've found that out in a hard way.

Problem with service workers

First, you start developing your app, include service worker because it's a cool new thing to do, you want offline support or definitely want to have all the stuff they bring as an option to use. Months go by, you release v1 of the app and users start rolling in. As it's the first version, things are bound to change, so you implement the first couple of changes. You maybe change some copy around, some links, but soon you get a report that you have a huge bug discovered by one of your users. Maybe something potentially catastrophic for your database, it happens.

Fear not, you patch it up and go about your day. Months go by, and you release v2 of the app, market it like crazy and it reaches some top lists of this and that, and same users that entered your app a couple of months ago, and never again, land on your page and load a completely cached version from the last time they visited, together with any hardcoded values, bugs, funnel changes... essentially a snapshot from the past.

By the time you realize what you have done, you've already saved a snapshot of the app in the arbitrary time to thousands of devices, unable to wipe the cache on their devices, and just sit and wait for them to potentially open your older, less secure version of the app from months ago.

Potential solutions

The way service worker works is when users land on your website for the 2nd time, it loads all assets and files from SW and THEN checks if you have pushed a new SW update in the meantime. If it finds one, it schedules it to be loaded next time you open the website. To make matters worse, normal refresh won't load the new SW content, but you have to close the session (i.e. close all website tabs currently open, or whole browser) and reopen the website to load the new version.

By following this article:

Let Users Know When You Have Updated Your Service Workers in Create React App

Gert Glükmann ・ Jan 4 '20

#react #javascript #serviceworkers #pwa

I found out that you can insert an action into this process of discovering the new version of SW. The problem is that you can either notify users that a new version is available and leave it up to them to click Load new version which will reload the website properly, or you can force a refresh when the browser figures out that a new SW version is available and installed, which can be after a couple of seconds and well into the time when the app was already interactive, meaning that user started to do something.

Usually, early in the live of an app, updates could be released several times a day, which means users could get a prompt or hard refresh multiple times a day when they land on a website, which is also not a good option.

Other way around, we leave ourselves open to the ghosts of the past by giving users the option to load a new version of the site or not. This way malicious users could take advantage of the app in its pre-patched state.

The worst thing is, when you decide to change your approach, you still have all the old users cached on your previous decision and they don't get the memo that they should reload as soon as they open the site.

Now, when you think about it, it becomes obvious that this is how native apps work from the start. You have a version that is the latest and a lot of previous versions that people have installed, and are still using. But the web isn't native.

Addon:
As leob mentioned in the comments (thanks!) some apps force users to update to new versions even in the native environment. Banking apps first come to mind, which just confirms that the issue exists and if security is an important priority for us, that we have to address it in a creative way.

Conclusion

Many years ago, Web solved the issue where users had to install a new version of software on their devices, where we had to incentivize them to update or upgrade, and support legacy versions with both features and bugfixes. We approach web development with a different mindset than native development. We KNOW we can push updates very quickly to 100% percent of our users, and we are used to pushing experimental features, knowing very well that we can patch them up as we go or remove them fairly quickly if they turn out to be bad ideas. Including service workers turn the tables around once again, by introducing fragmentation, legacy support, and fear of the unknown on the internet, which is something that should be avoided at all costs.

Sure, if we create just a couple of versions all of which are perfect, this is a non-issue, but let's be real, those apps don't exist. So how do you deal with these issues if you still want to keep offline support? Do you use service workers at all? Let me know!

Improving website performance by eliminating render-blocking CSS and JavaScript

Adrian Bece — Mon, 31 Aug 2020 07:20:20 +0000

In my previous post, I've talked about how I boosted Lighthouse scores for my personal website by implementing native lazy loading with fallback.

Best way to lazy load images for maximum performance

Adrian Bece for PROTOTYP ・ Aug 24 '20

#webdev #tutorial #html #javascript

Another important improvement that boosted my performance and Lighthouse score was eliminating render-blocking resources.

Critical and non-critical resources

When we usually build a project, we like to include everything we need right out of the box - all styles, JavaScript plugins, JavaScript code, fonts, images, etc. We usually do this to make sure that no async loading errors happen while we develop the project.

The reality is that browser needs to load, parse and run everything we include when website loads, which can make the first paint (with no cached resources) unnecessarily slow. It's called render-blocking because browser is wasting time and resources parsing the code that is unnecessary for the initial page load and not displaying the page content.

When we take a look at our resources (CSS, JavaScript, fonts, etc.) we can sort them into two categories:

Critical resources - code that's critical to the page's core functionality.
Non-critical resources - code not being used in page's core functionality and a code that runs after the page is loaded or on user interaction.

So let's take a look how we to handle critical and non-critical CSS and JavaScript resources.

Handling critical CSS

Critical CSS refers to the styles that are necessary for styling above the fold content. Above the fold content that is visible to users when they first load the page (top section of the page).

In order to add critical CSS to the page, we need to remove those styles from the CSS stylesheet and add them directly to HTML in a <style> tag inside a <head> element.



<head>
  <!-- ... -->

  <style>
    /* Add critical styles here */
  </style>

  <!-- ... -->
</head>

Critical CSS on my personal site

This approach may increase HTML document size a bit, but those changes are insignificant if you use compression algorithm like GZIP or Brotli for HTML delivery.

Adding critical CSS directly to HTML document ensures that those styles and parsed and applied on the first paint (initial load).

Handling non-critical CSS

In order to make the critical CSS effective, we need to tell the browser how to handle non-critical CSS and display the page. It also allows us to use the website while the additional non-critical CSS loads. Depending on Internet connection speed, you might not even notice the additional styles being loaded.

In order to handle non-critical CSS, we need to change how the CSS file which contains those styles loads.



<head>
  <!-- ... -->

    <link crossorigin rel="preload" href="/path/to/styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
    <noscript><link rel="stylesheet" href="/path/to/styles.css"></noscript>

  <!-- ... -->
</head>

This may look like a hack at first, but this is a really smart and efficient way of loading CSS in an efficient way with proper fallback:

link rel="preload" as="style" loads the CSS file in a non-render-blocking way.
onload="this.onload=null;this.rel='stylesheet'" makes sure that CSS file is parsed and loaded after the site loads and the onload function is deleted.
noscript fallback makes sure that the CSS loads the standard way if JavaScript is not available.

Non-critical styles being loaded on a below-the-fold content. Notice how some (critical) styles are already applied (grey background) before the rest is loaded (non-critical)

It's also important to note that we can load Google Fonts stylesheets in the same efficient way!



<link crossorigin rel="preload" href="https://fonts.googleapis.com/css2?family=Montserrat:wght@400;600&display=swap" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Montserrat:wght@400;600&display=swap"></noscript>

Firefox issue & handling IE

At the time of writing this article, Firefox has a bug related to preloading CSS. This efficient way of loading non-critical CSS currently isn't working on Firefox, but it should be fixed soon.

You might want to provide a fallback for browsers that do not support preloading or have issue with it (like Firefox). Luckily, this is really easy to do with inline JavaScript.



<script>
    var isIE = !!window.MSInputMethodContext && !!document.documentMode;
    var isFirefox = navigator.userAgent.toLowerCase().indexOf("firefox") > -1;

    if (isIE || isFirefox) {
        var pageStylesheet = document.createElement("link");
        pageStylesheet.rel = "stylesheet";
        pageStylesheet.type = "text/css";
        pageStylesheet.href = "/path/to/styles.css";
        document.head.appendChild(pageStylesheet);
    }
</script>

We just need to add this code before body closing tag to insert the regular link element into head element for Firefox and IE browsers which do not support preloading.

Handling critical JavaScript

We handle critical JavaScript the similar way we handle critical CSS, by inlining it within HTML code. It's important to note that we need to insert critical JavaScript code using script tag before the body closing tag. That way we make sure that JavaScript doesn't block content render and all available DOM nodes are created and available to JavaScript code.



<body>

  <!-- ... -->

<script>

    /* Inlined JavaScript code */

  </script>

</body>

Handling non-critical JavaScript

We can handle non-critical JavaScript just by adding defer or async tags to script tag (inline JavaScript or JavaScript loaded from src).

We use defer for scripts that need the whole DOM and/or their relative execution order is important. It tells the browser to load the page first and then load the script in the background.
We use async for independent scripts that can be executed in any order. This script doesn't wait for any other scripts and can loaded in parallel with other scripts with async scripts.



<script defer src="/path/to/script.js"></script>

<script async src="/path/to/script.js"></script>

Boosted performance & Lighthouse score

On my personal website I've handled critical and non-critical CSS and JavaScript as I've described in the article. After implementing this modern approach, I've eliminated render-blocking, non-critical CSS and JavaScript which in turn boosted my Lighthouse score and overall performance!

These articles are fueled by coffee. So if you enjoy my work and found it useful, consider buying me a coffee! I would really appreciate it.

Thank you for taking the time to read this post. If you've found this useful, please give it a ❤️ or 🦄, share and comment.

Best way to lazy load images for maximum performance

Adrian Bece — Mon, 24 Aug 2020 05:50:20 +0000

Image lazy loading is one of the more popular approaches of optimizing websites due to the relatively easy implementation and large performance gain. With lazy loading we load images asynchronously, meaning that we load images only when they appear in the browser's viewport.

Almost a year ago, native lazy loading for images and iframes was released for Chrome and other major browsers. The point of the feature is to give browsers control when to request an image or iframe resource, which makes dev jobs a bit easier. Up to that point, only option was to use various JavaScript plugins which monitored the viewport changes and loaded resources dynamically. Now browsers can do that natively!

At the time of writing this article, around 73% of currently used browsers support this feature which is not bad, but we don't want to make the website image content inaccessible and unusable to 27% of potential users.

So this puts us in an interesting situation:

We want to use the benefits of native lazy loading for browsers that support it
We want to use a JS plugin as fallback for lazy loading for browsers that don't support it
We don't want to load the lazy loading JS plugin if the browser supports native lazy loading.
Support both img and source elements is mandatory

The "loading" attribute

We have three possible values that we can use for loading attribute.

auto - default value. Same as not setting the attribute.
eager - load the resource immediately.
lazy - load the resource once it's in the viewport.

Although it depends on the use-case, generally we want to use eager value for resources above the fold and lazy value for resources below the fold.

Modern approach

We need to write a script that will run after the HTML document is loaded. I've used Jekyll and added the script as an include that was appended to the end of the HTML body element. This is the most effective way of running JavaScript functions to avoid render blocking.

Image markup

We want our JavaScript function to start the image loading process based on the native lazy loading feature support. To achieve that we'll add the path to our images to data-src instead of src. But we shouldn't leave src empty, so we'll use 1x1px transparent image placeholder. Our markup for img elements will look something like this

 <img 
    src="/path/to/placeholder/image.png"
    data-src="/path/to/full/image.jpg"
    alt="Image description"
    class="lazyload"
    loading="lazy"
/>

Please note that class="lazyload" is used by the lazyload fallback plugin. I've used lazysizes that uses this particular class name.

Additionally, we want to support picture element that contains multiple source element and fallback img element.


<picture>
    <source data-srcset="path/to/image.webp" type="image/webp" />
    <source data-srcset="path/to/image.jpg" />
    <img loading="lazy" 
        class="lazyload"
        src="path/to/placeholder/image.png"
        data-src="path/to/image.jpg"
        alt="Image description"
    />
</picture>

Feature detection

We need to detect if user's browser supports native lazy loading. Luckily, we can do that using JavaScript directly.

   if ("loading" in HTMLImageElement.prototype) {
      /* Native lazy loading is supported */
   } else {
      /*  Native lazy loading is not supported */
   }

Final JavaScript code

For native lazy loading, we only need to assign data-src value to src value for img and source elements and let the browser handle the rest.

For unsupported browsers, we only need to load the JavaScript plugin and, optionally, run it (if not done automatically). I've used lazysizes but any plugin will work, just make sure that the markup is correct (class names, data elements, etc.).

So the final JavaScript code will look something like this:

<script>
    if ("loading" in HTMLImageElement.prototype) {
        var images = document.querySelectorAll('img[loading="lazy"]');
        var sources = document.querySelectorAll("source[data-srcset]");
        sources.forEach(function (source) {
            source.srcset = source.dataset.srcset;
        });
        images.forEach(function (img) {
            img.src = img.dataset.src;
        });
    } else {
        var script = document.createElement("script");
        script.src = "/link/to/lazyload.js";
        document.body.appendChild(script);
    }
</script>

Boosted performance & Lighthouse score

On my personal website I've used a JavaScript plugin for image lazy loading for all browsers. After implementing this modern approach, I've eliminated one JavaScript file that is being loaded and parsed on website load which in turn boosted my Lighthouse score and overall performance!

More image optimization techniques for maximum performance

Lazy loading is one of many ways to optimize image performance on the web. I've wrote this in-depth posts that covers other important techniques and aspects of image optimization for the web like web-specific image formats, using CDN, progressive images, etc.

Optimizing images for the web - an in-depth guide

Adrian Bece for PROTOTYP ・ Oct 1 '19

#webdev #beginners #productivity #html

Improving website performance by eliminating render-blocking CSS and JavaScript

Adrian Bece for PROTOTYP ・ Aug 31 '20

#javascript #webdev #css #tutorial

These articles are fueled by coffee. So if you enjoy my work and found it useful, consider buying me a coffee! I would really appreciate it.

Thank you for taking the time to read this post. If you've found this useful, please give it a ❤️ or 🦄, share and comment.

Multi-language routing in React

Vlatko Vlahek — Wed, 30 Oct 2019 12:55:46 +0000

Multi-language routing in React

One of the great things around routing in React is that its ecosystem has allowed for great and very declarative routing syntax. You can define your routing as a set of components, write an object structure from which you will render the routing logic, etc.

And it’s constantly improving and getting better and better:

react-router v5.1 is out
reach router is also getting big traction, check it out.

But, what if you want to support a true multi-language routing, which will support route names in multiple languages and redirect your users to correct routes when you change languages?

Is that really a big deal?

Well, it is definitively possible to go on without such a feature and have a fully usable website. There are a lot of websites that have English-only routing, but multi-language content.

From a development perspective, the reasons for this vary:

A framework that doesn’t support it is used.
It’s a big effort to implement.
It’s not always easy to maintain.

However, having a multi-language route localization can give you and your end-users the following benefits:

multi-language SEO
users get the additional context of the page hierarchy in their own language

A solution written in React is relatively simple to implement and maintain, and this article will outline the packages and methods that will guide you to a solution.

The example is written with TypeScript, latest react-router-dom, and react-hooks.

Add a Router package

In case you aren’t using a router package, try react-router-dom out.

yarn add react-router-dom
yarn add @types/react-router-dom --dev

After adding a router, we should define a few routes and components that will be used on our website.

export const App: React.FC = () => (
  <BrowserRouter>
    <AppLayout>
      <Switch>
        <Route exact path={AppRoute.Home}>
          <views.Home />
        </Route>
        <Route exact path={AppRoute.Summary}>
          <views.Summary />
        </Route>
        <Route path="*">
          <views.GeneralError />
        </Route>
      </Switch>
    </AppLayout>
  </BrowserRouter>
);

In the latest react-router-dom version, component and render props were scrapped for children prop which is much more flexible. The only downside is that the v4 version was more concise and readable in most scenarios. Please note that the old way of doing things through component/render props is still available at this moment, but it will become deprecated soon.

We also added an AppLayout component which allows us to have a global header, navigation, and footer, and renders the routes inside the main tag as partial views.

There is also a fallback route here that renders the error component so our users know that they ended up on the error page in case they try to access a route that doesn’t exist.

Add an i18n package

First, we need to add a package that will allow us to internationalize things in our app. There are a lot of good examples, but one of the best packages around is react-intl.

It is a project by FormatJS (Yahoo! Inc) which has impressive support for localizing almost everything, including currencies, dates, etc.

    yarn add react-intl

This package was written in Typescript so it has its own types included.

Adding a base locale

It’s always easiest to start with a language that will be the primary language for the website as a baseline. You can always add more languages easily later on.

Let’s first add an enum which will be a collection of all languages used inside our app. For start, we will only add the base language.

export enum AppLanguage {
  English = 'en',
}

The value of each enum property should match a two-letter country code ISO locale.

After adding a language, we should also add some language strings for that language, which we will use to localize our routes and other content.

Create an intl folder somewhere in the app, and a file for your base language.

const baseStrings = {
  /** Routes */
  'routes.home': '/',
  'routes.summary': '/summary',

  ...
};

export type LanguageStrings = typeof baseStrings;
export const en = baseStrings;

The exported type will be used as an equality enforcer which all other languages need to support, meaning that any localization added to baseStrings will need to be added to other files in order to enforce some safety. It also works vice-versa.

If you try to add a string to a specific language which doesn’t exist in the base strings file, you will get a compilation error. This will enforce that all of the used languages have all strings at least set, if not translated, and save you from runtime errors.

We are also exporting the baseStrings as a matching iso variable for the language at hand.

Now let’s add a matching enum (or frozen object in plain JS) which we can use to reference the routes to avoid any typos.

export enum AppRoute {
  Home = 'routes.home',
  Summary = 'routes.summary'
}

Localized Switch component

In order to simplify the process of translating the route paths, we will create a custom LocalizedSwitch component that handles this logic.

It is also possible to do this on the route component level, however, swapping out the Switch component allows you to support this with the least amount of changes, as it is easier to update the parent then every route to a LocalizedRoute variant. Changing the route component is probably a more flexible solution though.

The intended suggestion for the LocalisedSwitch component is imagined as a drop-in replacement for the normal Switch one, and it is designed to work with Route components from the react-router-dom package.

export const LocalizedSwitch: React.FC = ({ children }) => {
  /**
   * inject params and formatMessage through hooks, so we can localize the route
   */
  const { formatMessage, locale } = useIntl();

  /**
   * Apply localization to all routes
   * Also checks if all children elements are <Route /> components
   */
  return (
    <Switch>
      {React.Children.map(children, child =>
        React.isValidElement<RouteProps>(child)
          ? React.cloneElement(child, {
              ...child.props,
              path: localizeRoutePath(child.props.path)
            })
          : child
      )}
    </Switch>
  );

  /**
   *
   * @param path can be string, undefined or string array
   * @returns Localized string path or path array
   */
  function localizeRoutePath(path?: string | string[]) {
    switch (typeof path) {
      case 'undefined':
        return undefined;
      case 'object':
        return path.map(key => `/${locale}` + formatMessage({ id: key }));
      default:
        const isFallbackRoute = path === '*';
        return isFallbackRoute
          ? path
          : `/${locale}` + formatMessage({ id: path });
    }
  }
};

Wiring it all up

To wire it all together, we need to add the IntlProvider component from the react-intl package, connect it to the data we defined, and add our own LocalizedSwitch component.

export const App: React.FC = () => (
  <LocalizedRouter
    RouterComponent={BrowserRouter}
    languages={AppLanguage}
    appStrings={appStrings}
  >
    <AppLayout>
      <LocalizedSwitch>
        <Route exact path={AppRoute.Home}>
          <views.Home />
        </Route>
        <Route exact path={AppRoute.Summary}>
          <views.Summary />
        </Route>
        <Route path="*">
          <views.GeneralError />
        </Route>
      </LocalizedSwitch>
    </AppLayout>
  </LocalizedRouter>
);

Supporting multiple languages

Now that we have covered the basics of setting up the logic that allows us to internationalize our application and localize the application routes, we need to add support for other languages and add their route definitions.

For the purpose of this example, let’s add support for Deutch, French and Croatian languages, all inside the intl folder that we already have.

Disclaimer: I don’t personally speak Deutch or French, so if the translations are not perfect, I do apologize for mangling your language, but please blame Google Translate :)

Adding translations for a new language

Just add a new language file inside the intl folder:

export const de: LanguageStrings = {
  /** Routes */
  'routes.home': '/',
  'routes.summary': '/zusammenfassung',

  ...
};

If you are wondering why this was done in .ts file in this scenario, and not another format like JSON, the sole purpose is to enforce safety that comes with using TypeScript.

You can, of course, write these in JSON, JS or another preferred format in case you don’t want or need the type-safety.

For every language file you add, extend the AppLanguage enum.

Updating the router

We first need to update the router to support redirecting to other languages, reading the current language from the pathname, and setting the locale accordingly.

Expected behaviour:

/summary -> Redirect to base language
/en/summary -> English language summary page
/de/zusammenfassung -> German language summary page

We will swap out the default router component with the one that supports pathname detection and returns react-intl provider.

interface Props {
  RouterComponent: React.ComponentClass<any>;
  languages: { [k: number]: string };
  appStrings: { [prop: string]: LanguageStrings };
  defaultLanguage?: AppLanguage;
}

export const LocalizedRouter: React.FC<Props> = ({
  children,
  RouterComponent,
  appStrings,
  defaultLanguage
}) => (
  <RouterComponent>
    <Route path="/:lang([a-z]{2})">
      {({ match, location }) => {
        /**
         * Get current language
         * Set default locale to en if base path is used without a language
         */
        const params = match ? match.params : {};
        const { lang = defaultLanguage || AppLanguage.English } = params;

        /**
         * If language is not in route path, redirect to language root
         */
        const { pathname } = location;
        if (!pathname.includes(`/${lang}/`)) {
          return <Redirect to={`/${lang}/`} />;
        }

        /**
         * Return Intl provider with default language set
         */
        return (
          <IntlProvider locale={lang} messages={appStrings[lang]}>
            {children}
          </IntlProvider>
        );
      }}
    </Route>
  </RouterComponent>
);

Wrapping everything in a route, allows us to use regex to determine the language from the pathname, and use that match to inject the current language into the provider.

Also, our new router component will enforce that a language is always a part of the pathname.

The regex used in this example will only support lowercase language, but you can modify it to [a-zA-z]{2} and use String.toLowercase() method when pathname matching if you want to support uppercase routes as well.

Language switcher

We also need to add a language switcher component that will allow us to change the active language and show the currently activated language based on the pathname.

Apart from the styling, we need a helper function that checks for matching route inside the strings object for other languages if we want to support navigating to the same page in another language directly.

export const LanguageSwitcher: React.FC = () => {
  const { pathname } = useLocation();
  const { locale, messages } = useIntl();

  return (
    <ul className={css(list.container)}>
      {Object.keys(AppLanguage).map(lang => (
        <li key={lang} className={css(list.item)}>
          <NavLink
            className={css(link.primary)}
            activeClassName={css(link.active)}
            to={getMatchingRoute(AppLanguage[lang])}
          >
            {AppLanguage[lang]}
          </NavLink>
        </li>
      ))}
    </ul>
  );

  function getMatchingRoute(language: string) {
    /**
     * Get the key of the route the user is currently on
     */
    const [, route] = pathname.split(locale);
    const routeKey = Object.keys(messages).find(key => messages[key] === route);

    /**
     * Find the matching route for the new language
     */
    const matchingRoute = appStrings[language][routeKey];

    /**
     * Return localized route
     */
    return `/${language}` + matchingRoute;
  }
};

Navigation

The last thing to do is updating the Navigation component itself, to also support switching to other routes in all languages.

We simply use the formatMessage function from the react-intl hook for this purpose.

export const Navigation: React.FC = () => {
  const { formatMessage, locale } = useIntl();

  return (
    <ul className={css(list.container)}>
      {Object.keys(AppRoute).map(elem => (
        <li key={elem} className={css(list.item)}>
          <NavLink
            exact
            className={css(link.primary)}
            activeClassName={css(link.active)}
            to={localizeRouteKey(AppRoute[elem])}
          >
            {formatMessage({ id: AppRouteTitles.get(AppRoute[elem]) || '' })}
          </NavLink>
        </li>
      ))}
    </ul>
  );

  function localizeRouteKey(path: string) {
    return `/${locale}` + formatMessage({ id: path });
  }
};

In order to allow for easier route name resolution, since TS enums don’t allow for reverse mapping on string enums, you can create an ES6 map.

export const AppRouteTitles = new Map([
  [AppRoute.Home, 'home.title'],
  [AppRoute.Summary, 'summary.title']
]);

Summary

As you can see, localizing the routes of the website is not a hard task in React. It requires a few components and little thinking on the side of the project architecture, so you don’t overcomplicate things. The result is easy to understand the solution that will easily scale regardless of the language count that you might add later on.

A fully working example can be found on:
vlaja/multilanguage-routing-react

UX lessons learned from eCommerce projects

Adrian Bece — Mon, 28 Oct 2019 07:10:57 +0000

I have worked as a certified Magento 1 and Magento 2 frontend developer for an eCommerce agency for 4 years. I've developed and maintained several webshops ranging from small scale to enterprise shops and I've audited numerous websites for frontend performance and UX.

After moving onto non-eCommerce projects, I've noticed that I could apply the lessons I've learned while working on eCommerce to create very user-friendly and performant frontends with great UX features.

In this article, I will present a general overview of some of the lessons and UX best practices that I've learned throughout my 4-year career working on eCommerce projects.

Reduce user's effort where possible

An eCommerce website can make the shopping experience as clear and simple as possible by providing various helpful features:

Saved billing & shipping addresses
Saved payment methods
Easy login (social media login)
Fast checkout with saved customer details
Customer wishlist
Clear shopping flow (uniform CTA elements)
etc.

By reducing the effort that the user has to invest in shopping and focusing the effort only on areas that require it, we can increase the conversion and overall revenue.

Example of stored payment method on Magento 2 demo

With that in mind, we can work on reducing the user effort by offering the user various ways of speeding up and simplifying the flow. It's important to take note of repeating processes in the flow and processes that could be automated or sped up.

Header & first impression of a website

Header and its navigation represent the webshop brand, informs the customer about types of products and services that it offers and provides helpful information.

It has several functions:

Represents the brand (with logo)
Navigation gives a general overview of the product catalog (top-level categories)
Displays account state (guest or logged in)
Displays cart state (amount of products in the cart)
Displays a search element (input or a toggle)
(optional) Provide only the most helpful links (FAQ, billing, shipping, returns, etc.)

Standard webshop navigation with branding, categories, cart, account and helpful link elements

Looking at the header, the customer needs to become familiar with the branding and instantly know what kind of content and general topics that can be found on the website. Alongside that, the header needs to provide helpful tools and links that can make the site navigation easier.

Call To Action elements

In eCommerce, Call To Action (CTA elements) need to have the most visual weight on the page, be uniform and lead the user down the path from browsing the product catalog, adding individual product(s) to the cart, and successfully finishing the checkout.

For example, the "Subscribe" button on a Newsletter element should have less visual weight than the "Add to cart" button.

Prominent CTA button

CTA elements that have the most visual weight on the site need to guide a user in the main website flow or the flow they choose to follow. Having many CTA elements on the page can be confusing to the user, so it's important to establish an element hierarchy and use the appropriate element for a context (primary flow, secondary flow, optional flow, etc.).

Importance of responsive design

There are more users accessing the web from a mobile device than a desktop device, so more and more customers are using mobile devices to shop online. More and more websites focus on having a great, if not superior, UX on mobile and tablet devices. Revenue and number of purchases on mobile and tablet devices continue to grow year after year.

79% of smartphone users have made a purchase online using their mobile device in the last 6 months

Almost 40% of all eCommerce purchases during the 2018 holiday season were made on a smartphone.

Source: Mobile eCommerce Stats in 2018 and the Future Online Shopping Trends of mCommerce

By using analytics tools like Google Analytics, we can determine the ratio of users using mobile devices to users using desktop devices and track various metrics (like conversion rates) for each group. Website owners and management can make various decisions when improving the site or planning new features.

Every second of loading time matters

How much does each second of loading cost?

Pages that loaded in 2.4 seconds had a 1.9% conversion rate

At 3.3 seconds, conversion rate was 1.5%

At 4.2 seconds, conversion rate was less than 1%

At 5.7+ seconds, conversion rate was 0.6%

Source: Cloudflare - How Website Performance Affects Conversion Rates

It's not all that surprising that users will abandon the site if it loads too slow. In the context of an eCommerce site, if a user abandons the site due to the large loading times right before checking out, it results in a revenue loss.

Many webshops found that improving the loading times and optimizing the frontend and backend resulted in a significant revenue increase.

Walmart found that for every 1 second improvement in page load time, conversions increased by 2%

COOK increased conversions by 7% by reducing page load time by 0.85 seconds

Mobify found that each 100ms improvement in their homepage's load time resulted in a 1.11% increase in conversion

Source: Cloudflare - How Website Performance Affects Conversion Rates

After working on eCommerce projects, I've started optimizing code and asset file size right from the start, eliminating any potential performance bottlenecks right from the start. These bottlenecks and issues are common for all websites. I've covered the subject of improving frontend performance in some of my previous articles.

Optimizing images for the web - an in-depth guide

Adrian Bece for PROTOTYP ・ Oct 1 '19

#webdev #beginners #productivity #html

Improving CSS performance and file size - an in-depth guide

Adrian Bece for PROTOTYP ・ Oct 16 '19

#css #webdev #productivity

Implementing Skeleton Loading in React

Adrian Bece for PROTOTYP ・ Sep 4 '19

#react #webdev #tutorial

Using schema.org to describe the content

By adding schema.org tags to a website, Google and other search engines can better understand the site they crawl and display. schema.org is just a collection of simple HTML attributes that can be easily added to websites. There are a lot of use-cases and tags that can describe your website in great detail and can be a topic of a future article due to the number of possible use-cases and options.

eCommerce website using schema.org tags

Here are some useful links on how to implement schema.org tags

Analyzing user flow to determine performance bottlenecks - category page example

The standard category page consists of a product catalog (displayed in a grid or a list), a toolbar with sorting and display options, layered navigation (filters) and pagination.

This layout usually also applies to the search results page.

From what we know, we can notice the following:

This page is reloaded each time user interacts with filters, sorting options, display options, pagination or the search page
Images play the biggest part in page size and number of requests

For example, If there are 24 products displayed on a category page with only 8 items in the user's viewport on load, we are downloading 16 images that the user might not even see, but it slows down a page load considerably (depending on image size and optimization).

With that in mind, the best improvement that we can do on a category page is to optimize image sizes and add lazy loading. I've gone into more detail about image optimization in the following article.

Optimizing images for the web - an in-depth guide

Adrian Bece for PROTOTYP ・ Oct 1 '19

#webdev #beginners #productivity #html

By following user flow, we can determine potential bottlenecks on the page and optimize them from the start. It's also helpful to be aware of the type of content that is going to be on the page (images, text, videos) and apply optimization techniques accordingly.

User focus and forms - checkout page example

Removing distracting page elements

When the user decides to check out and buy the items in their cart, we need to ensure that the user doesn't get distracted and leaves the checkout page. The best way of doing that is to simplify the header and footer (or remove footer entirely). Ideal checkout page consists of the following elements:

Header with branding only - the user is reassured that they are on the same website, but they are not distracted by navigation and links
Checkout form - divided into sections or steps.
Security section (short info, lock icon, etc.) - the user is reassured that the data they provide in checkout (address, payment data, etc.) is safe and that they can trust the website.

Let's take a look at the example of a simplified page layout on checkout.

First, let's take a look at how the header looks like on the homepage.

Harry's landing page - notice the header

And this is how it looks like on checkout. It keeps the user focused on the checkout form, while reassuring users that they've stayed on the same website.

Harry's checkout - notice how header is simplified

We have the ability to guide the user's focus while the user browses the website. It's important to know when we need to reduce the number of distracting elements on the page to focus the user on the important flow or give the user many focus points on the page.

Form layout

Often times, it's tempting to create multi-column forms, but this can cause some issues. Users can take different paths when filling out those forms.

Users can fill out multi-column forms in different ways

This can become very confusing to the user and they could lose the sense of progression, and might not check out successfully.

By keeping the form inputs in a single column and dividing them into sections and steps customer can scan the inputs more clearly, have a better sense of progression and have a better chance of successfully submitting the form and following the user flow.

Form validation

On checkout, form validation needs to happen as the user is typing data.

If we run validation when the user clicks the "Submit" button and there is an error somewhere in among a handful of inputs, the user needs to go back and find the error and fix it before proceeding. This ruins the user's sense of progression and doesn't reassure them that their data is valid in time.

Additionally, required fields need to be clearly marked and their labels need to stand out more prominently in the form.

If the data like address or telephone needs to follow a certain pattern or format, this needs to be clearly communicated to the user via tooltip next to the form.

Additionally, you can also use those tooltips to reassure users that their email and/or telephone number will only be used for purposes important to the website flow and not for promotion (unless the user doesn't explicitly gives permission).

Conclusion

After 4 years of working in the eCommerce industry, I've learned how properly follow the user flow on the page and pinpoint potential performance and UX bottlenecks, various UX best practices, how every second of load time matters, etc. I've successfully managed to apply these lessons when I moved onto projects beyond eCommerce and it changed the way I've looked at and analyzed the websites.

I hope that you've found this article helpful and that you'll be able to apply these UX improvements in your projects. I've only covered a handful of UX lessons I've learned, but feel free to share your own UX tips and thoughts in the comments.

These articles are fueled by coffee. So if you enjoy my work and found it useful, consider buying me a coffee! I would really appreciate it.

Thank you for taking the time to read this post. If you've found this useful, please give it a ❤️ or 🦄, share and comment.

Improving CSS performance and file size - an in-depth guide

Adrian Bece — Wed, 16 Oct 2019 05:35:02 +0000

What makes CSS slow
- File size
- CSS rendering
Reducing CSS file size
- Minification
- Optimization
- Compression
- CSS structure
Improving CSS animation performance
- Transitions and animations
- Promoting element into a composite layer
- will-change property
- contain property
Bonus: CSS Performance tips

What makes CSS slow?

File size

Large file size results in larger download times and parsing times. It's simple as that.

CSS Rendering

In order to understand where CSS rendering bottlenecks may come up, we need to look at the render pipeline steps:

1. Style - Determines which CSS rules apply to which elements in an HTML document.

2. Layout - Determines where the element is positioned on the screen and how much space does it take. CSS properties: position, top, left, right, bottom, etc.

3. Paint - Determines visual elements. CSS properties: color, border, background-color, etc.

4. Composite - Draws layers onto the screen. CSS properties: opacity and transform.

The full pixel pipeline (from Google Developers site)

CSS offers a lot of options in terms of animation and transitions. We can create a transition on a lot of CSS properties. There are transitions and animations which can use GPU and perform really well, resulting in smooth 60 FPS (Frames per second) experience with fluid and smooth animations. On the flipš side, there are CSS properties that, when animated, can result in low FPS and choppy animations.

Any changes or updates happening on one of the steps cause updates on the following steps. We can see that the Layout step is the most expensive to animate and Composite step is the least expensive to animate.

Reducing CSS file size

By decreasing the file size of the CSS file, we can decrease the download time and loading time. Some improvements related to file size can be done even when we are finished working with CSS making it a very effective optimization. For maximum efficiency, it's best to keep in mind and apply these improvements from the start.

Minification

CSS file minification is an easy win and should be the first step for achieving better CSS performance. Minification removes formatting characters inside the CSS file (whitespaces, line breaks, etc.) which are only useful to us (makes the code readable).

/* Non-minified code */

.card {
  padding: 1rem;
  background-color: #aaa;
}

/* Minified code */

.card{padding:1rem;background-color:#aaa}

There are numerous online, automated and CDN "uglifying" tools that will help you with minification. Tools for CSS minification:

CSS Compressor - simple online minification
CSSNano - Automated CSS optimizer + minifier
Clean CSS - Automated CSS optimizer + minifier

Optimization

Wait... We've already minified our CSS file. Isn't it already optimized?

Well, technically it is. When talking about CSS optimization, we are looking at removing unnecessary CSS or reformatting CSS properties that reduce the number of characters. Unlike minification, this improvement cannot be done on CDN and it must be done when code is being compiled (by a tool like Webpack or Gulp).

Let's take a look at the following example.

/* Unoptimized CSS */

.card {
  background-color: #aaaaaa;
  padding: 0.5rem 1rem 0.5rem 1rem;
}

.card__content {
    padding: 0.5rem 1rem 0.5rem 1rem;
}

At first look, this looks like any regular CSS that anyone would write and not think twice about it. But there are some optimizations that could be done to reduce the number of characters.

/* Optimized CSS */

.card {
  background-color:#aaa;
}

.card,
.card__content {
  padding:.5rem 1rem;
}

We have reduced the number of characters from 132 to 85 (a 35% reduction). Let's apply minification and see the final result.

/* Optimized CSS with minification */

.card{background-color:#aaa}.card,.card__content{padding:.5rem 1rem}

We have reduced the number of characters from 132 to 68 (48% reduction in total).

You can see how much CSS impact the optimization has. The reduction is a result of removing the DRY code which can be avoided in this simple example. Looking at the CSS file with thousand of lines of code which is being changed on a regular basis (especially if split into several files), we can easily make our code less DRY. Luckily, there are tools that help us optimize our code and keep it DRY.

In the previous section, we have mentioned two of the numerous tools for optimizing CSS with minification included:

CSSNano - Automated CSS optimizer + minifier
Clean CSS - Automated CSS optimizer + minifier

Compression

Compression is done server-side. It uses gzip or Brotli to compress and further reduce the file size in order to reduce the file download time.

This topic is very extensive and covers more file types than just CSS. CSS tricks wrote a great article on this topic if you are interested in implementing server-side compression.

It's also important to note that most CDN services offer the compression option out of the box.

CSS structure

Having a good CSS structure and using various CSS best practices and also result in a lower-sized CSS file when minified. For example, using BEM and only class selectors with low specificity will result in fewer characters in the file and the lower file size.

I've covered CSS structure improvements in one of my previous posts. By following these CSS principles, you will have a CSS file with great structure, DRY code and a great foundation for optimization and minification.

Improve your CSS with these 5 principles

Adrian Bece for PROTOTYP ・ Oct 7 '19

#css #webdev

Improving CSS animation performance

Transitions and animations

We've covered the CSS rendering pipeline and what makes animation slow. So basically, Layout step is the most expensive to animate and Composite step is the least expensive to animate.

If we look at the CSS properties that cause the Composite layer to update, they are transform and opacity. These two properties use hardware (GPU) acceleration, resulting in very performant updates.

If you apply a transition to position attributes like top or left, animation performance will be poor because we are updating the Layout step which forces both Paint and Composite to update. Replacing the position CSS properties with transform and using transition on it, we are updating Composite step only, resulting in smooth animation.

Promoting element into a composite layer

We aren't really restricted to using only transform and opacity for smooth animations. CSS offers quite a few ways of "promoting" an element into a composite layer to tell the browser that this element will have its Paint CSS properties updated often.

The hacky and "old way" of doing this is by either adding backface-visibility: hidden; or transform: translate3d(0,0,0);. In most cases, these properties won't affect your element in any way (if they don't override anything), but they will make the browser move the element into Composite layer, significantly improving animation performance.

.example {
  width: 20rem;
  height: 20rem;
  background-color: #aaa;

  border-radius: 0;
  backface-visibility: hidden;
  transition: border-radius 0.3s ease-in-out;
}

.example:hover {
  border-radius: 50%;
}

will-change property

A modern way of telling browsers which element is expected to be updated (in terms of CSS rendering) is setting the will-change property.

.card {
  background-color: #aaa;
  transition: background-color 0.3s ease-in-out;
  will-change: background-color;
}

.card:hover {
  will-change: background-color;
}

.card:active {
  background-color: #bbb;
}

There are several things to keep in mind when using will-change:

Don't apply will-change to too many elements.
Use sparingly
Don't apply will-change to elements to perform premature optimization.
Give it sufficient time to work.

contain property

The contain CSS property represents the future of CSS render pipeline optimization. Currently, it sits at limited browser support. It allows us to indicate that an element’s subtree is independent of the rest of the page. This allows the browser to recalculate layout, style, paint, size, or any combination of them for a limited area of the DOM and not the entire page.

contain: none; /* No optimization */
contain: strict; /* Equivalent to contain: layout paint size style */
contain: content; /* Equivalent to contain: layout paint style */
contain: size; /* component size is set and no descendant will modify its size.  */
contain: layout; /*  changes to any descendant of this element will not affect the layout of any outside element and vice versa.  */
contain: style; /* descendant’s styles will not affect outside elements.  */
contain: paint; /* you specify that no descendant will display outside the elements bounds. Similar to overflow: hidden; */

Example of using contain CSS property:

.box {
  contain: layout size; /* Won't change size and won't affect layout */
}


<div class="box">
  <div class="box__content">...</div>
</div>

Bonus: CSS Performance tips

Avoid using @import

@import CSS property is used to include a CSS file within another CSS file. The issue is that these files are then loaded one after another instead of parallel when using the recommended HTML way of including stylesheets.

Use HTTP/2 if you have multiple stylesheets

HTTP/2 brings noticeable performance improvements when loading a lot of smaller files. This is an ideal solution if you are using CSS structure that results in multiple CSS stylesheets (individual screens, modules, components, etc.).

If you are not using HTTP/2, it's recommended to merge all your CSS files into a single CSS file.

Be aware of "expensive" properties

Some properties are more resource-heavy and increase render time. If you are intending to support devices with lower processing power, being aware of these properties would be beneficial:

border-radius
box-shadow
filter
position: fixed

*
:nth-child

Serve CSS file(s) over the CDN

Serving static files like images, CSS, JS, etc. from CDN improves download times. Additionally, some CDN services offer basic minification and optimization options, so you can easily get a performance boost if your code is not minified already.

Keep your selectors simple

Having simple class selectors (consider using BEM and OOCSS or other flavors and combinations) can benefit performance when rendering your site, especially on devices with lower processing power. I've covered this topic more in-depth in one of my previous articles:

Improve your CSS with these 5 principles

Adrian Bece for PROTOTYP ・ Oct 7 '19

#css #webdev

These articles are fueled by coffee. So if you enjoy my work and found it useful, consider buying me a coffee! I would really appreciate it.

Thank you for taking the time to read this post. If you've found this useful, please give it a ❤️ or 🦄, share and comment.

Improve your CSS with these 5 principles

Adrian Bece — Mon, 07 Oct 2019 05:39:20 +0000

Writing CSS is really simple and straightforward, so why is there a need for principles and best-practices while writing CSS?

As the project scope increases and as the number of people working on the project increases, the problems become more and more apparent and can cause serious issues down the line. Fixing issues may become harder, duplicated code, complex override chains and use of !important, leftover / unused code (removed elements or features), code that is hard to read, etc.

Writing CSS at a professional level will make the CSS code more maintainable, extensible, understandable and cleaner. We're going to look at the five simple and very effective principles that will take your CSS to the next level.

Naming principle

"There are only two hard things in Computer Science: cache invalidation and naming things." -- Phil Karlton

Properly naming and structuring your CSS selectors is the first step to making your CSS more readable, structured and cleaner. Establishing rules and constraints in your naming convention makes your code standardized, robust and easier to understand.

This is why concepts like BEM (Block-Element-Modifier), SMACSS (Scalable and Modular Architecture for CSS) and OOCSS (Object Oriented CSS) are popular among many frontend developers.

Low specificity principle

Overriding CSS properties is very useful, but things can go out of hand pretty quickly on more complex projects. Overriding chains can get really long and complex, you might be forced to use !important to solve the specificity issue and you could get really easily lost when debugging or adding new features.

/* Low-specificity selector */
.card {}

/* High-specificity selectors */
.card .title {}

.blog-list .card img {}

.blog-list .card.featured .title {}

#js-blog-list .blog-list .card img {}

Browser and specificity

One of the benefits of following the low specificity principle is performance. Browsers parse the CSS from right to left.

Let's take a look at the following example:

.blog-list .card img {}

Browsers parse the selector like this:

Find all img elements on the page
Keep selected elements that are the descendants of .card class
Keep selected elements that are the descendant of .blog-list class

You can see how high-specificity selectors impact performance, especially when we need to globally select generic elements like div, img, li, etc.

Using the same level of specificity

By using low specificity CSS class selectors in combination with BEM or one of the other naming principles mentioned in the previous section, we can create a performant, flexible and understandable code.

Why use CSS classes? We want to keep the same level of specificity, stay flexible and be able to target multiple elements. Element selectors and id selectors do not offer the flexibility that we need.

Let's rewrite our previous example using BEM and keeping specificity low.

/* Low-specificity selector */
.card {}

/* Fixed high-specificity selectors */
.card__title {}

.blogList__image {}

.blogList__title--featured {}

.blogList__img--special {}

You can see how these selectors are simple, understandable and can be easily overridden and extended if needed. And by keeping them low-level (a single class), we are guaranteed optimal performance and flexibility.

DRY Principle

DRY (Don't repeat yourself) principle can be also applied to CSS. Duplicated code in CSS can cause code bloat, unnecessary overrides, reduce maintainability, etc. This issue can be fixed by structuring the code appropriately and having high-quality documentation.

Storybook is a great free tool that enables you to create an overview of available frontend components and write high-quality documentation.

/* Without DRY Princple */
.warningStatus {
  padding: 0.5rem;
  font-weight: bold;
  color: #eba834;
}

.errorStatus {
  padding: 0.5rem;
  font-weight: bold;
  color: #eb3d34;
}

.form-errorStatus {
  padding: 0.5rem 0 0 0;
  font-weight: bold;
  color: #eb3d34;
}

Let's refactor the code so it follows the DRY principle.

/* With DRY Principle */
.status {
  padding: 0.5rem;
  font-weight: bold;
}

.status--warning {
  color: #eba834;
}

.status--error {
  color: #eb3d34;
}

.form__status {
  padding: 0.5rem 0 0 0;
}

Single responsibility principle

By using the single responsibility principle in our CSS, we can ensure that our CSS classes are easily extended and overriden. Let's take a look at the following example.

.button {
  padding: 1rem 2rem;
  font-size: 2rem;
  border-radius: 0.2rem;
  background-color: #eb4934;
  color: #fff;
  font-weight: bold;
}

.button--secondary {
  border-radius: 0;
  font-size: 1rem;
  background-color: #888;
}

We can see that if we want to extend .button class with .button--secondary, we are doing lots of overrides to achieve what we need, when we only want to apply a different background color and keep the default styles.

The problem is that our .button class is having several roles:

Sets layout (padding)
Sets typography (font-size,font-weight)
Sets presentation (color,background-color, border-radius)

this makes our CSS classes very hard to extend and combine with other CSS classes. By keeping this in mind, let's use BEM and OOCSS to improve our CSS.

/* Shared styles */
.button {
  padding: 1rem 2rem;
  font-weight: bold;
  color: #fff;
}

/* Style extensions */
.button--radialBorder {
  border-radius: 0.2rem;
}

.button--large {
  font-size: 2rem;
}

.button--primary{
  background-color: #eb4934;
}

.button--secondary {
  background-color: #888;
}

We have broken down our button styles into several classes that can be used to extend the base button class. We can optionally apply the modifiers and add new ones as the design changes or new elements are being added.

Open/Close principle

software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

We've already used the open/close principle in the previous examples. All new features and options need to be added by extension. Let's take a look at this example.


.card {
  padding: 1rem;
}

.blog-list .card {
  padding: 0.5em 1rem;
}

The .blog-list .card selector has few potential issues:

Some styles can be applied only if the .card element is a child of .blog-list element.
Styles are forcibly applied to the .card element if placed inside the .blog-list element, which can produce unexpected results and unecessary overrides.

Let's rewrite the previous example:

.card {
  padding: 1rem;
}

.blogList__card {
  padding: 0.5em 1rem;
}

We've fixed the issue by having a single class selector. With this selector, we can avoid unexpected effects and there are no conditional nested styles.

Conclusion

We've seen how by applying these few simple principles we have significantly improved the way we write CSS:

Standardized naming and structure, and improved readability by using BEM, OCSS, etc.
Improved performance and structure by using low-specificity selectors.
Reduced code bloat and improved code quality with DRY principle
Flexibility and maintainability by using open/close principle
etc.

These articles are fueled by coffee. So if you enjoy my work and found it useful, consider buying me a coffee! I would really appreciate it.

Thank you for taking the time to read this post. If you've found this useful, please give it a ❤️ or 🦄, share and comment.

Optimizing images for the web - an in-depth guide

Adrian Bece — Tue, 01 Oct 2019 05:26:22 +0000

Calculating JPG image file size
Online image optimization
Automated solutions
Image loading optimization
Using CDN
WebP image format
Optimization for higher pixel density screens
Conclusion - Optimization priority

Unoptimized (non-minified) images are one of the main causes of poor website performance, mainly on the initial (first) load. Depending on the resolution and image quality, you might end up with images that take up more than 70% of your total website size.

It's very easy for unoptimized images to end up on a production site and slow down its initial load considerably. Inexperienced devs usually aren't aware of this potential problem. They also aren't aware of a wide range of tools and approaches for optimizing images.

This article aims to cover most of the tools and approaches for optimizing images for the web.

Calculating JPG image file size

The uncompressed image size can be easily calculated by multiplying image width px value with image height px value and multiply the result by 3 bytes which is equivalent to 24 bits (RGB color system). We divide the result by 1,048,576 (1024 \* 1024) to convert the value from bytes to megabytes.

image_size = (image_width * image_height * 3) / 1048576

For example, let's calculate file size for an uncompressed image that has 1366px x 768px dimensions.

1366 * 768 * 3 / 1048576 = 3Mb

Considering that average website size today is between 2Mb and 3Mb, imagine having an image on your site that takes more than 80% the size of your site. 3Mb takes ages to load on slower mobile networks, so you might lose some traffic on your website if the user is waiting for your website to load and most time is spent on loading a single image. Scary thought, isn't it?

So what we can do to avoid having optimized images on the web but preserve the acceptable quality and resolution?

Online image optimization

If you are working on a simple static website that only has a handful of images that won't change often or won't change at all, you can just drag and drop your images in one of the numerous online tools. They do an amazing job at compressing images using various algorithms and are more than enough for simple projects.

Most notable websites, in my opinion, are:

Automated solutions

However, if you are working on more complex projects with multiple people and using a lot of images, optimizing each one as it is added to the project can become tedious. Also, there is a risk that some images may end up not optimized due to human error or some other factor.

On complex projects, it's common to use an equally complex build system like Gulp, Webpack, Parcel, etc. Image optimization plugins can be easily added to those build configs and fully automate the image optimization process. Images can be optimized as soon as they are added to the project.

Most notable plugin, in my opinion, is imagemin which can be easily integrated with any CLI or build tools:

Image loading optimization

We've looked at the image optimization strategies that reduce the file size by compressing the image without changing the image resolution and affecting image quality too much. Although optimizing image file reduces the file size of images considerably, having multiple optimized images (on the webshop catalog page for example) loaded all at once can have a poor effect on performance.

Lazy Loading

Lazy loading is a concept of only loading assets that are needed. In our case, only images that are currently within the user's viewport (screen) are loaded. Other images are not loaded until they appear within the user's viewport.

Although native Lazy loading has just been recently introduced to browsers, there have been many JavaScript-based solutions available.

Native Lazy Loading

<img src="image.jpg" loading="lazy" alt="Sample image" />

JavaScript-based solutions

Most notable JavaScript-based solutions, in my opinion, are:

Progressive images

Although lazy loading does a great job performance-wise, looking at the problem from UX perspective we can see that the user is waiting for the image to load and looking at the blank space. On slow connections, downloading images can take ages. This is where progressive images come into play.

Basically, having a progressive image means that a low-quality image will be displayed to the user until a high-quality image has finished loading. A low-quality image has a considerably smaller file size due to the low quality and high compression rate, so this image will be loaded very fast. In between the low quality and high-quality image we can have as many images with varying quality as we need and we can load the higher quality image on each download.

Similarly to the article on Skeleton loading I've written, this technique gives the user an illusion of speed. User is looking at an image that is loading and becoming more clearer as it loads higher and higher quality image, instead of looking at the empty space waiting for something to happen.

This is an JavaScript implementation of progressive images: progressive-image

Responsive images

We also need to be careful of using properly-sized images.

For example, let's say we have an image that is 1920px maximum width on desktop , 1024px maximum width on tablet devices and 568px maximum width on mobile devices. Simplest solution would be to just use the 1920px image and cover all the cases, right? In that case, an user on a smartphone with slow and unreliable connection would have to wait ages for the massive image to download and we'd be back at the square one of the problem.

Luckily for us, we can use picture element to tell the browser which image to dowload, depending on the media query. Although this element is supported by more than 93% of globally used browsers, it has a pretty simple fallback with img element already inside it.

<picture>
  <source media="(min-width: 1025px)" srcset="image_desktop.jpg">
  <source media="(min-width: 769px)" srcset="image_tablet.jpg">
  <img src="image_mobile.jpg" alt="Sample image">
</picture>

Using CDN

CDN services like Cloudinary and Cloudflare can perform image optimization on the server and serve the optimized images to the user. If your website uses a CDN, it's worth looking into asset optimization options. This allows us not to worry about image quality optimization at all, and have all optimizations done server-side. We only need to look into optimizing image loading by either using lazy loading or progressive images.

WebP image format

WebP image format is developed by Google and is an image format specifically optimized for the web. According to the canIUse data, current browser support for WebP image format is at around 80% which is great. Luckily, implementing a fallback to standard jpg image with img element inside picture element is easy.

<picture>
  <source type="image/webp" srcset="image.webp" />
  <source srcset="image.jpg" />
  <img src="image.jpg" alt="Sample image" />
</picture>

Although there are numerous online file format converters that can convert images to WebP format, CDN services can easily perform format conversion server-side.

Optimization for high pixel density screens

This is more UX improvement rather than performance, but it's also important to take into account devices that have higher pixel density.

For example, let's assume that we are displaying an 768px x 320px banner image on 768px screen. But the screen has 2x density and the px width is actally: 2 x 768 = 1536px. Basically, we are stretching 768px over 1536px and this leads to blurry image on high pixel density devices.

In order to fix that, we need to serve an image optimized for high pixel density screens. We need to create separate images that are 2 times or 3 times the resolution of regular screens and use the srcset attribute with 2x tag marking for higher resolution image.

<img src="image-1x.jpg" srcset="image-2x.jpg 2x" alt="Sample image" />

Example - Responsive WebP/PNG images with high-density screen support

<picture>
    <source srcset="./images/webp/hero-image-420-min.webp 1x, ./images/webp/hero-image-760-min.webp 2x" type="image/webp" media="(max-width: 440px)">
    <source srcset="./images/minified/hero-image-420-min.png 1x, ./images/minified/hero-image-760-min.png 2x" media="(max-width: 440px)">
    <source srcset="./images/webp/hero-image-550-min.webp 1x, ./images/webp/hero-image-960-min.webp 2x" type="image/webp" media="(max-width: 767px)">
    <source srcset="./images/minified/hero-image-550-min.png 1x, ./images/minified/hero-image-960-min.png 2x" media="(max-width: 767px)">
    <source srcset="./images/webp/hero-image-420-min.webp 1x, ./images/webp/hero-image-760-min.webp 2x" type="image/webp" media="(max-width: 1023px)">
    <source srcset="./images/minified/hero-image-420-min.png 1x, ./images/minified/hero-image-760-min.png 2x" media="(max-width: 1023px)">
    <source srcset="./images/webp/hero-image-760-min.webp 1x, ./images/webp/hero-image-960-min.webp 2x" type="image/webp" media="(max-width: 1919px)">
    <source srcset="./images/minified/hero-image-760-min.png 1x, ./images/minified/hero-image-960-min.png 2x" media="(max-width: 1919px)">
    <source srcset="./images/webp/hero-image-960-min.webp" type="image/webp">
    <source srcset="./images/minified/hero-image-960-min.png">
    <img  src="./images/minified/hero-image-960-min.png" alt="Example">
</picture>

Conclusion - Optimization priority

Use optimized images (optimized by automated build tools, online services or CDN)
Use lazy loading (JS solution until native becomes more supported)
Optimize images for high pixel density screens
Use WebP image format
Use progressive images

Optional: Remember to serve images (and other static assets) over CDN if you are able to.

These articles are fueled by coffee. So if you enjoy my work and found it useful, consider buying me a coffee! I would really appreciate it.

Thank you for taking the time to read this post. If you've found this useful, please give it a ❤️ or 🦄, share and comment.

Draggable chat-heads in React Native

Sebastijan Dumancic — Tue, 24 Sep 2019 08:20:39 +0000

Most of us are familiar with Facebook’s floating heads that are screaming for your attention on top of all other apps. At the time, it was a novel concept, somewhat annoying, but still, something new.

Recently, we’ve had a client that requested similar behavior, just in-app, which would show draggable profile photos which could be paired by overlapping one over another.

Since you’re probably skimming this part to see if a solution you’re looking forward is here, let get straight to the point.

We’ve used panResponder and wrapped each person in one.

constructor(props: Props) {
        super(props);
        this.pan.addListener((value) => this.position = value);

        this.panResponder = PanResponder.create({
            onMoveShouldSetPanResponder: (evt, gestureState) => true,

            onPanResponderGrant: () => {
                this.pan.setOffset({
                    x: this.position.x,
                    y: this.position.y
                });

                this.pan.setValue({ x: 0, y: 0 });
            },

            // Move object while onPress is active. Snapping is handled later.
            onPanResponderMove: Animated.event([
                null, { dx: this.pan.x, dy: this.pan.y }
            ]),

            // Handle swiper behaviour after object is released.
            onPanResponderRelease: (e, { dx, dy, vx }) => {
                // Fix jumping when moving the object second time.
                this.pan.flattenOffset();

                // Send ending position to parent component.
                this.props.calculateOverlapping(dx, dy, this.props.person.id);

                // Animate springy tuff.
                Animated.spring(this.pan, { toValue: { x: 0, y: 0 } }).start();
            }
        });
    }

Register initial people position

Each person is wrapped in an Animated.View component which means it’s draggable. Animated.View, just as normal View, has an onLayout event which is invoked on mount and layout changes.

Once that event is triggered, we can register this person initial position. They are positioned absolutely, but when reporting position it will use XY coordinates based on the parent they are on (0,0 will be top left corner of the parent element).

const newPersonPosition = new PersonPosition(Math.trunc(event.nativeEvent.layout.x + 30), 
Math.trunc(event.nativeEvent.layout.y + 30), userId);

The position is truncated since we don’t need extreme precision that horizontal and vertical displacements report (dx and dy in onPanResponderRelease).

PersonPosition here is just a constructor that creates an object with its horizontal and vertical position, together with userId which we can use later on to trigger events on that specific user.

Also, I’ve added 30, a magic number, which is half of the width and height of a component. Reported location (event.nativeEvent.layout.x) is a position in the top left corner of the component. If you want to be scientific about this, the proper way would be to check for a component's width and height and add half of it, but I know mine is 60, so I just added half manually. Now we save this since it’s a center of a component, and we need that for overlap calculation.

Position for each person is then pushed into an array which is saved to state:

peoplePosition.push(newPersonPosition);this.setState({   peoplePosition});

This is to have an easier way of comparing future dropped components to all of the others (using array’s find method).

Checking for overlapping

Main part is to check for overlapping after the user releases the person. We can get the drop coordinates like this:

const droppedX = Math.trunc(draggedPerson.startingPointX + dx);
const droppedY = Math.trunc(draggedPerson.startingPointY + dy);

Where we take dragged person’s horizontal starting point and add the horizontal displacement and repeat for the vertical axis. The result is once again truncated to remove unneeded decimals.

Then, that ending position of the person is checked against the positions of all people that were not dragged:

const matchedPerson = notDraggedPeople.find((personPosition: PersonPosition) => 
Math.abs(personPosition.startingPointX - droppedX) < 30 && Math.abs(personPosition.startingPointY - droppedY) < 30);

If the dropped person is anywhere inside a set distance from any of the people, we have a match! Here the radius is hardcoded to 30px, but you can set it to whatever you want.

Maybe the best is half the width of an element + some buffer to make it easier to overlap successfully. You definitely want to avoid making it larger than the total width of the elements you’re overlapping to avoid false positives.

The distance of 0 means that the two components are perfectly overlapped (their centers match). Distance of 30 (in our case) means that they are touched by the edges. Tweak this number to determine how precise you have to be in order to get a sucesfull match.

If a match is successful, just push the person to the matchedPeople array and save it to the state:

let matchedPeople = [];

if (matchedPerson) {
    matchedPeople.push(matchedPerson);    

    this.setState({
        matchedPeople
    });
}

Trigger action after ovelapping

Finally, you probably want to do something after the user overlaps two heads successfully.

In our case, we just listened to state change for matchedPeople in ComponentWillUpdate:

componentWillUpdate(nextProps: Props, nextState: State) {
    if (nextState.matchedPeople.length) {
       // Navigate away from the screen
    }
}

You should check for changes here to avoid excessive triggering for each component updates, but since we navigated away from this screen once a successful overlaps occur (matchedPeople array is populated), it’s a simple logic to check for.

Provided you’re experienced with panResponder, this code should be easy to replicate. In case you need a refresher on panResponder, I’ve written another article which tackles rotateable circle to select items here:

https://medium.com/prototyped/circular-swiper-using-pan-responder-and-animated-library-b78eee9784a4

Did I mess up somewhere? Have better ideas? Drop us an email at hello@prototyp.digital or visit us at https://prototyp.digital. Cheers!

Avoiding the messy git history

Vlatko Vlahek — Tue, 17 Sep 2019 08:56:25 +0000

Avoiding the messy git history

If we try to name the things that have clearly defined modern software development, source control would most certainly be very high on the list, especially git which is probably the most widely used version control system today.

Days of having our code versioned in different folders locally, often prone to corruption are long gone. However, a lot of developers use git just as a means to store the source files somewhere remotely, without actually utilising some of its more advanced features that allow us to have a great, easily readable git history.

This article will cover one of the git-flow approaches, heavily based on git rebase, that will allow you to have a more streamlined git experience, especially when working inside a team. It’s a strict approach and takes a while to get used to.

The experience stems from working on bigger projects, based on the in-house practices that we have at PROTOTYP. We put a strong emphasis on code review and easy readability of all changes that happen inside our codebase.

Main goals of the approach are:

cleaner git history
fewer merge conflicts
enforcing code review
increasing branch stability

All examples in the article are done via command line, but there will be links and references on how to achieve some parts of the process in the git provider dashboards.

Initialising git flow

The first step of the journey is definitively initialising Git flow over your repository.

More thorough documentation on the matter by its original author can be found here.

In short, it’s a branching model that scaled really well for us in the past and is widely adopted.

In order to use this from the command line, you will most probably need to install git-flow. GUI solutions such as Tower or Sourcetree usually have it integrated.

You can check the installation instructions here.

Example:

// initialises git on your repository
git init

// initialises git flow on your git repo
git flow init

After initialising git flow on your repository, you will be asked for default branch names. We use the default values internally, only prefixing tags with letter “v”, so our versions are v1.0.0, v1.0.1 etc.

Feel free to use the versioning system for releases that has the most sense for your team and your product. However, semantic versioning or semver has been our weapon of choice for some time now, and while it could be an overkill for smaller one-off projects, it has proven great for releasing new features for SaaS products or mobile apps inside our company.

Each of the branches git flow introduces has its own place in the ecosystem, and understanding when to use each one is a must!

// New features
Feature branches? [feature/]

// Tags a version and merges develop to master. 
// A short lived branch. Versions bumps are ok inside it.
Release branches? [release/]

// A branch done from master directly, for fast hotfix push
// We use bugfix/ name for a bugfix branch that is branched from  
// develop
Hotfix branches? [hotfix/]

// Need to add some client specific code ? Use a support branch
Support branches? [support/]

// Tag for release branches
Version tag prefix? [v]

Remember, git is not some sort of a magic wand that makes all of your issues go away just by itself, nor does it have any sense in having multiple branches if you don’t know what to do with them in the first place.

Locking down develop and master branches

This one is maybe a tad controversial for people not used to this approach, but I would definitively note this as one of the most important steps in the process.

Protecting **develop* and master branches will require your team to merge code to them exclusively via merge requests, and through a code review process, which are both strongly encouraged practices.

It will also save you from a lot of potential “instability” troubles that tend to happen when people push a “small and insignificant fix that can’t break anything” directly to one of these branches. This creates a lot of frustration when things go wrong, which happens, sooner or later.

How to do it, differs from provider to provider, but here is the outline for more popular ones:

Bitbucket: https://blog.bitbucket.org/2016/12/05/protect-your-master-branch-with-merge-checks/

GitHub: https://help.github.com/articles/configuring-protected-branches/

GitLab: https://docs.gitlab.com/ee/user/project/protected_branches.html

I would suggest enabling some merge checks along, such as at least one code review and approval from another developer before merging any code to them.

Adding new code through feature branches

Considering that no code can be directly pushed to develop or master branches, it’s required that you create a new feature branch to add a new functionality to your app.

You can either do it from the command line or use integrated functionality in tools such as Sourcetree or Tower.

Source branch: develop
Naming: feature/feature-name

Example:

git checkout develop
git branch feature/my-new-feature

After you have successfully created your feature branch, feel free to push the code to it, until you are ready to get your feature reviewed as merged by another member of your team.

Merging your code

In order to merge the code via this approach, after you have finished your feature, you will first need to rebase it. This is a multi-step process.

Rebase by developer

As a developer who created a feature, you generally want to pull the latest changes from the develop branch that happened in the meantime and test whether your feature is still working.

git checkout develop
git pull
git checkout feature/your-feature-name

// This line will return a hash of commit where your branch diverged // from develop
git merge-base develop feature/your-feature-name

// {hash} is the result from the previous step
git rebase --onto develop {hash}

This will start the rebase process where changes from develop are integrated to your own feature branch, commit by commit.

Once you understand the steps that happen with rebase, there are also shorter alternatives such as:

git checkout feature/your-feature-name
git pull --rebase origin develop

You can check the complete rebase documentation here.

Why not simply use merge?

A valid point. You can, of course, merge the develop to your own feature branch and get similar results. However, there are a few key differences, why we prefer to rebase the branch over merge in this scenario.

Rebase:

Integrates changes commit by commit.
Conflicts also come in commit by commit, and it’s easy to ask your colleague what was the change to resolve the conflict more efficiently together.

Rebase can easily be aborted and started over, reverting all changes that you made if you are unsure if you messed up somewhere.

// After you stage files, you can continue to next commit
git rebase --continue

// Skips the current commit entirely
git rebase --skip

// Reverts all rebase changes that you did
// Returns the branch to pre-rebase state
git rebase --abort

You have more flexibility when rebasing as you can rename incoming commits or completely skip them, if you think they are unnecessary or superseded by your changes.
It doesn’t create unnecessary merge commits if you integrate changes to your feature branches often.
If you don’t have any conflicts, it will just pass through all commits and the process will be a breeze as it is with git merge.

Merge chaos:

Merge glues all changes together leading to a huge amount of potentially conflicting files, and resolving the differences is often quite a chore. Also, it makes it much harder to understand who and for what reason changed a file if a conflict occurs.

However, regardless of your choice, the burden of testing the feature before creating a Pull Request is definitely on the developer, and shouldn’t be skipped.

Creating a pull request (merge request in some providers)

Create a pull request from your feature branch to develop (or branch from which you branched off) inside the interface of your git provider.

Bitbucket: https://confluence.atlassian.com/bitbucket/create-a-pull-request-to-merge-your-change-774243413.html

GitHub: https://help.github.com/en/articles/creating-a-pull-request

GitLab: https://docs.gitlab.com/ee/gitlab-basics/add-merge-request.html

Gitlab offers automatic rebase option inside their interface, a feature that I really like, and would be hyped to see it in BitBucket, for example.

Rebase by reviewer

This step is the main trick to have a readable and streamlined git history.

Unlike the developer rebase, which is used for resolving potential conflicts and testing your feature with the latest changes, this one is primarily for readability reasons, although it can also catch issues if they do happen.

We think it’s a critical step in the process because after you create a PR, you don’t know how long it will take for somebody to review and merge it.

More often than not, before this happens, there are new features merged to your development branch, which means:

new features might have introduced conflicts which need to be resolved
git history has changed from the moment you first rebased

If the reviewer does another rebase, it should improve the testing of the feature, minimise the potential of the feature not working after being merged, and provide you with a very clean and linear git history.

How does it look in practice

Here is a little screenshot from Sourcetree, showing features merged via this method, and mutual relationships between develop, master and other branches.

As you can see:

it’s very readable
release point with the tag from develop to master can be found quickly
you can easily see in which order your features or bug fixes were merged.
This can help a lot if you are unsure which feature broke something else in your project. It even makes using *git bisect* much easier if things come to that.

Squash or no squash

The example shown here uses squash which is given as a feature by GitLab automatically, although you can squash commits locally if required, like this:

git checkout feature/my-new-feature // If you are not on it
git rebase -i HEAD~1

This would squash your whole branch to one commit. A word of advice, discuss internally if this is what you want.

From our perspective, as long as you follow the rebase flow, squash will not significantly impact the readability of your git graph, unless your features have 100+ commits.

In that scenario, maybe you bundled too much inside a single feature :).

I prefer squashing commits in a branch before doing a PR because it forces you to go for a new bugfix/ or hotfix/ branch if you messed something up. Also, regardless of whether your developers do atomic commits or huge beasts of commits, it will not matter.

However, it’s not mandatory to squash all to one single commit. If it’s a bigger feature, you can manually squash your branch to a few important commits via interactive rebase.

git checkout feature/your-feature-name
git merge-base develop feature/your-feature-name // returns {hash}
git rebase -i {hash}

You will get a screen like this:

pick be8606b Added localisation package and settings
pick 48e6aec Fixed an issue with payload not being propagated
squash 6085ce3 Added connected intl
squash 60ec657 Fixed connected intl
squash ba09d22 Modified tasks from package.json
pick 0bea497 Build android
pick 52c67b9 Updated packages
pick 21aa18c rm package lock

Simply change pick to squash to merge a commit with the commit that preceded it.

This is usually used to squash commit duplicates or commits with stupid names such as removed console.log in order to maintain a git history that is relevant and informative.

Not convinced that this is a way to go?

If you haven’t used git in this fashion it’s very understandable. At least try it out, and try to make an opinion of it after you use it for a few days or a single project.

It did allow us to improve our git usage at PROTOTYP, and to achieve better git readability with far fewer conflicts. And when they do happen, they are resolved quickly, allowing us to be more efficient and focus on features, and not pulling our hair out.

The process of switching to the flow on all projects was not easy and took some time. After a while though, everybody is satisfied with the results that it has brought to our team.

Here are a few final things about the process.

A few words about Git rebase

Oh boy. Not rebase, right?

For us, git rebase is one of the most powerful features that comes with git. Think of it as a swiss-tool for managing your git history.

However, opinions for this functionality are often highly opinionated and this can lead to a few misconceptions.

Here are a few:

Don’t use rebase, it’s a destructive operation!

This has some merit. Rebase rewrites git history, and can lead to disastrous results, if not used properly!

However, a lot of things with git are potentially destructive. This doesn’t mean they shouldn’t be used, just that you need to understand how and when to use them, and how to mitigate the issues if they do happen.

Be mindful of using this approach on public repositories and open-source projects where a lot of different people are pushing code, and not everybody is using the same principle. It requires the whole team to be disciplined.

Also, if several people are working on the same feature, only rebase before the pull request or if you are completely sure everybody commited their changes. Rebase does rewrite the history of your own branch, so it could lead to a lot of force pulling and pushing on the branch then, which can create a frustration of its own.

This flow only makes the git graph nicer, it doesn’t bring in any value.

I strongly disagree with this one, for multiple reasons.

First off, you can write nice code and ugly spaghetti code, but both can be functional. However, do ask yourself which is faster to understand and refactor and less prone to issues?

The same logic applies here. Added brevity is rarely a bad thing.

Also, the whole point of enforcing rebase is to minimise issues with conflicts, as they happen to be much much easier to resolve via this approach. The nice graph is only a great side effect of the whole process.

What if using rebase messes my branch and project up?

To be honest, it’s very very hard to completely mess a project or a branch up, especially if multiple people are working on it, and have their own local versions which are ok. They can always force push the change to reset your state.

You can also mess a branch up if you use merge and commit these changes, but you haven’t resolved issues properly.

However, if you do manage to do to the unthinkable, resolving these issues is often a very easy thing to do.

Git reflog

Behold, the magic eraser pen of all the bad things that we do to our repository.

git reflog

Hitting that command will show hashes of all states in which your branch was, up to 90 days. You can simply check out or reset the branch to a state before the merge or rebase, and start over, by finding the last hash before you did any destructive operation.

Something is strange here. Sometimes I need to rebase, sometimes not. What’s the catch?

If your branch is ahead of the tip of develop, you don’t need to do it. In the following scenario, ensure that you have pulled all changes from develop, and if you are still ahead of it, just do a Pull request.

If your branch is behind the tip of develop, you will need to rebase. Observe how the feature/other-feature is not connected to the foremost point of develop, but a point behind its tip.

Closing words

We hope that this article outlined both the process and its pros and cons, based on our experiences.

If you are looking for a new process that could bring in improvements to readability and stability of your git process, making you and your team more efficient in the process, give it a shot. It could go a long way!

If you have a similar or different workflow which works for your team, we would like to hear about it and see how it compares.

Implementing Skeleton Loading in React

Adrian Bece — Wed, 04 Sep 2019 20:26:40 +0000

The idea and concept of Skeleton Loading or Skeleton Screens was introduced in 2013. in this blog post by Luke Wroblewski. It describes the concept of a blank screen where dynamic content is replaced by styled blocks (skeleton) and is replaced with real content once it's finished loading.

Skeleton loading is better than a spinner

When a user looks at the page with a standard loading spinner, they're thinking "I'm waiting for it to load". We're making the user watch a dull repeating animation and the user feels like it's staring at the clock.

When a user looks at the page with skeleton loading or skeleton screen, they're thinking "It's almost loaded, something is happening". The user is watching a page that seems like it's right about to finish loading. User is watching at a page that is not empty or dull, even though we haven't loaded any content yet. It gives an illusion of speed.

But there is something to keep in mind about skeleton loading...

Skeleton loading is used when the final loaded state is predictable

We cannot simply replace every dynamically loaded element on the page with skeleton loading. In some cases, we cannot predict how the final loaded state of the page is going to look like.

For example, if we try and assume a final state of the page (let's say we chose 1 out of 4 wildly different possible states) and create a skeleton screen based on our assumption. When a user looks at the skeleton and the loaded content wildly differs from the skeleton, the transition looks very out of place and jarring. This may hurt the UX and make your app feel chaotic.

Let's assume we're looking at an eCommerce site and we are looking at the homepage. eCommerce homepages often change their look and layout, depending on the events or sales that are going on. It wouldn't be a good idea to implement the skeleton loading here.

Looking at the catalog page, where products are displayed in 4-column layout, with 24 items per page. We can safely assume that this state is not going to change. Even if we finally load 12 or 15 products, instead of assumed 24 the transition remains smooth. Catalog page loading is also very load-intensive (if pagination, sorting, and filters are used) so skeleton loading may also help in keeping the users on the page even in cases when loading times are larger than expected.

Implementing Skeleton loading in React

In the following example, we are implementing a skeleton loading for the food recipe card component. This is how the component looks like.

import * as React from 'react';
import { Link } from 'react-router-dom';
import { LazyImage } from 'components';
import { getUri } from 'util/getUri';

export const RecipeCard = ({
  calories,
  ingredients,
  image,
  label,
  source,
  uri
}) => {
  return (
    <li className="recipeCard">
      <Link className="recipeCard__link" to={`/recipes/recipe/${getUri(uri)}`}>
        <LazyImage className="recipeCard__image" src={image} alt={label} />
        <div className="recipeCard__wrapper">
          <div>
            <h3 className="recipeCard__title">{label}</h3>
            <p className="paragraph">
              <strong>
                By <span className="gradient--text">{source}</span>
              </strong>
            </p>
          </div>

          <div className="recipeCard__info">
            <strong className="gradient--text">{Math.ceil(calories)}</strong>{' '}
            calories |{' '}
            <strong className="gradient--text">{ingredients.length}</strong>{' '}
            ingredients
          </div>
        </div>
      </Link>
    </li>
  );
};

This is a simple skeleton that doesn't use any animations, just a plain color which also looks fine. You can easily add the animation by animating the background gradient.

First, we need to set up the styles for our skeleton components. We are setting up our base skeleton styles in .recipeCard__skeleton class. We are setting inline-block to mimic content behavior (like alignment), we use padding to add height (equal to 1 unit of line-height, in this case) to an element. We also have two modifier classes that change the width of the content and additional class for an image that has aspect ratio 1:1 (this is why padding is set to 100%).

.recipeCard__skeleton {
    display: inline-block;
    background-color: var(--color__gray--lighter);
    padding-bottom: var(--spacing__vertical--1);
}

.recipeCard__skeleton--medium {
    width: 33%;
}

.recipeCard__skeleton--large {
    width: 100%;
}
.recipeCard__image--skeleton {
    padding-bottom: 100%;
    background-color: var(--color__gray--lighter);
}

Let's create our Skeleton component:

Copy the content of the "real" component and paste it into the Skeleton component. Change the const name and export.
Replace all dynamic content (coming from props) to skeleton elements. Spans work fine due to them not having any default styles. Let the layout styles and grids handle everything else and keep the skeletons in place.
Conditionally load the skeleton in the main component

import * as React from 'react';
import { Link } from 'react-router-dom';

export const Skeleton = () => {
  return (
    <li className="recipeCard">
      <div className="recipeCard__link">
        <div className="recipeCard__image--skeleton" />
        <div className="recipeCard__wrapper">
          <div>
            <h3 className="recipeCard__title">
              <span className="recipeCard__skeleton recipeCard__skeleton--large"></span>
            </h3>
            <p className="paragraph">
              <span className="recipeCard__skeleton recipeCard__skeleton--large"></span>
            </p>
          </div>

          <div className="recipeCard__info">
            <span className="recipeCard__skeleton recipeCard__skeleton--medium"></span>{' '}
            <span className="recipeCard__skeleton recipeCard__skeleton--medium"></span>
          </div>
        </div>
      </div>
    </li>
  );
};

And this is how the final component will look like.

Pretty simple, right? Once you get a hang of replacing the content with skeletons, you can set up a very versatile library of classes for replacing skeleton content and create the skeleton screens really quickly.

These articles are fueled by coffee. So if you enjoy my work and found it useful, consider buying me a coffee! I would really appreciate it.

Thank you for taking the time to read this post. If you've found this useful, please give it a ❤️ or 🦄, share and comment.

Forem: PROTOTYP

Load fonts asynchronously & handle FOUT with my Gatsby plugin

Asynchronous font loading

Improving website performance by eliminating render-blocking CSS and JavaScript

Adrian Bece for PROTOTYP ・ Aug 31 '20

Flash Of Unstyled Text (FOUT)

Gatsby omni font loader plugin

codeAdrian / gatsby-omni-font-loader

Font loader optimized for maximum performance. Removes render-blocking font resources and loads them asynchronusly. Handle FOUT & FOUC with font loading status watcher. Supports both local-hosted fonts and web fonts.

Gatsby Omni Font Loader v2

Features

Install

Configuration

Installation

Configure the plugin

Handling FOUT

The thing about service workers...

Problem with service workers

Potential solutions

Let Users Know When You Have Updated Your Service Workers in Create React App

Gert Glükmann ・ Jan 4 '20

Conclusion

Improving website performance by eliminating render-blocking CSS and JavaScript

Best way to lazy load images for maximum performance

Adrian Bece for PROTOTYP ・ Aug 24 '20

Critical and non-critical resources

Handling critical CSS

Handling non-critical CSS

Firefox issue & handling IE

Handling critical JavaScript

Handling non-critical JavaScript

Boosted performance & Lighthouse score

Best way to lazy load images for maximum performance

The "loading" attribute

Modern approach

Image markup

Feature detection

Final JavaScript code

Boosted performance & Lighthouse score

More image optimization techniques for maximum performance

Optimizing images for the web - an in-depth guide

Adrian Bece for PROTOTYP ・ Oct 1 '19

Improving website performance by eliminating render-blocking CSS and JavaScript

Adrian Bece for PROTOTYP ・ Aug 31 '20

Multi-language routing in React

Multi-language routing in React

Is that really a big deal?

Add a Router package

Add an i18n package

Adding a base locale

Localized Switch component

Wiring it all up

Supporting multiple languages

Adding translations for a new language

Updating the router

Language switcher

Summary

UX lessons learned from eCommerce projects

Reduce user's effort where possible

Header & first impression of a website

Call To Action elements

Importance of responsive design

Every second of loading time matters

Optimizing images for the web - an in-depth guide

Adrian Bece for PROTOTYP ・ Oct 1 '19

Improving CSS performance and file size - an in-depth guide

Adrian Bece for PROTOTYP ・ Oct 16 '19

Implementing Skeleton Loading in React

Adrian Bece for PROTOTYP ・ Sep 4 '19

Using schema.org to describe the content

Analyzing user flow to determine performance bottlenecks - category page example

Optimizing images for the web - an in-depth guide

Adrian Bece for PROTOTYP ・ Oct 1 '19

User focus and forms - checkout page example

Removing distracting page elements

Form layout

Form validation

Conclusion

Improving CSS performance and file size - an in-depth guide

Table Of Contents