DEV Community: Nicholas Coffey

Why I Chose Neovim

Nicholas Coffey — Tue, 18 Feb 2025 18:26:10 +0000

This post can also be found on my personal blog.

A Developer's Canvas

For developers, text editors are the canvas in which software is created. I believe that a good text editor finds the proper balance of features and simplicity. Too many features and the experience is bloated and overwhelming. Too simple and it can become easy to get lost in a large codebase. Throughout my career I have alternated between various editors and I believe now I have found the editor that I will stick with well into the distant future. That editor is Neovim.

Life Before Neovim

When my career first started I didn't have enough experience to know what was good and bad about an editor. In school I learned with NetBeans and Visual Studio. Then in my first job I was mandated to use Eclipse *shudders*. In my spare time I found myself gravitating towards IntelliJ and VS Code.

When I finally landed my second job, I was lucky enough to get away from Eclipse and I chose VS Code for my professional work. I had a couple years of experience at this point and I knew I liked the lighter weight of VS Code over Eclipse. I found joy in tinkering with my config and sometimes spent too much time on it. So VS Code is where I stayed over the period of a few years and jobs.

Over this period I began to start see the cracks in VS Code. In the beginning, VS Code felt light and fast, but that was in comparison to Eclipse. As I worked on larger and more complex projects, my editor would chug and even crash. This would often knock me out of my flow state and all devs out there know that the coveted flow state is nothing to be messed with. Then one day during a pair programming session I noticed our lead dev using IntelliJ and asked him how he liked it. He said he loved the extra features it offered such as refactoring and easy configuration. So I got a paid license from our company and gave it a shot. I immediately noticed the difference in editing speed and the extra features were indeed nice. I liked it so much that I recommended it to coworkers and stuck with it myself for about a year. During that year, however, is when I started my Vim journey.

Going Through the Motions

While watching YouTube, I started to notice that some of the creators I followed were editing at speeds miles faster than I was capable of. At this point in my career I knew what Vim was and had experienced the canon event of being unable to exit the editor (:qa! btw). It blew my mind that what I thought was an archaic editor allowed people to work that fast and seamlessly. I wanted that speed, but I didn't want to move my entire setup to Vim. The Primeagen had just the solution. He recommended that a good way in the door was to start with just the Vim motions and that most popular editors offer a plugin to enable them. Vim is a modal editor and the motions allow you to navigate those modes and offer tons of text editing efficiency. So, I installed the IDEAVim plugin and took the Primeagen's Vim motion courses.

My first day at work using my new setup was frustrating. My productivity took a nosedive. I struggled with the motions and was never able to get close to a flow state. At one point I turned them off to get a PR finalized. I later learned that was a mistake and that pushing through is the best course of action. Fortunately, I re-enabled them and continued to struggle for about 2 weeks. The pull to fall back on old habits was strong, but my desire for a better editing experience was stronger. Then, like learning to ride a bike my muscle memory kicked in and things started to click. I no longer had to think about the motions and was able to solely focus on the problem at-hand.

Neovim is Life

My boost in productivity felt incredible and not long after I decided I wanted even more and made the leap to Neovim. To keep things brief, Neovim is a fork of Vim which allows configuration in Lua making customizations more flexible and powerful. I decided that I wanted a fully custom configuration instead of something like LazyVim. I followed TJ DeVries' kickstart tutorial and made my own tweaks from there. Using Neovim at work took some more adjustment, but not nearly as much as learning the motions. I never felt the pull to go back to IntelliJ. Neovim is much lighter and faster than any other editor I've used and the motions being native was just the icing on top. I now have been using Neovim for over a year straight and don't see myself ever changing editors.

Creating a Basic 'useQuery' React Hook

Nicholas Coffey — Tue, 26 Jan 2021 22:29:32 +0000

This post can also be found on my personal blog.

Often times when creating a React application that fetches data, I find myself repeating the same fetch logic in multiple components. In order to make my code more DRY (Don't Repeat Yourself), I decided to extract this logic into one reusable custom hook.

An example component before the custom hook

import { Fragment, useEffect, useState } from 'react'
import axios from 'axios'

// type data from https://jsonplaceholder.typicode.com/posts
type Post = {
  userId: number
  id: number
  title: string
  body: string
}

export default function Posts() {
  const [posts, setPosts] = useState<Post[]>()
  const [error, setError] = useState<string>()
  const [loading, setLoading] = useState(true)

  useEffect(() => {
    axios
      .get<Post[]>('https://jsonplaceholder.typicode.com/posts')
      .then(res => {
        setPosts(res.data)
        setLoading(false)
      })
      .catch(err => {
        setError(err)
        setLoading(false)
      })
  }, [])

  if (error) {
    return <p>Error: {error}</p>
  } else if (loading) {
    return <p>Loading...</p>
  }

  return (
    <>
      {posts.map(({ title, body }, index) => (
        <Fragment key={index}>
          <h1>{title}</h1>
          <p>{body}</p>
        </Fragment>
      ))}
    </>
  )
}

The logic in the Posts component above allows for a reactive component that shows posts they are loaded, when posts are still loading, and when there is an error fetching the posts. However, if another component need the same logic, like a list of users, that component would need to copy this logic.

What are hooks?

Hooks are simply functions that have access to other React hooks like useState and useEffect. Unlike components, hooks can return whatever they want. This functionality is exactly what allows us to pull our data fetching logic into one reusable place.

Making a 'useQuery' Hook

import { useState, useEffect, useCallback } from 'react'
import axios, { AxiosResponse } from 'axios'

export default function useQuery<T>(url: string) {
  const [data, setData] = useState<T>()
  const [error, setError] = useState<string>()
  const [loading, setLoading] = useState(false)

  const handleError = (error: any) => {
    setError(error.response?.data.err)
    setLoading(false)
  }

  // this function is calling useCallback to stop an infinite loop since it is in the dependency array of useEffect
  const runQuery = useCallback(() => {
    const handleSuccess = (res: AxiosResponse<T>) => {
      setData(res.data)
      setLoading(false)
    }

    setLoading(true)
    axios.get<T>(url).then(handleSuccess).catch(handleError)
  }, [url])

  useEffect(() => {
    runQuery()
  }, [runQuery])

  return { data, loading, error, refetch: runQuery }
}

This new hook allows us to fetch data from an API, while checking for errors and whether or not it's still loading just like in the Posts component above! To briefly explain how it works, when the hook is first mounted it will call runQuery enabled by the useEffect hook. The runQuery function uses axios to call the url passed into the hook and sets the data, loading, and error states depending on the API's response like in the Posts component's useEffect call. Then, the hook returns an object containing the data, loading, and error states as well the runQuery function renamed to refetch in case a component needs to get the data again.

Using 'useQuery' in the Posts component

import { Fragment } from 'react'
import useQuery from './useQuery'

// type data from https://jsonplaceholder.typicode.com/posts
type Post = {
  userId: number
  id: number
  title: string
  body: string
}

export default function Posts() {
  const { data: posts, loading, error } = useQuery<Post[]>('https://jsonplaceholder.typicode.com/posts')

  if (error) {
    return <p>Error: {error}</p>
  } else if (loading) {
    return <p>Loading...</p>
  }

  return (
    <>
      {posts.map(({ title, body }, index) => (
        <Fragment key={index}>
          <h1>{title}</h1>
          <p>{body}</p>
        </Fragment>
      ))}
    </>
  )
}

As seen above, the Posts component is now much cleaner. Instead of calling useState three times, only one call to the new useQuery hook is needed. All that's required is a url string to be passed in as well as an optional generic type to make the returned data typed. Then after destructuring the returned object into separate posts, error, and loading constants, all the logic below should remain the same. This is great, but what is more valuable is the fact that this hook can now be used in all of our components! If a user list component was needed, as mentioned above, useQuery could be used again just like in the Posts component giving that Users component access to it's own data, loading, and error states.

Conclusion

I was pleasantly surprised how easy it was to make my own custom React hook. It took a little more work and time upfront but now have a reusable hook that I can use in any React application I build in the future!