Ben Ilegbodu

From Vibe Coding to Deliberation-First Coding with AI

Ben Ilegbodu — Wed, 25 Feb 2026 00:00:00 GMT

You give the Agent a prompt. It writes 200 lines of code. You review it. The architecture is wrong. You explain what you actually meant. It rewrites everything. Still not quite right. It misunderstood your data model. **10 or more iterations later**, you've got working code... and a lingering feeling that you could have just written it yourself faster. Sound familiar? Here's the thing: **the problem isn't the Agent. It's the process.** The write-review-write loop is the easiest approach, but it's inefficient and error-prone because the Agent makes incorrect assumptions without sufficient context. Yes, tools like [Cursor's Plan Mode](https://cursor.com/docs/agent/modes) try to help by asking clarifying questions upfront, but they don't go deep enough on shared context and decision-making. There's a better way. I call it **deliberation-first coding**: structured conversations with AI Agents that front-load shared context so the Agent implements _your_ decisions correctly the first time. The key insight? **The best AI conversations happen before any code is written.**

Being Sneaky with GenAI

Ben Ilegbodu — Thu, 08 Jan 2026 00:00:00 GMT

The AI hype cycle has convinced us that every app needs a conversational interface, a RAG pipeline, or an autonomous agent. Meanwhile, most of us are just trying to ship features, fix bugs, and (just) maybe reduce the amount of repetitive nonsense we do every day. The reality? **The highest ROI AI integration isn't a chatbot. It's the stuff users don't even notice.** I call it "Sneaky AI": using simple LLM API calls to eliminate toil, generate intelligent defaults, and make your existing features feel magical—without rewriting your architecture or hiring a PhD. If you're interested, I gave a talk on it at [All Things Open AI 2025](https://2025.allthingsai.org/) entitled ["Sneaky Ways to Integrate GenAI"](https://www.benmvp.com/ato-sneaky-ai).

How GenAI is shifting architecture left

Ben Ilegbodu — Wed, 12 Nov 2025 00:00:00 GMT

Have We Finally Reached the Mythical "10x Developer"?

Ben Ilegbodu — Tue, 07 Oct 2025 00:00:00 GMT

For decades, our industry has been obsessed with the "10x developer" -- that mythical engineer who's supposedly 10 times more productive than the rest of us. It's always been a bit of a loaded concept if you ask me, often rewarding behaviors that aren't necessarily great for teams or codebases. But with the arrival of powerful GenAI coding assistants, the "10x" conversation is back in full force. Here's the thing though: **we're thinking about it all wrong**. When I first started hearing the AI hype, it seemed like everyone was defining a 10x developer as someone who can crank out 10 times more code. As someone who now uses GenAI for 90%+ of my output (yep, including writing this blog post!), I can tell you that's a complete trap. If we're optimizing for lines of code, we're basically optimizing for bloat, complexity, and a whole lot of future technical debt. Not exactly what I'd call "winning." 😅 Don't get me wrong -- the GenAI revolution absolutely does unlock 10x potential. But it's not just about volume. It's about being 10x more **thoughtful**, 10x more **robust**, and 10x more **innovative** in how we approach our work. I've been thinking about this a lot lately, and I see this new kind of productivity happening across four key areas.

Mock all functions in a JavaScript module except one using Jest

Ben Ilegbodu — Sun, 01 May 2022 00:00:00 GMT

There are times in a Jest test when we have a module where the majority of the functions need to be mocked, but we have one (or two) that need to be left alone. Likely in this case most of the functions have side effects. But there are some that are normal input/output (aka "pure") functions that need to work when they are called during a test run. We can use a combination of [`jest.requireActual()`](https://jestjs.io/docs/jest-object#jestrequireactualmodulename) and [`jest.createMockFromModules()`](https://jestjs.io/docs/jest-object#jestcreatemockfrommodulemodulename). ```js // app.test.js // create a mock of the `../utils/players` module that is called // from `app.js` (the code being tested) jest.mock('../utils/players', () => { // use auto-mocking system to get an object that mocks all // of the module's functions, just like what `jest.mock()` // (w/ no parameters) would do const allAutoMocked = jest.createMockFromModule('../utils/players') // grab all the *real* implementations of the module's functions // in an object const actual = jest.requireActual('../utils/players') // return a new module implementation return { __esModules: true, // first start with all of the module's functions auto-mocked ...allAutoMocked, // then optionally include any override module mocks getPlayers: jest.fn(() => []), getTeams: jest.fn(() => []), // lastly override w/ any of the module's functions that // we want to use the *real* implementations for formatPlayerName: actual.formatPlayerName, } }) ``` If you are like how I was looking for how in Jest to mock a JavaScript module to keep the real implementation of one function, but mock the rest, here's your answer! 🎉 Feel free to return to your test code so you can continue writing high-quality tests. 😉 But... if you're interested in learning how all of this works, by all means, read on!

Create one-off releases with semantic-release

Ben Ilegbodu — Sun, 13 Mar 2022 00:00:00 GMT

I use [`semantic-release`](https://github.com/semantic-release/semantic-release) for both personal and work projects to automate version management and publishing of packages. It's nice because it takes care of the entire release flow, like figuring out the [next version](https://docs.npmjs.com/cli/v8/commands/npm-version) (using [Angular Commit Message Conventions](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-format)), auto-generating GitHub release notes, and finally [publishing the package](https://docs.npmjs.com/cli/v8/commands/npm-publish) to the npm registry. I like `semantic-release` for the handful of personal projects I work on because package publishing is a part of DivOps that I don't want to deal with. Developing the library is enough. 😃 At work `semantic-release` **provides a centralized point in CI that handles releasing a package** so that individual developers aren't trying to figure it out on their machines. The default `semantic-release` configuration does all that I described, so initially I could release without an explicit config. Then I use [npx](https://www.npmjs.com/package/npx) to run it in CI. For example, a `release.yml` [Github workflow](https://github.com/features/actions): ```yml name: Release on: push jobs: main: name: NPM Release runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Use Node v16 uses: actions/setup-node@v2 with: node-version: '16' - name: Install dependencies run: npm ci - name: Run unit tests run: npm test env: CI: true - name: Run integration tests run: npm run integrate env: CI: true - name: Release new version to NPM env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} NPM_TOKEN: ${{ secrets.NPM_TOKEN }} # highlight-next-line run: npx semantic-release ``` > I don't even install `semantic-release` as a dependency in the project. I always use the latest version. However, sadly the default configuration [still uses `master` as the default branch](https://github.com/semantic-release/semantic-release/issues/1581). Since all of my repos use `main` as the default branch, I now need a `release.config.js` to configure the [supported branches](https://github.com/semantic-release/semantic-release/blob/master/docs/usage/configuration.md#branches). ```js {3} module.exports = { branches: [ 'main', 'next', 'next-major', // version number branches will release that version '+([0-9])?(.{+([0-9]),x}).x', { name: 'beta', prerelease: true }, { name: 'alpha', prerelease: true }, ], } ``` And because all of my libs are written in TypeScript, I also have a build step before releasing the pacakge. The build step allows the project to transpile TypeScript into vanilla JavaScript and auto-generate TypeScript declaration files (`*.d.ts`). As a result, **I need to specifically configure the [`@semantic-release/npm` plugin](https://github.com/semantic-release/npm) to specify the build directory (typically `lib/` for me)**. But to configure the plugin, I also must include all of the [plugins](https://github.com/semantic-release/semantic-release/blob/master/docs/usage/configuration.md#plugins) used by default. ```js {19-21} module.exports = { branches: [ 'main', 'next', 'next-major', '+([0-9])?(.{+([0-9]),x}).x', { name: 'beta', prerelease: true }, { name: 'alpha', prerelease: true }, ], plugins: [ // analyzes commits w/ conventional-changelog '@semantic-release/commit-analyzer', // generates a changelog w/ conventional-changelog '@semantic-release/release-notes-generator', // publishes the npm package from the specified folder ['@semantic-release/npm', { pkgRoot: './lib' }] // Publishes changelog as a GitHub release and // comments on released Pull Requests & Issues '@semantic-release/github', ], } ``` > FYI: at work I also use [`semantic-release-slack-bot`](https://github.com/juliuscc/semantic-release-slack-bot) to get release notifications in Slack from a Slack bot, but I'm leaving it out to simplify the discussion. With the addition of the build step, the `release.yml` Github workflow now looks like: ```yml name: Release on: push jobs: main: name: NPM Release runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Use Node v16 uses: actions/setup-node@v2 with: node-version: '16' - name: Install dependencies run: npm ci - name: Run unit tests run: npm test env: CI: true - name: Run integration tests run: npm run integrate env: CI: true # highlight-start - name: Build package run: npm run build # highlight-end - name: Release new version to NPM env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} NPM_TOKEN: ${{ secrets.NPM_TOKEN }} run: npx semantic-release ``` Because `semantic-release` relies on a strict commit format (by default [Angular Commit Message Conventions](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-format)) in order to auto-determine the next version, **I also set up all of my GitHub projects to only support [squash merge commits](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#squash-and-merge-your-pull-request-commits) in Pull Requests**. I've found that it's the least painful way to ensure developers use the proper commit format because I also add another GitHub workflow to validate the Pull Request title using the [`amannn/action-semantic-pull-request`](https://github.com/amannn/action-semantic-pull-request) GitHub action. An example `validate-pr.yml` workflow file looks like: ```yml name: Pull Request on: pull_request_target: types: - opened - edited - synchronize jobs: main: name: Validate PR title runs-on: ubuntu-latest steps: ## highlight-next-line - uses: amannn/action-semantic-pull-request@v4 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} ```

Putting test files in the pages folder in a Next.js app

Ben Ilegbodu — Sun, 13 Feb 2022 00:00:00 GMT

When developing Next.js apps I want to be able to include other files within the `src/pages` directory besides the [page React components](https://nextjs.org/docs/basic-features/pages) or [API routes](https://nextjs.org/docs/api-routes/introduction). I'm perfectly fine putting components in `src/components` and helper functions in `src/utils`. But I like to co-locate other files with my pages and API routes. Instead of creating a parallel `__tests__` folder, I like putting my `*.test.ts` or `*.test.tsx` [Jest unit tests](https://jestjs.io/) next to whatever it is that I'm testing. That works great in `src/components`, `src/utils` or any other location outside of `src/pages`. Similarly, I like putting my [Storybook stories](https://storybook.js.org/) (`*.stories.tsx`) next to my React components, including my page components (made possible by [Storybook Addon Next Router](https://storybook.js.org/addons/storybook-addon-next-router)). But when I add these files within `src/pages` or `src/pages/api` and run `next build`, I get the following error: ```text Build error occurred Error: Build optimization failed: found page without a React Component as default export in pages/my/plan.stories See https://nextjs.org/docs/messages/page-without-valid-component for more info. ``` It's pretty nice that the error leads me to a place where I can find more info. I love when frameworks do this. But when I visit the [Page Without Valid React Component](https://nextjs.org/docs/messages/page-without-valid-component) page it gives a rather short explanation as to why the error ocurred, and some possible ways to fix it. The problem is that all the possible ways to fix it assume I somehow screwed up! 😢 I mean I guess I did screw up by putting other files in the `src/pages` folder, but it seems like something that should be allowed! Why is Next.js so picky about what files go in there? I guess since Next uses [page-based routing](https://nextjs.org/docs/basic-features/pages) it makes sense that it will have no way of interpreting page component files from test files or Storybook stories. So for the longest I just accepted my fate and put my stories in a sibling `src/page-stories` directory and just avoided writing unit tests, moving nearly everything into `src/utils`. But it felt a bit clunky. Then a coworker showed me a workaround! The [`pageExtensions` configuration](https://nextjs.org/docs/api-reference/next.config.js/custom-page-extensions) allows us to alter the default list of valid page extensions (`.tsx`, `.ts`, `.jsx`, and `.js`). The config option is aimed at tools like [`@next/mdx`](https://github.com/vercel/next.js/tree/canary/packages/next-mdx), which have files that end in `.mdx`. But we can take advantage of it to let us put non-page files in the `src/pages` folder as well. And it's right there in the [docs](https://nextjs.org/docs/api-reference/next.config.js/custom-page-extensions#including-non-page-files-in-the-pages-directory). We add special extensions for the page components and API routes to help Next.js distinguish them from all of the other files. ```js module.exports = { pageExtensions: [ // `.page.tsx` for page components 'page.tsx', // `.api.ts` for API routes 'api.ts', ], } ``` Because I exclusively develop in TypeScript, I only have TypeScript extensions. So all of my pages end in `.page.tsx`, such as `src/pages/my/plan.page.tsx`. And any of my API routes end in `.api.ts`, such as `src/pages/api/client/auth.api.ts`. I give the API routes their own extension, just for added clarity. And because page components will always have JSX, there's no need for `.page.ts`. Likewise, since API routes should never have JSX, there's no need for `.api.tsx`. Now I can have `plan.page.tsx`, `plan.test.tsx` and `plan.stories.tsx` all in the same `src/pages/my` folder! And the cool thing is if I want to add a `utils.ts` or `constants.ts` in the `src/pages` folder, it will also work. Who knew something so simple could be so exciting? 😂 Keep in mind, though, that this change also has to apply to any [Custom App](https://nextjs.org/docs/advanced-features/custom-app) (`src/pages/_app.tsx`), [Custom Document](https://nextjs.org/docs/advanced-features/custom-document) (`src/pages/_document.tsx`), and [Custom Error Pages](https://nextjs.org/docs/advanced-features/custom-error-page) (`src/pages/404.tsx` & `src/pages/500.tsx`) that we've defined. They'll all need the `.pages.tsx` extension.

Avoiding React act warning when accessibility testing next/link with jest-axe

Ben Ilegbodu — Sun, 30 Jan 2022 00:00:00 GMT

Recently when adding accessibility tests with [`jest-axe`](https://github.com/nickcolley/jest-axe) to a React component, I ran into the dreaded [`act()` warning](https://reactjs.org/link/wrap-tests-with-act): ```text {11-14} FAIL src/components/Link.test.tsx ✕ is accessible (70 ms) ● is accessible Expected test not to call console.error(). If the warning is expected, test for it explicitly by mocking it out using jest.spyOn(console, 'error') and test that the warning occurs. Warning: An update to Link inside a test was not wrapped in act(...). When testing, code that causes React state updates should be wrapped into act(...): act(() => { /* fire events that update state */ }); /* assert on the output */ This ensures that you're testing the behavior the user would see in the browser. Learn more at https://reactjs.org/link/wrap-tests-with-act at Link (.../node_modules/next/client/link.tsx:131:19) at Link (.../src/components/Link.tsx:15:5) ``` This specific test was testing a React component that wrapped [`next/link`](https://nextjs.org/docs/api-reference/next/link). ```js {14} import { render, screen } from '@testing-library/react' import { axe } from 'jest-axe' import Link from './Link' it('is accessible', async () => { const { container } = render( contents, ) expect(screen.getByRole('link')).toHaveAttribute( 'href', 'https://www.benmvp.com', ) expect(await axe(container)).toHaveNoViolations() }) ``` **But it turns out that any component that rendered a `next/link` had this exact same problem.** I googled around for some combination of "jest-axe", "next/link", and "act()" and surprisingly found very little. But there was nothing that was helpful or provided a solution. If I were to use [`act()`](https://testing-library.com/docs/react-testing-library/api#act) the way the warning message suggested, it would look something like: ```js {13,15} import { act, render, screen } from '@testing-library/react' import { axe } from 'jest-axe' import Link from './Link' it('is accessible', async () => { const { container } = render(contents) expect(screen.getByRole('link')).toHaveAttribute( 'href', 'https://www.benmvp.com', ) await act(async () => { expect(await axe(container)).toHaveNoViolations() }) }) ``` But I didn't want to have to write this `act()` code every time I decided to use `jest-axe` with a component that rendered a `next/link` (either directly or indirectly). Plus it would be highly likely that my teammates would get tripped up by it even if I did document the problem. **[React Testing Library](https://testing-library.com/docs/react-testing-library/intro/) wraps all of its [user events](https://testing-library.com/docs/ecosystem-user-event) with `act()` so that we don't have to.** But even still, the `act()` warning usually happens when we perform some non-UI action in a test that causes the component to re-render. All I did was render and add an accessibility assertion. The component shouldn't have been re-rendering. Well, after lots of debugging and sleuthing (more details below if you're interested), I finally came up with a workaround that avoided using `act()` everywhere. It requires installing [`react-intersection-observer`](https://github.com/thebuilder/react-intersection-observer) and using its test utils in the Jest configuration. ```js {3,7,15,16} // jest.config.js module.exports = { setupFiles: ['/jest.setupFiles.js'], setupFilesAfterEnv: [ '@testing-library/jest-dom', 'jest-axe/extend-expect', 'react-intersection-observer/test-utils', '/jest.setupFilesAfterEnv.ts', ], } // jest.setupFiles.js import { defaultFallbackInView } from 'react-intersection-observer' global.IntersectionObserver = jest.fn() defaultFallbackInView(false) ``` These few lines solve the problem! **It seems so simple, but it took me hours of struggling and wondering if I'd even find a workaround.** The solution is definitely not straightforward. So if you're having this problem right now and just need an answer so you can move on, there you have it! 😃 But if you'd like to know why it works and why it was even failing in the first place, feel free to read on! I want to take you through (a condensed version of) my debugging process so you can learn how to debug 3rd-party code, learn some things about JavaScript, and hopefully add some tools to your DivOps setup.

Handling the React server hydration mismatch error

Ben Ilegbodu — Mon, 17 Jan 2022 00:00:00 GMT

I was recently working on a React component in a shared component library. The component library up until recently had only been used in client-side rendered apps (think [Create React App](https://create-react-app.dev/)). However, once it started being used in server-sie rendered apps (think [Next.js](https://nextjs.org/)), I started getting the React server hydration mismatch error. For prop errors, the warning looks something like: ```text Warning: Prop `className` did not match. Server: "positive" Client: "zero" ``` or for text content: ```text Warning: Text content did not match. Server: "0" Client: "5" ``` Unlike most React warnings, this warning doesn't link to a doc explaining the warning in greater details with some suggested solutions (like for instance the [Invalid Hook Call Warning](https://reactjs.org/warnings/invalid-hook-call-warning.html)). There _are_ docs on the [`hydrate()`](https://reactjs.org/docs/react-dom.html#hydrate) function that does the client-side hydrating on a server-rendered app, but we'd have to know to find it. Let's walk through what's happening in my component. Here is a representation of the code: ```js const Incrementer = () => { // initialize the state from a value in `localStorage` // if it exists const [value, setValue] = useState(() => { // using lazy state initialization so that we only // read from `localStorage` the very first render let initValue // test for the presence of `window` because it // won't exist in Node for server-side rendering. // we'll only get the `localStorage` value in // the browser if (typeof window === 'object') { initValue = window.localStorage.getItem('value') } return initValue ? parseInt(initValue, 10) : 0 }) let className = 'zero' if (value < 0) { className = 'negative' } else if (value > 0) { className = 'positive' } return (

{value}

) } ``` > FYI: This is not the **actual** code in the component library. The actual code is a `useMedia()` Hook for tracking the match state of a media query in Javascript. That code is quite involved, so I've simplified it with this example. The component is a very standard minimal example that's used to show interactivity in a React component. The only difference is that it optionally retrieves its initial value from [`localStorage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage) using [lazy state initialization](https://reactjs.org/docs/hooks-reference.html#lazy-initial-state). If you don't know what lazy state initialization is or when you should use it, check out a previous post of mine called [Four characters can optimize your React component](https://www.benmvp.com/blog/four-characters-optimize-react-component/). **Because `window` doesn't exist in the Node environment during server-side rendering, the component first has to check if `window` exists before accessing `localStorage`.** Therefore, when the component is rendered server-side, `value` will always be `0`, the default value (`className` will also be `"zero"`). And when the component renders on the client-side, `window` will exist, and it can read from `localStorage` to get the initial value. The fact that React components can render server-side is pretty cool. But unfortunately this code doesn't quite work as expected. The server-side render actually works fine with the default `0` value. Also, if the component was only rendered client-side, the component renders fine as well (reading from `localStorage` if the stored value exists). But it's when the component is _hydrating_ on the client from server rendered HTML that we have a problem. **React expects the initial render on the client to match what was rendered on the server.** To get a better understanding of hydration, read [Josh W. Comeau](https://twitter.com/joshwcomeau)'s blog post, [The Perils of Rehydration](https://www.joshwcomeau.com/react/the-perils-of-rehydration/#two-pass-rendering). But if the component gets a value from `localStorage` (let's say `"15"`) with the initialization of state, both `value` (`15`) and `className` (`"positive"`) will be different than the default values (`0` and `"zero"`) rendered on the server. And when what is hydrated on the client differs from what was server-rendered, we get the server hydration error. ```text Warning: Text content did not match. Server: "0" Client: "15" ``` And the real error isn't actually the warning. The real problem is that our UI is "stale." **React doesn't update the UI to match the props that were rendered differently by the client during hydration.** Instead it keeps the attributes that were already in the markup from the server-side rendering. React _does_ update the text content, however. So in our example, `15` will be rendered in the ``. But because it does _not_ update props, the `className` will still be `"zero"` (instead of `"positive"`).

Creating custom generic TypeScript utility types

Ben Ilegbodu — Tue, 21 Dec 2021 00:00:00 GMT

I was recently working on my latest project, which uses [Firestore](https://firebase.google.com/) as its NoSQL database. The way the data is stored in Firestore is _almost_ how I represent the data in app. The only difference is that Firestore has its own object for modeling dates that is different than the JavaScript [Date](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date) object. So in order to avoid having to write almost identical types for both the internal and Firestore representations of an object (and keep them in sync over time), I created a generic TypeScript utility type that would recursively replace all `Date` types to Firebase [`Timestamp`](https://github.com/firebase/firebase-js-sdk/blob/2e7586dd7320d48d4b58aa13b525ec4a599f87e2/packages/firestore/src/lite-api/timestamp.ts) types in any type whether it's an interface, array or something else. ```typescript // A generic type that returns a new type by returning a // `Timestamp` if the generic parameter is a `Date`. // Or, if given an array type, it returns the same // array type except replacing the item `Date` types w/ // `Timestamp` types. Does the same for object value // types as well. Otherwise, just returns the type back. type ToFirestore = MaybeDate extends Date ? Timestamp : MaybeDate extends Array ? Array> : MaybeDate extends Record ? { [Key in keyof MaybeDate]: ToFirestore } : MaybeDate ``` > See the code in action on the [TS Playground](https://www.typescriptlang.org/play?#code/PTAEFkHsGMGtQE4FMAOyDOSB2AXAhjgJaRaiQBmoeoAYoRjpMqAAYAqhAtkuvpyi1A4AniiQAoQriQJyeaElAduvPP1ABvcaB2IkeACYkANsNCZoJA+gBcoLAFdOAIxkAabbuSGTZrHixICytbeydXBHEAX3FxEFAAQVAAc2wZQmghUUUcAAsCPRwHBCx0KnskAHcssVBnM2Qikqlkqjiwdi4ePgFQQko8xVSsdMyUPAQ1JBwZPrLqFgARAiQWADp20AB5BDc+ymTCADdsKlIJybMRMT3CHELi0qFcxXQpzYu8K+zQJAAPBQoe7IFDGeQtZ6KO5ITisZYzQTXHigSrATadFQ9RHZdBrUCLSDIwbmKagchMMjOABWSGg9yOeGMDgk8SR8zKlSQxmMeK2gwQlUImD2VIcvAeJTKxKRdXksA2MrYkDoDCYSAAPOAvq54UgAHygAC8EG1SF1vz+Myw1nxK08AH4lF1VPxPHYtcIdSsLVabQkEJd1VJyLMAJIzTh6h2JANfdVKlXdNXq8MwvVRnTu03m-6+soAJVpTAM6t4CBaewCwgzoEdGlAAG0ANJIMxSUCwVsUE2es0rAC6dgT9CTyE12ZWzdb-YNMUzPa9M1iUhmsnkigACmDSFodJZuXhnEwCExQmWWg3+55oN4ZgY7LrPAYudMkAZ7Q+7TpCPfzDhy1gySeNwjKhLuuigAYKyfkuEHIOQdjnoBng6EidgAOTON4sByLw6GgAAPqAmEIA4WDQLk+FEehTLkZRhHEQYUgjAgVHEeg-hwOhnhRJeniqEUoToWx6FoFwEzCCJEwUccb7cTonCQEx5CEG+MESDo-jcIh-4tJ4kCVCxOkAUBOhHEKhDOIQxh3MIGFiQyMwiTZWCwAAtL4IkoA4zg2dA3ExJsAASkAnAgZBhawia8GqW4BIikDmEgUI4GUz4qVgdzEKQgp5OiyjdGovRsn0pCguuZCUEsKzYmI6DiDK0WMMgcWkMaw6qmOrVRg1PxIkk7XKiOMVjkhyRRjKSIAEJGkoQ2dRqjguDIl4TX12QAMKzR1o4avWWlIMZFZUKkdhLREoBRFGQA). This post is the third post in a series on TypeScript generics. The first post introduced generics by [re-implementing lodash functions](/blog/understanding-typescript-generics-lodash-functions/). In the second post, we [learned TypeScript generics by rebuilding existing utility types](/blog/learn-typescript-generics-rebuilding-existing-utility-types/). Now in this final post we're creating our own custom generic utility types using everything we've learned.

TypeScript user-defined type guards to the rescue

Ben Ilegbodu — Sun, 05 Dec 2021 00:00:00 GMT

Recently I was writing some TypeScript code where I needed to look at the user's preferred languages (using [`Navigator.languages`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/languages)) and compare it against my site's valid locales in order to determine which locale to display for internationalization (I18N). Here's what some of the implementation looked like: ```typescript const ALL_LOCALES = [ 'en-US', 'en-GB', 'en-CA', 'fr-CA', 'fr-FR', 'es-ES', 'es-US', ] as const // derive `Locale` type from `ALL_LOCALES` data type Locale = typeof ALL_LOCALES[number] // ⮑ "en-US" | "en-GB" | "en-CA" | "fr-CA" | "fr-FR" | "es-ES" | "es-US" const DEFAULT_LOCALE: Locale = 'en-US' // A `Set` to make it easy to see if a language string // is a valid locale const VALID_LOCALES_LOOKUP = new Set(ALL_LOCALES) // user-defined type guard that takes in a language string and returns // whether it is one of the valid locales const isValidLocale = (language: string): language is Locale => VALID_LOCALES_LOOKUP.has(language) // finds the first user language that is a valid locale or the default locale const getUserLocale = (): Locale => navigator.languages.find(isValidLocale) || DEFAULT_LOCALE ``` To understand how this all works, we need to first understand [narrowing](https://www.typescriptlang.org/docs/handbook/2/narrowing.html) in TypeScript. **TypeScript's type system aims to make it as easy as possible to write typical JavaScript code without having to do too much to get type safety.** So if we have a variable that is a union of multiple types, we can use various different JavaScript constructs to _narrow_ down the type. The simplest construct is [truthiness narrowing](https://www.typescriptlang.org/docs/handbook/2/narrowing.html#truthiness-narrowing). ```typescript const getTeamMessage = (team?: Team) => { // `team` has type `Team | undefined` if (team) { // Because `team` is "truthy" TS knows that // it *cannot* be `undefined`, so its type // is just `Team` return `Welcome ${team.name}!` } // Because of the `return` above, TS knows that // `team` can only be `undefined` here return 'Welcome!' } ``` There's nothing really spectacular about the code. It's normal JavaScript, but TypeScript understands "JavaScript-isms." It's able to infer the type of `team` inside and after the `if` statement based on the [truthiness](https://developer.mozilla.org/en-US/docs/Glossary/Truthy) condition. Truthiness narrowing basically can only exclude `null` and `undefined` from a type, but there are other JavaScript constructs that can do more, like [`typeof` type guards](https://www.typescriptlang.org/docs/handbook/2/narrowing.html#typeof-type-guards) and [`instanceof` narrowing](https://www.typescriptlang.org/docs/handbook/2/narrowing.html#instanceof-narrowing). ```typescript const log = (time: Date | string, message: string) => { // if `time` is an instance of the `Date` class, then TS knows // we can call `.toUTCString()` because it's a `Date` type. It also // knows that in the "else" case of the ternary, `time` is a `string` const timestamp = time instanceof Date ? time.toUTCString() : time // ⮑ `string` console.log(`[${timestamp}] ${message}`) } interface Option { value: string display: string } const getDisplay = (option: Option | string): string => // if `option` is a JS object then TS infers that it's an `Option` // object. So in the "else" case, `option` must be a `string` typeof option === 'object' ? option.display : option ``` In both examples we're using built-in JavaScript operators that return rudimentary type information: [`typeof`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/typeof) and [`instanceof`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/instanceof). Depending on the types in the unioned type, using one operator or the other can help TypeScript narrow down the possible types when you can call the method ([`.toUTCString()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toUTCString)) or access the property that you care about. But what happens if you have two objects types, neither of which are class instances? Using `typeof` or `instanceof` won't help. Depending on the properties of the objects, we can make use of [`in` operator narrowing](https://www.typescriptlang.org/docs/handbook/2/narrowing.html#the-in-operator-narrowing). ```typescript interface Team { name: string city: string revenue: number } interface Player { firstName: string lastName: string position: 'guard' | 'wing' | 'big' team: Team } const getName = (item: Team | Player) => // if `item` has a `city` property, then TS infers that it's // a `Team` object because `Team` is the only object w/ that property. // As a result in the "else" case, `item` must be a `Player` 'city' in item ? item.name : `${item.firstName} ${item.lastName}` ``` Both `Team` and `Player` are plain JavaScript objects so `instanceof` won't work and `typeof` will return `"object"` for both. However we can use the [`in` operator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/in) (also see [Using new-ish & lesser-known JavaScript operators to write concise code](/blog/using-javascript-operators-write-concise-code/) for more) to see if a unique property is on the `item` object. **Because `"city"` only exists on `Team` objects, TypeScript is now able to disambiguate the type and the ternary expression becomes fully type-safe.** JavaScript isn't a fully-typed language so the built-in constructs can only help TypeScript so much. Sometimes we have to give TypeScript a hand with narrowing and define our own type guard. That's where [type predicates](https://www.typescriptlang.org/docs/handbook/2/narrowing.html#using-type-predicates) within user-defined type guards come in. ```typescript const ALL_LOCALES = [ 'en-US', 'en-GB', 'en-CA', 'fr-CA', 'fr-FR', 'es-ES', 'es-US', ] as const // derive `Locale` type from `ALL_LOCALES` data 🤓 type Locale = typeof ALL_LOCALES[number] // ⮑ "en-US" | "en-GB" | "en-CA" | "fr-CA" | "fr-FR" | "es-ES" | "es-US" const DEFAULT_LOCALE: Locale = 'en-US' // A `Set` to make it easy to see if a language string // is a valid locale const VALID_LOCALES_LOOKUP = new Set(ALL_LOCALES) // user-defined type guard that takes in a language string and returns // whether it is one of the valid locales const isValidLocale = (language: string): language is Locale => VALID_LOCALES_LOOKUP.has(language) ``` > A trick to derive a union type from an array is to first mark the array with a [`const` assertion](/blog/use-cases-typescript-const-assertions/). Then using `typeof` plus `ARRAY_NAME[number]` will generate a union type. The `number` isn't the `number` type but instead a generic value for "all indices." A `Locale` is one of a handful of specific `string`s (`"en-US"`, `"fr-FR"`, etc.) so there's no way for us to distinguish a `Locale` from a `string` with regular JavaScript. The `language is Locale` return type of `isValidLocale()` is the _type predicate_ that allows us to write actual code to determine if the parameter (`language`) is in fact the desired type (`Locale`). The function is the _user-defined type guard_. **The return value must be a boolean.** When `true`, the type predicate is true and TypeScript infers that the parameter is the desired type. Like with the other narrowing examples, we could use the user-defined type guard in a simple conditional. ```typescript const getUserLocale = (): Locale => // if the language is a valid locale, TS now treats // `navigator.language` as a `Locale` even though it's // been defined as a `string` isValidLocale(navigator.language) ? navigator.language : DEFAULT_LOCALE ``` Typically [`Navigator.language`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/language) is a `string`. But with the user-defined type guard returning `true`, `navigator.language` is now narrowed to a `Locale`, a union of those locale strings. The `navigator.language` property only returns the first of the user's preferred languages. Because its possible that their primary preferred language could be an invalid locale for my site, I needed to check all of their preferred languages using [`Navigator.languages`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/languages). This made the `getUserLocale()` function a bit more complicated. ```typescript // finds the *first* user language that is a valid locale, // or uses the default locale if a valid one can't be found const getUserLocale = (): Locale => // use the user-defined type guard as the test function for `.find()`. When // it returns true, TS infers that the found item is also a `Locale`. navigator.languages.find(isValidLocale) || DEFAULT_LOCALE ``` The `navigator.languages` property is a `string[]`. The [`.find()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/find) method takes a test function that returns true when an array item passes the test. Because `isValidLocale` does the same thing, we can pass it to `.find()`. But since it's not just a regular function but a type predicate, TypeScript now knows that the found item in the `string[]` is specifically a `Locale`. A user-defined type guard can also be used with [`.filter()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/fill) to not only filter down the elements but filter down the types as well. ```typescript // returns a list of the user languages that are also valid locales const getUserLocales = (): Locale[] => // by using the user-defined type guard as the test function for // .filter()` TS knows that the returned array can only be // `Locale` items navigator.languages.filter(isValidLocale) ``` > I wrote a post almost exactly a year ago called [Filtering undefined elements from an array in TypeScript](/blog/filtering-undefined-elements-from-array-typescript/) which makes use of user-defined type guards with `.filter()`.

React Testing Library best practices

Ben Ilegbodu — Sun, 21 Nov 2021 00:00:00 GMT

In my opinion, [ESLint](https://eslint.org/) is one of the best ways to communicate best practices for JavaScript code because it doesn't require everyone to read and follow a document or blog post. Instead it notifies the individual developer that they have broken a rule. A rule which itself typically has docs explaining the rule and how to fix it. **So without intervention from a senior developer or "expert", ESLint is able to communicate best practices.** And if the best practices change, the ESLint rules is updated, a new version of the plugin is released, and the offending code starts failing. I've been using [React Testing Library](https://testing-library.com/docs/react-testing-library/) for several years now. After using [Enzyme](https://enzymejs.github.io/enzyme/) for many years prior, I found RTL to be a much better approach to testing React applications. Read [React Testing Library over Enzyme](/blog/react-testing-library-over-enzyme/) for more of my thoughts on the differences if you're interested. Although I've been using React Testing Library for a while, I only started recently using [`eslint-plugin-testing-library`](https://github.com/testing-library/eslint-plugin-testing-library). It codifies a whole bunch of best practices. Some of which had changed from when I had first learned RTL. So I want to walk through 5 groups of those best practices to help us write healthier and more resilient React tests.

TypeScript React props: interfaces vs type aliases

Ben Ilegbodu — Sun, 14 Nov 2021 00:00:00 GMT

The first lesson in my [TypeScript for React Developers minishop](/minishops/typescript-for-react-developers/) is how to define the type of the `props` object passed to React component functions. And usually there will be someone who's already dabbled in TypeScript who asks me why I choose to use an `interface` instead of a `type` alias for defining the props. The short answer is that **interfaces and type alias are effectively interchangeable for defining objects in TypeScript.** My assumption is that interfaces and type aliases used to have more differences between them, but as TypeScript has evolved they've both received upgrades to the point where they are now seemingly identical. The original TypeScript docs [suggested using an `interface`](https://www.typescriptlang.org/docs/handbook/advanced-types.html#interfaces-vs-type-aliases) over a `type` alias when possible, so that's what I've always done. But there are some nuances when one may make sense over the other. Instead of focusing on the technical differences, I want to spend this post focusing on the practical times we would use one over the other.

Wrapping next/link to use with a custom UI Link component

Ben Ilegbodu — Sun, 07 Nov 2021 00:00:00 GMT

[Next.js](https://nextjs.org/) has a pretty snazzy file-system based [router](https://nextjs.org/docs/routing/introduction) that is built on the concept of [pages](https://nextjs.org/docs/basic-features/pages). The router allows us to do client-side route transitions between pages similar to a single-page application (aka SPA). Next exports a React component called [`Link`](https://nextjs.org/docs/api-reference/next/link) to automatically handle these client-side route transitions. ```js import Link from 'next/link' const Home = () => { return (

Home
About Us
Blog Post

) } export default Home ``` **But the Next `` renders a vanilla `` tag with no styling**, which pretty much no one is going to want. We may throw a `className` on the `` for styling, but more than likely we have a custom `` component of our own that handles the styling. I use the fantastic [MUI](https://mui.com/) React component library for my personal projects, and it has its own [`Link` component](https://mui.com/components/links/). So with MUI, the example becomes: ```js {8,13,18} import NextLink from 'next/link' import { Link as MuiLink } from '@mui/material' const Home = () => { return (

Home
About Us
Blog Post

) } export default Home ``` Notice that we had to add the [`passHref`](https://nextjs.org/docs/api-reference/next/link#if-the-child-is-a-custom-component-that-wraps-an-a-tag) prop to the `` so that the `href` is passed down to the ``. Otherwise we'd have to duplicate the `href` prop on both the `` and the `` components. > It's important to note that if your component library's `Link` component is a function component (more than likely it is given Hooks), it must wrap the component in [`React.forwardRef`](https://reactjs.org/docs/forwarding-refs.html). **But having to do this double `` dance every time we want to render a styled link gets annoying**, especially if we're passing more props to the `` and ``. So what I typically do in my Next apps is create a lightweight custom `Link` component that wraps both `next/link` and MUI `Link`. ```js import { forwardRef } from 'react' import NextLink from 'next/link' import { Link as MuiLink } from '@mui/material' /** * A convenience component that wraps the MUI `Link` component that provides * our look & feel with Next's router `Link` * * @see https://next.js.org/docs/api-reference/next/link */ const Link = forwardRef(function Link( { href, prefetch, replace, scroll, shallow, locale, ...muiProps }, ref, ) { return ( ) }) export default Link ``` The component isn't terribly complex. It takes in the props and passes the appropriate ones to the underlying `` versus the ``. Because it's a function component, it also uses [`forwardRef`](https://reactjs.org/docs/forwarding-refs.html) so that it can still support refs like the underlying ``. > I use a function declaration (`function Link`) instead of my typical arrow function so that the component definition within `forwardRef` still has a component name (`Link`). It helps with debugging in the DevTools so that it'll say `ForwardRef(Link)` instead of just `ForwardRef`. But since I develop in React with TypeScript, my `Link` component actually looks like this: ```tsx {7-8,16} import { forwardRef } from 'react' import NextLink, { LinkProps as NextLinkProps } from 'next/link' import { Link as MuiLink, LinkProps as MuiLinkProps } from '@mui/material' // `LinkProps` is the combination of the MUI `LinkProps` and the Next `LinkProps` // We wanna use the `href` prop from `next/link` so we omit it from MUI's. export type LinkProps = Omit & Omit /** * A convenience component that wraps the MUI `Link` component that provides * our look & feel with Next's router `Link` * * @see https://next.js.org/docs/api-reference/next/link */ const Link = forwardRef(function Link( { href, prefetch, replace, scroll, shallow, locale, ...muiProps }, ref, ) { return ( ) }) export default Link ``` The main difference here is the `LinkProps` type definition. ```typescript type LinkProps = Omit & Omit ``` **It ensures that we only can pass in valid props for our new `` component.** How it's defined is also important. First we take all the props of our component library's `Link` component (`MuiLinkProps` in this case), but omits the `href` prop. This is because it is also defined in `NextLinkProps` and we want to ensure that we use the type definition for `href` from `next/link` because it supports both a `string` as well as a [`URL` object](https://nodejs.org/api/url.html#url_url_strings_and_url_objects). Then we intersect (or extend) all of the props from `NextLinkProps`. I personally also exclude the [`as`](https://nextjs.org/docs/tag/v9.5.2/api-reference/next/link#dynamic-routes) prop because it's basically legacy functionality. We can omit `passHref` and `children` as well because we're explicitly setting them on `` (the `children` of `` is the ``). Lastly, we update `forwardRef()` to include the ref type and component props type as the generic params: `forwardRef`. So now back in our home page component, we can use our new `` component. ```js {7,10,13} import Link from '../components/Link' const Home = () => { return (

Home
About Us
Blog Post

) } export default Home ``` Now we're back to it _feeling_ like we're just using our component library `` component, but with all of the bells and whistles of `next/link`. 🎉 One more thing before we finish. The `next/link` only works for local links. It does nothing for external links. **In fact, using it for external links results in a bunch of wasted work.** So it's better if we just use our component library's `` component directly. ```js {17} import { Link as ExternalLink } from '@mui/material' import Link from '../components/Link' const Home = () => { return (

Home
About Us
Blog Post
Ben Ilegbodu

) } export default Home ``` I explicitly name the component library's link component `ExternalLink` to make it abundantly clear that it's only to be used for external links. Our custom `` component that wraps `next/link` is the default one to use. Alternatively, I could update the custom `Link` component to be smarter and only render a `` when the url is external, but then it would need all the logic to resolve the `href` to a `string` if it's a `URL` object and then detect whether or not a URL string is external. That's more work than I'm willing to put in. 😅

What is a DivOps Engineer and what do they do?

Ben Ilegbodu — Sun, 31 Oct 2021 00:00:00 GMT

I've written a number of _DivOps_-focused posts ([5 tips for a healthier DivOps setup](/blog/5-tips-healthier-divops-setup/), [50 shades of React rendering with Next.js](/blog/50-shades-react-rendering-nextjs/), and [Auto-generate React PropTypes from TypeScript components](/blog/auto-generate-react-prop-types-typescript-components/) just to name a few). But I've never actually explained what _DivOps_ is. It's a play on words for [DevOps](https://www.atlassian.com/devops) which is a well-defined role bridging the gap between software development and IT operations. DivOps to me is the bridge between frontend web development and traditional DevOps. **So a DivOps engineer writes code for web frontend applications and libraries, but rarely is any of it shipped to Production or what users interact with.** Instead they write all of the tooling and configuration code _outside_ of the `src` folder that's needed for an app or lib to run. Although I write a lot about DivOps, I can't take full credit for the term. [Enrique](https://twitter.com/chochosmx) coined the term with this tweet:

Frontend engineers who also manage infra should be called
ops
— Enrique staying ~ (@chochosmx) October 12, 2019

And my friend [Jonathan Creamer](https://twitter.com/jcreamer898) made it "official" by [creating the #DivOps community](https://www.jonathancreamer.com/announcing-div-ops/). Check out the [r/divops](https://www.reddit.com/r/divops/) subreddit and [DivOps Discord server](https://discord.gg/Vvk67JDX6t) to join the community. I have yet to see an explicit role for a "DivOps Engineer," but I think we're getting close. **Typically those fulfilling the role are Frontend Engineers working on the frontend platform (possibly even on a Frontend Platform team), but are not working on the design system or component library.** These developers are likely focused on DivOps. I would like to see companies create explicit roles for this work because it's highly valuable and critical. In my opinion, formalizing the role legitimizes the work and provides a 3rd path in frontend engineering. In addition to UI development (visual + interaction) or app development (state + API management), there's now DivOps. So I want to list out the high-level areas of work to which a DivOps engineer contributes, as well as some of the tooling within each area.

Learn TypeScript generics by rebuilding existing utility types

Ben Ilegbodu — Sun, 24 Oct 2021 00:00:00 GMT

TypeScript's type system is very powerful because it allows us to express types in terms of other types. One way we do this is with [generics](https://www.typescriptlang.org/docs/handbook/2/generics.html), which are types that take parameters. A lot of times when we get started with generics, we actually use them directly within functions (see my previous post on [Understanding TypeScript generics through lodash functions](https://www.benmvp.com/blog/understanding-typescript-generics-lodash-functions/)). But when we use them to create reusable types, we can create really powerful types much like the built-in [utility types](https://www.typescriptlang.org/docs/handbook/utility-types.html). So I want to break down some existing TypeScript utilty types in order for us to better understand how TypeScript generics work. I personally learn best by seeing real-world examples. Somehow seeing something new in the context of something familiar helps me make the connection. I hoping it'll do the same for you. Without further ado, let's dig in.

How to extract React component logic into a custom Hook

Ben Ilegbodu — Sun, 17 Oct 2021 00:00:00 GMT

[React custom Hooks](https://reactjs.org/docs/hooks-custom.html) are kind of like logic helpers for our React components, so that the components themselves can focus on rendering and user interactions. Commonly folks will extract component logic into a custom Hook when they need to reuse the logic in multiple components (such as [`useMedia`](https://github.com/streamich/react-use/blob/master/docs/useMedia.md), [`useClickAway`](https://github.com/streamich/react-use/blob/master/docs/useClickAway.md), [`useEffectOnce`](https://github.com/streamich/react-use/blob/master/docs/useEffectOnce.md), and [many others](https://github.com/streamich/react-use)). But I will also make a single-use custom Hook simply when the logic is large or complex. In my opinion, it makes it easier to reason about the logic and UI separately. Let's say we have a hypothetical page that has a list of teams and a list of players. And at the top it has filters for both the teams and players. ```js import { useEffect, useState } from 'react' const Page = () => { const [teamsFilter, setTeamFilter] = useState('') const [teams, setTeams] = useState([]) const [playersFilter, setPlayersFilter] = useState('') const [players, setPlayers] = useState([]) useEffect(() => { // page is mounted once `useEffect()` is called let isMounted = true window .fetch(`https://api.benmvp.com/teams?q=${teamsFilter}`) .then((res) => res.json()) .then((data) => { // only set state if page is still mounted if (isMounted) { setTeams(data.teams) } }) window .fetch(`https://api.benmvp.com/players?q=${playersFilter}`) .then((res) => res.json()) .then((data) => { // only set state if page is still mounted if (isMounted) { setPlayers(data.players) } }) return () => { // page is no longer mounted when cleanup func is called isMounted = false } // makes both API calls when either filter changes 👎🏾 }, [teamsFilter, playersFilter]) return (

) } ``` > If you're wondering about the `isMounted` check after we receive the data from the API, it's to ensure that the component wasn't unmounted during the time that we made the API request and got back the response. Read [Handling async React component effects after unmount](/blog/handling-async-react-component-effects-after-unmount/) for more details on the problem and solution. The component makes two API requests any time the `TeamsFilter` or `PlayersFilter` change. But it's inefficient because only one filter can change at a time, yet we make requests to both APIs. So if we're changing the `TeamsFilter` we're still retrieving the same `players` data over and over. We can fix by splitting up the single `useEffect()` call into two of them. ```js import { useEffect, useState } from 'react' const Page = () => { const [teamsFilter, setTeamFilter] = useState('') const [teams, setTeams] = useState([]) const [playersFilter, setPlayersFilter] = useState('') const [players, setPlayers] = useState([]) // separate the teams `useEffect()` from the players one so that // we only retrieve data for the one that has changed useEffect(() => { let isMounted = true window .fetch(`https://api.benmvp.com/teams?q=${teamsFilter}`) .then((res) => res.json()) .then((data) => { if (isMounted) { setTeams(data.teams) } }) return () => { isMounted = false } }, [teamsFilter]) useEffect(() => { let isMounted = true window .fetch(`https://api.benmvp.com/players?q=${playersFilter}`) .then((res) => res.json()) .then((data) => { if (isMounted) { setPlayers(data.players) } }) return () => { isMounted = false } }, [playersFilter]) return (

) } ``` As you can see the component is dominated by what I call the component logic. This is all the state management code: the state itself (`teams` & `players`), the API calls and updating the state (`setTeams` & `setPlayers`). So what I would probably do now is break out the teams state management code and the players state management code into their own [custom React Hooks](https://reactjs.org/docs/hooks-custom.html). ```js import { useEffect, useState } from 'react' // Take a filter and return the teams when we // get the data const useTeams = (filter = '') => { const [teams, setTeams] = useState([]) useEffect(() => { let isMounted = true window .fetch(`https://api.benmvp.com/teams?q=${filter}`) .then((res) => res.json()) .then((data) => { if (isMounted) { setTeams(data.teams) } }) return () => { isMounted = false } }, [filter]) // at first `teams` will be `[]` but after the API // response, it'll return again with the API data // (provided the component is still mounted) return teams } // Take a filter and return the players when we // get the data const usePlayers = (filter = '') => { const [players, setPlayers] = useState([]) useEffect(() => { let isMounted = true window .fetch(`https://api.benmvp.com/players?q=${filter}`) .then((res) => res.json()) .then((data) => { if (isMounted) { setPlayers(data.players) } }) return () => { isMounted = false } }, [filter]) // at first `teams` will be `[]` but after the API // response, it'll return again with the API data // (provided the component is still mounted) return players } const Page = () => { const [teamsFilter, setTeamFilter] = useState('') const [playersFilter, setPlayersFilter] = useState('') const teams = useTeams(teamsFilter) const players = usePlayers(playersFilter) return (

) } ``` Overall the code is a bit longer than it was before, but I would argue that it is easier to reason about now that the component logic is split out into the `useTeams()` and `usePlayers()` custom Hooks. We can think of custom Hooks in much the same way we thinking about regular JavaScript helper/utility functions that extract logic. The unique aspect about custom Hooks is that they can call other Hooks. And when the state within the custom Hook updates, the component that calls the Hook also is re-rendered in order to retrieve the new data! Now instead of the `Page` component maintaining the `teams` and `players` states directly, it gets them `useTeams()` and `usePlayers()`, respectively. The `useTeams()` and `usePlayers()` custom Hooks are only being used once, but I extracted them just to "clean up" the component. What it's responsible for now is greatly simplified. In my opinion, it's much easier to follow what's happen in `Page`. The extraction also allows me to now zero in on the logic of the Hooks themselves. There are still some commonalities between `useTeams()` and `usePlayers()`. They both make API calls, and they both check the mounted state before setting the state. Let's try extracting _that_ logic into a `useFetch()` custom Hook. ```js import { useEffect, useState } from 'react' // given a url fetch the data and return the JSON // response, provided that the component is still // mounted const useFetch = (url) => { const [jsonData, setJsonData] = useState(undefined) useEffect(() => { let isMounted = true window .fetch(url) .then((res) => res.json()) .then((data) => { if (isMounted) { setJsonData(data) } }) return () => { isMounted = false } }, [url]) // at first `jsonData` will be `undefined but after the API // response, it'll return again with the API data // (provided the component is still mounted) return jsonData } const useTeams = (filter = '') => { const data = useFetch(`https://api.benmvp.com/teams?q=${filter}`) // if `data` or `data.teams` is `undefined` return `[]` return data?.teams ?? [] } const usePlayers = (filter = '') => { const data = useFetch(`https://api.benmvp.com/players?q=${filter}`) // if `data` or `data.players` is `undefined` return `[]` return data?.players ?? [] } const Page = () => { const [teamsFilter, setTeamFilter] = useState('') const [playersFilter, setPlayersFilter] = useState('') const teams = useTeams(teamsFilter) const players = usePlayers(playersFilter) return (

) } ``` > If the [`?.` (optional chaining)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining) or [`??` (nullish coalescing)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Nullish_coalescing_operator) operators are new to you, check out my [Using new-ish & lesser-known JavaScript operators to write concise code](/blog/using-javascript-operators-write-concise-code/) post that explains them and other cool operators you might not yet know (but totally should). Now the `useTeams()` and `usePlayers()` custom Hooks have been hollowed out. Their `data` is initially `undefined` prior to the API request in `useFetch()`. And then when `useFetch()` gets back the JSON data, it'll set it only if the `useEffect()` hasn't been cleaned up. As a result of the state update in `useFetch()`, the `useTeams()` or `usePlayers()` Hooks re-run to get the new `data` which will be returned back to the `Page` component. And now that we have a rather generic `useFetch()` helper we can add more functionality to it (like having a loading state or error handling) without adding complexity to the `Page` component or even the `useTeams()` and `usePlayers()` custom Hooks. That's the power of React custom Hooks.

React useCallback & useMemo use cases

Ben Ilegbodu — Sun, 10 Oct 2021 00:00:00 GMT

I went a long while writing React with Hooks without using the [`useCallback()`](https://reactjs.org/docs/hooks-reference.html#usecallback) or [`useMemo()`](https://reactjs.org/docs/hooks-reference.html#usememo) Hooks. And even now I still hardly use `useMemo()`. So that's all to say that we can build perfectly fine React applications without knowing or using either Hook. However, I'm frequently asked to explain when and why we would use `useCallback()` or `useMemo()` so I figured I might as well take some time to explain when I use them most frequently. Pretty much it comes down to maintaining [referential (strict) equality](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Equality_comparisons_and_sameness) in the dependencies of Hooks, or avoiding recalculating expensive computations.

Successfully using async functions in React useEffect

Ben Ilegbodu — Sun, 26 Sep 2021 00:00:00 GMT

JavaScript [async functions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function) making dealing with [promises](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) a bit simpler because it flattens out nested promises into sequential statements. But using async functions within React's [`useEffect()`](https://reactjs.org/docs/hooks-effect.html) comes with a gotcha that I'd like to walk through and explain. Let's say we have a `useTopPlayers()` custom Hook that retrieves the NBA best players in a specific statistical category. The NBA's "API" only returns the IDs of the players, so after getting the IDs we have to make **another** API request to get the raw player info for each. Finally we need to normalize the raw info into a useful format that our app can consume. ```js import { useEffect, useState } from 'react' import Bugsnag from '@bugsnag/js' import { getTopPlayers as getTopPlayersApi, getPlayersById as getPlayersByIdApi, } from './api' import { normalizeApiPlayers } from './utils' const useTopPlayers = (category, season) => { const [players, setPlayers] = useState([]) useEffect(() => { getTopPlayersApi(category, season) .then((playerIds) => { // avoid nesting by returning the promise returned by // `getPlayersByIdApi` return getPlayersByIdApi(playerIds) }) .then((rawPlayers) => { setPlayers(normalizeApiPlayers(rawPlayers)) }) .catch((err) => { // notify our error monitoring (using Bugsnag) Bugsnag.notify(err) // `null` players means an error happened setPlayers(null) }) }, [category, season]) return players } ``` This is pretty standard code. It's simplified a bit because I have abstracted the logic around making the two API requests and normalizing the data into helper functions. But there are two main drawbacks of using promises here: 1. Any code depending on the result of the call to `getTopPlayersApi()` has to be nested within the `.then()` promise chain. 2. Another async call within a `.then()` could result in nested promise chains which is basically the same as [callback hell](http://callbackhell.com/). We can at least flatten the chain by returning the promise returned by the nested async function in the outer `.then()`. Async functions to the rescue! The naive approach would be to add [`async`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function) to `useEffect()`'s callback function. ```js {5,7-8} const useTopPlayers = (category, season) => { const [players, setPlayers] = useState([]) // 🛑 DON'T DO THIS! 🛑 useEffect(async () => { try { const playerIds = await getTopPlayersApi(category, season) const rawPlayers = await getPlayersByIdApi(playerIds) setPlayers(normalizeApiPlayers(rawPlayers)) } catch (err) { Bugsnag.notify(err) setPlayers(null) } }, [category, season]) return players } ``` The code seems to flow more nicely using [`await`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await), right? But we're unintentionally breaking one of the rules of the `useEffect()` Hook by making `useEffect()` asynchronous. Despite breaking the rules, the majority of the time our code would still work fine. **However, if we have multiple `useEffect()` calls that were order-dependent, we could run into a race-condition, creating a bug that would be super hard to track down.** But if we're using the [React Hooks ESLint Plugin](https://www.npmjs.com/package/eslint-plugin-react-hooks) (which we absolutely should be), it clues us in to our lurking issue. ``` Effect callbacks are synchronous to prevent race conditions. Put the async function inside: useEffect(() => { async function fetchData() { // You can await here const response = await MyAPI.getData(someId); // ... } fetchData(); }, [someId]); // Or [] if effect doesn't need props or state Learn more about data fetching with Hooks: https://reactjs.org/link/hooks-data-fetchingeslintreact-hooks/exhaustive-deps ``` Similarly, if we're using TypeScript it also warns us of the problem (although admittedly far less clearly). ``` Argument of type '() => Promise' is not assignable to parameter of type 'EffectCallback'. Type 'Promise' is not assignable to type 'void | Destructor'. Type 'Promise' is not assignable to type 'Destructor'. Type 'Promise' provides no match for the signature '(): void | { [UNDEFINED_VOID_ONLY]: never; }'. ``` What are these errors telling us? Well, `useEffect()` is supposed to either return nothing or a [cleanup function](https://reactjs.org/docs/hooks-effect.html#example-using-hooks-1). But by making the `useEffect()` function an async function, it [automatically returns a `Promise`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function#return_value) (even if that promise contains no data). You may be tempted, instead, to move the `async` to the function containing the `useEffect()` (i.e. the custom Hook). ```js {2} // 🛑 DON'T DO THIS! 🛑 const useTopPlayers = async (category, season) => { const [players, setPlayers] = useState([]) useEffect(() => { try { const playerIds = await getTopPlayersApi(category, season) const rawPlayers = await getPlayersByIdApi(playerIds) setPlayers(normalizeApiPlayers(rawPlayers)) } catch (err) { Bugsnag.notify(err) setPlayers(null) } }, [category, season]) return players } ``` But this doesn't work at all for 2 main reasons. First, by making the custom Hook `async`, we're now returning `players` data wrapped in a `Promise` instead of just `players`. Remember, `async` automatically makes the function return a `Promise`. Secondly, `await` only works if its _direct_ containing function is `async`. **You cannot put `async` on a top-level function and expect `await` to work within nested functions.** So it not only doesn't work with React, but also isn't even valid JavaScript. Instead, we can follow the lint error's suggestion by defining an `async` inner function within the `useEffect()` function and immediately calling it. ```js {6,8-9,19} const useTopPlayers = (category, season) => { const [players, setPlayers] = useState([]) useEffect(() => { // Add inner async function const fetchTopPlayers = async () => { try { const playerIds = await getTopPlayersApi(category, season) const rawPlayers = await getPlayersByIdApi(playerIds) setPlayers(normalizeApiPlayers(rawPlayers)) } catch (err) { Bugsnag.notify(err) setPlayers(null) } } // Call function immediately fetchTopPlayers() }, [category, season]) return players } ``` Now the Hook is back to returning `players` data and the main `useEffect()` function is back to returning nothing. Instead, we've defined the `fetchTopPlayers()` inner function that we immediately call. We make `fetchTopPlayers()` an async function so that we can use `await` within it. I gotta admit, having to define the inner function is a bit clunky. But, in my opinion, it's a small price to pay to drastically improve the developer experience of async `useEffect` calls. You know, what's actually the most annoying is having to come up with a non-duplicative name for the inner function. We _could_ instead use an [IIFE](https://developer.mozilla.org/en-US/docs/Glossary/IIFE) (immediately-invoked function expression). ```js {6,16} const useTopPlayers = (category, season) => { const [players, setPlayers] = useState([]) useEffect(() => { // use IIFE to avoid creating named function 🤪 ;(async () => { try { const playerIds = await getTopPlayersApi(category, season) const rawPlayers = await getPlayersByIdApi(playerIds) setPlayers(normalizeApiPlayers(rawPlayers)) } catch (err) { Bugsnag.notify(err) setPlayers(null) } })() }, [category, season]) return players } ``` > [Prettier](https://prettier.io/) automatically adds that weird `;` at the beginning of the statement. Because I don't normally use semicolons in my code, if there was a line prior to the IIFE the JavaScript interpreter wouldn't be able to properly understand what's going on. But to me, this is taking a clunky solution and making it worse. 🤪

Using new-ish & lesser-known JavaScript operators to write concise code

Ben Ilegbodu — Sun, 19 Sep 2021 00:00:00 GMT

JavaScript has been around for over 25 years, since May 1995 when [Brendan Eich](http://en.wikipedia.org/wiki/Brendan_Eich) supposedly created it in 10 days. I wrote a full [history of ECMAScript](/blog/learning-es6-history-of-ecmascript/) if you're interested in learning more. There's a lot of syntax and operators that has been added to JavaScript since its inception. Many we use regularly (like `===`, `&&`, etc.) so they are familiar to us, but there are others that are rarely used, but still have some useful use cases. So I want to walk through 8 operators that are either new(-ish) or lesser-known, and explain the situations in which we may want to use them to make our code more concise and/or accurate. Let's jump right in!

How to create an SVG gradient loading spinner

Ben Ilegbodu — Sun, 12 Sep 2021 00:00:00 GMT

I recently got to work on a different type of project than I normally tackle. Instead of building a React component in TypeScript or configuring a new DivOps setup, I needed to create an SVG gradient loading spinner. It looked like:

The spinner isn't a solid color, but has a gradient from 100% to 0% opacity. The design seemed simple enough, but the implementation ended up being way more complicated than I anticipated. This is because **SVGs don't support adding a gradient to a [``](https://developer.mozilla.org/en-US/docs/Web/SVG/Element/circle).** However, it's possible to simulate a gradient with some cleverness. If you just need an answer so you can move on to solve your problem, here's my final solution. 😄 ```html ``` If you're interested in learning about SVGs or how I was able to piece together tidbits from different sources of information to solve the problem, I would love to walk you through my journey. It's my journey in how I learned how to add a gradient along an SVG circular path so that I could create this loading spinner.

How to shallow clone a JavaScript array

Ben Ilegbodu — Sun, 29 Aug 2021 00:00:00 GMT

Usually the rationale for shallow cloning an array is because we want to mutate it, but we need to leave the original unchanged. This practice of "defensive programming" is common in utility functions because we don't know if the caller will need to use the array for other purposes. **Mutating the array directly can cause hard-to-catch bugs.** So we copy it first, and then perform whatever mutations are necessary. To help ground this need in reality, let's apply shallow cloning an array in a real-world scenario. Let's say we have a helper function called `addMessge()` that will add a specified message to the list of messages with the current timestamp. There are likely more, but I've got 8 approaches for creating a shallow copy of a JavaScript array. Let's dive right in! > FYI: A shallow copy means that we do not make copies of deeply nested objects. So if an element of an array is an object, we only copy over its reference. We don't traverse the object creating new copies of each of its properties.

Understanding TypeScript generics through lodash functions

Ben Ilegbodu — Sun, 22 Aug 2021 00:00:00 GMT

JavaScript is a highly dynamic language, so generics are instrumental in helping us to add types to make our code type safe with TypeScript. [TypeScript Generics](https://www.typescriptlang.org/docs/handbook/2/generics.html) are super powerful, but also can be pretty complicated. As a result, we find lots of blog posts, YouTube videos, workshops, and courses on how to use generics in TypeScript. This post is a little different. I learn best by seeing real-world examples. Seeing something new in the context of something familiar helps my brain make the connections. So this post walks through how we can develop with TypeScript generics (something new) by re-implementing common lodash functions (something familiar). My hope is that these examples will help build and solidify your understanding of how to leverage generics in your TypeScript code. Let's get started!

Forwarding refs for a polymorphic React component in TypeScript

Ben Ilegbodu — Sun, 15 Aug 2021 00:00:00 GMT

Late last year I wrote about how to develop [Polymorphic React Components in TypeScript](/blog/polymorphic-react-components-typescript/). Polymorphic components are one of the [React component patterns](/blog/picking-right-react-component-pattern/) that enable us to create reusable and extendable components without having to rewrite display/layout, visual look-and-feel, and/or UI logic. The implementation from that post, however, didn't discuss how to properly type a polymorphic component in TypeScript when it supports a ref using [`forwardRef()`](https://reactjs.org/docs/forwarding-refs.html). That was an additional wrinkle that my team needed and figured out later. So let's talk about it now. Just so we're all on the same page, here's our polymorphic `Text` component in TypeScript (including the helper types): ```typescript import React from 'react' // Source: https://github.com/emotion-js/emotion/blob/master/packages/styled-base/types/helper.d.ts // A more precise version of just React.ComponentPropsWithoutRef on its own export type PropsOf< C extends keyof JSX.IntrinsicElements | React.JSXElementConstructor > = JSX.LibraryManagedAttributes> type AsProp = { /** * An override of the default HTML tag. * Can also be another React component. */ as?: C } /** * Allows for extending a set of props (`ExtendedProps`) by an overriding set of props * (`OverrideProps`), ensuring that any duplicates are overridden by the overriding * set of props. */ export type ExtendableProps< ExtendedProps = {}, OverrideProps = {} > = OverrideProps & Omit /** * Allows for inheriting the props from the specified element type so that * props like children, className & style work, as well as element-specific * attributes like aria roles. The component (`C`) must be passed in. */ export type InheritableElementProps< C extends React.ElementType, Props = {} > = ExtendableProps, Props> /** * A more sophisticated version of `InheritableElementProps` where * the passed in `as` prop will determine which props can be included */ export type PolymorphicComponentProps< C extends React.ElementType, Props = {} > = InheritableElementProps> // 👇🏾👇🏾 sample usage in `Text` component 👇🏾👇🏾 interface Props { children: React.ReactNode color?: Color font?: 'thin' | 'regular' | 'heavy' size?: '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' | '10' } type TextProps = PolymorphicComponentProps< C, Props > export const Text = ({ as, children, font = 'regular', size = '4', color = 'gray-40', ...other }: TextProps) => { const classes = getClasses({ font, size, color }) const Component = as || 'span' return ( {children} ) } ``` > If you're not quite sure how all of this works, read [Polymorphic React Components in TypeScript](/blog/polymorphic-react-components-typescript/) first for a step-by-step explanation. When using [`forwardRef()` generic function in TypeScript](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/2dfb801ec978b29ab81690a9b24ecb1f06c4eaf2/types/react/index.d.ts#L804) with a non polymorphic component, we pass in the type of the ref with the function call. Let's pretend our `Text` component is a simple component that always renders a ``, so the type of the `ref` is `HTMLSpanElement`. ```typescript {1,6} export const Text = React.forwardRef( ({ children, font = 'regular', size = '4', color = 'gray-40' }, ref) => { const classes = getClasses({ font, size, color }) return ( {children} ) }, ) ``` When defining a polymorphic component, we need to replace `HTMLSpanElement` with our `C` generic type, but we can't. **The problem is that `forwardRef()` is a function call so there's no opportunity to define the generic `C` type to pass to it.** We could wrap `forwardRef()` in a function call, a component generator of sorts. But then we would no longer have the component interface and couldn't use JSX directly. So here's what we came up with. First we defined a new helper type, `PolymorphicRef`, that returns the type of the ref for the polymorphic component. ```typescript export type PolymorphicRef< C extends React.ElementType > = React.ComponentPropsWithRef['ref'] ``` We can then use this type in our call to `forwardRef()` to avoid passing in the types to the function call. Instead we declare the types of the individual function parameters. ```typescript // highlight-range{10-11,17} export const Text = React.forwardRef( ( { as, children, font = 'regular', size = '4', color = 'blue', ...other }: TextProps, ref?: PolymorphicRef, ) => { const classes = `${color} ${font} ${size}` const Component = as || 'span' return ( {children} ) }, ) ``` So this works in that everything within the component code is strongly typed. But the type of `Text` itself is `any` 😭. So after trying and trying and trying, we gave in and explicitly defined the type for `Text` (now including a ref) using a [type annotation](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#type-annotations-on-variables). ```typescript {1-3,5} type TextComponent = ( props: TextProps, ) => React.ReactElement | null export const Text: TextComponent = React.forwardRef( ( { as, children, font = 'regular', size = '4', color = 'blue', ...other }: TextProps, ref?: PolymorphicRef, ) => { const classes = `${color} ${font} ${size}` const Component = as || 'span' return ( {children} ) }, ) ``` `TextComponent` (naming is hard lol) is a function that takes in `TextProps` and returns JSX. In other words, it's a component. This _almost_ gets us there, except now `Text`, from a type perspective, doesn't support a `ref` prop even though from a code perspective it does. 🤦🏾‍♂️ **So the final step was to update `TextProps` to now support the `PolymorphicRef`.** ```typescript {1-4,13} export type PolymorphicComponentPropsWithRef< C extends React.ElementType, Props = {} > = PolymorphicComponentProps & { ref?: PolymorphicRef } interface Props { children: React.ReactNode color?: 'red' | 'green' | 'blue' font?: 'thin' | 'regular' | 'heavy' size?: '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' | '10' } type TextProps = PolymorphicComponentPropsWithRef< C, Props > type TextComponent = ( props: TextProps, ) => React.ReactElement | null ``` This introduces a new helper type called `PolymorphicComponentPropsWithRef` which adds the `PolymorphicRef` to the `Props` so that we can create `TextProps`. We could've made the base `PolymorphicComponentProps` support refs by default (see the `PropsOf` helper). But we were incrementally supporting refs in components, so we needed the separation. So altogether the new `Text` component with all its reusable helper types looks like (new code highlighted): ```typescript {46-60,71,76-78,80,90,96} import React from 'react' // Source: https://github.com/emotion-js/emotion/blob/master/packages/styled-base/types/helper.d.ts // A more precise version of just React.ComponentPropsWithoutRef on its own export type PropsOf< C extends keyof JSX.IntrinsicElements | React.JSXElementConstructor > = JSX.LibraryManagedAttributes> type AsProp = { /** * An override of the default HTML tag. * Can also be another React component. */ as?: C } /** * Allows for extending a set of props (`ExtendedProps`) by an overriding set of props * (`OverrideProps`), ensuring that any duplicates are overridden by the overriding * set of props. */ export type ExtendableProps< ExtendedProps = {}, OverrideProps = {} > = OverrideProps & Omit /** * Allows for inheriting the props from the specified element type so that * props like children, className & style work, as well as element-specific * attributes like aria roles. The component (`C`) must be passed in. */ export type InheritableElementProps< C extends React.ElementType, Props = {} > = ExtendableProps, Props> /** * A more sophisticated version of `InheritableElementProps` where * the passed in `as` prop will determine which props can be included */ export type PolymorphicComponentProps< C extends React.ElementType, Props = {} > = InheritableElementProps> /** * Utility type to extract the `ref` prop from a polymorphic component */ export type PolymorphicRef< C extends React.ElementType > = React.ComponentPropsWithRef['ref'] /** * A wrapper of `PolymorphicComponentProps` that also includes the `ref` * prop for the polymorphic component */ export type PolymorphicComponentPropsWithRef< C extends React.ElementType, Props = {} > = PolymorphicComponentProps & { ref?: PolymorphicRef } // 👇🏾👇🏾 sample usage in `Text` component 👇🏾👇🏾 interface Props { children: React.ReactNode color?: Color font?: 'thin' | 'regular' | 'heavy' size?: '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' | '10' } type TextProps = PolymorphicComponentPropsWithRef< C, Props > type TextComponent = ( props: TextProps, ) => React.ReactElement | null export const Text: TextComponent = React.forwardRef( ( { as, children, font = 'regular', size = '4', color = 'blue', ...other }: TextProps, ref?: PolymorphicRef, ) => { const classes = `${color} ${font} ${size}` const Component = as || 'span' return ( {children} ) }, ) ``` Now when we render a `` component, if the `as` prop is `"label"`, not only does `` support the `ref` prop, but its type has to be `HTMLLabelElement` (or the generic `HTMLElement`). Type checking will fail when passing other types. 🎉

Initializing the Firebase Admin Node SDK with env vars

Ben Ilegbodu — Sun, 08 Aug 2021 00:00:00 GMT

The [Firebase Admin Node SDK](https://firebase.google.com/docs/admin/setup) is intended to run in a privileged environment. In my ([Next.js](https://nextjs.org/) React) web apps deployed on [Vercel](https://vercel.com/), I use the Admin SDK for scripts that import/export data as well as REST APIs that make read/write Firebase calls to accomplish a task. In order to initialize the Admin SDK, we first need to generate a private key file from our [Google service account](https://console.firebase.google.com/u/0/project/_/settings/serviceaccounts/adminsdk). We'll get a JSON file containing the private key. It'll look something like this (redacted for obvious reasons): ```json {5} { "type": "service_account", "project_id": "[PROJECT_ID]", "private_key_id": "xxxx", "private_key": "

The non-destructive JavaScript array methods

Ben Ilegbodu — Sun, 25 Jul 2021 00:00:00 GMT

In my previous post, we took a deep dive into the [`.reduce()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce) method on the JavaScript Array API. This time I want to zoom out and take a look at all of the JavaScript array methods. Well, not all. I only want to focus on those methods that are non-destructive; those methods that don't change the array, but return something new. With React as well as some state management solutions, [immutability](https://css-tricks.com/understanding-immutability-in-javascript/) is key. So mutating arrays, for instance, is a no-no. So now I've just gotten used to avoiding those methods that mutate the array when possible. So let's take a look at the methods on the JavaScript Array API that are non-destructive. Hopefully, we can learn something new!

Learn the Array reduce method by re-implementing lodash functions

Ben Ilegbodu — Sun, 18 Jul 2021 00:00:00 GMT

The built-in [JavaScript `Array` object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array) has lots of helpful methods that allow us to manipulate arrays. I use [`.map()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map) and [`.filter()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/filter) all the time when I'm transforming data. Arguably the most powerful, yet also least understood method is [`.reduce()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/reduce). It allows us to basically transform an array into nearly anything else: another array, an object, a boolean, a number, etc. So let's learn how `.reduce()` works by re-implementing [`lodash`](https://lodash.com/) functions.

Exploring the JavaScript Promise API methods

Ben Ilegbodu — Sun, 11 Jul 2021 00:00:00 GMT

[ECMAScript 2021](https://ui.dev/es2021/) introduced a new static method to the `Promise` object called [`Promise.any`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/any). In total there are now 6 static methods on the `Promise` object: - [`Promise.all`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all) - [`Promise.allSettled`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/allSettled) - [`Promise.any`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/any) - [`Promise.race`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/race) - [`Promise.resolve`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/resolve) - [`Promise.reject`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/reject) We use promises everywhere in JavaScript code for handling asynchronous code. But when would we use one method over another? Well let's walk through use cases for each to find out!

Tools to catch accessibility errors in JavaScript applications

Ben Ilegbodu — Mon, 05 Jul 2021 00:00:00 GMT

I've learned a lot about accessibility these last 2 years working at Stitch Fix. I don't know if it's because I've been working on our design system where I've had to make accessible components. Or if it's simply that the industry has raised its collective awareness of the needs for developing accessibility features. **While accessibility features are an absolute necessity for some to use our sites, many of them are also beneficial to everyone.** High color contrast is important for the visually impaired, but also comes in handy when a "well-sighted" person is on their phone in the sunlight. Having proper keyboard interactions is critical for those who cannot use a mouse, but are also useful for keyboard power users.

Good #a11y features are beneficial for lots of people. pic.twitter.com/2RMnTzseey
— Chris Heilmann (@codepo8) June 28, 2021

[React](https://reactjs.org/) has gotten a bad rep about creating unaccessible apps. I've even seen people ask if React itself is unaccessible. I can't be 100% certain, but I don't think unaccessible apps are not unique to React. It just happens to be the most popular web development library right now. **I think apps built with all of the JavaScript frameworks have accessibility problem.** They make it so much easier to build interactivity. But unless we know the rules, we can just as easily build that interactivity in an unaccessible manner. Instead, we should be creating accessible UIs making the full use of the semantic HTML elements and CSS. Anything clickable should be a `