DEV Community: Gabriel Abud

10 Things I Learned by Making a React Hook Library

Gabriel Abud — Wed, 26 Aug 2020 16:17:04 +0000

Since the introduction of Hooks in React 16.8, there has been an explosion of Hook libraries, and for good reason. Hooks are how you reuse code in functional components. Without Hooks, functional components would not be a viable alternative to class based components.

While I had made custom Hooks before, I had procrastinated making my own React Hook library. I knew if I made my own custom Hook without making it a library, it would die in the uncompleted side project graveyard that is my Github. So I needed to make it shareable in order to hold me accountable.

What I Built

I was frustrated by the existing table libraries out there. In most of my projects, I need to show tabular data in one form or another. While most existing table libraries do a decent job, once you start deviating from the default UI you end up fighting with the library a lot. These table libraries have a ton of existing issues, because it's hard to present a UI that is truly flexible to all the use cases.

What I needed was an easy way to handle the table state with no opinions on the UI. I stumbled on to the idea of headless components, which seemed like the perfect fit for what I needed. In essence, a headless component provides you the tools to manage the state of the component, without giving you an opinionated UI.

Introducing React Final Table

Building off of this concept, I came up with React Final Table. It's an extremely lightweight (1.5KB minzipped and 0 dependencies), type-safe, headless component library that exposes a single hook. Out of the box, it supports filtering, searching, selection, sorting, and pagination for your tables. In its most basic form, it looks like this:

import { useTable } from 'react-final-table';

const columns = [
  {
    name: 'firstName',
    label: 'First Name',
    render: ({ value }) => <h1>{value}</h1>,
  },
  {
    name: 'lastName',
    label: 'Last Name',
  },
];

const data = [
  {
    firstName: 'Frodo',
    lastName: 'Baggins',
  },
  {
    firstName: 'Samwise',
    lastName: 'Gamgee',
  },
];

const MyTable = () => {
  const { headers, rows } = useTable(columns, data);

  return (
    <table>
      <thead>
        <tr>
          {headers.map((header, idx) => (
            <th key={idx}>{header.render()}</th>
          ))}
        </tr>
      </thead>
      <tbody>
        {rows.map((row, idx) => (
          <tr key={idx}>
            {row.cells.map((cell, idx) => (
              <td key={idx}>{cell.render()}</td>
            ))}
          </tr>
        ))}
      </tbody>
    </table>
  );
};

See the documentation for more example use cases.

Without further ado, here are the top things I learned during this process:

1. React Hooks are great

The React equivalent to reusable functions are Hooks. Anywhere that you are duplicating non-UI code across components, you should evaluate whether making a custom Hook is worthwhile. Some of the most likely candidates are authentication and fetching data.

2. TSDX makes development a breeze

TSDX is a library for quick development of Typescript packages. There is a template for React, which means getting started with a new package takes only a few seconds. See my guide on using TSDX for more.

3. React Testing Library makes testing a breeze

While I'm a big fan of testing in Python, Jest, and even end to end testing with Cypress, I wasn't sure how to best do integration testing on the frontend. I knew I didn't want to break everything up into unit tests, since what I really want to test is that it works as expected, regardless of the implementation details.

React Testing Library makes it easy to test React Hooks without testing the implementation. This means my tests resemble how people are likely to use my library without being brittle to changes in the codebase.

4. Use sandbox examples

While testing is great, it can only get you so far. Sometimes you need to visually see what's happening as you add features. For this, it's important to set up a couple of sandbox examples that use your unpublished library. You can use npm link (or yarn link) to link to your unpublished library. Once you've published a version, you can share Sandbox examples using a link with Codesandbox.io. Here's an example of React Final Table using Codesandbox.

Or better yet, set up Storybook with many example use cases. Storybook allows you to develop many components in isolation along with documentation.

5. There is more to Hooks than useState and useEffect

While we all start out overusing Hooks like useState and useEffect, there are many others to be aware of.

Some of my favorite lesser known Hooks are useReducer (for complex state), useMemo/useCallback (for performance), and useRef (for persisting changes outside of the render lifecycle). In this library I made heavy use of all of these.

6. Headless UI components > UI components

From personal experience, headless UI components are more resilient to change and easier to refactor. It might seem convenient to use a pre-made component library with a UI, but think twice if you're going to be customizing it a lot. It might end up creating more work than you anticipated.

7. Use Typescript Generics for flexible libraries

In order to make a flexible Typescript library, I had to be sure I let people store any type of data in their tables. But how can you do this safely without using type any everywhere?

This is where Generics come in. They let us specify the type at runtime and still ensure that Typescript is performing type safety checks. Here is a code snippet to elaborate on what a Generic is:

// this function takes an element of any type and returns that same type
function identity<T>(arg: T): T {
  return arg;
}

console.log(typeof identity(42)); // number
console.log(typeof identity('string')); // string
console.log(typeof identity(undefined)); // undefined

8. Github Actions and continuous integration are essential

If you're not using continuous integration in your personal or work projects, you should definitely start. I used to be a heavy CircleCI user, but recently I've started to prefer Github Actions. The configuration and integration in Actions is much simpler than CircleCI, and the pre-built action ecosystem is much larger. In React Final Table, besides the ESLint, Prettier, and testing steps, I've added a Github Action to run code coverage and another to publish to NPM automatically, based on commit messages. This has greatly simplified my development process, as I don't need to manually update the version and publish to npm every time I make a change.

9. Learn from open source

I often get ideas around architecture, best practices, and contributing practices from open source projects I like. Some notable ones I found helpful for this library were downshift(another headless UI library), react-hook-form, and react-query.

10. Solve your own problems

The last recommendation I have is to make libraries that will solve a problem you have. Nothing is more demotivating than creating something you have no need for, so be sure you will be one of the main users of this library.

By creating things that you need, you will also have a vested interest in your library and are more likely to produce something of higher value.

Build your First Typescript Package in Under 10 Minutes

Gabriel Abud — Tue, 28 Jul 2020 15:42:30 +0000

I've been putting off building my own Typescript packages for a while.

Not for a lack of ideas, but because I know modern Javascript/Typescript development is a mess. Just check the size of your node_modules directory after starting a default React project to see what I mean, over 200MB of dependencies just to get started! Or better yet, try to start a React project without create-react-app.

It would take me days to configure my own Typescript package with Babel, Prettier, Rollup, ESLint, Jest, etc. just the way I want it. Not to mention probably cost me my sanity.

Then I stumbled onto TSDX.

After reading the README, I was able to publish an npm package complete with tests in a single evening.

This guide is a simplified version of what I learned publishing my first package. By the end of this tutorial you should have a published and tested Typescript package in the NPM registry.

NPM Registry

First you'll need to create an NPM account and configure it to use in your command line. Start with this short guide to configure your account and login via the command line with npm login if you haven't done so.

What we're Building

Since this tutorial is aimed at beginners, we're going to be building something simple. A reusable React component with Jest tests, types, and Github actions:

Truly awe inspiring, I know.

Live Demo

Final Source Code

Setup

Let's bootstrap our TSDX project from the command line:

npx tsdx create toggle

At the prompt, select React:

After the dependencies are installed, let's make sure we can start the project in development/watch mode:

cd toggle
npm start

You should now have a functioning package!

File Structure

> tree -L 2 -I node_modules
.
├── LICENSE
├── README.md
├── dist
│   ├── index.d.ts
│   ├── index.js
│   ├── toggle.cjs.development.js
│   ├── toggle.cjs.development.js.map
│   ├── toggle.cjs.production.min.js
│   ├── toggle.cjs.production.min.js.map
│   ├── toggle.esm.js
│   └── toggle.esm.js.map
├── example
│   ├── index.html
│   ├── index.tsx
│   ├── package.json
│   └── tsconfig.json
├── package-lock.json
├── package.json
├── src
│   └── index.tsx
├── test
│   └── blah.test.tsx
└── tsconfig.json

The default project is pretty minimalist. There are a few directories/files that are important to know though.

Directories

src: This is where all of the source files that will be built live
example: An example playground to test your component/package
dist: What will get built and published to npm. You shouldn't really have to touch this directory and it should be excluded from source control.
test: Your tests

Files

src/index.tsx: Your main source file that will be built. This needs to import all your other source files
package.json: Dependencies/all configuration for your package
example/package.json: Dependencies for your playground (these will not be published to npm)
example/index.tsx: File that loads your package for the playground
test/blah.test.tsx: Example test file
README.md: Generated README with a lot of useful information for reference.

Toggle Component

To keep with React best practices, we'll make a separate file for our component.

Copy and paste the following code into src/Toggle.tsx:

// Inside src/Toggle.tsx
import React, { FC } from 'react';

export const Toggle: FC = () => {
  return (
    <label className="switch">
      <input type="checkbox" />
      <span className="slider round"></span>
    </label>
  );
};

Nothing crazy here, just a default HTML checkbox. Let's export our component from our index.tsx file which is the main file that will be used in the package.

// src/index.tsx

export * from './Toggle';

TSDX projects come with an example folder to help you visualize your component in a browser. This is what we'll use as a sandbox for our component as well. Since we changed the name of the component, we'll have to update the example import:

// example/index.tsx

import 'react-app-polyfill/ie11';
import * as React from 'react';
import * as ReactDOM from 'react-dom';
import { Toggle } from '../src/index'; // 👈 Change our import 

const App = () => {
  return (
    <div>
      <Toggle />{/* 👈 Change to use your new component*/}
    </div>
  );
};

ReactDOM.render(<App />, document.getElementById('root'));

Now let's run this sandbox environment to see what we have:

cd example
npm i
npm start

Navigate to http://localhost:1234. You should see a checkbox!

Styling

Let's add some styles to our sweet checkbox now. Open a new file called Toggle.css inside of the src directory and copy the following styles into it:

/* src/Toggle.css */

/* The switch - the box around the slider */
.switch {
  position: relative;
  display: inline-block;
  width: 60px;
  height: 34px;
}

/* Hide default HTML checkbox */
.switch input {
  opacity: 0;
  width: 0;
  height: 0;
}

/* The slider */
.slider {
  position: absolute;
  cursor: pointer;
  top: 0;
  left: 0;
  right: 0;
  bottom: 0;
  background-color: #ccc;
  -webkit-transition: .4s;
  transition: .4s;
}

.slider:before {
  position: absolute;
  content: "";
  height: 26px;
  width: 26px;
  left: 4px;
  bottom: 4px;
  background-color: white;
  -webkit-transition: .4s;
  transition: .4s;
}

input:checked + .slider {
  background-color: #2196F3;
}

input:focus + .slider {
  box-shadow: 0 0 1px #2196F3;
}

input:checked + .slider:before {
  -webkit-transform: translateX(26px);
  -ms-transform: translateX(26px);
  transform: translateX(26px);
}

/* Rounded sliders */
.slider.round {
  border-radius: 34px;
}

.slider.round:before {
  border-radius: 50%;
}

Let's import those styles into our Toggle.tsx component. We will need to install the rollup-plugin-postcss to tell Rollup how to compile CSS as part of our package:

npm i -D rollup-plugin-postcss

Now create a file called tsdx.config.js in the root of your project and paste the following code:

// tsdx.config.js

const postcss = require('rollup-plugin-postcss');

module.exports = {
  rollup(config, options) {
    config.plugins.push(
      postcss({
        plugins: [],
      })
    );
    return config;
  },
};

Now we can import our styles using ESM imports:

// src/Toggle.tsx

import React, { FC } from 'react';
import './Toggle.css'; // 👈 Import our new styles

export const Toggle: FC = () => {
  return (
    <label className="switch">
      <input type="checkbox" />
      <span className="slider round"></span>
    </label>
  );
};

Save and refresh your browser.

Tada!

Component Props

But what if we want to actually do something with the state of our toggle component? It's not very useful as is.

Let's add component props in order to give us more flexibility:

// src/Toggle.tsx

import React, { FC } from 'react';
require('./Toggle.css');

export type ToggleType = {
  isOn: boolean;
  handleChange: () => void;
};

export const Toggle: FC<ToggleType> = ({ isOn, handleChange }) => {
  return (
    <label className="switch">
      <input checked={isOn} onChange={handleChange} type="checkbox" />
      <span className="slider round"></span>
    </label>
  );
};

We can now pass props into the component and manage the state of it. Our types will automatically be built and included as part of our project, since we are exporting ToggleType.

Let's update our playground to contain this state and make sure the toggle still works:

// example/index.tsx

import 'react-app-polyfill/ie11';
import React, { useState } from 'react';
import * as ReactDOM from 'react-dom';
import { Toggle } from '../src/index';

const App = () => {
  const [isOn, setIsOn] = useState(false);

  return (
    <div>
      <Toggle isOn={isOn} handleChange={() => setIsOn(!isOn)} />
    </div>
  );
};

ReactDOM.render(<App />, document.getElementById('root'));

Now we're handling state outside of the component. This means we can change the toggle state anywhere by simply calling setIsOn(!isOn).

Tests

We're ready to publish our package, however let's make sure we have a functioning test first. We want people to contribute to your project and we don't want to test the functionality in our sandbox every time a new PR is opened.

Let's rename the blah.test.tsx file to toggle.test.tsx and update our react-dom render method:

// src/tests/blah.test.tsx -> src/tests/toggle.test.tsx

import * as React from 'react';
import * as ReactDOM from 'react-dom';
import { Toggle } from '../src';

describe('it', () => {
  it('renders without crashing', () => {
    const div = document.createElement('div');
    ReactDOM.render(<Toggle isOn={false} handleChange={() => {}} />, div);
    ReactDOM.unmountComponentAtNode(div);
  });
});

In order for Jest to be able to read CSS files, we'll need to install a package to allow us to mock these files:

npm i -D identity-obj-proxy

And then edit our package.json to reflect this:

// package.json
...
  "jest": {
    "moduleNameMapper": {
      "\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$": "<rootDir>/__mocks__/fileMock.js",
      "\\.(css|less|scss|sass)$": "identity-obj-proxy"
    }
  },
...

See Jest docs for more on why this is necessary. We should have a functioning test now, from your root level directory:

npm test

Huzzah!

The only problem is that this is just testing that the component mounts and doesn't break the app doing so. What we really want to test is that the toggle functionality and isOn prop works.

We can use react-testing-library to test our component prop functionality:

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

Let's update our test file to use some of these new testing methods. We'll be using the render and fireEvent methods:

// test/toggle.test.tsx

import * as React from 'react';
import { render, fireEvent } from '@testing-library/react';
import { Toggle } from '../src';

it('Should render the toggle and be clickable between states', () => {
  // mock onChange function
  const onChange = jest.fn();

  const { getByTestId, rerender } = render(
    <Toggle isOn={false} handleChange={onChange} />
  );
  // checkbox and parent label components
  const checkbox = getByTestId('Toggle');
  const label = getByTestId('Toggle-label');

  // isOn=false should mean it's unchecked
  expect(checkbox).toHaveProperty('checked', false);

  // Clicking from off -> on
  fireEvent.click(label);
  expect(onChange).toHaveBeenCalledTimes(1);

  // isOn=true should mean it's checked
  rerender(<Toggle isOn={true} handleChange={onChange} />);
  expect(checkbox).toHaveProperty('checked', true);

  // Clicking from on -> off
  fireEvent.click(label);
  expect(onChange).toHaveBeenCalledTimes(2);
});

If this is a bit confusing or if you're unfamiliar with react-testing-library, that's okay. All we're really doing here is rendering the component and making sure isOn reflects a checked state and that our handleChange function is called every time on click.

Double check that it still works:

npm test

Publish

You'll want to make sure you update the version, author, and name of your package. The name should be unique and not taken in the NPM registry. There are three fields you need to change in your package.json:

 "author": "Frodo Baggins",
 "name: "frodo-toggle",
 "version": "1.0.0",

The last step is to publish now!

npm publish

If you get an error, it's likely that you either need to a) login again via npm login or b) change the package name to be unique. If you want to see if the package name is available, try searching for it in the npm registry.

Congratulations, you are now a Typescript package author. 😎

Anyone can now install your package from the command line by running:

npm i your-toggle-lib # replace this with your package name

Next Steps

There are a few things you could do to make this package better from here. If you're planning on allowing outside contributors you may want to tweak the default Github action that comes with TSDX to run your test suite on new PRs. This will make sure that outside contributors are not merging in broken changes.

Other possible next steps:

Add props to change the color and add labels to the toggle button.
Add a size prop with "small", "medium", and "large" options.
Add different transitions based on a prop.
Add styled-components instead of css

The world is your oyster!

Configuration is the most painful part of any project, but libraries like TSDX and create-react-app are amazing at lowering the barrier of entry for newcomers and lazy people (like me). No one likes spending a day fighting with configuration files. Hopefully this guide gives you a bit more confidence that you can write your own packages. I look forward to seeing your projects on Github and npm!

Why I Stopped Using Redux

Gabriel Abud — Mon, 06 Jul 2020 21:00:11 +0000

Redux was a revolutionary technology in the React ecosystem. It enabled us to have a global store with immutable data and fixed the issue of prop-drilling in our component tree. For sharing immutable data across an application, it continues to be an excellent tool that scales really well.

But why do we need a global store in the first place? Are our frontend applications really that complex or are we trying to do too much with Redux?

The Problem with Single Page Applications

The advent of Single Page Applications (SPAs) such as React, brought about a lot of changes to how we develop web applications. Separating our backend from our frontend code allowed us to specialize and separate out concerns. It also introduced a lot of complexity, namely around state.

Fetching data asynchronously now meant that the data had to live in two places: the frontend and the backend. We have to think about how best to store that data globally so it's available to all of our components, while maintaining a cache of the data to reduce network latency. A big part of frontend development now becomes burdened with how to maintain our global store without suffering from state bugs, data denormalization, and stale data.

Redux is not a Cache

The main problem most of us get into when using Redux and similar state management libraries is that we treat it as a cache for our backend state. We fetch data, add it to our store with a reducer/action, and refetch it periodically to make sure it's up to date. We are making Redux do too much and using it as a catch-all solution to our problems.

One important thing to remember is that our frontend and backend state are never really in sync, at best we can create a mirage that they are. This is one of the downsides of the client-server model and why we need a cache in the first place. Caching and maintaining state in sync is immensely complex however, so we shouldn't be recreating this backend state from the ground up like Redux encourages us to.

The line between backend and frontend responsibility quickly becomes blurred when we start to recreate our database on the frontend. As frontend developers, we shouldn't need to have a thorough knowledge of tables and their relationships in order to create a simple UI. Nor should we have to know how best to normalize our data. That responsibility should fall on the people designing the tables themselves - the backend developers. Backend developers can then provide an abstraction for the frontend developers in the form of a documented API.

There are now a myriad of libraries (redux-observable, redux-saga, and redux-thunk to name a few) built around Redux to help us manage data from the backend, each adding a layer of complexity to an already boilerplate-heavy library. I believe most of these miss the mark. Sometimes we need to take a step back before taking a step forward.

What if we stop trying to manage our backend state in our frontend code and instead treat it like a cache that just needs to be updated periodically? By treating our frontends like simple display layers that read from a cache, our code becomes significantly easier to work with and more accessible to pure frontend developers. We get all of the benefits of separating out concerns without most of the downsides of building SPAs.

A Simpler Approach to Backend State

There are a couple of libraries that I believe are a huge improvement over using Redux (or similar state management library) for storing backend state.

React Query

I've been using React Query for a few months in most of my personal and work projects. It's a library with a very simple API and a couple of hooks to manage queries (fetching data) and mutations (changing data).
Since using React Query, not only am I more productive but I end up writing 10x less boilerplate code than I would have with Redux. I find it easier to focus on the UI/UX of my frontend applications without having to keep the whole backend state in my head.

To compare this library to Redux, it helps to see an example of the two methods in code. I've implemented a simple TODO list fetched from the server with both methods, using vanilla JS, React Hooks, and axios.

First, the Redux implementation:

import React, { useEffect } from "react";
import { useSelector, useDispatch } from "react-redux";
import axios from 'axios';

const SET_TODOS = "SET_TODOS";

export const rootReducer = (state = { todos: [] }, action) => {
  switch (action.type) {
    case SET_TODOS:
      return { ...state, todos: action.payload };
    default:
      return state;
  }
};

export const App = () => {
  const todos = useSelector((state) => state.todos);
  const dispatch = useDispatch();

  useEffect(() => {
    const fetchPosts = async () => {
      const { data } = await axios.get("/api/todos");
      dispatch({
        type: SET_TODOS,
        payload: data}
      );
    };

    fetchPosts();
  }, []);

  return (
    <ul>{todos.length > 0 && todos.map((todo) => <li>{todo.text}</li>)}</ul>
  );
};

Note that this doesn't even begin to handle refetching, caching, and invalidation. This simply loads the data and stores it in your global store on load.

Here's the same example implemented with React Query:

import React from "react";
import { useQuery } from "react-query";
import axios from "axios";

const fetchTodos = () => {
  const { data } = axios.get("/api/todos");
  return data;
};

const App = () => {
  const { data } = useQuery("todos", fetchTodos);

  return data ? (
    <ul>{data.length > 0 && data.map((todo) => <li>{todo.text}</li>)}</ul>
  ) : null;
};

By default this examples includes data refetching, caching, and stale invalidation with pretty sensible defaults. You can set the caching configuration at the global level and then forget about it - in general it will do what you expect. For more on how this works under the hood, check out the React Query docs. There are a ton of configuration options available to you, this only begins to scratch the surface.

Anywhere you need this data, you can now use the useQuery hook with the unique key you set (in this case "todos") and the async call to use to fetch the data. As long as the function is asynchronous, the implementation doesn't matter - you could just as easily use the Fetch API instead of Axios.

For changing our backend state, React Query provides the useMutation hook.

I've also written a curated list of React Query resources that you can find here.

SWR

SWR is conceptually almost identical to React Query. React Query and SWR were developed around the same time and both influenced each other in positive ways. There is also a thorough comparison between these two libraries in the react-query docs.

Like React Query, SWR also has really readable documentation. For the most part, you can't go wrong with either library. Regardless of what ends up becoming the norm in the near future, it will be much easier to refactor from that than the equivalent Redux mess.

Apollo Client

SWR and React Query focus on REST APIs, but if you need something like this for GraphQL the leading contender is Apollo Client. You'll be pleased to learn that the syntax is almost identical to React Query.

What About Frontend State?

Once you start using one of these libraries, you will find that on the vast majority of projects, Redux is overkill. When the data fetching/caching part of your app is taken care of, there is very little global state for you to handle on the frontend. What little amount is left can be handled using Context or useContext + useReducer to make your own pseudo-Redux.

Or better yet, use React's built in state for your simple frontend state. There is nothing inherently wrong with that.

// clean, beautiful, and simple
const [state, setState] = useState();

Let's embrace the separation of backend from frontend more fully instead of remaining in this ambiguous in-between state. These up and coming libraries represent a shift in how we manage state in single page applications and are a big step in the right direction. I'm excited to see where they lead the React community.

Git Concepts I Wish I Knew Years Ago

Gabriel Abud — Mon, 29 Jun 2020 17:53:40 +0000

The most used technology by developers is not Javascript.

It's not Python or HTML.

It hardly even gets mentioned in interviews or listed as a pre-requisite for jobs.

I'm talking about Git and version control of course.

Most of us get by with learning a few git concepts for far too long. We learn the minimum to get by working on a small team with a simple feature branch workflow. If you're anything like me, this will carry you for years into your career.

It's time we revisited Git and how important it is to master in order to advance in our careers. This guide serves as a reference for what I believe are necessary, yet lesser-known concepts. Mastering Git will make a huge difference in how you manage code and your own day-to-day workflow. Because Git commands are a bit archaic and hard to remember, this guide will be broken up by concepts and expected behavior instead.

If you don't have a firm grasp of general Git concepts, like the difference between your working directory, local repository, and remote repository, read this guide first. Likewise if you don't have the basic git commands mastered, start with the official documentation. This guide is not meant to take you from absolute beginner to professional and assumes you are already somewhat proficient using git.

Git Commands
- Logging
- Navigation
- Modifications
- Cleanup
- Aliases
Other Git Tricks
- Ignoring Files
- Special Files
Git Workflows
- Rebase vs Merge
- Remote Repository Settings
- Pull Requests
- Branch Naming
- Commit Messages

Git Commands

📋 Logging

What did I just do?



git log
git log --oneline # more succinct output
git log --graph # with a visual graph of branches

View your "undo" history



git reflog

Because sometimes git log doesn't cut it, especially for commands that don't show up in your commit history.

reflog is basically your safety net after running "scary" commands like git rebase. You'll be able to see not only the commits you made, but each of the actions that led you there. See this Atlassian article to learn more about how refs work.

View your current state + any merge conflicts



git status

While git status is a pretty basic command we all learn early on, its importance as a learning tool for internalizing git fundamentals bears repeating. It can also help you navigate through a complicated rebase or merge.

See the differences in your staged (or unstaged) changes



git diff --staged # for staged changes
git diff # for unstaged changes

See the differences between two branches



git diff branch1..branch2

🧭 Navigation

I want to see what I did before



git reset <commit-sha>

This will uncommit and unstage those changes but leave those files in the working directory.

I want to switch to another branch



git switch branch-name   # new syntax (as of Git 2.23)
git checkout branch-name # old syntax

git checkout can be a bit confusing because it can work on the file and branch level. As of Git 2.23, we now have git restore (checkout file) and git switch (checkout branch), which would be my suggestion if you're just starting out to avoid checkout confusion.

I want to go back to the branch I was on



git switch -

📝 Modifications

I dug myself into a rabbit hole, let's start over



git reset --hard HEAD

This will reset your local directory to match the latest commit and discard unstaged changes

I want to reset a file back to how it was



git restore <filename>     # new syntax (as of Git 2.23)
git checkout -- <filename> # old syntax

I want to undo the last commit and rewrite history



git reset --hard HEAD~1

I want to rewind back n commits



git reset --hard HEAD~n        # n is the last n commits
git reset --hard <commit-sha>  # or to a specific commit

There is an important distinction between soft, mixed, and hard resets. Basically:

--soft: Uncommit changes but leave those changes staged
--mixed (the default): Uncommit and unstage changes, but changes are left in the working directory
--hard: Uncommit, unstage, and delete changes

I've rewritten history and now want to push those changes to the remote repository



git push -f

This is necessary anytime your local and remote repository diverge.

WARNING: Force pushing should be done with great care. In general, on shared branches you should avoid doing any force pushes. Limit force pushing to your own branches, before opening a pull request, so that you don't inadvertently mess up your teammates' git history.

I want to add a few more changes to the last commit



git commit --amend

I want to rewrite a bunch of commits locally



git rebase -i <commit hash> # where the commit hash is the one *before* all the changes you want to make

This will open up an interactive prompt where you can select which commits to keep, squash, or delete. You can also change commit messages here. This is very useful when cleaning up typo or linting commits, for example.

I found rebasing to be one of the more confusing topics when learning Git in depth. See the section on rebasing for more.

This rebase is a mess, let's scrap it



git rebase --abort

You can do this mid rebase. I often find that a rebase is way more trouble than it's worth, especially when rebasing two branches with a lot of similar changes. Until the rebase is complete, you can always abort it.

I want to bring in a commit from a different branch



# From the branch you want to bring the commit *into*
git cherry-pick <commit-sha>

I want to bring in a specific file from a different branch



git checkout <branch-name> <file-name>

I want to stop tracking a file in version control



git rm --cached <file-name>

I need to switch branches but my current state is broken



git stash # saves your changes to the top of the stash stack
git stash save "message to go along with changes"
git stash -u # stash untracked files as well

I want to see what's in my stash



git stash list

I want to bring back something in my stash



git stash pop # "pops" the most recent item added to the stash stack
git stash apply stash@{stash_index} # apply a given item in the stash (from git stash list)

I want to undo a commit without rewriting history



git revert HEAD # undo the last commit
git revert <commit hash> # for a specific commit

This will replay the inverse of the commit specified as a new commit, thereby undoing your changes without undoing history. This is a much safer way to undo a commit on shared branches, where rewriting history has much bigger consequences.

I want to find which commit caused a bug



git bisect start
git bisect bad           # Current version is bad
git bisect good v1.1     # v1.1 is known to be good

git help bisect          # For more

This one is a bit tricky so see the documentation for more.

🧹 Cleanup

Oh my god how do I have so many branches?



git branch --no-color --merged | command grep -vE "^(\+|\*|\s*(master|develop|dev)\s*$)" | command xargs -n 1 git branch -d

This will delete all merged branches that you have locally except for master, developer or dev. If you have different names for your main and dev branches, you can change the grep regex accordingly.

This is a long command to remember, however you can set it to an alias like so:



alias gbda='git branch --no-color --merged | command grep -vE "^(\+|\*|\s*(master|develop|dev)\s*$)" | command xargs -n 1 git branch -d'

If you use Oh My Zosh this is already done for you. See the section on aliases for more.

Let's garbage collect old branches/detached commits



git fetch --all --prune

This is also a really useful command if you've setup your remote repository to delete branches on merge.

⌨️ Aliases

Git commands can be long and really hard to remember. We don't want to type them out each time or spend days memorizing them, so I strongly recommend you make git aliases for them.

Better yet, install a tool like Oh My Zosh for Z shell (Zsh) and you will get a bunch of the most commonly used git commands as aliases by default + tab completion for these. I'm lazy about configuring my shell exactly how I want it so I love open source tools like Oh My Zosh that do this for me. Not to mention it comes with a sweet looking shell.

Some of my favorites I use almost every day:



gst - git status
gc  - git commit
gaa - git add --all
gco - git checkout
gp  - git push
gl  - git pull
gcb - git checkout -b
gm  - git merge
grb - git rebase
gpsup - git push --set-upstream origin $(current_branch)
gbda  - git branch --no-color --merged | command grep -vE "^(\+|\*|\s*(master|develop|dev)\s*$)" | command xargs -n 1 git branch -d
gfa - git fetch --all --prune

If you forget what these aliases or any others you have set yourself stand for, you can run simply run:



alias

Or to search for a given alias:



alias grep <alias-name>

Other Git Tricks

Ignoring Files

Many files do not belong in version control. You should utilize your global gitignore for this. Examples of things that do not belong in version control are node_modules directories, .vscode or other IDE files, and Python virtual environments.

For any sensitive information, you can use environment files and add these to your local .gitignore at the root of your project.

Special Files

You may need to mark certain files as binary files so that git knows to ignore them and doesn't produce lengthy diffs. Git has a .gitattributes file for just this purpose. In a Javascript project, you may want to add your yarn-lock.json or package-lock.json so that Git doesn't try to diff them every time you make a change.



# .gitattributes
package-lock.json binary

Git Workflows

Rebase vs Merge

Your team may choose to adopt either a rebase or merge workflow. There are pros and cons to both, and I've seen both be used effectively. For the most part, unless you really know what you're doing, you should probably opt for a merge workflow.

You can still use rebase effectively even when you're primarily using merge to bring in your changes into production. The most common situation that would call for this, is if you're working on a feature while another developer pulls in a feature into master. You could certainly use git merge to bring those changes in, but now you have an extra commit for the simple change your teammate made. What you really want is to replay your commits on top of the new master branch.



git rebase master

This should give you a much cleaner commit history now.

To explain the difference in depth would take a whole article (blog post pending), so I suggest you check out the Atlassian docs on the difference instead.

Remote Repository Settings

I am most familiar with Github and Gitlab, however these settings should be supported by most other remote repository managers.

1. Delete branches on merge

Once things are merged, you should not care about the branch anymore since the history should be reflected on your master/dev branch. This significantly cleans up the number of branches you have to manage. It also makes git fetch --all --prune much more effective in keeping your local repository clean.

2. Prevent pushes directly to master

Without this, it's a very understandable mistake to accidentally forget you're on master and do a git push, potentially braking your production build. Not good.

3. Require at least one approval before merging

Depending on the size of your team, you may want to require even more than one approval before merging. The bare minimum should be one though, even if you're on a team of 2 people. You don't have to spend hours nit picking every single line, but in general your code should have two sets of eyes on it. Feedback is key to learning and personal growth.

4. Require passing CI tests to merge

Broken changes should not be merged into production. Reviewers will not be able to catch broken changes 100% of the time, so automate these checks instead. Enough said.

Pull Requests

Keep pull requests small and concise, no more than a couple hundred lines ideally. Small and frequent pull requests will make the review process faster, lead to more bug-free code, and make your teammates' life easier. It will also lead to increased productivity and more shared learning. Make a commitment with your team to spend a certain amount of time reviewing open pull requests, every day.

We all love reviewing these:

If you're working on a feature that will be in a broken state for a while, use feature flags to disable it in production. This will prevent your feature branch from diverging too much from your dev/master branch and allow you to do more frequent, small pull requests. The longer you go without merging code in, the harder it will be to do so later.

Finally, include a detailed description in your pull request, with images and/or gifs if necessary. If you use a tool like Jira to manage tickets, include the ticket number the pull request addresses. The more descriptive and visual you make your pull request, the more likely your teammates will want to review it and not drag their feet.

Branch Naming

Your team may want to come up with branch naming conventions for easier navigation. I like to start each branch with the first letter of your first name + last name, followed by a forward slash, and the branch description separated by hyphens.

This may seem insignificant but with tab completion and tools like grep, this can really facilitate finding and making sense of all the branches you may have.

For example, when I create a new branch:



git checkout -b gabud/implement-important-feature

A week later when I forget what I called my branch, I can start typing git checkout gabud, press TAB, and my Z shell then shows me all of my local branches to choose from without seeing any of my teammates' branches.

Commit Messages

Language is important. In general I find it best to not commit things in broken states, and each commit should have a succinct message that explains what the change should do. Following the official Git recommendation, I find it best to use the present, imperative sense for commit messages. Think of each commit message as being a command to the computer/git, which you can add to the end of this sentence:

If this commit were applied, it would...

An example of a good commit message in the present, imperative sense would then be:



git commit -m "Add name field to checkout form"

Which now reads: "If this commit were applied, it would add name field to checkout form". Nice and clear.

Final Thoughts

This is by no means all there is to learn about Git. I suggest you checkout the official documentation and git help for more. Don't be afraid to ask for help with Git from your teammates, you'd be surprised to learn that most of your teammates have many of the same questions.

What about you? Which Git commands or concepts have been the most instrumental in your workflow?

Prettier and the Beauty of Opinionated Code Formatters

Gabriel Abud — Wed, 24 Jun 2020 18:22:36 +0000

I love Prettier.

It's probably the single tool that has had the biggest effect on my productivity as a programmer (after Git, maybe).

For those of you that don't know, Prettier is an opinionated code formatter for Javascript/Typescript, HTML, JSX, and more. It is lightweight, requires next to no configuration, and automatically formats code for you. Gone are the days where you spend half of your day arguing with co-workers how to nest HTML, what the correct line length is, or whether strings should have single vs double quotes.

This is my Prettier configuration:



module.exports = {
  printWidth: 80,
  singleQuote: true,
  trailingComma: 'es5',
};

Isn't that simple? My settings are a bit opinionated so you can get by with even less!

I use VSCode, so I setup all my projects to format on save. I strongly recommend you do the same if you haven't already. Any modern IDE should have this capability.

There is a strange pleasure in seeing your garbled JSX fit perfectly into place on save.

The Rise of the Opinionated Formatter

Opinionated formatters are great because they eliminate the ongoing flame war nerds and programmers love to have about code formatting. While it's good that we care this much about the quality of our code, overall this is a huge waste of time. Since we started using Prettier on my team, pull request reviews are much more effective and we're no longer having stylistic discussions every. single. week.

We need to start valuing our time more and realize these discussions are a waste of time. While you may be right that God's intention for strings is to use double quotes, it really doesn't matter. The benefit of using them is already outweighed by the time you've wasted discussing it. Leave that discussion and mental baggage to the Prettier team, I promise they've already given plenty of thought to what the best defaults are.

Prettier is not the only code formatter out there. For Python, I use and love Black. Check out this Github repo for alternatives in other languages.

How to Enforce Prettier

There are many ways to enforce Prettier on your team besides having everyone set it up in their IDE. If you are purely a frontend team, you can use husky and lint-staged. If you are working on a full-stack or multi-language team, you can use the pre-commit Python package to run Prettier as a pre-commit hook. That means that any staged files will be Prettified when you commit using git.

Do we need Additional Linting?

In the past, I used ESLint heavily in my frontend projects. Especially with Airbnb's configuration, which tends to be very strict.

The problem with ESLint is that it's too configurable. It doesn't solve the stylistic flame war. It just ends up adding options, which we really need less of. As web developers we already suffer from decision fatigue, having to choose between frameworks, 3rd party libraries, state management, different styling options, REST vs GraphQL, build tools, etc.

An example of ESLint decision fatigue from a real project:



rules: {
  'react/no-unescaped-entities': 'off',
  'no-restricted-syntax': 'off',
  'no-continue': 'off',
  'no-underscore-dangle': 'off',
  'operator-linebreak': 'off',
  'implicit-arrow-linebreak': 'off',
  'react/destructuring-assignment': 'off',
  'react/no-multi-comp': 'off',
  'jsx-a11y/click-events-have-key-events': 'off',
  'jsx-a11y/no-static-element-interactions': 'off',
  'react/jsx-one-expression-per-line': 'off',
  'lines-between-class-members': ['error', 'always', { exceptAfterSingleLine: true}],
  'react/no-array-index-key': 'off',
}

ESLint rules are often arbitrarily turned on/off based on people's opinion. Either that or you need a whole README devoted to why certain rules are enforced and others are not. Every time you bring on a new developer you are then opening up these decisions to question. This is too much unnecessary mental drain on everyone.

Most of what ESLint enforces is not automatically fixable, unlike Prettier. This makes it clunky to run in CI or as a pre-commit hook. It requires a developer to go and try to fix it themselves, creating additional manual work. Fixing linting issues is not the fun part of coding.

I still think ESLint has some uses, however with Prettier I think those are pretty minimal. My configuration now basically just extends eslint-config-react-app (used by create-react-app) and eslint-prettier (to avoid conflicting Prettier and ESLint rules), and I don't touch any extra rules. I could see myself getting rid of it eventually as Prettier matures.

My .eslintrc.js now looks like this:



module.exports = {
  extends: [
    'react-app',
    'plugin:prettier/recommended',
  ],
}

Simplicity is underrated.

What about you?

Have you found Prettier or opinionated formatters to be as useful for yourself and your team? Do you think ESLint (or additional linting) is necessary and conducive to productivity?

Effective Learning and Feedback Loops

Gabriel Abud — Wed, 10 Jun 2020 17:52:59 +0000

I follow a lot of tech people on Twitter that like to give advice to prospective developers on how to get started. Most of it looks like this:

"Start by learning HTML, CSS, vanilla JS, and how HTTP works"

"Get into data science by learning Python fundamentals, statistics, and higher-level calculus"

"Start with jQuery before learning React"

I used to think like this too, in fact half of my bookshelf right now consists of old discarded programming language books that I hardly opened. Like in any skilled profession, there is a lot to learn and not much guidance on where to start.

What is Effective Learning?

We've all heard the phrase, "it takes 10,000 hours to become an expert at something". Some people with natural talent will become experts in much less time, however there is no getting around the matter that becoming good at anything takes a significant amount of time. It's why medical school takes 10 years (or less if you live outside of the US). It's why athletes like Michael Phelps at their peak would train ~6 hours a day, 5-6 days a week. It's why Mozart never stopped practicing the piano.

I think the focus of what to learn is missing the point. It's not what you should start learning, it's what makes you the most excited to continue. If it takes such a significant amount of time to get really good at something, it doesn't really matter what you start with as long as it motivates you. This means you need to create good feedback loops around your learning.

The Feedback Loop

One of the reasons Silicon Valley has become so successful is because they've embraced this notion of experimentation. Facebook's old motto was "move fast and break things". While this is a problematic motto for other reasons, there is no denying that Facebook has become very successful as a company, and I think this motto gives us a glimpse as to why. Quick experimentation leads to quick feedback, which leads to more experimentation, and so on. Examples of companies with quick iteration loops abound in Silicon Valley - Google, Uber, Tesla, Twitter, and Apple are always churning out new products and ideas.

This is also the concept around Agile programming. Quick iteration cycles lead to quick feedback, which in turn lead to quick products.

To learn anything well, you need to create short feedback loops between your practice and the result. This feedback loop motivates you to continue practicing and learning. If Michael Jordan had spent all of his teenage years shooting free throws without constantly playing with others, he would have given up in frustration long before joining the NBA.

Fundamentally this is a biochemical pathway in your brain that you have to wire. You perform an activity which causes some result, which creates a neurochemical response in your brain, which makes you look forward to doing that activity again. For Michael Jordan the response is scoring a basket. For musicians it's hearing beautiful music. For programmers it's creating intelligent software. It's also why social media is so addicting, but I digress.

Examples of Feedback Loops

Feedback can come in a lot of different ways. We are social creatures however, so the most effective form of feedback is from others.

Learning a New Language

A lot of the same concepts in programming also apply to learning a new language. Rather than starting by learning the gender tenses, verb conjugations, and past/present/future forms of verbs, start with something much simpler that gives you instant feedback.

The reason that people who fully immerse themselves in a language learn an order of magnitude faster is because their feedback loops are much shorter. As someone who is bilingual and has successfully (and not so successfully) learned other languages, my advice would be:

Learn some of the basic question words (how, where, why, what, when, who). Questions are some of the easiest ways to start a conversation with strangers and conversations give you instant feedback. If you can learn how to order at a restaurant, ask where the bathroom is, and ask for directions, then you can basically visit any country on your own.
Go to meetups where you can talk to others who are learning without feeling embarrassed. Talking to other people is one of the best ways to get feedback but you won't do it if you're ashamed to make mistakes.
Watch Netflix shows, listen to music in that language, or watch Youtube tutorials in that language.
If within your financial means, take a vacation to a country that speaks that language and use the few words you've learned to start conversations.

Learning to Program

In programming, feedback may come from seeing your program do something cool. It doesn't have to be feedback from others, it can be from your computer. Although as social beings feedback from others will always be more motivating.

When you make a simple Hello World application, seeing the output in your terminal is feedback. When you make a change to a React application and see your website instantly reload, that is feedback. When you get a job at a company because you learned and mastered the most in demand technologies - that is feedback.

So what is the path of least resistance to getting some of this feedback? Build things. It doesn't matter what, don't suffer from analysis paralysis. If you like following tutorials on building TODO apps, do that. If you like thinking about the stock market, build an app that helps you track it. If you like playing chess, build a chess app. Build whatever motivates you and will give you instant feedback.

Another great way to get quick feedback is to write tests. Tests serve a myriad of purposes (see Why do we Test?), but one of the biggest benefits is that you get near instant feedback in the form of passing or failing tests. This significantly shortens your feedback loop and leads to quicker development, and therefore quicker learning.

As you become more advanced, you will be able to build more interesting applications and still maintain this quick feedback loop. But you don't need to start with that, you're not going to make something used by thousands of people on the first try. If you hold yourself to such high standards you will also struggle, not receive any feedback, and ultimately give up.

My Advice

Don't code in a black box. If you write code professionally already, you can institute better practices to form shorter feedback loops. Write lots of quick, easy to maintain tests. Open short, frequent pull requests and be sure to institute good code review practices. If you work on a team, every pull request should be reviewed by at least one other developer. If you don't code professionally, make pull requests to open source projects. It's fine if these are corrections to documentation or better comments on code to start - that is still feedback.

And host all your projects on Github with good READMEs for others. You'll be surprised how often a project that you think is useless will get interest from others.

What to Learn

Rather than learning 10 foundational things before ever getting started, my advice is to learn in such a way that minimizes your feedback loop. In software, here are some ideas of the path of least resistance that minimize your feedback loop.

Learn React to build a simple application. It can be anything. Host it on Github and share it with others with a one-click deploy service like Netlify or AWS Amplify.
Learn Data Science by learning Pandas and applying it to automating mundane spreadsheet tasks at work.
Learn Python by building a functioning website using Django and Django plugins for authentication. Deploy this using Heroku's free tier and a Django config.

The point is not the languages (you can swap out React for Vue or Python for Rust if that's what interests you), the point is that these are some of the easiest ways to build appealing applications. React, Django, and Python are also among the most employable skills in web development right now. Here's the latest Stackoverflow developer survey if you don't believe me. Receiving a job offer is a very strong form of feedback. You could certainly learn the fundamentals first and build an application with pure HTML and CSS, hosted on your own server on Digital Ocean. You will certainly learn a lot, but the feedback you get from building that (an ugly website that looks like it's from the 90's) will not encourage you to continue learning. I also haven't yet seen a job posting that only asks for ninja level HTML/CSS skills.

Whether it's from other people, from seeing your computer do something that you told it to, or from making some mundane task at work easier, getting feedback is key. Once you gain a certain level of proficiency, your feedback loop will be much shorter and your learning will grow exponentially. The key is to get started!

Why do we Test?

Gabriel Abud — Sat, 06 Jun 2020 19:21:27 +0000

Why do we test?

As I write tests way past the work day and fight with Jest, mocks, and React components, I find myself ruminating over this question.

What is the point? Is it to meet some arbitrary metric (90% or 100% test coverage) placed on by managers or senior engineers? Is it for the user, so they have a better user experience and less bugs? Is it for yourself, to feed some narcissistic tendencies and grandiose ideas that you're the best programmer in the world?

Am I the only one that gets a dopamine rush from these little green dots?

Ultimately the most important metric for a business is how much money is saved by writing tests. But how many of us, as engineers, really have a good understanding of this?

Developers don't care about this. Not only that, they are so far removed from the money making aspect of a business that it's impossible for them to have a good understanding of this. A project manager may have a better understanding, but they're not the ones writing the tests. Nor will they have a good enough understanding of a codebase to be able to tell a developer what to test. The people in a business that understand the true cost of things don't understand the software and how it's written. This is one of the conundrums of labor specialization. We become experts in our domain but in doing so miss the bigger picture.

So as narrow-minded engineers, we need a better reason than "to save money". Something that we can understand and relate to, while not being too constrictive.

We should test to save developer time.

Hear me out. Developer time is something we have a good understanding of (some of you may scoff at this, I know). Developers understand what features are likely to break and how long things will take to implement. Your team's time is not free, so in most cases it is pretty strongly correlated with saving your company money anyway. Testing, in essence, is an investment in your team's future development experience. Saving developer time is ultimately the principle around DRY programming, extreme programming (XP), and SLURP programming. Okay I made that last one up, there are too many stupid programming acronyms.

Our own time also holds up better as a metric in different situations and company types. Facebook and Google will have drastically different use cases for tests than a small startup getting off the ground. A breaking feature in production for www.facebook.com is likely to set off a wave of alarm bells that results in a lot of work for developers (aka $$$). End to end tests for a product that is used by millions of people is therefore much more crucial than one used internally by a handful of employees.

But how does prioritizing developer time help us to actually write better tests?

Let's go over the different kind of tests and why this way of thinking can help you:

1. Unit Tests

These should be the quickest to write and should give us assurance that the individual pieces of our system work as we intended. Ultimately these should run quickly, test your own code (not 3rd party libraries), and serve as documentation for future developers. They save developer time by facilitating refactoring and helping onboard new team members. When an integration test inevitably fails, it is likely that a unit test can tell you exactly where and why it failed. Writing around a test interface also promotes good code practices, like using pure functions and dependency injection.

Unit tests should be quick enough so that you can use tests to drive development (see TDD).

While you can and should have unit tests for both the frontend and backend, I believe they have most value in your backend business logic.

2. Integration Tests

These test how things interact within your system. Integration tests save us time by preventing common use cases from breaking as we refactor. I tend to think of these as more frontend-leaning tests, although they can also be on the backend. They are also much quicker than manually clicking through multi-step forms, assuming they are well written. Integration tests may still use mocks and give us more assurance (per unit of time spent writing them) than unit tests that our system works as the user expects.

3. End to end tests

These test how your system interacts as a whole. A true end to end test does not have any mocks and is running through your software in a way that real users might use it. These have the most value but are also the most complicated to run and take the most time. End to end tests save developer time by preventing after hours calls about how billing is down for the entire company. Maybe your TLS certificate expired or your Single Sign-On provider is misconfigured. Dammit John I told you not to touch those settings.

Are there any bad tests?

This is not to say that all tests are good. You have to keep an eye out for bad tests too, the ones that take up developer time.

Examples of this are tightly coupled tests or ones that care too much about the implementation details. You should constantly be asking yourself, what am I trying to achieve with this test? Am I testing new business logic, which is prone to human error and refactors, or am I testing how an existing library works? You don't need to test React, Flask, or Django, there are already thousands of developers who have done that job for you.

// Detect dark theme var iframe = document.getElementById('tweet-762283869458620416-542'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=762283869458620416&theme=dark" }
"Because Dan Abramov said so" is not a good testing philosophy

If a test is going to take you a couple of days to write, is already mostly covered by simpler tests, and does not cover realistic use cases, it's a good sign that it may not be necessary.

Likewise, a test that takes several seconds to run because you didn't mock some expensive 3rd party function is going to cost time for every developer. It may make sense for you as a sole developer to write this test, but now multiply the seconds that test takes x the number of times each developer runs the test suite in a day x the number of developers at your company. It quickly adds up.

If your tests are written in such a way that every little change to the codebase requires refactoring a test (or more than one) needlessly, it is definitely not a time saver. This is my problem with Snapshot testing. These kind of tests make us feel "safe" but they are not actually saving any amount of time or making our code any less error prone.

// Detect dark theme var iframe = document.getElementById('tweet-807626710350839808-144'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=807626710350839808&theme=dark" }

I think what Guillermo is getting at is that tests can get messy and a few well thought out ones will give you most of your results. Tests, like software and many other fields tend to follow the 80/20 principle. 20% of tests will end up giving you 80% of the results. Don't just mindlessly write tests for the sake of writing them, to reach some arbitrary coverage number, or because you saw an image of pyramid that tells you how important unit tests are.

Take these diagrams with a grain of salt

Instead of asking fellow engineers to always write tests, make sure they understand why they're writing them. 100% code coverage does not literally mean it is 100% safe, you could have a bad test that will never occur in reality and is considered to have 100% coverage. From personal experience, not enough time is spent talking about what good tests look like.

So besides awareness, how do we use this concept to better our development? Through consistent reviews and reflection on the tests we write. Is a piece of code creating a disproportionate amount of maintenance work for you? Maybe it's time to refactor and write better tests for it.

Rather than focusing on unhelpful metrics or rigid rules, testing should be treated as a continual learning/betterment process. Tests should have the necessary attention paid to them and not be treated as second class citizens. Everyone should spend time refactoring and reviewing them, discarding ones that are not testing essential pieces of your software, and improving slow ones. Scrap your next stand-up and instead have a test-up, it'll be a much more productive use of developer time.