Forem: Brett Fisher

My 2024 Web App Tech Stack

Brett Fisher — Sat, 13 Jan 2024 23:42:41 +0000

With a new year comes a renewed sense of motivation to build side projects that I probably won't finish, but I'm still going to try anyways! I tried a lot of different technologies in 2023, and this is my list for the ones that I want to either continue or start using in 2024.

TLDR

Frontend Framework - React
Component Library - shadcn/ui
State Management - Zustand
Authentication/Data storage - Firebase
Data Fetching - TanStack Query
SSR - NextJS
Tooling - Vite
Bundling for quick projects - esbuild
Hosting - Vercel

Frontend Framework - React

I've been using React for years now and don't plan on stopping any time soon. It's not the easiest framework to learn, but I know how to use it and can build frontend web apps very quickly with it. Plus, it's got a huge and supportive community and as far as I can tell, it's here to stay.

Runner Up - Svelte! I first heard about Svelte around 4 or 5 years ago, and in 2023 it seems like I started hearing about it everywhere. People have talked about its nice learning curve and simplicity. With nearly 75K stars on GitHub at the time of this writing, it's definitely a technology I'd like to experiment with.

Component Library - shadcn/ui

I've been looking for a component library like shadcn for a long, long time. It's built on top of Tailwind and provides a complete set of clean, easy-to-use frontend components. I absolutely love the way it looks and how easy it is to customize the base components and even create your own variants.

State Management - Zustand

Someone at work told me about Zustand the other day, and it absolutely blew my mind. I was amazed at how easy it was to create a reactive global state with basically no configuration. I was able to quickly solve a problem at work with some legacy React class components using Zustand that would have been a lot more difficult without it.

For a while, I hadn't even been using a state management library in my side projects - React's built-in createContext had been doing the job just fine. But Zustand requires such little setup work and seems so flexible that I'm excited to try it out more.

Authentication/Data storage - Firebase

I've been using Firebase for my side projects since college and still love it. It's so easy to set up authentication and databases with Cloud Firestore that I don't think I'll be moving away from it any time soon. I love getting an app working end-to-end as quickly as possible and feel like I'm able to do that with Firebase.

I've been hearing a lot about Supabase too but know very little about it. For those of you who have worked with Supabase and Firebase, let me know in the comments if you prefer one over the other and why!

Data Fetching - TanStack Query

I absolutely LOVE this library. It makes everything about data fetching so clean and easy, including state management and caching. It has so many options to configure, but it feels like there are really only a few concepts you need to know to get it working for most use cases.

I introduced it to some web projects I built when I worked for Amazon and everyone on my team loved it. I still use it at the startup I work for and it has prevented so many potential headaches when it comes to managing the data we fetch from our backend.

SSR - NextJS

For projects that will be delivering a lot of static content, I've found NextJS to be easy to set up and use. My personal site, microthoughts.dev , is a Next JS project and it's been a delight to use.

Personally, I didn't love it for really dynamic apps that require a lot of user interaction because then it felt like I had to put a lot of "use client" lines in my files which kind of seemed to defeat the purpose of the framework. I'm definitely not an expert on Next though, so please share your thoughts on this in the comments!

Tooling - Vite

For more dynamic sites, I've been using Vite to scaffold my projects. It builds super fast and everything just seems to work out of the box with Typescript, React and JSX.

Bundling for quick projects - esbuild

I've used esbuild to build a few Chrome extensions for work and love how easy it is to build React code just with the CLI and a few flags.

Hosting - Vercel

I host a few personal sites on Vercel and have loved it from day one. It's so easy to connect to a GitHub repository and have it automatically deploy the site when you push new changes. I've also found it easy to connect to custom domain names that I purchase which is a huge plus (maybe it's just me, but recently I've had a lot of issues with this on Netlify).

Conclusion

There are so many technologies out there for building web apps, and each one has its unique set of advantages and disadvantages.

The stack you choose in 2024 could be totally different than mine, and that's fine! I think what's important is to choose technologies that enable you to quickly build apps in a way such that you know it will be scalable and maintainable given your experience, knowledge, and the people you work with.

Which technologies are you going to continue using this year? Which new ones are you excited to try? Let me know in the comments!

The Easiest Way to Use Snackbars in Vue

Brett Fisher — Fri, 16 Oct 2020 05:18:12 +0000

TLDR; Check out the code on Code Sandbox to learn how to make a snackbar that can be opened from any Vue component in your app!

In one of my Vue projects, I display a simple popup ("snackbar") explaining any errors that get thrown. I started to find myself adding a snackbar to every component that could possibly throw an error (such as from a network call). On top of that, I had to add data members controlling the visibility of the snackbar and the message it displayed.

This article explains how to create a single snackbar that you can then open from any component with any message you want. This eliminates any duplicate snackbar code across components. Let's get started!

Step 1: Create the event bus

To make a snackbar that can be opened across the entire app, we'll use a pattern called an event bus. An event bus is a global object that can receive and respond to events. Inside our Vue components, we can add a snackbar event to the bus and have it respond by opening a snackbar.

Lucky for us, we can just use a new Vue object to function as an event bus. It provides the handy $emit and $on functions to emit and respond to events.

// EventBus/index.js

import Vue from 'vue';

export const ACTIONS = {
  SNACKBAR: 'snackbar',
};

const EventBus = new Vue();

export default EventBus;

That's it! For convenience, I also added an ACTIONS object that makes it easy to constrain the actions that can be emitted on the bus.

Step 2: Create a function to open the snackbar

I created a folder called globalActions with an index.js file to contain functions that could be used in any component across my app. Let's put a function in there that will add the snackbar event to the event bus:

// globalActions/index.js

import EventBus, { ACTIONS } from '../EventBus/index';

export const showSnackbar = message => {
  EventBus.$emit(ACTIONS.SNACKBAR, message);
};

Now let's create a component that uses this function to display a snackbar.

Step 3: Use the function in a component

I created a custom component called MyComponent to use this snackbar function:

<!-- components/MyComponent.vue -->
<template>
  <v-btn @click="openSnackbar">Show snackbar</v-btn>
</template>

<script>
  import { showSnackbar } from '../globalActions';
  export default {
    methods: {
      openSnackbar: () => {
        showSnackbar('Hello from snackbar!');
      },
    },
  };
</script>

This imports the showSnackbar function and calls it with the message "Hello from snackbar!" when a button is pressed. Right now we won't see a snackbar because all that will happen is an event gets emitted on the event bus. Now let's tell the event bus that when it sees the ACTIONS.SNACKBAR event, it should show a snackbar. We'll add this to our App.vue file so that any component will be able to display a snackbar.

Step 4: Add a snackbar to App.vue

I'm using Vuetify in my project, so it's really easy to just pop in Vuetify's snackbar. However, you can easily accomplish the same goal with any other library or even your own custom snackbar. I just have one snackbar component in App.vue and some data members to control its visibility and the message it displays:

<!-- App.vue -->
<template>
  <div id="app">
    <my-component />
    <v-snackbar v-model="snackbar" timeout="2500"
      >{{ snackbarMessage }}</v-snackbar
    >
  </div>
</template>

<script>
  import EventBus, { ACTIONS } from './EventBus/index';
  import MyComponent from './components/MyComponent.vue';

  export default {
    name: 'App',
    components: {
      MyComponent,
    },
    data: () => ({
      snackbar: false,
      snackbarMessage: '',
    }),
    mounted() {
      EventBus.$on(ACTIONS.SNACKBAR, message => {
        this.snackbarMessage = message;
        this.snackbar = true;
      });
    },
  };
</script>

When the component is mounted, we use the $on function on our event bus to listen to the ACTIONS.SNACKBAR. It updates the snackbarMessage member and sets snackbar to true. Now whenever we call the showSnackbar function from a component, a snackbar will pop up with the passed-in message!

Check out the full code on Code Sandbox.

Conclusion

An event bus provides a super easy way to respond to events that could happen at any place in our app. You can also customize the snackbar as much as you want since the message it displays doesn't have to be the only argument you pass to the bus. For example, you could pass in options for the snackbar color, the duration it stays open, or a callback function to perform when the snackbar is clicked.

That's it for today, happy snackbar-ing!

How to Install a Specific Version of an NPM Package

Brett Fisher — Tue, 22 Sep 2020 03:21:51 +0000

The other day I got a warning in a Vue project I've been working on for a while. It was complaining about me using an unsupported version of TypeScript. I decided to download a supported version, but how was I supposed to do that?

First I uninstalled my existing version of TypeScript:

$ yarn remove typescript

Then after some quick Googling, I found this for downloading a specific NPM package version:

$ yarn add typescript@3.5.3

You can do the same thing with NPM:

$ npm install typescript@3.5.3

And that's it! You can do this for any NPM package:

$ yarn add some-package@version
// or
$ npm install some-package@version

The Easiest Way to Use Query Parameters in React

Brett Fisher — Mon, 21 Sep 2020 03:32:37 +0000

TLDR; - I wrote a hook that makes it easy to manage URL query parameters with React. View it on Github or Code Sandbox.

There have been multiple times I've been working on projects and have needed to get and set query parameters in the URL. I tried watching the URL with useEffect, but that led to way too many bugs and messy code. Eventually, I decided to create a simple hook that would take away all the pain of getting and setting query parameters!

I put all this code in a file in my projects and just import it whenever I need to use it. In fact, you can just copy and paste the following code block to immediately simplify query parameter management in your own project!

// useQueryParam.ts

import { useState } from 'react';

const getQuery = () => {
  if (typeof window !== 'undefined') {
    return new URLSearchParams(window.location.search);
  }
  return new URLSearchParams();
};

const getQueryStringVal = (key: string): string | null => {
  return getQuery().get(key);
};

const useQueryParam = (
  key: string,
  defaultVal: string
): [string, (val: string) => void] => {
  const [query, setQuery] = useState(getQueryStringVal(key) || defaultVal);

  const updateUrl = (newVal: string) => {
    setQuery(newVal);

    const query = getQuery();

    if (newVal.trim() !== '') {
      query.set(key, newVal);
    } else {
      query.delete(key);
    }

    // This check is necessary if using the hook with Gatsby
    if (typeof window !== 'undefined') {
      const { protocol, pathname, host } = window.location;
      const newUrl = `${protocol}//${host}${pathname}?${query.toString()}`;
      window.history.pushState({}, '', newUrl);
    }
  };

  return [query, updateUrl];
};

export default useQueryParam;

Using it in components is easy (Code Sandbox):

import React from 'react';
import useQueryParam from './useQueryParam';

const App = () => {
  const [search, setSearch] = useQueryParam('search', '');

  return (
    <input
      value={search}
      onChange={({ target: { value } }) => setSearch(value)}
    />
  );
};

That's it! useQueryParam takes two arguments - the first is the name of the parameter, and the second is the default value to be assigned in case the parameter is not present in the URL. If you were just looking for an easy way to manage query parameters in React, you can stop reading. Just copy the code block above and you're good to go. If you'd like to know a little more about how it works, then keep reading.

How it Works

Let's look at the first two functions:

const getQuery = () => {
  if (typeof window !== 'undefined') {
    return new URLSearchParams(window.location.search);
  }
  return new URLSearchParams();
};

const getQueryStringVal = (key: string): string | null => {
  return getQuery().get(key);
};

getQuery just returns an instance of URLSearchParams, which just contains a mapping of URL query names to their respective values. Note that for use with SSRs like Gatsby, you must check for the existence of window.

getQueryStringVal just gets the value of a specific parameter in the URL. We can use these two functions to craft the actual useQueryParam hook. It's got two parts, let's examine those. Here's the first part at the beginning of the hook:

const [query, setQuery] = useState(getQueryStringVal(key) || defaultVal);

We use our getQueryStringVal to get the value of the query parameter, and initialize query to defaultVal in case key doesn't exist in the URL. This will store the value of the parameter, now we just need a function to update it:

const updateUrl = (newVal: string) => {
  setQuery(newVal);

  const query = getQuery(); // Get the URLSearchParams object

  // Update URLSearchParams object
  if (newVal.trim() !== '') {
    query.set(key, newVal);
  } else {
    query.delete(key);
  }

  // This check is necessary if using the hook with Gatsby
  if (typeof window !== 'undefined') {
    // Update URL
    const { protocol, pathname, host } = window.location;
    const newUrl = `${protocol}//${host}${pathname}?${query.toString()}`;
    window.history.pushState({}, '', newUrl);
  }
};

This is the function we return from the hook for updating the URL. We first update the variable we created with useState. We then use the set method on URLSearchParams to update the mapping. Finally, we use the pushState function on window.history to update the URL without the page refreshing.

That's it! This hook may not necessarily address every possible edge case that could come up when working with query parameters. However, it's worked great for me so far. Feel free to use it in your own projects!

How to Create a Monorepo with Yarn Workspaces

Brett Fisher — Sun, 06 Sep 2020 02:46:32 +0000

TLDR; If you'd prefer to just see the working code, view the whole project here: https://github.com/bandrewfisher/monorepo-tutorial

For the past couple of years, I've been working on a project for a professor at my university. It's a site that facilities research in ancient Assyrian trade. It's been a ton of fun and I've learned so much about web development in the process. For a while, I've maintained three separate Git repositories for the project - one for the Vue frontend, one of the TS Express backend, and a third one containing utility code shared between the other two repositories.

This was tricky to maintain, to say the least. The codebase is relatively small, so I figured it would be more maintainable to move everything to a single repository. In this post I'll explain how you can easily create a monorepo for JS projects with multiple packages.

Create a Project

Create a new directory and then initialize it with Yarn:

$ mkdir vue-express-monorepo
$ cd vue-express-monorepo
$ yarn init -y

Setup Yarn Workspaces

To create a monorepo, we will use Yarn workspaces. According to the docs, this "allows you to setup multiple packages in such a way that you only need to run yarn install once to install all of them in a single pass." If you are using npm, then there's a pretty good tool called Lerna that can help you accomplish the same goal. Yarn workspaces don't claim to replace Lerna, but for my purposes I've found that so far I've been able to use Yarn workspaces without Lerna.

We will create two packages and put them inside a directory called packages. Create a packages directory:

$ mkdir packages

We need to tell Yarn that the packages directory contains our packages. Edit your package.json file so that it looks like the following:

{
  "name": "vue-express-monorepo",
  "private": true,
  "workspaces": [
    "packages/*"
  ]
}

Now we're ready to create our packages.

Create Packages

Create a directory in the packages directory. Initialize it with Yarn and create an index.js file:

$ cd packages
$ mkdir package-a
$ cd package-a
$ yarn init -y
$ touch index.js

Now add this to your index.js file:

function packageAFunc() {
  console.log('Using a function from package A');
}

module.exports = packageAFunc;

Let's create another package and then use this function from package-a inside of it.

$ cd ..
$ mkdir package-b
$ cd package-b
$ yarn init -y
$ touch index.js

Add the following to your index.js file in package-b:

const packageAFunc = require('package-a');

packageAFunc();

Finally, you just need to run a yarn install in the root level of your project.

$ cd ../..
$ yarn install

Yarn will link package-a and package-b in a node_modules folder in the project root.

Try running the package-b file:

$ node packages/package-b/index.js

You should see "Using a function from package A" printed to the console!

Conclusion

Converting the site I've been building to use a monorepo has been incredibly helpful. This is a super simple example, but I used the same concepts from this post to create a monorepo with three separate frontend, backend, and utility packages. This has made sharing code throughout the project much easier. It's really nice that Yarn comes with this interesting feature that makes creating a monorepo so easy.

One of the main advantages I've noticed of this approach has been continuous deployment for the site. With everything living in one repository, it was easy to write a build script that built my Vue frontend and TS Express backend before deploying it all to AWS. I think this would have been a bit trickier if the site was still spread across multiple repositories.

I posted the link to my GitHub repo with the complete code, but here it is again for good measure: https://github.com/bandrewfisher/monorepo-tutorial

3 Things I Learned from my Internship at Amazon

Brett Fisher — Sun, 30 Aug 2020 04:50:24 +0000

Yesterday was the last day of my three-month-long internship with Amazon. Compared to the other two companies where I've interned, Amazon was by far my favorite company to work for. I got to work on a great team and learned a lot. Today I'll be talking about the three most important things I learned from Amazon (note that any views represented here are my own and do not necessarily represent those of Amazon).

1. Define your Culture

Even before I started the internship, Amazon began sending me emails asking me to become familiar with their leadership principles. The leadership principles are 14 points that define Amazon's culture and help them make decisions. For example, they talk about customer obsession, taking ownership, and thinking big, among others.

At first glance, these may just seem like cute ideas that would look great on some cheesy inspirational poster you would see in a fourth-grade classroom. However, I quickly learned that Amazon takes its leadership principles seriously. They are key to how the company operates on a day-to-day basis.

This made me realize the importance of defining your culture. Whether you're running a business or just want to improve yourself, solid principles to live by can change everything. For example, one of the principles I choose to live by is to be completely honest. Once I decided to be fully transparent and honest with others, I felt a lot more secure in my life. This isn't a blog about ethics, so I'll stop there. But I do think that firmly sticking to certain principles can help every aspect of a business or a person's life.

2. It is Possible to Enjoy your Job

I've loved coding ever since I started in high school. There's nothing like having an idea for a project and then bringing it to life with code. However, I started becoming concerned when I began working for actual companies during my first two internships. A lot of times I felt like my only job was to fix bugs. I got bored easily and the hours passed by slowly. I looked forward to my end dates. I wondered if I'd be able to find a full-time job that I enjoyed.

When I began working for Amazon, this changed. I was given an interesting project to work on. I stayed busy all day and never got bored. There were times I would get frustrated when things didn't work, but that was to be expected. I was mostly relieved that I had found a job I looked forward to each day.

I don't know if I'll return to Amazon full-time. It's a big decision and there's a lot to consider. But the fact that I liked my job is a huge plus. At the very least, it gives me hope that I can find a job I enjoy. Maybe you don't even want to be a coder, and that's fine. Whatever it is you want to do, I believe you can find a job you like.

3. Refactor Early, Refactor Often

I know that this point might sound like a bit of a cliché. But I believe that refactoring my code early and often was key to my success at Amazon. This didn't necessarily mean that the first time around my code was bad. It just meant that I found a better way to do things.

Most of the refactoring I did wasn't that big. Most of them involved changing the structure of my components so that they were more testable. This goes back to one of my previous blog posts about writing more testable code. It's a lot easier to refactor your code so that it's testable instead of writing code and then trying to figure out how to test it.

Nobody likes trying to implement huge refactors to an entire app. I think that performing small refactors along the way saved me from having to do this with my project. Had I tried to work around my old code instead of refactoring, I might not have been able to finish my project on time.

Conclusion

Overall, I had a great experience at Amazon. I learned a lot of valuable lessons that I believe I can carry with me throughout my life. Regardless of whether I return to Amazon as a full-time employee, I'm grateful I had the opportunity to intern there. Interestingly, some of the most important things I learned didn't have to do with programming at all. But that's what I love about software engineering - there will always be chances to learn new things.

Why I Decided to be a Software Engineer

Brett Fisher — Tue, 25 Aug 2020 03:44:16 +0000

As I enter my senior year of college studying computer science, I've had a lot of time to think about what kind of career I want. I've reflected a lot on my decision to become a software engineer. I've held various jobs doing web development for my school and completed internships with SimpleNexus, BlueHost, and Amazon. These have all provided me with great experience and only strengthened my desire to dedicate my career to software engineering. But it wasn't easy to decide to major in computer science. It was an even harder decision to stick with it. Today I'll write about the challenges I faced while trying to decide on my career.

High School

I definitely didn't always want to be a software engineer! In high school, I had a wide variety of interests (and still do). At one point I was certain I wanted to study psychology, and a couple years later decided I wanted to study math. Math was the plan for probably a year or so, and that's when I discovered programming. My dad did a lot of Perl coding at his job. Out of pure curiosity, I decided to pick up one of his books on Perl and see what I could learn. After going through the book, I started learning Java through YouTube tutorials before following the Khan Academy courses on web development.

I was hooked! It was so cool to me that I could envision some cool functionality in my mind and translate it into working code. I had decided that this would be the career for me and enrolled in college to study computer science.

Facing Challenges

I signed up for a couple of intro CS classes at my university, excited to learn even more. This is when things got tough! One of the intro classes required us to program microcontrollers with C and Assembly, and it was a nightmare! I spent so many late nights in the computer lab feeling completely and utterly defeated. I had no idea why I was doing that to myself and seriously thought about trying to find some other major that wouldn't be so frustrating. It was baptism by fire, to say the least.

Despite my tough classes, I got good grades and stuck with the program. I'd say my decision to stick with software engineering has been largely influenced by the internships I've held. In the "real world", I didn't spend any time writing parsers in C++ or solving linear algebra problems like I had to do in my classes. My managers never asked me what a Turing machine was or if a graph had any strongly connected components. Of course, this theory has its applications, but I have so much more fun building useful things. I've seen this in my elective classes too. I'm done with all the theory-intense core requirements and now get to take classes that are more focused on creating interesting projects. That's what I love doing more than anything, and that's why I've decided to be a software engineer.

As one of my previous managers liked to say, "Computer Science is to coding as linguistics is to speaking English". By comparing my schoolwork to my internships and other jobs, I've seen how useful this comparison is. I like coding way more than complicated CS theory. Luckily there are plenty of jobs available where I'll get to do lots of the kind of coding I enjoy.

Conclusion

To me, there's nothing more exciting than discovering a problem that's solvable with software and then creating the software to solve the problem. For example, I wanted a super-easy way to coordinate meetings with people across the world, so I created ZoneTime. Right now, I'm studying Chinese. I've felt that a lot of the sites out there with Chinese resources are lacking key features that make it easy to search for and study Chinese characters. Therefore, I've taken up a side project to create my own site that gives me exactly what I want.

That's what's so special about being a software engineer. It's creativity, freedom, and power all wrapped in one. And you never stop learning. Tech changes every day, and I don't want to be stuck at a job where I stop learning. That won't ever be a problem in this field. There's always something new to learn, and that is so amazing. Who knows, maybe my curious brain will take me down some other path in the future. But for now, I've got a lot of code I need to write first.

Question: Why did you decide to be a software engineer? If you don't want to be a software engineer, what do you want to do instead?

How to Test Responsive React Components

Brett Fisher — Sat, 22 Aug 2020 22:56:44 +0000

I was recently writing some responsive React components and needed to find a way to unit test them. I was using some custom components developed by my company that made it easy to render different layouts depending on the screen size. I wanted to test that certain components were visible on larger screen sizes and hidden on smaller screen sizes. I use Jest as my test runner, and I wasn't sure if there was a way to make Jest render different screen sizes. Luckily, it doesn't matter. There's a much easier way to test how your component behaves on different screen sizes.

As an example, let's create a simple responsive component. On small screen sizes it will print "I'm small!" and on larger screen sizes it will print "I'm big!". I'm going to use Material UI's useMediaQuery hook to determine what gets rendered based on the screen size. However, you'll soon see that it doesn't matter what library or method you use to make your app responsive.

Here's our first attempt: (Code Sandbox)

import React from 'react';
import { useTheme } from '@material-ui/core/styles';
import useMediaQuery from '@material-ui/core/useMediaQuery';

const App = () => {
  const theme = useTheme();
  const isSmall = useMediaQuery(theme.breakpoints.down('sm'));

  return <div>{isSmall ? "I'm small!" : "I'm big!"}</div>;
};

export default App;

What if I wanted to write a unit test that determined if the text "I'm small!" was rendered on small screens? That might be a little tricky. One solution would be to mock out useMediaQuery. The problem with that is it makes our unit tests flaky. What if in the future we decide to use a different method to determine the screen size? Then we would have to change our unit tests. Ideally our unit tests shouldn't need know about our components' implementation details.

I actually wrote about making your components more testable in one of my previous posts. The principles I wrote about there can apply here as well. What if we just added another component that took isSmall as a prop? Then it would be easy to test. For example (Code Sandbox):

import React from 'react';
import { useTheme } from '@material-ui/core/styles';
import useMediaQuery from '@material-ui/core/useMediaQuery';

export const ResponsiveApp = ({ isSmall }) => (
  <div>{isSmall ? "I'm small!" : "I'm big!"}</div>
);

const App = () => {
  const theme = useTheme();
  const isSmall = useMediaQuery(theme.breakpoints.down('sm'));

  return <ResponsiveApp isSmall={isSmall} />;
};

export default App;

Now we could just write a unit test for ResponsiveApp, which doesn't have any dependencies like useMediaQuery. For example:

import React from 'react';
import { render } from '@testing-library/react';
import { ResponsiveApp } from './App.jsx';

describe('ResponsiveApp test', () => {
  const createWrapper = isSmall => <ResponsiveApp isSmall={isSmall} />;

  it("displays I'm small! on small screens", () => {
    const { getByText } = createWrapper(true);
    expect(getByText("I'm small!")).toBeDefined();
  });

  it("displays I'm big! on big screens", () => {
    const { getByText } = createWrapper(false);
    expect(getByText("I'm big!")).toBeDefined();
  });
});

No mocking necessary! And if we change the method we use for determining responsive behavior in App, it won't affect our unit test at all. This is a small example, but following this kind of pattern has changed how I write code and makes components so much easier to test.

What is Closure in JavaScript?

Brett Fisher — Thu, 20 Aug 2020 00:47:20 +0000

I recently purchased and read the book You Don't Know JS Yet by Kyle Simpson, which I found to be a great read. Even though I've worked as a JS developer for years, there were so many new things I learned by reading it (I am not endorsed by anyone affiliated with this book - I'm just recommending it because I genuinely liked it).

One of those things was "closure" - a term I had heard a couple of times but never understood what it actually meant. I think it's hard to beat Kyle Simpson's definition:

Closure is when a function remembers and continues to access variables from outside its scope, even when the function is executed in a different scope.

So, what does that look like?

Some Examples of Closure

You've probably already used closure before and just didn't realize it. Take the following example:

function doAsyncTask(successMsg) {
  someAsyncTask().then(() => {
    console.log(`I remembered your variable! ${successMsg}`);
  });
}

getSuperImporantInfo('Hooray!');

// Some time later...
// I remembered your variable! Hooray!

When someAsyncTask finishes executing, it prints out the successMsg variable passed to doAsyncTask. someAsyncTask could take several seconds or even several minutes to execute, but the callback function passed to then "remembers" the successMsg variable. We say the the callback function is "closed" over successMsg.

I've done things like this all the time, I just didn't know I was using closure!

Now let's say you want to create a counter function. Every time you call the function, it will return the next number after the last number it returned. You can use closure to "remember" the last number returned.

function createCounter() {
  let count = 0;
  return () => count++;
}

const inc = createCounter();

inc();
// 0
inc();
// 1
inc();
// 2

createCounter returns an anonymous function which has access to the count variable. The function returned by createCounter is "closed" over count. We can even create multiple increment functions, all of which will have their own copy of count.

const inc1 = createCounter();
const inc2 = createCounter();

inc1();
// 0
inc2();
// 0
inc1();
// 1
inc1();
// 2
inc2();
// 1

These may be simple examples, but I've certainly needed to write counter functions like this before. Before I knew about closure, I would create variables visible to my entire module and increment those in my counter function. Now I know there's a better way that doesn't require me polluting my modules' scopes.

That's all there is to it! What other examples can you think of where you could use closure to your advantage?

How to Create Your Own React Text Field

Brett Fisher — Sun, 16 Aug 2020 04:48:02 +0000

On the home page of my blog, there is a search field that lets you search for posts by title or tags. I originally tried using Material UI's Text Field component, which seemed to be working just fine. However, once I built my site and ran it in production mode, the styling on the Text Field disappeared. I don't know if this is a problem with Material UI or Gatsby (or even something else), but I wasn't about to publish that to my site. All I wanted was a simple input element with some nice styling. I thought, "Hey, I'm a web developer. I'll just make the component myself"! I'll show you how I did it.

I'll be using React with TypeScript. If you want to follow along, I suggest either creating a new Gatsby site, which comes with TypeScript support out of the box, or adding TypeScript to a Create React App project. I'll be using Tailwind CSS to style my components, so you'll also want to install that.

Create a Basic `input` Wrapper

My goal was to just create a simple search field, or a generic text field that I could use in other places on my site. HTML's input field works just fine, but we'll need to style it a bit so that it looks nice. First, create a TextField.tsx file that just wraps a basic input element:

Code Sandbox

import React from 'react';

const TextField = () => {
  return <input />;
};

export default TextField;

Test it out in your App.tsx and it should just render a normal input field. Ok, it works, but it's not very useful. Let's add props for value and onChange so we can observe and manipulate the Text Field's state.

Code Sandbox

import React from 'react';

interface TextFieldProps {
  value: string;
  onChange: (val: string) => void;
}

const TextField = ({ value, onChange }: TextFieldProps) => {
  return (
    <input
      value={value}
      onChange={({ target: { value } }) => onChange(value)}
    />
  );
};

export default TextField;

Notice that input's default onChange event accepts a callback where the first argument is the input event. I'm not too interested in that, so I destructured that event and just pass in the value to the onChange callback. It just simplifies things a bit. Great, now we have a basic input wrapper! Let's work on styling it.

Styling our Text Field

If you haven't used Tailwind before, then it basically just provides a set of utility classes that easily let you style your components. I highly recommend checking it out.

Add the following className to your input component:

Code Sandbox

<input className="rounded-md w-full border border-gray-400 p-3 mb-5" ... />

These are Tailwind classes that round the corners on the input, give it a light gray border, add some padding and bottom margin, and makes the input the full width of its parent. These are just my personal preferences for a generic Text Field component - feel free to style yours however you want!

Adding More Useful Props

Our Text Field is looking great. But it would be nice to be able to modify other important values on the underlying input element, such as placeholder, autoFocus, name, and type. Adding those in as props is pretty easy:

Code Sandbox

import React from 'react';

interface TextFieldProps {
  value: string;
  onChange: (val: string) => void;
  placeholder?: string;
  autoFocus?: boolean;
  name?: string;
  type?: 'email' | 'password' | 'text';
}

const TextField = ({ onChange, ...rest }: TextFieldProps) => {
  return (
    <input
      className="rounded-md w-full border border-gray-400 p-3 mb-5"
      onChange={({ target: { value } }) => onChange(value)}
      {...rest}
    />
  );
};

export default TextField;

Notice that I decided to only destructure onChange because I use it a little differently than the way input does. All the other props are stored in rest because then they can be directly passed to input with the spread operator.

Doubling our Text Field as a `textarea`

I'll add in one more prop called textarea. If it's true, it will make our Text Field render a textarea instead of an input. This is simpler to do than creating a custom Textarea component because all the props we are passing to input can also be passed to textarea.

Code Sandbox

import React from 'react';

type InputElement = HTMLInputElement | HTMLTextAreaElement;
type InputChangeEvent = React.ChangeEvent<InputElement>;

interface TextFieldProps {
  value: string;
  onChange: (val: string) => void;
  placeholder?: string;
  autoFocus?: boolean;
  name?: string;
  type?: 'email' | 'password' | 'text';
  textarea?: boolean;
}

const TextField = ({ onChange, textarea = false, ...rest }: TextFieldProps) => {
  const InputElement = textarea ? 'textarea' : 'input';
  return (
    <InputElement
      className={`rounded-md w-full border border-gray-400 p-3 mb-5 ${
        textarea ? 'h-32' : ''
      }`}
      onChange={({ target: { value } }: InputChangeEvent) => onChange(value)}
      {...rest}
    />
  );
};

export default TextField;

There are a few important changes here. First take a look at the variable called InputElement. If the textarea is true, then our component will render a textarea. Otherwise, it will render a normal input.

Next, take a look at the className property. I wasn't satisfied with the height of the default textarea, so I conditionally added an h-32 class if the textarea prop is true. That just makes its height a little bigger.

Finally, take note of the onChange prop. Since our component can render either a textarea or an input, TypeScript got confused about the type of the value variable in the onChange callback. I created these two types at the top of the file:

type InputElement = HTMLInputElement | HTMLTextAreaElement;
type InputChangeEvent = React.ChangeEvent<InputElement>;

I just figured these out with my editor's intellisense. Now when I add the InputChangeEvent as the type annotation for the parameter in our onChange callback, TypeScript stops complaining.

Passing a Ref to our Text Field

So far, our custom Text Field is working out pretty well. The last feature I'd like is to be able to pass a ref to the underlying input element. This would be useful if we wanted to programatically focus the input, for example. Luckily this is pretty easy to do with React's ref forwarding feature. Pretty much all we have to do is wrap our functional component in a call to React.forwardRef.

Code Sandbox

import React from 'react';

type InputElement = HTMLInputElement | HTMLTextAreaElement;
type InputChangeEvent = React.ChangeEvent<InputElement>;

interface TextFieldProps {
  value: string;
  onChange: (val: string) => void;
  placeholder?: string;
  autoFocus?: boolean;
  name?: string;
  type?: 'email' | 'password' | 'text';
  textarea?: boolean;
}

const TextField = React.forwardRef<InputElement, TextFieldProps>(
  ({ onChange, textarea = false, ...rest }, ref) => {
    const InputElement = textarea ? 'textarea' : 'input';
    return (
      <InputElement
        ref={ref as any}
        className={`rounded-md w-full border border-gray-400 p-3 mb-5 ${
          textarea ? 'h-32' : ''
        }`}
        onChange={({ target: { value } }: InputChangeEvent) => onChange(value)}
        {...rest}
      />
    );
  }
);

export default TextField;

Now if a ref is given to Text Field, it will apply directly to the input or textarea component. The only way I was able to get TypeScript to stop complaining was to put ref={ref as any}, which isn't ideal but I wasn't too concered about it since I'm the only one who will be using this component. If you know how to give it a proper type, please let me know!

Conclusion

That's about all there is to creating a custom Text Field. While I love Material UI, it's a fun exercise to see if I can create components on my own. Plus, I still haven't figured out why Material UI has problems with its Text Field on my built site...anyways, happy coding!

2 Ways to Write Easily Testable React Components

Brett Fisher — Tue, 11 Aug 2020 07:08:20 +0000

Unit testing my React components is a skill that did not come very easily to me. When working on personal projects, it was so easy to justify not writing unit tests for reasons like the project wasn't very big or I wasn't anticipating having very many users. However, I've recently learned some useful patterns that have made unit testing my components much easier, and now I'm at the point where I even enjoy writing unit tests! These days, I don't write unit tests because I "have to" - I write them because I want to and sleep a lot better at night knowing that my code is protected. I'm going to describe a couple of common patterns that make writing testable components easier.

How I used to write unit tests

Before I understood too much about test-driven development (TDD), I would spend a few days writing a component and then come back to test it. The problem with this approach was that I would write components that were very difficult to test. Let's take a simple example. Here's a component that fetches a list of users from some API and displays them in a table.

import React, { useState, useEffect } from 'react';
import axios from 'axios';

const UserTable = () => {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    axios
      .get('https://jsonplaceholder.typicode.com/users')
      .then(({ data }) => setUsers(data));
  }, []);

  return (
    <div>
      <table>
        <thead>
          <tr>
            <th>Name</th>
            <th>Username</th>
            <th>Email</th>
          </tr>
        </thead>
        <tbody>
          {users.map(({ name, username, email }) => (
            <tr key={username}>
              <td>{name}</td>
              <td>{username}</td>
              <td>{email}</td>
            </tr>
          ))}
        </tbody>
      </table>
    </div>
  );
};

export default UserTable;

Now let's write a unit test for this component. When writing unit tests, we want to think about what the business logic is. So, what does this component do? We see that it fetches a list of users using axios in the useEffect at the beginning of the functional component, then displays that list of users. Let's write a test that makes sure the component successfully fetches and displays a list of users. Here's what a test might look like:

import React from 'react';
import { render, waitFor, screen } from '@testing-library/react';
import UserTable from './UserTable';
import axios from 'axios';

describe('UserTable test', () => {
  const mockUsers = [
    {
      name: 'Harry Potter',
      username: 'boywholived',
      email: 'harry@hogwarts.com',
    },
    {
      name: 'Tom Riddle',
      username: 'darklord',
      email: 'voldemort@deatheaters.com',
    },
  ];

  beforeEach(async () => {
    axios.get = jest.fn().mockResolvedValue({ data: mockUsers });
    render(<UserTable />);
    await waitFor(() => expect(axios.get).toHaveBeenCalled());
  });

  test('renders user list', async () => {
    const { getByText } = screen;

    mockUsers.forEach(({ name, username, email }) => {
      expect(getByText(name)).toBeDefined();
      expect(getByText(username)).toBeDefined();
      expect(getByText(email)).toBeDefined();
    });
  });
});

Since we don't want to actually make a network request in our unit test, we first mock out the get function on axios in the beforeEach function. That way, when the component is rendered in our test, axios.get will return our array of mockUsers instead of making a real request. Then in our test, we check that the name, username, and email of each of our mock users is indeed rendered.

This component is pretty straightforward to test, but I find a few problems with it. First of all, there's a decent amount of setup. We have to mock axios and then wait for its get method to be called (even though our mocked get function immediately resolves, it's still asynchronous. We have to wait for the promise to resolve before we can reliably test that the data is rendered). I don't really want to have to worry about the implementation details of the components I'm testing. I could have axios calls in many different components, and then I would have to mock it out in every single one of my test files. What if I decided to start using some other fetching library instead of axios? Then I would have to change all my tests to mock that new library instead. This is all distracting from the purpose of unit tests - to test the business logic of your components.

I've used a couple of different approaches to solving these problems. The first is dependency injection, and the second is using presentational components.

Dependency Injection

One of the problems we mentioned with this component is its hard dependency on axios. That means we have to worry about mocking axios specifically in every component we test that uses it. What if instead of mocking it, we created another component and passed in a fetchUsers function as a prop? Then we wouldn't have to mock anything, we could just pass in our own function in the test file. Here's a new version of the component:

import React, { useState, useEffect } from 'react';
import axios from 'axios';

export const UserTable = ({ fetchUsers }) => {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    fetchUsers().then(setUsers);
  }, [fetchUsers]);

  return (
    <div>
      <table>
        <thead>
          <tr>
            <th>Name</th>
            <th>Username</th>
            <th>Email</th>
          </tr>
        </thead>
        <tbody>
          {users.map(({ name, username, email }) => (
            <tr key={username}>
              <td>{name}</td>
              <td>{username}</td>
              <td>{email}</td>
            </tr>
          ))}
        </tbody>
      </table>
    </div>
  );
};

const UserTableContainer = () => {
  const fetchUsers = async () => {
    const { data } = await axios.get(
      'https://jsonplaceholder.typicode.com/users'
    );
    return data;
  };

  return <UserTable fetchUsers={fetchUsers} />;
};

export default UserTableContainer;

Notice that now we have two components. UserTable is a lot like the old component, except it accepts a fetchUsers function as a prop. Notice that in the useEffect, fetchUsers directly assigns users to its resolved value. Compare that with how we previously had to extract data from the axios call. fetchUsers is completely generic - it just has to be a function that directly resolves to the array of users to be displayed.

We also have a UserTableContainer, which does the heavy lifting of passing in the fetchUsers function, which basically just wraps an axios call. Now take a look at our revised unit test:

import React from 'react';
import { render, waitFor, screen } from '@testing-library/react';
import { UserTable } from './App';

describe('UserTable test', () => {
  const mockUsers = [
    {
      name: 'Harry Potter',
      username: 'boywholived',
      email: 'harry@hogwarts.com',
    },
    {
      name: 'Tom Riddle',
      username: 'darklord',
      email: 'voldemort@deatheaters.com',
    },
  ];

  beforeEach(async () => {
    const fetchUsers = jest.fn().mockResolvedValue(mockUsers);
    render(<UserTable fetchUsers={fetchUsers} />);
    await waitFor(() => expect(fetchUsers).toHaveBeenCalled());
  });

  test('renders user list', async () => {
    const { getByText } = screen;

    mockUsers.forEach(({ name, username, email }) => {
      expect(getByText(name)).toBeDefined();
      expect(getByText(username)).toBeDefined();
      expect(getByText(email)).toBeDefined();
    });
  });
});

Notice that we are testing UserTable instead of UserTableContainer. That's because UserTable actually contains the logic we want to test - displaying the list of users. This is better because we don't have to mock axios. In fact, we no longer care what fetching library our app uses. Notice that in the previous unit test, we had to mock axios's behavior of resolving to an object containing a data attribute with the fetched data. We had to know about this in our unit test, but now it really doesn't matter how our fetching library behaves. It's UserTableContainer's job to pass in the fetchUsers function, but we don't have to test that because its only job is to provide that function.

This is called dependency injection. UserTable asks for the function it will use to fetch the list of users instead of having a hard dependency on axios, and consequently it's much easier to test.

This is just one solution to the problems we were having earlier. The other solution I'll discuss is called presentational components.

Presentational Components

Presentational components are components that only present data, they have no state. For this example, instead of passing in a fetchUsers function, we could just make a component that accepts users as a prop and displays them. Then we wouldn't have to pass in a fetchUsers function at all in our test, all we would have to do is pass in a mock array of users and make sure that the component renders them. Here's the component rewritten to use this approach:

import React, { useState, useEffect } from 'react';
import axios from 'axios';

export const UserTable = ({ users }) => (
  <div>
    <table>
      <thead>
        <tr>
          <th>Name</th>
          <th>Username</th>
          <th>Email</th>
        </tr>
      </thead>
      <tbody>
        {users.map(({ name, username, email }) => (
          <tr key={username}>
            <td>{name}</td>
            <td>{username}</td>
            <td>{email}</td>
          </tr>
        ))}
      </tbody>
    </table>
  </div>
);

const UserTableContainer = () => {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    axios
      .get('https://jsonplaceholder.typicode.com/users')
      .then(({ data }) => setUsers(data));
  }, []);

  return <UserTable users={users} />;
};

export default UserTableContainer;

Now in our test, we don't even have to wait for anything in our beforeEach function. We can just render UserTable with the mock users and test that everything is displayed properly.

import React from 'react';
import { render, waitFor, screen } from '@testing-library/react';
import { UserTable } from './App';

describe('UserTable test', () => {
  const mockUsers = [
    {
      name: 'Harry Potter',
      username: 'boywholived',
      email: 'harry@hogwarts.com',
    },
    {
      name: 'Tom Riddle',
      username: 'darklord',
      email: 'voldemort@deatheaters.com',
    },
  ];

  beforeEach(async () => {
    render(<UserTable users={mockUsers} />);
  });

  test('renders user list', async () => {
    const { getByText } = screen;

    mockUsers.forEach(({ name, username, email }) => {
      expect(getByText(name)).toBeDefined();
      expect(getByText(username)).toBeDefined();
      expect(getByText(email)).toBeDefined();
    });
  });
});

Now if that isn't easy to test, I don't know what is!

Conclusion

Jest's mocking feature is incredibly powerful and useful, but personally I try to avoid it whenever possible. I usually find that I can refactor my components to use either dependency injection or presentation components, and then I don't have to worry about the implementation of my dependencies.

So which of these two approaches to improving your tests is better? It depends. For this simple example, I would probably go with a presentational component because I just want to test that it presents the data correctly. But sometimes I want to test a little more than just presentation, and that's when dependency injection comes in handy. For example, I recently wrote a component that uses localStorage. I originally tried mocking it with Jest and it was a huge pain. But after I refactored my component to accept a storageService, I was able to test the component easily. In my app, I passed in localStorage as the storageService, but in my test I passed in an object that looked like localStorage but wouldn't actually try to store anything in the browser.

I've found that it's hard to write a hard list of rules for what approach to use in every instance. As I've spent more time writing components and unit tests, I've developed a feel for what makes the most sense. Unit testing isn't just something you do - it's a way of thinking. Being a good unit tester doesn't mean you figure out clever ways to test every component - a huge part is knowing how to write and refactor your code such that it's easy to test in the first place.

Hopefully this has helped you write easier-to-test components! Good luck!

Why I Converted From Vue to React - UPDATED

Brett Fisher — Sat, 25 Jul 2020 23:16:27 +0000

The original version of this article got a lot more attention than I was expecting, especially since it was only my second post on dev.to. I'm grateful to everyone who read it and left feedback! As I read through the comments, I learned that some of the content of the original article wasn't entirely accurate and that I also wasn't clear about several of the points I was trying to make. My original article was an attempt to explain from a more technical standpoint why I chose React over Vue, but I realized I didn't quite have enough knowledge to tackle that in depth. In fact, I learned that I've gone the direction I have not because of "under the hood" differences between React and Vue, but instead out of small experiences that have shaped what feels the most comfortable for me in my career as a web developer. For other developers, Vue may feel more at home, and there's nothing wrong with that.

My intent was not and still is not to convince readers that React is inherently a better framework than Vue. Vue was the first web development framework I learned, and working with it was a delightful experience. I found its learning curve to be very forgiving compared to that of React. Ultimately, as I learned what was personally most important to me as a web developer, I decided to make the transition to use React as my front end framework of choice. I would still be happy to work with Vue professionally, but for personal projects, I believe that React better suits my needs. With that, I present a revised discussion on why I chose React over Vue.

How I fell in love with Vue

I started learning how to code when I was about 16 years old. I started building simple console based programs in Perl before gaining intereset in web development. I got the first book I found at the library on web dev which taught me about PHP and jQuery, which I thought were amazing! I never did any major projects, but I enjoyed hacking up small apps in my free time.

Fast forward a few years to when I got my first web dev job. I was working for my university on their grade management site, and my job was to rewrite some of the existing front end pages to use Vue instead of Backbone and/or PHP. Having only used jQuery, PHP, and sometimes even vanilla JS to create frontend pages, using Vue was definitely a different way of thinking for me. When I couldn't figure out how to do something with Vue, I would try using jQuery inside of my Vue components (which I quickly learned was a bad idea since jQuery manipulates the actual DOM, but Vue uses a virtual DOM).

However, after a lot of practice and making LOTS of mistakes, I embraced Vue and learned just how powerful it really is. I began using it for side projects and started attending a Vue Meetup hosted by a tech company close to where I live. I even ended up getting a summer internship at that company as a Vue + Rails developer. At a different job for my school, I chose to use Vue to create a fully functional site for the history department that they continue to use to research ancient Assyrian tablets.

Throughout these various jobs I had, I generally enjoyed working with Vue. It's known for its ease of use. One developer I worked with said that there isn't really such a thing as "advanced" Vue because it's all so easy to use (I slightly disagreed with him as I found things like scoped slots and render functions to take a little while to get used to, but I understand his point).

My first taste of React

After I'd been working with Vue for almost a year, I signed up for a databases class where we were required to do a group project. Our team settled on using Python Flask for the backend and React for the frontend. I spent most of my time working on the backend, and once it was mostly complete, I offered to help with the frontend.

I hadn't worked with React before, and I began to understand why a lot of people said it was hard to learn. I learned enough to help out with our project, but I think it was mostly my lack of familiarity with React that didn't win me over at first. Hey, I was already familiar with Vue, so why should I abandon it when it had worked so well for me? I didn't see any advantage that switching to React would give me.

The next semester after I took that class, I decided to accept an internship with Bluehost as a React developer. Despite the title of this article, my first few months at the job working with React left a pretty bad taste in my mouth. I missed how concise Vue could be, and it drove me crazy that JSX could be thrown around almost anywhere in a React component. I began gaining a huge appreciation for Vue's single file components that had all the HTML in the <template> section of the file.

As a *very* simple example, this is the kind of code I would run into a lot at Bluehost (see it on Codepen):

import React, { useState } from 'react';

const UserDashboard = () => {
  const [view, setView] = React.useState('followers');
  const [user] = React.useState({
    name: 'John Doe',
    email: 'johndoe@example.com',
    followers: 1000,
    following: 500,
  });

  const renderProfile = () => {
    return (
      <ul>
        <li>Name: {user.name}</li>
        <li>Email: {user.email}</li>
      </ul>
    );
  };

  const renderFollowers = () => {
    return (
      <ul>
        <li>Followers: {user.followers}</li>
        <li>Following: {user.following}</li>
      </ul>
    );
  };

  return (
    <div>
      <section>
        <button onClick={() => setView('profile')}>Profile</button>
        <button onClick={() => setView('followers')}>Followers</button>
      </section>
      <section>
        {view === 'followers' ? renderFollowers() : renderProfile()}
      </section>
    </div>
  );
};

Of course a real app wouldn't have everything hardcoded like that, but it illustrates my point of the bewilderment I experienced upon seeing HTML treated like any other kind of object you can interact with in JavaScript. A lot of things about this way of coding made me an even stronger disciple of Vue, such as:

Ternary operators used for rendering JSX just seemed...unnatural to me. I thought that Vue's v-if and v-else directives were much more intuitive.
Having to declare dependencies for things like useEffect and useCallback seemed so primitive. I knew that ESLint plugins made it easy to find out which dependencies you might be missing, but there was no need to do anything like that in Vue's methods or computed.
I most especially didn't like that JSX could appear anywhere in a React component. I had to work with some pretty big components at Bluehost, and it wasn't exactly fun trying to hunt down all the places that JSX could appear inside of a functional (or class based) component. Vue just has all of its HTML at the top of the .vue files.

As a comparison, here's the same component implemented with Vue (see it on Codepen):

<template>
  <div id="app">
    <section>
      <button @click="view = 'profile'">Profile</button>
      <button @click="view = 'followers'">Followers</button>
    </section>

    <section>
      <ul v-if="view === 'followers'">
        <li>Followers: {{ user.followers }}</li>
        <li>Following: {{ user.following }}</li>
      </ul>
      <ul v-else>
        <li>Name: {{ user.name }}</li>
        <li>Email: {{ user.email }}</li>
      </ul>
    </section>
  </div>
</template>

<script>
  export default {
    data: () => ({
      user: {
        name: 'John Doe',
        email: 'johndoe@example.com',
        followers: 1000,
        following: 500,
      },
      view: 'followers',
    }),
  };
</script>

Just looking at it, it feels so much cleaner. The JS is minimal, only containing the initial data. The best part is, all the HTML is in one place. No chance of JSX pieces randomly showing up in different parts of the render function. Yes, I know you can use JSX with Vue. But this seems more rare than common. In the year and a half timespan that I was working with Vue, almost every Stack Overflow post, documentation page, or blog post gave examples using the approach with the HTML template at the top followed by a <script> tag containing the logic. Most of the time you're probably going to see Vue code that follows the pattern above, and that's what I was used to and liked.

So...why did I convert to React?

Reading that, it would be easy to wonder why I started to favor React over Vue when it came to choosing a framework for my personal projects. In the previous section, the example code I gave was small, but the Vue code at first glance just seems so much easier to grasp. The pros and cons mentioned above only compound with the large files and codebases I dealt with at the companies I worked for.

The BIGGEST reason why I ultimately started favoring React was that it seems so much easier to get TypeScript working with it. I mentioned this in my original article, but I don't think I stressed enough that if there were one reason why I've decided to stick with React, this would be it.

React <3 TypeScript

As I started learning TypeScript, I started getting addicted to it because the type safety and additional Intellisense I got with my IDE felt so good. I won't go on about how great TypeScript is because there are already plenty of other articles on the internet about that. But basically, I started feeling kind of naked when working on normal JS projects. Especially when dealing with objects having more complex structures, I really started appreciating the cognitive load that TypeScript took away just because my IDE was able to tell me exactly which properties should exist on an object and what type they were.

Don't get me wrong, Vue's TS support has gotten to be pretty decent. I used to think that the official class component decorators were the only way to get decent TS support in Vue, which at first I wasn't a big fan of. I hadn't seen decorators in JS before, and I felt a little dirty using them since they're not even officially part of JavaScript yet. I've since learned that class decorators are not a bad thing, especially since they make creating a TS GraphQL Express server insanely easy with the TypeGraphQL library.

I've since learned that class components are not a requirement for TS with Vue, since it can be as easy as using Vue.extend. And with Vue 3 natively supporting the composition API, using TypeScript in Vue will become even easier.

However, as I learned through experience, TS with Vue is by no means seamless. Using Vue.extend seems like the easiest way to get TS working with Vue without having to rewrite your code, but as this article explains, there are basic problems with that. For example, you can't define prop types with interfaces, which I find to be a pretty big problem. To do that, you'll have to use the class components. Maybe there's a way around this now? If there is, feel free to correct me because I am not aware of it.

The downside with class components is that if you want to convert an existing Vue project to use TypeScript, you basically have to rewrite your whole component. With React, on the other hand, I've found it a lot easier to just "drop in" TypeScript.

Let's look at another example to illustrate this point. We'll create a simple component that could be used on a social media site - it will display information about a user and include a button allowing you to follow that user. It will accept everything it needs as props (making it easy to test :D). Say we originally created this component with ordinary Vue and wanted to convert it to use TypeScript. Here's the original (Code Sandbox link):

<!-- UserProfile.vue -->
<template>
  <div>
    <h1>{{user.name}}</h1>
    <ul>
      <li>Username: {{user.username}}</li>
      <li>Followers: {{user.followers}}</li>
    </ul>
    <button @click="onFollow">Follow</button>
  </div>
</template>

<script>
  export default {
    name: 'UserProfile',
    props: {
      user: {
        type: Object,
        required: true,
      },
      onFollow: {
        type: Function,
        required: true,
      },
    },
  };
</script>

<!-- App.vue -->
<template>
  <div id="app">
    <user-profile :user="user" :onFollow="onFollow" />
  </div>
</template>

<script>
  import UserProfile from './UserProfile.vue';

  export default {
    name: 'App',
    components: {
      UserProfile,
    },
    data: () => ({
      user: {
        name: 'John Doe',
        username: 'johndoe',
        followers: 1794,
      },
    }),
    methods: {
      onFollow() {
        alert(`You followed ${this.user.name}!`);
      },
    },
  };
</script>

Here's the TS version using class components (Code Sandbox link):

// types.ts
export interface User {
  name: string;
  username: string;
  followers: number;
}

<!-- UserProfile.vue -->
<template>
  <div>
    <h1>{{user.name}}</h1>
    <ul>
      <li>Username: {{user.username}}</li>
      <li>Followers: {{user.followers}}</li>
    </ul>
    <button @click="onFollow">Follow</button>
  </div>
</template>

<script lang="ts">
  import { Component, Vue, Prop } from 'vue-property-decorator';
  import { User } from './types';

  @Component({
    name: 'UserProfile',
  })
  class UserProfile extends Vue {
    @Prop({ required: true }) user: User;
    @Prop({ required: true }) onFollow: () => void;
  }

  export default UserProfile;
</script>

<!-- App.vue -->
<template>
  <div id="app">
    <user-profile :user="user" :onFollow="onFollow" />
  </div>
</template>

<script lang="ts">
  import { Component, Vue } from 'vue-property-decorator';
  import { User } from './types';
  import * as UserProfile from './UserProfile.vue';

  @Component({
    name: 'App',
    components: {
      UserProfile,
    },
  })
  class App extends Vue {
    private user: User = {
      name: 'John Doe',
      username: 'johndoe',
      followers: 1794,
    };

    private onFollow(): void {
      alert(`You followed ${this.user.name}`);
    }
  }

  export default App;
</script>

As you can see, the difference between the two is fairly large. Because of the earlier problems mentioned with simply using Vue.extend, at this point using TypeScript with Vue requires either using class components, the composition API plugin, or waiting for Vue 3 to come out so that the composition API is just built in. If you are rewriting an existing Vue codebase to use TypeScript, you'll basically have to completely change the structure of your Vue components. I experienced this while working on the website for my university. I originally used the offical options API, but decided to start using TypeScript as the data the site was handling became increasingly more complex.

I didn't necessarily have to rewrite my business logic, but for larger components, converting them to class components could take quite some time. I understood this was the price I had to pay to get type safety, and I accepted that. But now, many months later, as a React developer I can't help but think what the process would have been like if I were trying to convert an existing React site to use TypeScript.

Let's look at the same component from above but written in React. Here is it written with normal JS (Code Sandbox):

import React, { useState } from 'react';

const UserProfile = ({ user, onFollow }) => {
  return (
    <div>
      <h1>{user.name}</h1>
      <ul>
        <li>Username: {user.username}</li>
        <li>Followers: {user.followers}</li>
      </ul>
      <button onClick={onFollow}>Follow</button>
    </div>
  );
};

export default function App() {
  const [user] = useState({
    name: 'John Doe',
    username: 'johndoe',
    followers: 1794,
  });

  const onFollow = () => {
    alert(`You followed ${user.name}!`);
  };

  return (
    <div className="App">
      <UserProfile user={user} onFollow={onFollow} />
    </div>
  );
}

Here's the same React app in TypeScript (Code sandbox):

import React, { useState } from 'react';

interface User {
  name: string;
  username: string;
  followers: number;
}

interface UserProfileProps {
  user: User;
  onFollow: () => void;
}

const UserProfile = ({ user, onFollow }: UserProfileProps) => {
  return (
    <div>
      <h1>{user.name}</h1>
      <ul>
        <li>Username: {user.username}</li>
        <li>Followers: {user.followers}</li>
      </ul>
      <button onClick={onFollow}>Follow</button>
    </div>
  );
};

export default function App() {
  const [user] = useState<User>({
    name: 'John Doe',
    username: 'johndoe',
    followers: 1794,
  });

  const onFollow = () => {
    alert(`You followed ${user.name}!`);
  };

  return (
    <div className="App">
      <UserProfile user={user} onFollow={onFollow} />
    </div>
  );
}

Just like the Vue migration to TS, we needed to declare our types. But in React, that was pretty much all we had to do. Notice how similar the JS React and TS React apps are to each other. Granted, this is a pretty small example, but from experience I can say that it usually is this easy when migrating an existing React app to use TS. The other weekend, I decided to migrate my old JS React blog to use TS React, and it really was this easy. Basically all I had to do was add types where they were required, and I was done. No refactoring my code to use a new structure or decorators, the way I would have had to do in Vue.

Understand that this is not me saying that React is better than Vue. I'm just saying that I have had a much easier time using TypeScript with React, and that's a huge selling point because TypeScript is so important me. I get that this wouldn't be as big of a deal for a developer not using TypeScript.

In fact, if TypeScript didn't exist or if I only developed with normal JS, there's a good chance that I would prefer Vue! Hooks were a huge game changer with React, but I think just about every React developer (myself included) has run into headaches with infinite render loops because of messing up the dependencies in the useEffect hook. This ESLint plugin helps find a lot of the trivial bugs associated with this problem and has saved my bacon on many occassions, but even with it, infinite render loops can happen. I've run into infinite render loops a couple of times with Vue, but it's definitely a lot more common in React. It's really nice that Vue's computed and watched properties figure out the dependencies for you. I know this isn't quite comparing the same thing, but they are pretty close. However, the ease of using TypeScript in React outweighs this problem for me, especially as I've gotten more experienced with using hooks and understanding their nuances.

React has less secrets

In my original article, I said that React is just JavaScript, which is sort of true. The Vue website says so itself, but as many people commented to me, JSX is not valid JS, which is why we require something like Babel to build our JSX files. Yeah, you don't have to use JSX with React, but that doesn't sound like very much fun to me! That being said, React feels a lot closer to plain old JS than Vue does.

If you had told this to me when I first started learning React, I probably wouldn't have cared because I thought React was so much harder than Vue! But as I've spent more time with it, this feeling of React being so close to regular JS has grown on me.

For example, in a normal JS file, you usually have to import or require all your dependencies. React is no different. If you see an unfamiliar function or component in a React JSX file, you can just look at the import statement to see where it's coming from. Is it coming from a third party library, or from some other location in the project?

As an example, here's a tiny React app that uses some components from the Material UI library (Code Sandbox link).

import React, { useState } from 'react';
import Button from '@material-ui/core/Button';
import TextField from '@material-ui/core/TextField';

export default function App() {
  const [items, setItems] = useState([]);
  const [text, setText] = useState('');

  const addItem = () => {
    setItems(prevItems => [...prevItems, text]);
    setText('');
  };

  return (
    <div className="App">
      <h1>My List of Things</h1>
      <ul>
        {items.map(item => (
          <li>{item}</li>
        ))}
      </ul>
      <TextField
        value={text}
        onChange={({ target: { value } }) => setText(value)}
        label="List item"
      />
      <Button variant="contained" onClick={addItem}>
        Add Item
      </Button>
    </div>
  );
}

The components we need from Material UI, such as Button and TextField, are just imported at the top of the file. This is how it would be with pretty much every other React component library out there. Even if I'm working on a project that's using multiple third party libraries, every component, function, or constant can be traced pretty easily.

As a comparison, we'll look at the same component, only this time using Vuetify (Code Sandbox link).

<template>
  <v-app>
    <h1>My List of Things</h1>
    <ul>
      <li v-for="(item, idx) in items" :key="idx">{{item}}</li>
    </ul>
    <v-container>
      <v-text-field v-model="text" label="List item" />
      <v-btn @click="addItem">Add Item</v-btn>
    </v-container>
  </v-app>
</template>

<script>
  export default {
    data: () => ({
      items: [],
      text: '',
    }),
    methods: {
      addItem() {
        this.items.push(this.text);
        this.text = '';
      },
    },
  };
</script>

These lines in our main.js actually make Vuetify available:

import Vue from 'vue';
import Vuetify from 'vuetify';
Vue.use(Vuetify);

My main problem with this is that Vue allows Vuetify to make the v-* components globally available (and I know that you can manually import Vuetify components the way you have to do with Material UI). The main point I'm trying to get at is that it seems to be a common occurrence in Vue code to either have global components like in Vuetify or global variables available on this, such as this.$router or this.$store coming from Vue Router and Vuex, respectively. Yes, I know that you can just import the router and store objects instead of using these global variables, but in my experience with production code and online examples I've seen the global approach used more often. I'm not saying this is inherently a bad thing - it might not bother some people, and that's fine. In fact, a good IDE can help take some of the mystery out of finding the definition of these global components.

The main reason I don't like these global variables is it makes unit testing more difficult. I have had so many problems trying to get unit tests working with an app using Vuetify because the test runner complains about not being able to find the globally registered components. In the above example, in a unit test I would get errors about v-app or v-container not being defined. Even when following Vuetify's guide on unit testing, I would still end up with weird errors and warnings from Jest that would take me far too long to fix. I never ran into problems like that with Material UI, because all the dependencies are just imported, so Jest wouldn't complain about not being able to find them.

That's just one example, of course, but overall I've tended to just have better luck testing React apps than Vue apps. That's speaking from my own experience - someone else may have had better luck the other way around, and I'm not here to say that's wrong.

In summary of this point, when I say that React has less secrets, I mean that I've personally found it easier to figure out where a component's dependencies (third party or in-house) are coming from when working in large codebases. This has provided a lot of benefits. Testing, as I mentioned, is just one of them. Yes, lack of global components can make for a long list of import statements, I will admit. But it's always comforting to know that I can usually find out exactly where each piece of code in a React app is coming from. While working in a big Vue codebase, I found myself confused a lot by global variables on this. I thought it was too easy to get confused about if such variables were instance properties, coming from a third party plugin, or had been added to the Vue prototype somewhere else in the codebase. This was never a problem for me with React code.

What about the weird JSX syntax?

Earlier, I mentioned that large React components at Bluehost confused me when JSX appeared in so many places throughout the component. To address this problem, I would argue that this isn't necessarily React's or JSX's fault. I believe that the source of these components' confusion came mostly from their size and not following basic principles of clean coding.

I formed this opinion after recently reading Bob Martin's book Clean Code. He gives several examples of large and confusing Java classes before proceeding to show how much more readable and maintainable they can be just by logically breaking them up into multiple classes. This same principle holds true with React and Vue components. When working as a Vue developer, I sometimes had to work with massive Vue files that other people had written, and I was just as confused as I was when working with other people's large React files.

At first I blamed my confusion on React, but I've learned that JSX appearing in multiple places hasn't been a problem for me as long as I keep my components small. Don't blame poorly written code on the framework.

Conclusion

Once again, I'd like to reiterate that I don't believe Vue is bad - I still think it's really great, and I'm excitedly looking forward to the release of Vue 3. What I was hoping to get across by releasing this revised article was that my personal experiences as a web developer have shaped my decision to stick with React at this point in time.

I find React's TypeScript support to be the biggest selling point to me, as well as my experiences in writing unit tests for it. Maybe I was just doing something wrong that caused me so many struggles with getting Vue unit tests to work (especially with Vuetify), but while I enjoy writing tests, I don't enjoy spending too much time debugging them since I would rather be working on the app itself. In general, I've been more successful at accomplishing this by using React. Though Vue has treated me very well and I'd have no problem accepting a future job as a Vue developer, for my personal projects I'll be sticking with React.

Forem: Brett Fisher

My 2024 Web App Tech Stack

Frontend Framework - React

Component Library - shadcn/ui

State Management - Zustand

Authentication/Data storage - Firebase

Data Fetching - TanStack Query

SSR - NextJS

Tooling - Vite

Bundling for quick projects - esbuild

Hosting - Vercel

Conclusion

The Easiest Way to Use Snackbars in Vue

Step 1: Create the event bus

Step 2: Create a function to open the snackbar

Step 3: Use the function in a component

Step 4: Add a snackbar to App.vue

Conclusion

How to Install a Specific Version of an NPM Package

The Easiest Way to Use Query Parameters in React

How it Works

How to Create a Monorepo with Yarn Workspaces

Create a Project

Setup Yarn Workspaces

Create Packages

Conclusion

3 Things I Learned from my Internship at Amazon

1. Define your Culture

2. It is Possible to Enjoy your Job

3. Refactor Early, Refactor Often

Conclusion

Why I Decided to be a Software Engineer

High School

Facing Challenges

Conclusion

How to Test Responsive React Components

What is Closure in JavaScript?

Some Examples of Closure

How to Create Your Own React Text Field

Create a Basic input Wrapper

Styling our Text Field

Adding More Useful Props

Doubling our Text Field as a textarea

Passing a Ref to our Text Field

Conclusion

2 Ways to Write Easily Testable React Components

How I used to write unit tests

Dependency Injection

Presentational Components

Conclusion

Why I Converted From Vue to React - UPDATED

How I fell in love with Vue

My first taste of React

So...why did I convert to React?

React <3 TypeScript

React has less secrets

What about the weird JSX syntax?

Conclusion

Create a Basic `input` Wrapper

Doubling our Text Field as a `textarea`