De Code Natura

How to write a custom React fetch hook

Mon, 22 Jun 2020 00:00:00 GMT

Writing the same fetch code in every component that needs it can be extremely boring, long, and prone to bugs.
Luckily this can be optimized with a custom React hook. Leaving us to handle the render logic only.

The standard hooks

At the end of the day, a custom hook is just a function that calls the standard React hooks inside of it.

We will leverage both useState and useEffect hooks for our custom fetch hook.

We want to make sure the hook allows us to display its status when loading data, failure, or success.
For this reason, we can start by defining the type for our data to handle all three cases.

// loading type has no data nor error
interface ILoadingState {
  status: "loading";
  data: null;
  error: null;
}

// error type has no data but an error
interface IErrorState {
  status: "error";
  data: null;
  error: Error;
}

// success type has data with type provided by user
// and no error
interface ISuccessState<T> {
  status: "success";
  data: T;
  error: null;
}

// By writing 3 interfaces instead of a conditional one
// we are sure that if the status is "success" it will always have data
// and "error" will always have an error
type state<T> = ILoadingState | IErrorState | ISuccessState<T>;

Once the types are done we can jump on drafting the hook.

// we don't know the type returned from the fetch
// so we leave it as any unless the user provides it
function useFetch<S = any>(url: string): state<S> {
  // standard useState hook to save our data
  const [state, setState] = useState<state<S>>({
    status: "loading",
    data: null,
    error: null,
  });

  // standard useEffect to fetch data
  useEffect(() => {
    fetch(url)
      .then((response) => {
        return response.json();
      })
      .then((data: S) => {
        setState({
          status: "success",
          data,
          error: null,
        });
      })
      .catch((error: Error) => {
        setState({
          status: "error",
          data: null,
          error: error,
        });
      });
  }, []);

  return state;
}

As you might notice, all this code is the exact same that would be written in any component needing to fetch data. Nothing special is going on other than the fact we are using these hooks inside a simple function.

I wrote a simple example to test the hook below:

const App = () => {
  const { status, data, error } = useFetch("https://aws.random.cat/meow");

  if (status === "error") {
    return <div>Error: {error.message}</div>;
  } else if (status === "success") {
    return (
      <div>
        <img src={data.file} width={600} />
      </div>
    );
  } else {
    return <div>Loading</div>;
  }
};

The code works! It displays an initial loading, then an error in case of failure and a cat pic in case of success.

What if we want a new cat pic? Unfortunately, this code only works when the component initially renders. It has no way of being called again.

We can improve the hook to allow an optional parameter to re-run useEffect when the value changes.

function useFetch<S = any>(url: string, params: unknown[] = []): state<S> {
  const [state, setState] = useState<state<S>>({
    status: "loading",
    data: null,
    error: null,
  });

  useEffect(() => {
    // each time we re-run useEffect
    // we change the state to loading
    // to provide feedback to the user
    setState({
      status: "loading",
      data: null,
      error: null,
    });
    fetch(url)
      .then((response) => {
        return response.json();
      })
      .then((data: S) => {
        setState({
          status: "success",
          data,
          error: null,
        });
      })
      .catch((error: Error) => {
        setState({
          status: "error",
          data: null,
          error: error,
        });
      });
    // optional array of parameters for re-running the useEffect hook
  }, params);

  return state;
}

The new functionality expands our code without modifying the original hook.

An example of how this code could be used for refreshing data.

const App = () => {
  const [reloading, setReloading] = React.useState<boolean>(false);
  // we define the custom shape of our data
  const { status, data, error } = useFetch<{ file: string }>(
    "https://aws.random.cat/meow",
    // array of parameters
    [reloading]
  );

  // simple hack to refresh our hook
  // when button is pressed
  // the value of reloading changes
  // triggering our custom hook to re-run
  // and give us a new cat pic
  const reloadImage = () => {
    setReloading(!reloading);
  };

  if (status === "error") {
    return <div>Error: {error.message}</div>;
  } else if (status === "success") {
    return (
      <div>
        <img src={data.file} width={600} />
        <button onClick={reloadImage}>New cat!</button>
      </div>
    );
  } else {
    return <div>Loading</div>;
  }
};

And that’s all there is to it.

The full code is available on GitHub.

I also published the fetchHook source code on npm, it is available here, you can simply install it and use as described above.

How to setup NextJS with TypeScript and ESLint + prettier

Mon, 18 May 2020 00:00:00 GMT

Sharing code on front-end and back-end has always been my dream. NextJS makes it easy with a simple framework including both, simple to run, simple to use.

NextJS makes it really easy to modify its setup, making compatibility a first class citizen.

To jumpstart a NextJS project you don’t need anything more than this command.

$ npm init next-app nextjs-example

Change nextjs-example to whatever name you want the project to have.

$ cd nextjs-example to get in the folder, and now we’re ready to start.

NextJS and TypeScript

NextJS comes with TypeScript just one click away, creates an empty tsconfig.json file and run $ npm run dev.
The tsconfig will be populated automatically and all .js files are ready to be converted to .ts.

Differently from the babel TypeScript presets (used by Gatsby, for example), NextJS will not compile on type errors. I don’t feel a great difference between the two options. At the end of the day, if you are using TypeScript you want your types to be correct, regardless of compilation.

NextJS + prettier

Adding prettier is easily achieved as well.

$ npm i - prettier

And next, create a .prettierrc file.

// .prettierrc
{
  "endOfLine": "lf",
  "semi": true,
  "singleQuote": false,
  "tabWidth": 2,
  "trailingComma": "es5"
}

And that’s pretty much it.

NextJS + ESLint

ESLint needs to be configured with both TypeScript and prettier, but also NextJS’s React implementation.

There are quite a few libraries that need to be added for this all to work properly.

npm i -D eslint eslint-loader eslint-plugin-react eslint-config-prettier eslint-plugin-prettier @typescript-eslint/eslint-plugin @typescript-eslint/parser

A basic .eslintrc.js config will look like this.

// .eslintrc.js
module.exports = {
  // Specifies the ESLint parser
  parser: "@typescript-eslint/parser",
  extends: [
    "plugin:react/recommended",
    "plugin:@typescript-eslint/recommended",
    "prettier/@typescript-eslint",
    "plugin:prettier/recommended",
  ],
  settings: {
    react: {
      version: "detect",
    },
  },
  env: {
    browser: true,
    node: true,
    es6: true,
  },
  plugins: ["@typescript-eslint", "react", "prettier"],
  parserOptions: {
    ecmaFeatures: {
      jsx: true,
    },
    // Allows for the parsing of modern ECMAScript features
    ecmaVersion: 2018,
    // Allows for the use of imports
    sourceType: "module",
  },
  rules: {
    // Disable prop-types as we use TypeScript for type checking
    "react/prop-types": "off",
    "@typescript-eslint/explicit-function-return-type": "off",
    "prettier/prettier": "error",
    "@typescript-eslint/interface-name-prefix": "off",
    "@typescript-eslint/no-explicit-any": "off",
    "@typescript-eslint/ban-ts-ignore": "off",
    // needed for NextJS's jsx without react import
    "react/react-in-jsx-scope": "off",
  },
  globals: { React: "writable" },
};

I’m not a fan of an overpersonalized linting config. It takes time away from development and introduces complexity to an accepted standard.

BONUS: NextJS and Jest

Testing makes apps more reliable and bug fixing easier. I prefer to have it and write tests as the app progresses.

Interviews go a lot better when you display testing skills. Being on the other side of the interview, I always appreciate candidates who can write tests.

Jest is the go-to testing library for React applications, adding it to a NextJS application is not too difficult but requires some changes.

First, the packages. jest, @testing-library/jest-dom and @testing-library/react for testing, and babel-jest for the config.

npm i -D jest @testing-library/jest-dom @testing-library/react babel-jest

We need to create a .babelrc file to enable the testing environment.

// .babelrc
{
  "presets": ["next/babel"]
}

The Jest config is pretty short as well, I removed the .css transformations since NextJS includes a good css-in-js solution to handle styles.

// jest.config.js
module.exports = {
  collectCoverageFrom: ["**/*.{ts,tsx}", "!**/*.d.ts", "!**/node_modules/**"],
  // we need to create this file
  setupFilesAfterEnv: ["<rootDir>/setupTests.js"],
  testPathIgnorePatterns: ["/node_modules/", "/.next/",],
  transform: {
    "^.+\\.(js|jsx|ts|tsx)$": "<rootDir>/node_modules/babel-jest",
  },
  transformIgnorePatterns: ["/node_modules/"],
};

Last, the setup file for Jest is just one line.

// setupTests.js 
import "@testing-library/jest-dom/extend-expect";

BONUS 2: What about end-to-end tests?

It takes even less time to set up end-to-end testing, I wrote a small how-to here.

If you have any questions, feel free to leave a comment.

Write your first end-to-end test in 5 minutes

Mon, 20 Apr 2020 00:00:00 GMT

There are some features and web applications that are not easy to test. Unit tests can only go so far in testing what the end-user sees when visiting your application.

Anything that requires real interaction with the DOM, for example tracking the mouse position or drag and drop, can be easily tested with end-to-end tests.

The main advantage of end-to-end tests is that you write tests that run in a real browser. That’s the closest you can get to the end-user, making these tests highly reliable.
They are also technology agnostic, so whatever framework you happen to use, testing is exactly the same.

Setting up the repository

I’m using this repository as an example since it provides a perfect target to end-to-end tests. It does use react and TypeScript, but don’t worry if you are not familiar with them, we are not going to touch the code. Make sure to delete the /cypress folder as it contains what we are going to do below.

Run npm i and npm start to see how the app works (start is also required to run the tests, so keep it running!).

Setting up cypress

I’m going to use cypress.io as end-to-end testing library. The excellent documentation and ease of installation make it an easy choice to quickly write down some tests.

Since cypress doesn’t require any configuration outside of its own folder, it’s safe to install in any frontend codebase.

$ npm i -D cypress

There are 2 ways of running cypress: in the browser (in watch mode) or the command line (no watch mode). We can try both by adding the scripts in package.json.

{
  "scripts": {
    "cypress": "cypress run", // cmd
    "cypress--open": "cypress open" // browser
  }
}

Running once npm run cypress-open will set up all the files required inside the /cypress folder.

The last step is to set up our port in cypress.json.

{
  "baseUrl": "http://localhost:8080" // change to whatever port you need
}

Writing the first test

Once you ran the command above once, you will have completed the setup to install cypress.
Cypress comes with a few example tests in /cypress/integration/examples but we can delete those, we will write our own soon.

Feel free to visit the application at localhost:8080 to see how it works. The app just handles some mouse inputs. On the main div, pressing the left-click will generate a note, left-clicking the note’s icon will make it editable, and right-clicking on it will delete it.

Create a homepage.spec.js file inside /cypress/integration, and let’s tell cypress to visit our app.

// cypress/integration/homepage.spec.js

it("successfully loads", () => {
  cy.visit("/");
});

And voilà the first test is done! You can check that it passes by running npm run cypress or npm run cypress--open.

Cypress looks very similar to many unit testing libraries like jest or mocha. It also comes with its own assertion library, so it is fully independent.

While this was easy, this test only checks that the app running.

Writing all the other tests

The first interaction in our app regards left-clicking on the main div, so let’s write a test for that.

it("click generates a note in the defined position", () => {
  // First, we check that our base div is indeed empty,
  // no note elements are present in the page
  cy.get("#app > div").children().should("have.length", 0);

  // Cypress provides a very intuitive api for mouse actions
  const pos = 100;
  cy.get("#app > div").click({ x: pos, y: pos });

  // now that we have clicked the div
  // we can check that a note appeared on top of our div
  cy.get("#app > div").children().should("have.length", 1);
});

This test already does enough to make us happy. When the click happens, a new note element is created.
We can improve it further by checking the position of the new note.

it("click generates a note in the defined position", () => {
  // First, we check that our base div is indeed empty,
  // no note elements are present in the page
  cy.get("#app > div").children().should("have.length", 0);

  // Cypress provides a very intuitive api for mouse actions
  const pos = 100;
  cy.get("#app > div").click({ x: pos, y: pos });

  // now that we have clicked the div
  // we can check that a note appeared on top of our div
  cy.get("#app > div").children().should("have.length", 1);


  // Checking the position on the div of our new note
  cy.get("#app > div button")
    .should("have.css", "top")
    // we detract half the size of the button on note.tsx
    // 100 - 12 padding = 88
    .and("match", /88/);

  cy.get("#app > div button")
    .should("have.css", "left")
    // we detract half the size of the button on note.tsx
    // 100 - 12 padding = 88
    .and("match", /88/);
});

An important note on cypress tests, the DOM will not reset between tests, this makes it easy to test incremental features.
We can use this to keep testing the note we created in the previous test. The next interaction we can test is editing.

it("left click on note edits the note content", () => {
  // We don't care for position of the click
  // as long as the click happens inside the note
  cy.get("#app > div button").click();

  // Typing does not happen instantly, but one key at a time
  cy.get("input").type("Hello World");
  // {enter} will tell cypress to hit the enter key
  // this will save our text and close the edit input
  cy.get("input").type("{enter}");

  // Check to make sure our note has been edited correctly
  cy.get("#app > div div").contains("Hello World");
});

The last feature to test is the delete action, a simple right-click on a note button deletes it, the test is very similar to the edit note one, just shorter.

it("right-click on note deletes a note", () => {
  // defensive check to make sure our note is still there
  cy.get("#app > div").children("button").should("have.length", 1);

  // right-click on the note button
  cy.get("#app > div button").rightclick();

  // Check to make sure the note disappeared
  cy.get("#app > div").children("button").should("have.length", 0);
});

And with this all our app functionality has been tested.

Bonus test - login form

Most applications start with a login form, and I didn’t write any code for this extremely common use case.
Below a quick example test including a timeout to load the next page once the authentication is successful.

describe("Login Page", () => {
  it("logs in", () => {
    cy.visit("/login");

    cy.get("input[name='login']").type("test user");
    cy.get("input[name='password']").type("password");
    cy.get("button[type='submit']").click();

    // change /success for the route it should redirect to
    cy.location("pathname", { timeout: 10000 }).should("include", "/success");
  });
});

Closing thoughts

End to end tests can be easier to write than unit test as they don’t care for technologies or code-spaghetiness.

They are also very effective as they are the closest automated tests to the end-user.

The full repository can be found here.

How to add a trending section to your gatsby blog

Mon, 09 Mar 2020 00:00:00 GMT

I always wanted to have a trending page in the blog to display the most viewed articles.
There are many ways to collect data, but getting the data back is not as easy. I found guides to set up servers, outdated plugins but nothing simple for the average website using Google analytics.

I’m using gatsby-plugin-google-analytics to get visitors data on my blog. Unfortunately, Google does not make it easy to understand how you are supposed to query the data it collects.

Additionally, the only plugin available for gatsby is poorly documented and has not been updated for the last year and a half. npm audit also highlights high vulnerabilities on the package from outdated dependencies.
Checking the code from the plugin, I found out it uses Google Reporting’s v3 API. Google’s ability to suddenly drop products is quite renowned, so I wanted to rely on the latest v4 API.

Making sure analytics works with the Reporting API

The first step, assuming Google analytics is already set up, is to make sure we can get data from it.
Google makes available the Request Composer, a simple form using the Analytics Reporting v4 API to show how to query data with it. Using your account, you should be able to query data from your site.

Example query requesting the page views for the last 30 days.
The viewId property can be found on your Google analytics account > admin > View Settings.

Make sure to launch the query and check the result to confirm it works as it should.

Creating a Viewer account

We need a Google Cloud account to be able to query the data successfully.

The default users’ permissions do more than what we need.
I prefer to create a new account with just the Viewer role, it limits the scope of the account and is less of a problem if somehow the key gets exposed.

To create a new user, navigate to Service accounts from the sidebar and + Create Service Account.
Give it the name you want but make sure it has only the Viewer role.

Once this is done, in the third and last screen + Create Key and then Done.

There should be a new account with the Viewer role in the dashboard now. We will use the downloaded JSON file to authenticate with Google in our application.

Getting data from the Reporting API

Now we can start working on our gatsby project.

npm i dotenv googleapis will add dotenv and the Google API client to our repository to make sure we can use our data safely and query the analytics data.
Create an empty .env file at the root of the project and add inside the PRIVATEKEY, CLIENTEMAIL from the JSON and the VIEWID from Analytics. The .env should be .gitignore‘d, for production set the environment variables in the service you are using.

// gatsby-node.js
// google auth logic
const crypto = require("crypto");
const { google } = require("googleapis");

require("dotenv").config();

exports.sourceNodes = async ({ actions }) => {
  const { createNode } = actions;

  // google auth logic
  const scopes = "https://www.googleapis.com/auth/analytics.readonly";
  const jwt = new google.auth.JWT(
    process.env.CLIENT_EMAIL,
    null,
    process.env.PRIVATE_KEY,
    scopes
  );
  await jwt.authorize();

  const analyticsReporting = google.analyticsreporting({
    version: "v4",
    auth: jwt,
  });

  // Analytics Reporting v4 query
  const result = await analyticsReporting.reports.batchGet({
    requestBody: {
      reportRequests: [
        {
          viewId: process.env.VIEWID,
          dateRanges: [
            {
              startDate: "30DaysAgo",
              endDate: "today",
            },
          ],
          metrics: [
            {
              expression: "ga:pageviews",
            },
          ],
          dimensions: [
            {
              name: "ga:pagePath",
            },
          ],
          orderBys: [
            {
              sortOrder: "DESCENDING",
              fieldName: "ga:pageviews",
            },
          ],
        },
      ],
    },
  });

  // Add analytics data to graphql
  const { rows } = result.data.reports[0].data;
  for (const { dimensions, metrics } of rows) {
    const path = dimensions[0];
    const totalCount = metrics[0].values[0];
    createNode({
      path,
      totalCount: Number(totalCount),
      id: path,
      internal: {
        type: `PageViews`,
        contentDigest: crypto
          .createHash(`md5`)
          .update(JSON.stringify({ path, totalCount }))
          .digest(`hex`),
        mediaType: `text/plain`,
        description: `Page views per path`,
      },
    });
  }
};

Now run npm start and check localhost:8000__graphql there should be two new fields to query, pageViews and AllPageViews. The first takes an id (slug) as parameter, the second displays all pages.

Example allPageViews query.

Displaying the new data

Now that we can get our numbers from graphql, it is time to create a new route for it. I opted for a new route called /popular to display my articles sorted by views.

// src/pages/popular.tsx

import React from "react";
import { Link, graphql } from "gatsby";

import { ArticleCard } from "../components/styled";

interface IProps {
  data: {
    allMarkdownRemark: {
      edges: Array<{
        node: {
          excerpt: string;
          fields: {
            slug: string;
          };
          frontmatter: {
            date: string;
            title: string;
            description: string;
          };
        };
      }>;
    };
    allPageViews: {
      nodes: Array<{ id: string; totalCount: number }>;
    };
  };
}

const PopularPosts: React.FC<IProps> = ({ data }) => {
  const pageViews = data.allPageViews.nodes;

  // add the pageview data to the post objects
  const posts = data.allMarkdownRemark.edges.map(post => {
    const { slug } = post.node.fields
    const currentPageViews = pageViews.find(
      filteredPageViews => filteredPageViews.id === slug
    )?.totalCount;
    return {
      ...post,
      pageViews: currentPageViews || 0,
    };
  });

  return (
    <div>
      <h1>Most popular Articles</h1>
      {posts
        .sort((postA, postB) => postB.pageViews - postA.pageViews)
        .map(({ node }) => {
          const title = node.frontmatter.title || node.fields.slug;
          return (
            <ArticleCard key={node.fields.slug}>
              <small>{node.frontmatter.date}</small>
              <h3>
                <Link to={node.fields.slug}>{title}</Link>
              </h3>
              <p
                dangerouslySetInnerHTML={{
                  __html: node.frontmatter.description || node.excerpt,
                }}
              />
            </ArticleCard>
          );
        })}
    </div>
  );
};

export default PopularPosts;

export const pageQuery = graphql`
  query {
    allMarkdownRemark(sort: {
      fields: [frontmatter___date],
      order: DESC
    }) {
      edges {
        node {
          excerpt
          fields {
            slug
          }
          frontmatter {
            date(formatString: "MMMM DD, YYYY")
            title
            description
          }
        }
      }
    }
    allPageViews(sort: { order: DESC, fields: totalCount }) {
      nodes {
        id
        totalCount
      }
    }
  }
`;

The npm package

Open source is the best part of the JavaScript ecosystem.

I created a gatsby plugin with the code from the Getting data from the Reporting API section. It can be used as an alternative to the code in gatsby-node.js.
Just follow the instructions in the readme and you should be able to set it up in no time.
It is my humble contribution to the amazing gatsby community.

How to add styled-components to a React application

Mon, 02 Mar 2020 00:00:00 GMT

I’ve talked about the advantages of CSS-in-JS and styled-components in a previous article you can find here.
A few days ago I had to set up it from scratch again and hated doing it. It does require quite a few actions to leverage the full advantages it can offer so let’s see all the steps required.

Install emotion

I prefer emotionjs between the CSS-in-JS libraries. It works very well with TypeScript and has an easy syntax.

$ npm i @emotion/core @emotion/styled will add the basic packages. @emotion/core is required, @emotion/styled only if you want styled-components. I favor the latter but sometimes use core for either some small styling with css or keyframes.

The vscode styled-components extension for syntax highlight and IntelliSense is a must.

Setting up .babelrc

Babel requires a plugin to parse emotion.
The default setup requires installing babel-plugin-emotion but it does not include the css prop. @emotion/babel-preset-css-prop does and includes the default plugin.

// the css prop
const Button: React.FC<IProps> = props => (
  <a
    css={{
      color: 'hotpink',
      '&:hover': {
        color: 'darkorchid'
      }
    }}
    {...props}
  />
)

$ npm i -D @emotion/babel-preset-css-prop will install it.
The emotion plugin needs to appear after @babel/preset-react and @babel/preset-typescript in the list of plugins in case you are using them (you should!).

// recommended .babelrc config for emotionjs
{
  "env": {
    "production": {
      "presets": [
        "@babel/react",
        "@babel/typescript",
        "@emotion/babel-preset-css-prop"
      ]
    },
    "development": {
      "presets": [
        "@babel/react",
        "@babel/typescript",
        ["@emotion/babel-preset-css-prop", { "sourceMap": true }]
      ]
    }
  }
}

Linting with style

Stylelint adds rules and checks for styled-components libraries. Since emotionjs is based on styled-components, the linting is fully compatible. It is also enabled by default.
$ npm i -D stylelint stylelint-config-standard
You can set up custom rules as well, declaration-empty-line-before is for prettier compatibility.

// .stylelintrc
{
  "extends": [
    "stylelint-config-standard"
  ],
  "rules": {
    "declaration-empty-line-before": null,
  }
}

Install the vscode extension to enable default detection on vscode.

Closing thoughts

Setting up new libraries can be a chore, especially when the documentation is spread in different places.
The advantages of using styled-components outweigh the initial set up chore. But it doesn’t mean it has to be a time-consuming activity.

What I learned from the women in tech in my life

Mon, 17 Feb 2020 00:00:00 GMT

Over my (still short!) career I was lucky enough to meet many people who inspired me to be a better professional and human being. I haven’t yet met many women in tech, but the few I’ve had the opportunity to get to know contributed heavily to my career and the direction I want it to take.

The value of free time

When I started my journey as a web developer, I was convinced that knowing more was the key to success.
To achieve this, I believed working all day (and sometimes all night) was the way to go. While I was becoming a better developer, I could not make any progress as a person.
The ability to detach and dedicate myself to me can greatly reduce the mental stress accumulated during work.

I’ve since changed my attitude towards my time and I am really able to enjoy my work and my own time when the workday is over.

The value of order

Distractions and disorganization are expensive in time for me and money for clients.
A disorganized employee can cost a company up to 20% of their annual salary every year.

As a remote developer, being organized can really make or break my work.
Spending a few minutes at the beginning of each day outlining what needs to get done can easily improve my focus and make me more efficient.

The value of inspiring others and making them succeed

I used to enjoy being the best in a team, it brings a nice boost to the ego, but I grew to understand it is a shallow objective.
Sometimes being the best in the room means you failed to raise others and with your inaction, did not contribute to the success of others.
A successful team is one where everybody is dedicated to the individual growth of each one of its elements. It is no use being the best if you don’t use your knowledge to uplift others.

I was once the guy saying “my team is full of idiots”. Once I started taking full accountability of my teams, my working environment has changed for the positive.

The value of diversity

According to Stackoverflow 2019 developer survey 91.7% of responders are men.

Men could have been perfectly capable of teaching me the same things highlighted in this article. But there is value in confronting different realities and points of view. In my case, this leads to adding more value to my life and work.

The real growth comes from working with people from different backgrounds and life experiences.
Embracing diversity leads to growth, an echo chamber to stagnation.

Thanks in no specific order:

Kristin, my mentor and an amazing engineer
Roxana, web developer
Irene, web developer
Britt, product manager

7 tips to improve remote company culture

Mon, 03 Feb 2020 00:00:00 GMT

A lack of remote culture can lead to a major decrease in productivity as well as an increase in employee turnover.

Hiring an employee costs at least 2 to 3 monthly salaries. This is a good investment when more heads are needed, but a very bad one if you have to replace employees all the time.

Calculating the cost of low productivity is harder, but it is definitely expensive. Maximizing productivity and happiness can reduce company costs dramatically.

Having a positive working environment and culture is vital for a successful company.
Remote companies are generally happier than non-remote ones.
Remote employees can enjoy more time with their families and zero commuting. While this grants a better starting point, a remote culture is still needed.

Below, 7 tips to make your remote company’s culture more effective.

1 - Share, share, share

Every oral conversation that happens in an office does not include remote workers. Slack and similar platforms, help make communication more inclusive.
Long-lasting discussions belong to a workspace, confluence, slite, notion are all good alternatives. Developers usually prefer Github, but it is rarely a good alternative.
The aim is not to change the way conversations happen, but to make it more accessible.

Good video communication software is also vital for facilitating conversations. Zoom is an excellent choice, but hangouts works as well.

2 - Nobody cares for free breakfast in another country

Many companies offer free coffees, breakfasts, beers, local game nights, and so on. If your perks can only be enjoyed in the office, you are excluding your remote employees. Making half or more of your employee second class citizens is a recipe for high turnover.

Some perks that can be offered:

More time off
Bonus for new hardware (laptops, headphones, second monitor, the list is long)
Paid coworking space
conference entries
Childcare support
Courses, webinars, other training programs

There is no simple answer as everyone chooses to work remotely for different reasons. It has to be discussed with each person individually. Make the first step, nobody will come to HR and ask to get a bonus for a new mouse.

3 - Invite and pay for office visits

While working can be done from anywhere, decisions are easier to take from the same room.
Organize with remote teammates joining the office for a few days or more.
The frequency might vary, it should be decided as part of the hiring process. A good rule is to always have the next trip planned.

Being in the same office is a great opportunity to have colleagues know each other better. It is the perfect amount of time to become friends and not enough time to grow bad feelings.

I shouldn’t have to say it, but the company should pay for these visits. It’s part of the job.

4 - Organize retreats

Corporate retreats and team building activities are a great place to form new company objectives and goals. Employees will bond in a relaxed environment with open communication this is the prime time to start forming fresh input and ideas on new company goals. Taking the input from employees into consideration when forming the new business strategy will help them form a stronger connection with the company and work harder towards a common goal. — Amaury de Saint Blanquat

Annual retreats reward employees for their hard work, make people connect in a positive and stress-free environment and foster new ideas.

5 - Be inclusive

Everyone works remotely for their own reasons. Often these reasons have to do with issues that make working from a familiar environment easier an office. From physical issues, mental, family related, the list is endless.

When organizing trips or retreats, ask each person if it requires a special diet, meds, or if there’s anything else that needs to be taken into consideration. If you want to keep the activities a surprise, at least inform of what is needed and required from every person.

Organizing a rock climbing trip requires some special attention if somebody has acrophobia or is in a wheelchair. Don’t assume, just ask. Having somebody skip a trip because of an untold issue is worse than rescheduling something more inclusive.

6 - Respect personal life

The definition of office hours blurs when you work from home. It can become very easy to work longer and longer hours, especially when under deadline.

Make sure the working hours are clearly defined.
Burned-out employees are more expensive than happy ones. Make sure that the remote employees’ time is respected.

7 - Move towards them

It is up to everybody to create and foster a remote culture.
Communication and organization need to account for remote employees as much as non-remote ones.
Everything has to move online or teammates have to be flown to the office.
Remote workers hare happier on average. As stated above, more happiness leads to fewer costs and higher productivity.
Hiring remote it is not a magic pill that makes money out of nothing. Remote companies work in a different way than non-remote ones. This needs to be accounted and steps need to be taken to achieve a successful remote environment.

You can’t have remote employees if you don’t move towards them.

React Native Turotial: Todo App

Mon, 13 Jan 2020 00:00:00 GMT

The cousin of the “hello world” program, the todo app is a good way to get started in a new technology front-end wise.

Starting out

This tutorial uses “Set up React Native, TypeScript and ESLint + prettier” to set up a basic React Native project. This tutorial uses TypeScript but it can be replicated just as easily in JavaScript.

The coding part

We want our todo app to have two views: the default view where the todos are displayed, and the edit view where new todos can be written.

We will allow adding and removing todo items, but not modifying existing ones. All todos will have a name key as a unique id. More properties can be easily added afterward.

For our application state, we will use React Native’s AsyncStorage. Since our state is not complicated, (3 actions, list, save, delete) we will use React hooks to handle all logic.

We will not use any other library except for uuid to generate unique IDs.

Handling the views

App.tsx should handle our views. The easiest way to do so is with a ternary operator switching component to be rendered.

// App.tsx
import React from "react";
import { StyleSheet, View, Button } from "react-native";

import { DefaultView, EditView } from "./app/components";

export type viewState = "default" | "edit";

const App = () => {
  const [
    viewState,
    setViewState
  ] = React.useState<viewState>("default");

  const handleNewPress = () => setViewState("edit");
  const handleCancelPress = () => setViewState("default");

  return (
    <View style={styles.container}>
      {viewState === "default" ? (
        <>
          <DefaultView />
          <Button title="Add new Item" onPress={handleNewPress}>
            Add new Item
          </Button>
        </>
      ) : (
        <>
          <EditView setViewState={handleCancelPress} />
          <Button title="Cancel" onPress={handleCancelPress}>
            Cancel
          </Button>
        </>
      )}
    </View>
  );
};

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: "#fff",
    alignItems: "center",
    justifyContent: "center",
  },
});

export default App;

With an useState hook, we can define our 2 views. A couple of buttons will be responsible for switching between the two views.

We know that EditView will need a submit button to add todos. The button will also have to switch view so we need to pass setViewState as a prop.

The DefaultView and EditView components are still missing, but we will take care of them later. Our next priority is the logic of the todo application.

Handling the logic

Relying on React Native’s AsyncStorage simplifies the amount of logic we have to handle. Everything we need can be reduced in three actions:

Add a new todo
Delete an existing todo
List all todos

We can consider our data as an array of objects (the todos).
Initially, we just display a name property.
Deleting can be messy if more todos share the same name, a unique ID solves the issue.

// store.ts
import { AsyncStorage } from "react-native";
import uuidv4 from "uuid/v4";

const ITEMS_KEY = "ITEMS";

export interface Item {
  id: string;
  name: string;
}

// add a new todo
export const addItem = async (itemName: string) => {
  const item: Item = { name: itemName, id: uuidv4() };
  try {
    const storedItems: Item[] = JSON.parse(
      await AsyncStorage.getItem(ITEMS_KEY)
    );
    // itemsArray will be null if there are no elements
    // we need to make it an array in that case
    const itemsArray = storedItems || [];
    await AsyncStorage.setItem(
      ITEMS_KEY,
      JSON.stringify([...itemsArray, item])
    );
  } catch (error) {
    console.error(error);
  }
};

// remove an existing todo
export const deleteItem = async (item: Item) => {
  try {
    const storedItems: Item[] = JSON.parse(
      await AsyncStorage.getItem(ITEMS_KEY)
    );
    const filteredItems = storedItems.filter(
      selectedItem => selectedItem.id !== item.id
    );
    await AsyncStorage.setItem(
      ITEMS_KEY,
      JSON.stringify(filteredItems)
    );
  } catch (error) {
    console.error(error);
  }
};

type getItemsType = () => Promise<Array<Item>>;

// list all todos
export const getItems: getItemsType = async () => {
  try {
    const itemsArray: Item[] = JSON.parse(
      await AsyncStorage.getItem(ITEMS_KEY)
    );
    return itemsArray;
  } catch (error) {
    console.error(error);
  }
  return [];
};

Adding new todos

The EditView will use only the addItem action, as well as some React to handle the input. We will also need the uuid library to create a unique ID.

// EditView.tsx
import React from "react";
import { Text, TextInput, Button } from "react-native";

import { addItem } from "../store";
import { viewState } from "../../App";

interface IProps {
  setViewState: React.Dispatch<React.SetStateAction<viewState>>;
}

const EditView: React.FC<IProps> = ({ setViewState }) => {
  const [
    itemName,
    setItemName
  ] = React.useState<string>("");

  const onSubmit = async () => {
    await addItem(itemName);
    setViewState("default");
  };

  return (
    <>
      <Text>Add a new Item</Text>
      <TextInput
        value={itemName}
        placeholder="Title"
        onChangeText={setItemName}
      />
      <Button title="Submit" onPress={onSubmit}>
        Submit
      </Button>
    </>
  );
};

export default EditView;

Inputs in React Native work pretty much the same as standard React, same for buttons. The only visible difference is the name of the change prop.

Displaying the list

The DefaultView will be responsible for showing all the todos using the getItems action.
We need to asynchronously load our todos after the component gets mounted. Since we are using functional components, we can achieve this using the useEffect hook. Another useState hook will hold the data returned from getItems.

// DefaultView.tsx
import React from "react";
import { Text, FlatList } from "react-native";

import { Item, getItems } from "../store";
import ListItem from "./ListItem";

const DefaultView: React.FC = () => {
  const [data, setData] = React.useState<Array<Item>>([]);

  React.useEffect(() => {
    // isMounted unsubscribes React from the async operation
    // if the component is unmounted
    let isMounted = true;
    getItems().then((items: Item[]) => {
      if (isMounted) setData(items);
    });
    return () => (isMounted = false);
  }, [data]);

  return (
    <>
      <Text>Todo List</Text>
      <FlatList
        data={data}
        renderItem={({ item }) => <ListItem item={item} />}
        keyExtractor={item => item.id}
      />
    </>
  );
};

export default DefaultView;

The individual todos are wrapped in a ListItem component. ListItem will render the data as well and handle the deleteItem action.

List todos and deleting

By extracting all the todos rendering to a single component, we can easily expand the todo app by touching the least amount of files and code.

// ListItem.tsx
import React from "react";
import { Text, Button } from "react-native";

import { Item, deleteItem } from "../store";

interface IProps {
  item: Item;
}

const ListItem: React.FC<IProps> = ({ item }) => (
  <>
    <Text>{item.name}</Text>
    <Button title="Delete" onPress={() => deleteItem(item)}>
      Delete
    </Button>
  </>
);

export default ListItem;

Adding more properties to our todos will just need minimal changes to the addTodo method and Item interface in store.ts. As for rendering, ListItem.tsx is the only file that should be touched.
This assures that future refactors and new features will be small in scope and easy to add.

The full code of this project can be found here.

Set up React Native, TypeScript and ESLint + prettier

Mon, 06 Jan 2020 00:00:00 GMT

React Native has made mobile app development very close to a React application. Many tools we use on a React project are available to Native as well. In this article, I want to illustrate how easy and fast it is to add TypeScript, ESLint and prettier for a React Native project.

TypeScript with Expo

Expo.io makes emulating a React Native project on any device a walk in the park. It’s my tool of choice when starting a new project.

$ npx expo init todo-app

It is all you need. Make sure to follow the instruction and pick a template with TypeScript.

Download the expo app on your phone and you can tunnel localhost on your phone as well, A+ dev experience.

Bonus: Enable React Native tools on vscode

Install React Native Tools on vscode for a better experience in your code editor.

Prettier + React Native

Setting up prettier tends to be straight-forward in most codebases. Install the package and set up a .prettierrc file if you want to override the default rules.

$ npm i -D prettier

// .prettierrc
{
  "endOfLine": "lf",
  "semi": true,
  "singleQuote": false,
  "tabWidth": 2,
  "trailingComma": "es5"
}

Bonus: Set up prettier for vscode

Install the prettier plugin on vscode and enable it on your personal settings.json file. View -> command palette -> search for ”> preferences: open settings (JSON)“.

// settings.json rules for prettier
{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": false
  },
  "[javascriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": false
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": false
  },
  "[typescriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": false
  }
}

Add ESLint

ESLint requires a bit more tailoring for expo. We need to install all the ESLint dependencies plus the expo config for eslint. The package is made to be compatible with expo and React Native environments. It also supports TypeScript.

$ npm i -D eslint @typescript-eslint/eslint-plugin @typescript-eslint/parser eslint-config-universe

After, either package.json or .eslintrc.js have to be configured to use our config.

// package.json
{
  "eslintConfig": {
    // for expo projects using react native
    "extends": "universe/native"
  }
}

// .eslintrc.js
module.exports = {
  extends: "universe/native",
};

And you are set.

Bonus: Set up ESLint for vscode

Install the ESLint package for vscode if you don’t have it already. A few lines on the user’s settings.json file will make it work (like we did for prettier).

// settings.json rules for ESLint
{
  "eslint.autoFixOnSave": true,
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    {
      "language": "typescript",
      "autoFix": true
    },
    {
      "language": "typescriptreact",
      "autoFix": true
    }
  ]
}

Closing thoughts

Setting up a good environment for developers should not take time away from coding. Modern tools can make this process really fast. My aim for this article is to help you get started in 5 minutes or less.

The complete code can be found here

Pros and cons of adopting TypeScript for my blog

Mon, 23 Dec 2019 00:00:00 GMT

I’ve been a proponent for TypeScript for enterprise applications for some time.
TypeScript can be invaluable for teams and big applications. It reduces the occurrence of bugs and helps new developers understand the codebase.

But what about a small Gatsbyjs private project maintained by a single developer?

This blog fits the bill. After getting it up, I write articles during the weekend but code-wise I rarely add new stuff. I don’t want it to become my side project as I have other stuff that takes priority over making another blog.

Thus, I never spent the time to consider switching the starter template to TypeScript.

Adopting TypeScript in Gatsbyjs

Installing TypeScript is pretty much pain-free on Gatsbyjs. After installing the provided plugin, a basic tsconfig.json is all it is needed.

// basic tsconfig.json for gatsbyjs
{
  "compilerOptions": {
    "module": "commonjs",
    "target": "esnext",
    "jsx": "preserve",
    "lib": ["dom", "esnext"],
    "strict": true,
    "noEmit": true,
    "isolatedModules": true,
    "esModuleInterop": true,
    "noUnusedLocals": false
  },
  "exclude": ["node_modules", "public", ".cache"]
}

After turning the first file from .jsx to .tsx the first problem hits me: ESLint is not working.

Gatsbyjs ships without ESLint, so of course it is not working. The blog starter I used does have prettier enabled, but without ESLint no errors are displayed on vscode.

Enabling ESLint

I already have ESLint enabled for TypeScript at work. I can copy the config and add the relative Gatsbyjs plugin. That should be enough, right?

Configs are not always a walk in the park, and prettier + ESLint can feel exactly like the opposite.

After not getting anywhere with this, I started toying with vscode’s settings.json. After a few minutes, I managed to break ESLint error reporting for all my other projects as well.

And that’s when I noticed my vscode version was outdated. To update I had to change the whole package as Manjaro’s binaries were not getting updated.

I felt like Hal fixing a light bulb.

After fixing my vscode installation, I sat down and learned how ESLint and prettier work together.
It was luck that made the whole thing work for the project I work on. Now with this newly acquired knowledge, I could go back to convert the codebase to TypeScript.

Converting JavaScript to TypeScript

As I said earlier, the codebase is small. There are a dozen components files, another dozen styled-component files, and six pages. Since half of those have propTypes already in place, it should not take more than an hour to convert them.

Here you can read how to set up TypeScript, ESLint and prettier for Gatsbyjs.

TypeScript is the perfect tool to get to learn the graphql layer that powers Gatsbyjs. Most of the types I had to write were mirroring the graphql schemes.
TypeScript also highlighted optimizations in the data flow. Allowing me to delete a few doubled graphql requests.

Another big issue highlighted by TypeScript regarded the SEO component and schema.org markup. Many props were either missing or not used correctly. TS identified these problems that I wouldn’t have noticed otherwise. Things like meta keywords needing to be a string with keys separated by commas instead of an array.

TypeScript was able to direct me towards the little undetected bugs. My blog was working even before TS. With it, I am more aware of how things work thanks to typings. And I can better identify issues before they hit production.

Is TypeScript worth the hassle for a small one team project?

This was my original question, and why I waited more than six months to finally cave and convert the project. TS was able to give me a complete vision of props shape and requirements for all the libraries I use. This greatly increased the health of the application and the reliability of the code.
The total cost in man-hours to convert the whole project didn’t go over an hour. It also highlighted major hidden issues across the codebase.
If you have never used TypeScript, a small Gatsbyjs application is a perfect opportunity to learn it.

Bonus points: Email form was boom

While refactoring the code, I discovered the form on the /about page was broken. Google graced me with an unannounced change in API that broke it somewhere in the last few months. Luckily, I had also netlify in place catching all submissions. I can proudly say I didn’t lose any of the spam emails I received in these months.
I’ve now cleaned up the netlify integration and removed the broken google script I had set up. It works better with less code to maintain.

How to setup gatsby with TypeScript and ESLint + prettier

Mon, 16 Dec 2019 00:00:00 GMT

Gatsbyjs starters are perfect for jumpstarting a new project. As all boilerplates, it lacks some tools to optimize our development experience.
Fortunately for us, Gatsbyjs is highly customizable.

TypeScript

Typescript is the easiest of them and the most impactful. Install the TS package, add it to the gatsby-config.js file, and create a tsconfig.json file.

// basic gatsbyjs tsconfig.json
{
  "compilerOptions": {
    "module": "commonjs",
    "target": "esnext",
    "jsx": "preserve",
    "lib": ["dom", "esnext"],
    "strict": true,
    "noEmit": true,
    "isolatedModules": true,
    "esModuleInterop": true,
    "noUnusedLocals": false
  },
  "exclude": ["node_modules", "public", ".cache"]
}

You can now start converting JS files to TS. Remember to add the @types/ packages, as by default they are not included.

As a bonus, install typescript and add a type check script to your package.json.

"type-check": "./node_modules/typescript/bin/tsc --noEmit --skipLibCheck"

Gatsby and gatsby-plugin-typescript use babel, so type checking will not stop the build. Use the script either manually or as a pre-commit hook to run it automatically.

Prettier

Like TypeScript, prettier is pretty straight-forward. One of the most used starters, gatsby-starter-blog already includes it. Let’s see how to add it from scratch.

We have to install prettier as dev dependency npm i -D prettier. After that, a simple .prettierrc file will suffice.

// .prettierrc
{
  "endOfLine": "lf",
  "semi": true,
  "singleQuote": false,
  "tabWidth": 2,
  "trailingComma": "es5"
}

Install the prettier plugin on vscode and enable it on your personal settings.json file. View -> command palette -> search for ”> preferences: open settings (JSON)“.

// settings.json rules for prettier
{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": false
  },
  "[javascriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": false
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": false
  },
  "[typescriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": false
  }
}

ESLint

ESLint requires a bit more than the other two. First, we need to install all the dev deps needed to run it. We will need eslint, eslint-loader, and gatsby-plugin-eslint for the initial config.
eslint-plugin-react for react, eslint-plugin-prettier and eslint-config-prettier for prettier. @typescript-eslint/eslint-plugin and @typescript-eslint/parser for TypeScript compatibility.

$ npm i -D eslint eslint-loader gatsby-plugin-eslint eslint-plugin-react eslint-plugin-prettier eslint-config-prettier @typescript-eslint/eslint-plugin @typescript-eslint/parser

Open gatsby-config.js and add the ESLint config to make it work. We need to allow TS extensions and optimize a couple of options.

// gatsby-config.js with eslint for both JS and TS files
{
  ...
  plugins: [
    ...,
    {
      resolve: "gatsby-plugin-eslint",
      options: {
        test: /\.js$|\.jsx$|\.ts$|\.tsx$/,
        exclude: /(node_modules|.cache|public)/,
        stages: ["develop"],
        options: {
          emitWarning: true,
          failOnError: false,
        },
      },
    },
  ]
}

Then we need to set up a basic .eslintrc.js file. Here’s where we will have to tell ESLint to be nice to react, prettier and TypeScript.

// basic .eslintrc.js compatible with react prettier and typescript
module.exports = {
  // Specifies the ESLint parser for TypeScript
  parser: "@typescript-eslint/parser",
  extends: [
    "plugin:react/recommended",
    "plugin:@typescript-eslint/recommended",
    "prettier/@typescript-eslint",
    "plugin:prettier/recommended",
  ],
  settings: {
    react: {
      version: "detect",
    },
  },
  env: {
    browser: true,
    node: true,
    es6: true,
  },
  plugins: ["@typescript-eslint", "react", "prettier"],
  parserOptions: {
    ecmaFeatures: {
      jsx: true,
    },
    // Allows for the parsing of modern ECMAScript features
    ecmaVersion: 2018,
    // Allows for the use of imports
    sourceType: "module",
  },
  rules: {
    // Disable prop-types as we use TypeScript for type checking
    "react/prop-types": "off",
    "@typescript-eslint/explicit-function-return-type": "off",
    // Enable prettier rules
    "prettier/prettier": "error",
    // interface start with capital I
    "@typescript-eslint/interface-name-prefix": "off",
    // allow "any" as type
    "@typescript-eslint/no-explicit-any": "off",
    // allow @ts-ignore for testing purposes
    "@typescript-eslint/ban-ts-ignore": "off",
  },
};

Last this we need to make sure vscode is actually working with us and understands all that we want. Install the ESLint package for vscode if you don’t have it already. A few lines on the user’s settings.json file will make it work (like we did for prettier).

// settings.json rules for ESLint
{
  "eslint.autoFixOnSave": true,
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    {
      "language": "typescript",
      "autoFix": true
    },
    {
      "language": "typescriptreact",
      "autoFix": true
    }
  ]
}

Your Gatsbyjs template with TypeScript, prettier and ESLint enabled is ready.
The initial time it costs to set it up is dwarfed by the advantages that these technologies can provide. Have fun coding!

How to review a Pull Request

Mon, 09 Dec 2019 00:00:00 GMT

Pull Requests are the heart of any team working on a shared project using git. It lives in that particular time when the code has been finished but not shipped yet. In this void, QA and pull request reviews happen.

Understanding other people’s code is part of every developer’s job. Reviews are the perfect moment to train this skill.

Before a code review

A review is not a request for a complete rewrite, nor an exercise in pedantry or a meaningless thumb up.
There are a few things that have to be assumed when giving a review to avoid miscommunications.
What follows are general assumptions that work in most cases. Every team should have its own discussion on what is assumed and what is not.

The code is working

One of the most important assumptions for a code review. A pull request review’s aim is to review the code, not to QA it. A frontend code review should not check styling or functionality. For backend, it should not query the service to see if the data is correct.
These steps should be their own process, they require more time and more people than a review should take.

The code is ready

Another vital aspect to take care of before a review happens is that everything is ready for it.
The code should be written in a way that the developer sees fit for deployment.

Code reviews aim to improve what is already in place. If the code is not fit for deployment, a review is just a waste of time for the whole team.

Taking more time to make sure the code reaches the standard of the codebase is not time wasted but gained. Your colleagues’ time is as valuable as yours.

The code is tested

Testing is another important aspect of every application. Untested code is fragile and unreliable. Yet it’s a practice I often see dismissed even in enterprise applications.

Making sure all new code is tested in a clean way is a huge first step in having a reliable and efficient codebase. So make sure every PR increases the total code coverage.

How to code review

A review is mostly a discussion.

It helps teams reach a shared expectation of what the code should look like.

Could this be rewritten using another data structure to simplify the code?
Could the code be split and abstracted?
Is it better to adopt a more performant solution over a simpler one?
Should the state of this component be global or local?
Leading comma or trailing comma?

Don’t be afraid to start discussions around the code, that’s the purpose of a code review.

Experience does not matter

Everyone can give a good code review, regardless of experience.

Some of the best discussions in code reviews I’ve received came from juniors.

The need for an explanation for an intricated part of the code can lead to a refactor to simplify it.
A question about a silent agreement can lead to a push for better documentation.

At the same time, a senior developer can use a code review as a mentorship opportunity.
There are many ways to enhance a review as a senior.

Pair programming code reviews can lead to teachable moments. You can go more in detail through the reasoning of the code. It’s even better than rubber duck debugging.
Share resources! You might find that an idea you have is actually wrong or outdated. It can help teach a few things to others who did not come across the same resources.
Document everything that needs answers to be understood. Build knowledge for your whole team.

Both more and less experienced developers can add value to reviews. Never dismiss a review coming from a junior developer, and don’t be afraid to be the junior.
As a senior, use a review as a mentoring opportunity.

Reviews increase the overall quality of the code

If I had a cent for every bug caught in a code review, I would have already retired to a tropical beach some time ago.

Nobody can write perfect code. Try to review your own code a week after writing it, you will find plenty of things to improve.

Having a second (and third and fourth…) pair of eyes checking the same code is the best way to make sure the code is up to standard and bug-free. It also helps the long term maintainability of the codebase.

If you don’t have an extra pair of eyes, your own will suffice, as my teacher in middle school used to say, “Always read your test again before submitting”.
You don’t know how much your code can improve until you look back at it.

Conclusion

(Adopting Pull Requests) improved our stylistic consistency, gave us a forum to discuss code structure and architectural decisions, and increased the likelihood that typos and logical errors would be caught before they reached our users.

— Lou Kosak, from Testing at Airbnb

Code reviews can improve the code, documentation, and knowledge of the team.

Approach code reviews as both reviewer and code author with a willingness to improve. An ignored suggestion or unasked question is not going to make you a better developer.
Every voice in the team counts, every question deserves an answer in code, documentation or knowledge. Make sure to encourage and address them.

Learning to work remotely

Mon, 11 Nov 2019 00:00:00 GMT

I’ve tried explaining to my mother over the years, what working remotely really is. While I made some big steps forward in explaining to her that I do in fact work. She still holds the idea that remote working is not “really working”.

The lack of an office and colleagues in the same room does not make the quality or the amount of work any different. If that was the case, remote jobs would either be paid as a full-time part-time or it wouldn’t exist to begin with.

One of the questions I get asked more frequently regarding working remotely is “How do you manage to work at home with so many distractions?“.
I believe this is one of the most important issues working remotely. It deserves more words than a can fit twitter PM and more visibility than an email.

The safety of the office

There’s nothing more motivational for work than to be surrounded by people who work.
Seeing everyone around you being productive is great. You start doing something just to fit in and 8 hours later it’s time to go home.

The other side of the coin is distractions. It is inevitable when you put a lot of people in the same room. A colleague tapping your shoulder, coffee break, cigarette break, useless meetings, and on and on. All these little things take time from you.
It might seem like part of the job, nobody is going to reprimand you for helping a colleague or being in a meeting. But most of it is time lost. And time equals productivity.
Eight hours in an office filled with distractions can shave in half your output.

The challenge of working from home

Remember that time you said you were going to be productive on the weekend, wake up early and get stuff done. How many times did you actually do it?
When there’s nobody working around you, you can’t rely on peer pressure to be productive.

At the same time, being able to pick your own office you can really be distraction-free.
But that doesn’t just happen. Being at home, you will probably be distracted by everything.
“I could water the plants”, “what if I clean up a little bit”, “There’s no milk in the fridge, I should buy some”.

The easiest way to solve both problems is to join a coworking space.
You pay a monthly or daily fee, you get a shared desk or an office surrounded by people working hard. On top of this already good deal, you get the added benefit that you don’t work with any of the people around you. They can’t distract you if they don’t need anything from you.

A good coworking space can even serve as a hub to know other professionals in the same field. The networking possibilities can be very well worth it.

But at the end of the day, you are still paying to work. It might be good if you can turn networking into a positive investment.

If you are only looking for a nice environment to work, a coworking can leave a very weird taste after a while.
It becomes too similar to an office. You get to know the regulars, make friends and welcome back the office distractions, or the place is empty (most of my experiences) and you lose the peer pressure.

A coworking space is a step everyone working remotely should try for a few weeks.

Going back to working from home, the disadvantage was only one, not being able to focus by yourself.
This is one of the biggest problems of working remotely.
Being able to focus and work without distracting yourself a skill that can be hard to master.

I have a few tricks I use to focus while working remotely.

One of my most effective habits is to set up objectives for the day, a todo list for my 8 hours of work.

Check emails
Review PR #186
Fix bug #189
Continue working on X until Y works
Coordinate with colleague about Z

This way I can go on about my day check-marking every small task as I complete it. I try to be as atomic as possible with the tasks so I can add more checkmarks. An added benefit is to be able to describe in a detailed and methodic way your tasks to your colleagues if you use any tracking tool like Geekbot for Slack.

Make sure the room or the desk or laptop you use is uniquely associated with work. In my case, both my working station and laptop are used uniquely for work. This helps me create a distinction between what is work and what isn’t.

Music can always help focus. I tend to listen to lo-fi beats while working. Be careful not to pick something you like to listen outside of work or you will start associating it with work.

Remote means you can work from anywhere

Not trading an office for a coworking space.

Learning to focus will help you work from anywhere in any condition.
Working remotely can free up so much time for yourself.
Reading books, learning a new language, writing articles, doing yoga, raising a family, getting a second job.

How to use it is up to you.

About CSS-in-JS and React

Mon, 02 Sep 2019 00:00:00 GMT

CSS-in-JS is something I’ve been unable to stop using on both personal projects and work.
CSS has been introducing more and more features, making SCSS less of an obvious choice.

At the same time, CSS-in-JS libraries entered the scene. They add some interesting features: Server-Side-Rendering, code splitting as well as better testing.

For the purpose of this article, I will be using EmotionJS and React. EmotionJS features TypeScript support, easy setup, and testing integration.

Advantages of CSS-in-JS

Being JavaScript, it offers all the features modern front-end development relies on.

Server-Side Rendering and code split with Emotion

Server-Side Rendering (SSR) with Emotion and React is simple. If you have React SSR enabled then congratulations! You have enabled it for Emotion as well.

Code splitting is pretty much the same.
Emotion is JavaScript so it will code split just like the rest of the application.

Sharing props between React and Emotion

Building styles based on classes can become quite complicated for big codebases.
In most cases, having each prop become a class can increase the verbosity of the code.
Having props determine styles without classes would cut a lot of unnecessary code.

The above image shows how convoluted a template literal can become.

This can be avoided by leveraging Emotion.

import { css } from "@emotion/core";
import styled from "@emotion/styled";

const themes = {
  red: css`
    color: pink;
    background: red;
    border-color: pink;
  `,
  blue: css`
    color: light-blue;
    background: blue;
    border-color: light-blue;
  `,
};

const sizes = {
  small: '8px',
  medium: '12px',
  large: '16px'
}

const disabledCss = css`
  color: grey;
  border-color: grey;
`;

/* Defining the button with the conditional styles from props */
const StyledButton = styled.button`
  ${(props) => themes[props.theme]};
  font-size: ${(props) => sizes[props.size]};
  border: ${(props) => props.border ? '1px solid' : 'none'};
  ${(props) => props.disabled && disabledCss};
`;

/* And finally how to use it */
<StyledButton
  theme="red"
  size="medium"
  border={true}
  disabled={false}
>
  Hello
</StyledButton>

There are no classes to depend on. The styles are applied to the components, removing the classes layer.

New styles are easily added and even more easily removed, JavaScript handles variables far better than we handle classes.

These atomic styles are easy to share across the codebase. Being variables, they can be imported and exported to other files.

Testing Emotion and React

Style regression and changes have always been up to the developer to check manually. CSS and SCSS do not allow to test this in any meaningful way.

Jest allows to snapshot React components to see diffs in HTML, making sure changes are safe. In the same way, Emotion styles can be snapshotted.

Snapshotting CSS removes the need to have to check manually if the styles break when making new changes.
This can be a huge time saver for both developers and testers who can ship code with more confidence.

Achieving all this in Emotion is rather fast.

Add this to your Jest setup file

import * as emotion from 'emotion'
import { createSerializer } from 'jest-emotion'

expect.addSnapshotSerializer(createSerializer(emotion))

And it’s done. When creating a snapshot, the EmotionJS output will be included in the snapshot.

Closing thoughts

CSS-in-JS has drastically changed the way to write CSS. Leveraging the most used programming language gives CSS new features to improve the way styles can be written.

Performance, maintainability, and testing are the core of a good application. CSS-in-JS offers improvements over older standards to all these issues.

How to organize a remote team

Sun, 11 Aug 2019 00:00:00 GMT

Skilled professionals and companies don’t often live in the same place. Some companies can afford to have people move to their city, but many don’t. And so remote jobs were born.

Working remotely can be fantastic. It requires a different work organization than a team in the same office. Different rules and principles apply to a team spawning different countries and time-zones.

Issues with remote teams

I will illustrate the three main issues I’ve faced the most working as a remote developer.

I’ll assume we are dealing with a half remote team in the next sections. Full remote teams are better at handling many issues since there is no alternative most of the time.

The biggest issue with remote teams is communication

Communication is key in every team, it can make or break a company. Yet it is often overlooked for remote employees.

In an office you can “bump” on your colleagues, meet them for a break or see them looking up from your screen.
This doesn’t happen with a remote team, while you say “I’ll drop him/her a message on slack” you forget most of the times.
Talking is easy, writing is a conscious action that requires focus. This is the biggest issue of remote companies.

The all common quick verbal agreement while on coffee break doesn’t work in a remote team.

Everything has to be written down.
From your daily schedule to decisions and even ideas.
While this might seem time-consuming, it is the only way to include remote employees. Lack of communication is far more taxing on everyone’s time.

Too many times I hear remote developers saying “I didn’t know that” or “When was that decided?“. This makes your colleagues less effective at doing their job. So they get dissatisfied on top of making the company lose money. And when a trained dissatisfied employee leaves, the company loses more money.

See the section below for a list of suggested software to improve communication.

The lack of socialization

Socialization makes teams bond thus increasing productivity and responsibility.

Socialization requires an active effort to include people outside of the office environment.
Its absence hurts your company’s ability to develop cross-team networks and share knowledge.

Useless perks

Perks are a way to attract and retain talent.

Perks centered around activities in the office or after hours are exclusive. They make the job less desirable if they are part of your offer.

If you already have remote employees, your ability to retain them might be lower than you think.

Solutions

These issues do not appear or are minimized by having everyone in the same office.
To have a successful remote team you will need to actively solve them.

Having a remote team is a high maintenance high reward deal.
It requires an effort to provide an environment equal to or better than an office.

There is no downside in applying these principles to a non-remote team. The aim is increasing team efficiency, quality and happiness.

Handling communication in a remote team

Communication is a kaleidoscopic issue, there is more than one solution to get it right.

Slack is the first step towards an efficient remote team. Scoped channels for every topic, plugins to enhance it. Here the bulk of the communication happens.

Must-have Slack plugins:

Github inside Slack. Best way to be notified of new commits, pull requests and comments.
Google Calendar one less tab to have on your browser.
Trello as with Github, instant feedback on Slack.
Zoom quickly fire a meeting, generate a link, and save a recording.
Geekbot daily stand-ups on Slack, no need to lose half an hour on a call no one is interested in.

The trick here is to try and see what works best. Many companies developed their successful approach outside of these plugins.

It’s important to keep the discussion open. Like a tree, it requires constant care to grow.

Socializing in remote teams

Having all employees know each other will create a diverse and healthy environment.

Lack of a shared office space narrows the chances people have to communicate. You need to actively create opportunities for people to socialize.

Pair programming and cross-team collaborations are good ways for people to socialize at work. They should be incentivized until they will become natural and not require external input.

Zoom video calls + pair programming. It allows the sharing of both screen and keyboard/mouse.
Donut is a plugin for slack that organizes coffee breaks and more between remote teams.

Perks everyone can enjoy

Remote employees have a hard time finding perks they can have access to.

I’ve personally never seen any perks worth mentioning as a remote developer. Compensating with a higher salary does not help retain talent. There is always a company paying more.

Perks I would like to see more often would be:

Parental leave (EU is definitely better, yet generally contractors are not that protected).
Equivalent wellness/fitness perks (if the company offers a gym discount, let me have it where I live).
Tickets to conferences to different cities.
Minimum vacation requirements.

Closing thoughts

It is always a good idea to have remote employees visit the headquarters a few times a year. More socialization and teamwork are always welcome.

Remote work allows companies to hire the talent they couldn’t otherwise attract.
This, in turn, requires more active care of employees’ organization and happiness.

Bad comments and how to fix them

Mon, 05 Aug 2019 00:00:00 GMT

I’ve talked about the importance of code comments here.

As developers, we have a vast array of solutions to enhance the readability and safety of our code.
Below there are some real-world examples of bad comments, and how how they can be improved.

Commented out code

Pretty simple, code that has been commented out. It could have been important or not, but it does not offer anything now.

This code can be deleted.
If you want to keep it around, it will still live in your git history. Make sure to give it a nice commit so you can easily go back to it.

We do not need to pollute the codebase with useless code. It increases file size and makes everything harder to understand.

Description comment

Some comments describe what a variable could describe with the same effectiveness.
Having well-named variables is better than hard to read code with comments in it.

The if statement looks pretty complex, thus deserving a comment its behavior.
Abstracting the condition in a variable can give the same information as the comment.

Warning comments

Other comments act as warnings, “do not touch this because of reasons”.
This is a pretty weak use of comments. They either deter developers from improving the code or they just get ignored.

We can solve this is by writing a test with fake data containing the exception stated by the comment.
If someone modifies the code, the test will fail. This gives us more confidence in our deployments than a flimsy warning comment.

Final notes

Comments are very valuable and should be used across any codebase. But some comments are just band-aids masking the real problem. One of the skills of a good developer is identifying where a comment is needed and where it is not.

Working for startups

Wed, 31 Jul 2019 00:00:00 GMT

The web is full of articles against working for startups. How much less reliable they are and in general worse than a more established company.

The startup experience

Since I started working as a web developer, I always picked jobs at startups. Working for these companies offer many benefits that are often not mentioned.

Reliability

Many often point out the unreliability of startups. A company that came out a few years ago and often still requires funding can not offer the job safety many wants.
While partially true, many developers I know fall in the same category. As a new developer without experience, you are in the same position as a startup. Why would anyone bet on you if you can’t bet on something that reflects you?
Many “modern” companies started as startups themselves. Facebook was born yesterday, the same as Airbnb. Without developers working there, they would not have turned out as they did.

Remote friendly

Most of the startups I interacted with were very keen on remote work. Being able to expand the pool of possible hires increases their quality.
From personal experience, traditional companies struggle more with remote work.

This is something very important to me as I value being able to choose where to live.

Growth potential

The small number of employees and less rigid organization allow more creative projects.
Some projects that I did in my spare time ended up being used by the startups I was working for. Among others, a price calculator for a startup’s various (confusing) product tiers.
You are also more free to decide on which technologies or features to adopt and experiment with.

This is not a plus for everyone. If you want a more “standard” office job, you might not like the increased responsibility.

Life-work balance

As said above, the increased growth potential can slip into a toxic working mentality. While you might think, the first few times, working weekends and late evenings are ok, it gets ugly pretty fast. No matter if you have or not things to do after your workday is over, you shouldn’t work because you are bored. Find a hobby or something to keep you busy.

I was working 24/7 years ago and it felt good at the moment. I kept doing more until I realized I wasn’t gaining anything. My salary was the same while my responsibilities increased.
You end up hating your job. It’s not a healthy way of living.

I really don’t support the sense of “always available” that can feel like a requirement with startups. It’s not healthy, and distracting/potentially worrying you when you’re out with friends. It is exactly the sort of stuff I would want to avoid on a team I’m involved in.

— Aidan, dear friend and colleague

Closing notes

Startups offer a great environment for growth. It is an excellent opportunity for juniors to know different aspects of the industry.
Don’t be afraid to propose and experiment with new ideas, a startup is a perfect place to be creative.
Being overworked is not cool, having a life is way better. It is also a faster way to improve both as a person and a professional.

The beauty of TypeScript

Fri, 12 Jul 2019 00:00:00 GMT

TypeScript popularity has been increasing in the last few years, and it isn’t slowing down.

I wasn’t interested in learning TypeScript for a long time. Working with JavaScript I felt I had everything I needed. Introducing a typed system didn’t feel necessary to me.
After a friend’s suggestion, I tried converting a few projects to TypeScript, and I fell in love.

What is TypeScript

TypeScript is a typed superset of JavaScript. It compiles to JavaScript. There isn’t much else to it.
Configuration and compilation speed where the blockers for many developers.
Now with @babel/typescript and the endless starters, these problems don’t exist anymore. For custom webpack & babel setup, adding TypeScript takes a couple of minutes.
Popular starters like create-react-app and gatsby already offer TypeScript as an opt-in feature.
Vuejs 3 will be written fully in TypeScript and already provides full TypeScript support.
Angular has been using TypeScript since the beginning.

Problems solved by TypeScript

The time I spend checking localhost has decreased a lot. A typed system gives you more confidence in what your code is doing.

Another great time sink for me was the heavy console.log use. Lovecraftian data structures with 10 layers of nested objects are not an issue if their type is one click away.
Even writing tests using mock data takes less time.

Even onboarding becomes easier with TypeScript.
The typed system helps new developers understand the ropes of the code they have to work with.

If it doesn’t compile, it’s broken.

Code compilation catches issues that would otherwise need manual testing.

Some developers argue on the time sink that is having to deal with TypeScript. A tradeoff between time and safety.
It is like arguing you shouldn’t write tests because it takes time.

Airbnb calculated that adopting TypeScript could prevent 38% of their bugs. That’s more of a time sink than writing any type will ever be.

About code comments

Mon, 01 Jul 2019 00:00:00 GMT

Comments are always a controversial topic among developers. Some love them and comment every line of code, while others avoid them at all costs.

Who needs comments and why

Why comments are useful is a question as old as the first programming language.

You are the first person who will need your comments. If you worked on it, there are high chances you are going to touch it again in the future. You will not remember the reason why you did things a certain way. A well-placed comment can save you a few hours of debugging, even more, if it’s another person code.

Temporary comments

Comments are not all born equal, some are not meant to last forever while others have more lasting lives.

Temporary comments include requests for refactoring or enhancements left out during development. Usual reasons include lack of time and waiting for unreleased library features.

// TODO add React.memo when react@16.6 gets released
const Dropdown = (props) => (
  <div>
    ...
  </div>
)

All temporary comments must be actionable. Either immediately (given the time) or after a set event happens, possibly not years in the future. To make these comments easy to search and identify, it is a good practice to start them with the same formula.

I use // TODO, easy to search when you can dedicate time to remove a few of them.

try {
  const response = await fetch('my-api');
  return await response.json();
} catch (error) {
  // TODO handle error
}

Permanent comments

These are a different type of comment, their purpose is to explain your choices or more complex code. Do not overdo it. An obvious comment is a useless noise.

Explanation of code

Comments should explain code that takes more than 30 seconds to read.
Language features and API specific code rarely need explaining, but edge cases do.
If the code uses native language features in an unusual way, it requires a comment.
If the code uses library specific code in an undocumented way, it requires a comment.

try {
  const response = await fetch('my-api');
  return await response.json();
  /* this executes if there's an error in the fetch above */
} catch (error) {
  console.error(error);
}

The above comment displays an unneeded comment. The try/catch block is a standard feature of JavaScript introduced in 1999. This case is a very standard one, it doesn’t need a comment. The MDN article on it uses a similar example.

/*
  create an array with all inputted strings
  split all strings in array
  remove all duplicates and turn it to string
  input: "bob" "alice" "john" "bob bob dan"
  output: "bob alice john dan"
*/
const deduplicateStrings = (...string) => [
    ...new Set(
      [...string].join(' ').split(' ')
    )
  ].join(' ');

This example is hard to read. It uses Array destructuring and Set both ES2015 features, in an unconventional way.
A comment explaining its functionality improves its readability.

While a test could achieve the same result it is not a substitute. Tests make sure the code works as intended, they shouldn’t explain the code.

Explanation of intent

Sometimes the intent is different than what would seem easier to do. Be it a limitation of the code/framework/project or a specifically requested feature.

/*
  'my-api/a&b&c' is super slow
  to make the request smaller we only request A & B and calculate C
  see github.com/kornil/this-project/issues/21
*/
const FetchABC = async () => {
  const response = await fetch('my-api/a&b');
  const data = await reposnse.json();

  return [a, b, a + b];
}

In this case, developers opted for an alternative instead of the default way. The comment documents why and where the decision took place.

/*
  React-table formats our data before giving us back cellProps.
  Problem is that booleans become undefined
  so we have to apply toString() before the data is given to react-table.
*/
const cleanData = rawData.map((data) => {
  return data.hasOwnProperty('live') ?
    { ...data, live: data.live.toString() } : data;
});

The undocumented behavior of a dependency is a standard case for an explanation comment.

Tips for good comments

Using different styles of comments can make it easier to distinguish them. JavaScript allows two different types of comments, // and /* */. Using the first for temporary comments can help recognize actionable ones.

If a colleague asks the reason behind a choice, the code deserves a comment.

If there is commented out code, remove it. It will still be available in the git history. The codebase doesn’t need the noise.

If it is easy to read, it probably doesn’t need a comment.
If it’s too complicated, it probably needs a refactor.

A good variable name can add more value than a comment.

Working alone is not an excuse to not write comments, and neither is “we will remember it”.

Git workflow in 5 minutes

Mon, 17 Jun 2019 00:00:00 GMT

A stable and reliable git workflow can improve your and your team productivity. Let’s learn it in 5 minutes.

What git workflow can provide

A reliable method when writing code in a team goes a long way. Merge/Rebase hell is far too common and can waste a lot of dev time. Reviewing also becomes easier: with scoped PRs, only a small amount of code gets reviewed at a time.

Challenges to an optimal git workflow

A team is good at git as the most inexperienced team member is. It is the responsibility of everyone to make sure your own team is capable of using git.

Being on the same page is also a huge part of a good workflow. Half assign stuff never goes far.

We will assume some rules aimed at simplifying and reducing the possible issues. We aim for simplicity, as developers with different experiences will be working together.

Git workflow philosophy

History is the most precious thing git can offer us, so we are going to preserve it no matter what. This means rebase has to go, we don’t allow anything that can alter the history of our branches.

This will increase the transparency of our project. Checking older commits will offer a clearer path to understand past decisions.

Last but not least, since no one is able to change the git history, everyone works on the same one. This simplifies merging branches and reduces the number conflicts.

Branches

Master is where deployment happens. It shouldn’t do anything else. In most cases, you shouldn’t even have it on your machine.

Development is our multi-purpose branch. This is the only branch that merges into master. Every other branch should come from here. This is also where QA happens.

Work branches are where coding gets done. Based on development, they are scoped to a single feature and are short-lived.
Only one developer works on a branch. If two or more are assigned to the same feature, then each will get its own branch.
Once completed, they are reviewed and once the review is ok, merged into development.
These branches names should be self-explanatory:

feature/login-page
fix/lazy-loading
refactor/error-handling

Pull Requests

Pull requests happen between work branches against development. Here reviews take place to make sure the code is up to standard. Once the branch is considered good, it can be merged into development.
Here it will be QAed, usually on a staging environment mimicking production.
Once development is good, it can be merged into master and deployed.

Commits

Commits are atomic in nature, they have a single and clear scope. The goal is to always be able to to back to an old commit and understand what it does, why and how.

For this reason names should also be clear. First letter capitalized, no longer than 50 character, no third person (wasted characters). If a commit needs more to explain its purpose, you can use the commit body to go more into details.
Good examples of commit titles:

Fix stripe error
Improve dropdown style
Fix issue #123

Working with a team can be difficult in many ways. A good workflow can help improve your job, the amount of work delivered as well as its quality.

Simplicity is the ultimate sophistication.

The importance of testing

Tue, 11 Jun 2019 00:00:00 GMT

Testing is a part of front-end development that I often see forgotten, yet it can play a major role in the reliability of a project.

What a good testing suite can provide

Having a good testing suite raises the confidence in the code you deploy. Knowing your app works as it is supposed to do removes a lot of hidden issues and doubts.
Detecting bugs with tests before you deploy is far better than having your users deal with them.

QAing everything by yourself can take a lot of time and the result would still be sub-par. A good testing suite automates most of this process, freeing you more time in the long run.

Challenges in testing a front-end application

Front-end adds a layer of complexity for your application: the user. Tests should take into account users by being able to cover what the user does, not only code.

The current JavaScript ecosystem keeps evolving at a very fast pace. Tests that rely on the internals of the libraries make for brittle tests, prone to break as the APIs change.

Most modern applications use a global state to connect different parts of the code. Most components will want access to this global state, so we have to account for it in our tests.

A Philosophical approach to testing

End users don’t care how you handle your global state, they care that when they try to log in, it works. When users click buttons around they expect them to work. That’s what we should test, what the user sees and does.

Since dependencies can change, our testing should be as library-agnostic as possible.

Testing is about making your life simpler, not harder. Don’t write tests for the sake of writing tests, if there is no value in a test, don’t write it.

The libraries used in the following examples are jest, react and react-testing-library. The end-to-end test using casperjs as browser testing utility.

Types of tests

There are a few different types of tests, we can adopt to solve the problems outlined above.

Unit tests

A simple unit test for testing the input and output of a function. In the example, the function accepts a string, if it is a URL, returns the domain name and top-level domain. In case http or https is not present, returns the input.

The test for this function sends the 2 possible inputs and checks if the outputs match what we expect.

Snapshot tests

Using a test renderer we can simulate a component and save a snapshot of the rendered element.

The test will then compare the new snapshot to the previous one for inconsistencies.

These tests can simplify testing UI, but they will break as the UI changes. If your application changes too much, other unit tests will provide more stability.

Integrated unit test

A test render can do for more than snapshots. By firing simulated events we can check our components behavior.

In this example, we create a table holding two values 2 and 1. We then simulate sorting the table and check the first value.

End-to-end test

These can be harder to set up. The example uses casperjs as I found it to be easier (also it’s free) than the alternatives.

This kind of tests mock an entire browser to execute the commands provided in the test.
In this example we take a screenshot of the login page, fill the form and take a new screenshot once logged in.

End-to-end tests can help strengthen your testing suite. A good codebase should include both unit tests and end-to-end tests.

Closing tips

There are more ways that can increase the quality of your application and your tests.

Css-in-js solutions like emotion allow you to snapshot the style generated by your components. This increases the coverage your snapshots can provide.

Using a CI solution like travis-ci or circleci is the standard for unit tests. You can also schedule end-to-end tests to run daily as a health-check for your application.

Even after such a complete testing solution, bugs can and will still appear.
Error tracking software like sentry or bugsnag can help you identify problems faster.

Testing an important part of programming. It reduces bugs, increases reliability and confidence in your code. Part of being a good developer is to know how to write effective tests.

Adapted from my presentation on the new front-end testing suite for streamroot.

The danger of lazy development

Fri, 07 Jun 2019 00:00:00 GMT

JavaScript has become over the years a leading force in the tech field.
It proved itself in the front-end field, as well as back-end with quite some success. And it’s now expanding into more fields like IoT and machine learning.

In all this, most JavaScript relies on npm as package manager. npm opened the doors of open source for JavaScript, contributing to its huge growth. Most Github top open source projects use JavaScript (or TypeScript) as the main language.

That’s also its biggest problem.

Bad code & performance

Many developers work on bad code daily. Bad code organization, insane requirements, refactor abandoned halfway, inexperience, the list goes on.

A popular example of bad code in JavaScript is unnecessary dependencies. It’s one of the best ways of raising code complexity & bundle size. Every package is a bet on its reliability for the present and the future of your application.

This is not only a problem for the developers working on the code. Almost every dependency has a cost in code size. Your end users are going to feel your application slowing down as its size increases.

Bundlephobia has a nice tool to analyze the cost of each dependency, give it a try with a few dependencies you use.

There are countless reasons why a dependency can become a problem for developers. Below the most common ones.

Abandoned projects

End of life is a grim reality in the world of open source. Projects get abandoned for many reasons, meant to be a draft, too much work, too little benefit, and so on.
Regardless of the reason, no package lives forever, no matter the owner.

Draft-js by Facebook has been drifting into nothingness for more than a year. There is currently no official alternative.

Splits in the community

Projects created to cover a specific need can struggle to find a new purpose as needs change. This often results in a split between the users. Forks start to appear with different philosophies in mind.

This can lead to developers jumping ship and having to rewrite important parts of their code.

Typescript-React-Starter by Microsoft is a fork of Create-react-app with Typescript added in.

Deprecated projects

JavaScript moves fast, many projects get deprecated.
It’s sometimes easier to rewrite an entire project than to fix it.

angularjs deprecated in favor of angular (2). Left the community in disarray, with many switching to other frameworks.

Hacks

Some packages can get hacked, usually, pull requests adding malicious code.

Event-stream is a package with more than 1 mil download/week. A malicious dependency made its way into the project, hacking Copay, a bitcoin wallet.

Countless more reasons can make open source packages obsolete.

When considering adding a new package to your project, try to see the pros and cons of doing it without.
Will it cost more or less in the long run?
Is the community behind it stable?
Are issues resolved on time?
Does it often introduce breaking changes?
How much will it increase the size of my final bundle?
Not all packages are worth the cost, learning where the equilibrium lies is the essence of our job.

Using a lot of dependencies is not a display of skill. Focus on the language and use packages to enhance it, not out of laziness.

The lazy developer manifesto is a small guide on how to use laziness in a smart way.

React hooks vs Redux part 2

Fri, 31 May 2019 00:00:00 GMT

In the first article, we explored how a React hook can simplify a basic Redux app.

The real value of Redux comes with more complex needs, such as fetching data from external APIs. Countless articles already explain how to do it.

In this article, we will build a simple application fetching data from a server.

I’ll take some example code from Dave Ceddia’s article on how to fetch data with Redux. Dave Ceddia provides a good explanation of how Redux handles everything. His article provides a more in-depth look at the code I will use below.

Redux

Redux can’t handle asynchronous actions by default. We are going to need redux-thunk as an extra dependency to handle them.

import { createStore, applyMiddleware } from "redux";
import thunk from "redux-thunk";

const store = createStore(
  rootReducer,
  applyMiddleware(thunk)
);

We will define our async fetch in its own file for simplicity. I took the liberty of rewriting it using async/await.

// fetchProducts.js
const fetchProducts = async () => {
  return dispatch => {
    try {
      dispatch(fetchProductsBegin());
      const res = await fetch("./products");
      const data = await res.json();
      dispatch(fetchProductsSuccess(json.products));
    } catch (error) {
      dispatch(fetchProductsFailure(error));
    }
  };
}

After that, we are going to need three actions, one for requesting the data, a success and an error one.

// actions.js
export const FETCH_PRODUCTS_BEGIN = 'FETCH_PRODUCTS_BEGIN';
export const FETCH_PRODUCTS_SUCCESS = 'FETCH_PRODUCTS_SUCCESS';
export const FETCH_PRODUCTS_FAILURE = 'FETCH_PRODUCTS_FAILURE';

export const fetchProductsBegin = () => ({
  type: FETCH_PRODUCTS_BEGIN
});

export const fetchProductsSuccess = products => ({
  type: FETCH_PRODUCTS_SUCCESS,
  payload: { products }
});

export const fetchProductsFailure = error => ({
  type: FETCH_PRODUCTS_FAILURE,
  payload: { error }
});

Our actions are then imported into a reducer where we will handle all three cases.

// reducer.js
import {
  FETCH_PRODUCTS_BEGIN,
  FETCH_PRODUCTS_SUCCESS,
  FETCH_PRODUCTS_FAILURE
} from './productActions';

const initialState = {
  items: [],
  loading: false,
  error: null
};

const productReducer = (state = initialState, action) => {
  switch(action.type) {
    case FETCH_PRODUCTS_BEGIN:
      return {
        ...state,
        loading: true,
        error: null
      };

    case FETCH_PRODUCTS_SUCCESS:
      return {
        ...state,
        loading: false,
        items: action.payload.products
      };

    case FETCH_PRODUCTS_FAILURE:
      return {
        ...state,
        loading: false,
        error: action.payload.error,
        items: []
      };

    default:
      return state;
  }
}

export default productReducer;

In the end, the component responsible for rendering our application.

import React from "react";
import { connect } from "react-redux";

import fetchProducts from "./fetchProducts"

class ProductList extends React.Component {
  componentDidMount() {
    this.props.dispatch(fetchProducts());
  }

  render() {
    const { error, loading, products } = this.props;

    if (error) {
      return <div>Error! {error.message}</div>;
    }

    if (loading) {
      return <div>Loading...</div>;
    }

    return (
      <ul>
        {products.map(product =>
          <li key={product.id}>{product.name}</li>
        )}
      </ul>
    );
  }
}

const mapStateToProps = state => ({
  products: state.products.items,
  loading: state.products.loading,
  error: state.products.error
});

export default connect(mapStateToProps)(ProductList);

The need for code organization becomes important as we deal with a growing number of actions.

React hooks

Can React hooks solve the same problem with the same elegance?

First, we need to rewrite the fetchProducts function to be more generic.

export const fetchProducts = async () => {
  try {
    const res = await fakeGetProducts();
    return res.products;
  } catch (error) {
    return error;
  }
};

We are going to use the UseReducer hook, it offers a similar structure to what Redux gives us. The same actions defined above can be re-used, as well as the reducer itself.

import React, { useReducer, useEffect } from "react";
import {
  fetchProducts,
  fetchProductsSuccess,
  fetchProductsFailure
} from "./productActions";
import reducer from "./reducer"

const initialState = {
  loading: true,
  error: null,
  products: []
};

const Counter = () => {
  const [state, dispatch] = useReducer(reducer, initialState);

  // equal to componentDidMount in this particular case,
  // the empty array as second argument will make it only run once
  // instead of every re-render
  // https://reactjs.org/docs/hooks-reference.html#timing-of-effects
  useEffect(() => {
    fetchProducts()
      .then(response => dispatch(fetchProductsSuccess(response)))
      .catch(error => dispatch(fetchProductsFailure(error)));
  }, []);

  const { error, loading, products } = state;

  if (error) {
      return <div>Error! {error.message}</div>;
    }

    if (loading) {
      return <div>Loading...</div>;
    }

    return (
      <ul>
        {products.map(product =>
          <li key={product.id}>{product.name}</li>
        )}
      </ul>
    );
}

Full codesandbox can be found here.

The APIs are pretty similar and it’s quite easy to change one for the other. Small and atomic reducers offer a way to decrease the complexity of your application.

Switching Redux for Hooks can help simplify the codebase by making it more local. Not everything should be in the global scope of the application. The added benefit of dropping classes is a nice cherry on top.

React hooks vs Redux

Tue, 21 May 2019 00:00:00 GMT

React is by far the most popular JavaScript framework, its learning curve is pretty linear, it has a rich and growing environment around it and a team behind it dedicated to improving it more and more every day.

Managing state in React has always been a topic full of discussions behind it, Redux was king for a good chunk of time, then other libraries started coming out doing a similar thing but better in one or more aspects.

Example Redux project vs basic React hooks project

Let’s go over to how to create a simple app that increments or decrements a counter with 2 buttons.

Redux

Let’s assume Redux is already configured and working. For an example project, you can check out simple-redux-app.

npx simple-redux-app test-folder

(npx makes it so that you don’t have to install the package globally before using it if you have npm ≥ 5.2.0 this is available by default.) Once this is out of the way it’s time to write our logic. I usually prefer to define the action types in their own file for cleanliness.

// actions/types.js
export const INCREMENT = 'INCREMENT';
export const DECREMENT = 'DECREMENT';

For the reducer, we want to be able to perform 2 actions, INCREMENT and DECREMENT that will modify our value by either plus or minus 1.

// reducers/counterReducer.js
import * as actions from '../actions/types';
function counterReducer(state = 0, action) {
  switch (action.type) {
    case actions.INCREMENT:
      return state + 1;
    case actions.DECREMENT:
      return state - 1;
    default:
      return state;
  }
}

Then, we have to define those actions.

// actions/counterActions.js
import { INCREMENT, DECREMENT } from './types';
export function addToCounter() {
  return {
    type: INCREMENT,
  };
}
export function removeFromCounter() {
  return {
    type: DECREMENT,
  };
}

Combining our reducer with other possible reducers should look something like this.

// reducers/index.js
import { otherReducer, combineReducers } from 'redux';
import counterReducer from './counterReducer';
export default combineReducers(
  { otherReducer, counterReducer }
);

And this is pretty much it, doesn’t look too complicated. Now to link it with our actual component.

import React from 'react';
import { connect } from 'react-redux';
import * as actions from '../actions';
const Home = (
  { counterValue, handleIncreaseValue, handleDecreaseValue }
) => (
  <div>
    <h2>Home Page</h2>
    <p>The counter value is {counterValue}</p>
    <button onClick={handleIncreaseValue}>
      Add
    </button>
    <button onClick={handleDecreaseValue}>
      Remove
    </button>
  </div>
);
const mapStateToProps = state => ({
  counterValue: state.counterReducer,
});
const mapDispatchToProps = dispatch => ({
  handleIncreaseValue: () => {
    dispatch(actions.addToCounter());
  },
  handleDecreaseValue: () => {
    dispatch(actions.removeFromCounter());
  },
});
export default connect(
  mapStateToProps,
  mapDispatchToProps
)(Home)

It seems like a lot of code for just a simple 2 button app that updates a value, in addition, we don’t share this component or actions with any other part of the app. All the files and logic we need to make this simple functionality overburden our application, a lot of complexity but we don’t gain much from it.

React Hooks

This is how the code would look like using locally scoped hooks.

import React from 'react';
const Home = () => {
  const [counterValue, setCounterValue] = React.useState(0);

  return (
    <div>
      <h2>Home Page</h2>
      <p>The counter value is {counterValue}</p>
      <button
        onClick={() => setCounterValue(counterValue++)}
      >
        Add
      </button>
      <button
        onClick={() => setCounterValue(counterValue--)}
      >
        Remove
      </button>
    </div>
  )
}
export default Home;

This is considerably less code, with the same performance if not better (Redux adds one more layer in the structure of the components), and only affects one file.

The logic is all in the same place, there’s nothing to investigate, on first look it’s obvious what the purpose of the code is. To know more about what the hooks API has to offer, you can check the official React docs here.

This code does not need any of the advanced features offered by Redux, we don’t need to travel forward or backward in the state history for a single action, we don’t need the development tooling or the rich console messages.

To know more about what Redux does and does not do, you can read a more complete article from its author here: You might not need Redux.

Hooks in React have much to offer, it’s a simple yet powerful tool.

You don’t need fancy tooling for most simple cases, leveraging React APIs can provide more benefits and less code complexity than a new library.

Simplicity is the ultimate sophistication.