DEV Community: Jamund Ferguson

UI Code is Throwaway Code, Always Has Been

Jamund Ferguson — Sun, 22 Mar 2026 16:05:43 +0000

The most impactful engineering leader I ever worked with was a guy named Bill Scott who led UI engineering at PayPal. What I loved about Bill was his constant enthusiasm for new technology. He helped lead the charge to take PayPal's old C++ and Java stack and modernise it into Java microservices and Node.js for the front end. And just absolutely surrounded himself with people who were looking for ways new technology could be used to create better experiences for our customers and improve the lives of developers.

If he were still with us today, I think he would absolutely love the AI revolution taking place in software development right now.

When I was interviewing at PayPal back in 2013 I spoke with him a an influential blog that he'd written called The Experimentation Layer. Reflecting on his time at Netflix, he was pushing back against the cult of reusability in software development and talked about designing for throwaway-ability instead. He was a huge proponent of Lean UX and A/B testing. In the article he mentioned that in his time at Netflix, after something like a year, only 10% of the front end code stayed the same. It was constantly being optimised and improved to deliver better outcomes for their viewers.

He wasn't anti-reusability. He wrote an entire book about building reusable components for UIs. One that was extremely important to me as an early engineer coming up in the jQuery UI era through the HTML5 transition and the death of Flash.

But regardless, it made me a little bit annoyed. It put me off. I had just come from a role where, for the past two years at oDesk, I had been building reusable component libraries. And so we sparred a bit, gently, in the interview. And he helped me understand where he was coming from.

The goal is to build the best experiences for users as quickly as possible. Not being afraid to experiment and try new things, especially when the status quo isn't working. The biggest thing in his philosophy was just constantly getting user feedback and making sure that what you're putting out in front of users is actually working for them. And making sure that you have the infrastructure needed to iterate frequently and measure and observe your successes and failures. The other lesson that I've taken from that time is not to be married to my code. It's just code. It's an experiment. And it's okay if we decide to throw it away.

The calculus of how "throwaway-able" your code needs to be depends on where it lives in the stack. He uses this funnel to illustrate the volatility of different parts of the software stack:

If you're looking at a modern React application, you might think of it like this instead:

In modern client-side React architecture, there are places that we need to be more careful about changes than others. But there are places in a large codebase that ultimately don't matter so much. I think for many people, for better or worse, if a bunch of Tailwind CSS classes change in the code for a component used in only one place, you're not really bothered about it as long as the thing looks like it's supposed to look.

In a different context, you can also think about which features are likely to be sort of permanent and which features are temporary, like landing pages, right, or some kind of feature-flagged experiment you don't expect to really make it.

Death of the Code Review

There's been a lot of talk lately about the death of the code review. I think it's premature, at least for teams supporting real codebases with real users. If we use Bill Scott's framework for determining which code is likely to change frequently or should be designed for throw-away ability, I think that can help us understand where it might be OK for a little "slop" to enter our application without looking too hard.

The way forward with this deluge of AI-generated code isn't to avoid reviewing it; it's figuring out where human review matters the most.

Anticipating UI Engineering's Future

Today, I asked Claude if it wanted to play a game, and it generated one and let me play it, right in the chat interface.

Other companies like Vercel and Cloudflare are talking about similar things. Sandboxes and "code mode" and generative UIs. There are also MCP apps and WebMCP, which are all different ways to allow AI agents to essentially bypass the UI layer created by devs and show something else to the user instead, something custom, something just for them. Dynamic AI-generated user interfaces are likely coming one way or another, and that UI code likely isn't going to be reviewed by humans.

Even so, I'm pretty certain the architecture underlying those future interfaces will be reviewed and tested very carefully by human reviewers. Nobody wants to build their house on foundation of slop. But the "experimentation layer" part, the part of the code we're less fussed about. I'm pretty sure that part is going to get a whole lot bigger.

RIP Bill. You were a real one.

Code Review Kinda Sucks Now

Jamund Ferguson — Sun, 15 Mar 2026 15:09:53 +0000

tl;dr Code review was never just about finding bugs. We need better tools to help us make sure we don't lose the understanding of our codebases as the rate at which they grow increases with AI.

Recently, I was really impressed by an article posted on X by Dominic Elm.

In particular, this quote absolutely drew me in:

Code review was never really about catching bugs. It was about building shared understanding, a team's collective mental model of what the system does, why it works that way, and how it can safely change

The article went on to detail all the challenges with AI making it so easy to generate code but not review it he had a couple of conclusions at the end, which I'll summarise here.

Make sure to apply AI code review right away, so humans can focus on the more important architectural issues.
Review AI-generated code with a different lens in mind than human-generated code.
Put more emphasis on the author proving they understand their own code.

I thought these were fantastic and just wanted to add a few more ideas to that based on my own experience.

Code Review as Team Sport

The quote about code review being for shared understanding that resonated with me so much reminded me of this incredibly hard to find blog post by Nicolas C. Zakas (thank you, Internet Archive). Nicolas is the creator of ESLint and a prolific JavaScript author. The article is called "Effective learning through code workshops"

What he describes in the beginning is the way code reviews were performed, at very serious companies, before GitHub and similar tools for async review became popular. Code reviews were literally meetings where the team would review code that had been printed out on pieces of paper. Everyone would be in there looking for bugs by hand. Writing notes with pens and pencils. With the person who wrote the code often looking quite uncomfortable and nervous, receiving all this negative feedback. That approach obviously couldn't scale and was eagerly replaced by the async code review model that was likely made popular with the proliferation of open source and GitHub.

Nicolas took that old school approach and tried to modernise it for Box. He called them "code review workshops". Where weekly someone would be assigned to look at code that they didn't write and explain it to the team. And the whole team walks through that code together and identifies patterns and practices that they like and dislike, and makes notes for future improvement. Confusing code is really easy to notice and dissect in this type of meeting. Context is shared with the team. You're not reviewing a single pull request with the whole group; but usually it's a feature or file that might have been contributed to by multiple individuals.

When I was at PayPal, I had a fantastic engineering manager named Rose Elliot, who used this technique as a way to strengthen and uplevel our team.

It was a great way for people to learn about parts of the codebase that weren't theirs. And it promoted a culture where we were continually improving and documenting our code and best practices. During each session, we would make notes about what we wanted to change, and create issues in our task management system to follow up on those changes. We still leaned into asynchronous code reviews. We also spent a lot of time on linting and automating the identification of common mistakes. But taking the time to review code together regularly helped us build a shared understanding of both how things worked today and what we wanted our app to look like in the future.

One thing I like about this approach is that it doesn't slow down progress in the sense that you have to wait for an in-person code review meeting to get the code merged or even shipped to production. But it provides a feedback mechanism to the whole system to make sure that you're going in the right direction and keeps everyone more informed.

I don't know if this is the solution for dealing with the massive amount of code that we're getting in this AI/agentic-engineering era, but it feels like it could help.

Reducing Cognitive Load

Reviewing giant pull requests is never easy. And the code review article from Dominic goes into various stats on how the longer the pull request, the more likely a reviewer is to make mistakes or just gloss over it without giving any real feedback. This should pretty relatable for most devs. So how can we reduce the cognitive load for reviewers?

Smaller Pull Requests

In the article, it was described that smaller pull requests help reduce cognitive load. And there was something mentioned about a code review tool called graphite, which uses an approach called stacked diffs, to basically make it easier to look at the difference between individual commits and review them separately. It breaks down a complex pull request into smaller pieces that can be reviewed individually. It's a slightly different workflow than traditional GitHub pull requests, but it's backward compatible and looks promising.

Outside of using a separate tool, I found recently when using Claude Code, instead of executing one large plan it can help to break down your work into smaller plans. So we talked through the work that needed to be done, created a large plan. I saved that to the side and then had Claude execute smaller individual plans and committed the results each time or in some cases made pull requests for each (smaller) implementation separately. Just because Claude can do a whole bunch of stuff at once doesn't mean you shouldn't break it down into easily understandable chunks.

Diagrams and Documentation

One of the big suggestions in Dominic's article was asking the reviewer to include diagrams in their pull requests so that they could sort of prove that they understood the system impact of their code changes. I've been thinking a lot about how diagrams and visual representations of code can help us more quickly grasp what's going on. Line-by-line diffs are really hard to reason about and it's clear that more advanced semantic diffing and visual diffing can help us understand these things more quickly. But one thing I found interesting was he said at his work, people just use AI to generate the diagrams, and it didn't really help very much. Developers weren't actually internalising what was happening.

Similarly, Mikey See from Convex, tried to use nine different code review tools and made a video with his results.

One of the tools called Sorcery AI, automatically include diagrams with every pull request.

I've been fairly convinced that this kind of thing will really help engineers better understand what's happening in code changes. But in the review, he just said it was noise and it was just completely ignored, every single time.

Is there room for this kind of tool and graph automatic diagram generation? I think so. I think that we just haven't found the right place for it yet. One suggestion might be to essentially automatically include documentation with code. Again, with the emphasis that even though humans maybe didn't write the code, hopefully they'll be like a README file, say, with each component or each feature folder that can have some really good details about how it works and what's going on so humans can get up to speed very quickly.

With React components, it would be super easy for AI to always create storybook examples for every single component you do, and then maybe we could even render those storybooks directly in the code review. Right? What if you could actually see the component right there alongside the code.

Semantic Diffs & Code Graphs

I can still think of a lot of use cases for visuals and graphs that could help, even if the current implementations aren't that useful. Even just imagine a simpler way of looking at a diff between, let's say, two React components. The things that matter the most are prop changes, state changes, hook changes. Clearly line by line diffs aren't that useful here. Are we changing the types of the props? Are we changing how we're managing state? Is there a better way we could visualise that? Outside of React thinking about, say, a function, the inputs and outputs are the things that matter the most right, especially if the function is well tested. Can we surface that more clearly?

I gave a talk ten years ago at UtahJS where I spoke about using abstract syntax trees to analyse your code systematically. And one of the examples I gave is using ASTs to generate meaningful diffs.

There's a tool called Sem that I recently found that applies some of these approaches.

Imagine something like this, but with arrows and colour coding and everything to make it really obvious what the type looked like before and what the type looked like after.

AI code review right now can help somewhat with basically fancier linting, and potentially matching architectural patterns, but AST-based diffs and semantic diffing might help us highlight the things that matter more in diffs, so that humans can more quickly grok what's going on. This is absolutely going to be necessary in the future if we're going to keep ahead of all this mountain of AI-generated code.

Code Maps & Blast Radius Detection

We're also seeing some movement around graphing code and understanding the blast radius of a change. I think this is also really interesting because, to some extent, with AI code review there might be parts of the code that we really don't care what the details are. Imagine there's a small feature not on a critical path. It might be good to know that no matter what's in this code, it's not going to affect anything else. Tools like that might help us narrow the scope of what human code review needs to look like, or at least emphasise where we really should pay attention to a code change.

There's a tool going on right now called GitNexus that attempts to do that, but I'm sure there are others as well.

GitKraken also offers "mode maps" and other visualizations:

Conclusion

Code review kind of sucks right now. It's so easy to generate code that looks good. But it's hard to wrap our heads around the impact of those changes. We need to adopt better processes and tools to help our engineers quickly get up to speed in understanding the changes happening in our codebases.

Here are a couple of suggestions that build on Dominic's article that I think might help.

We should take another look at Team Code Review workshops. With AI doing most of the coding these days, who's going to get offended if you don't like their implementation? Let's do it. Modified for the hybrid and remote workplace, of course.
We need to keep down the size of our code reviews, stacked diffs might be a real solution there. Or even just making sure your AI agents follow some simple guidelines on how frequently they commit changes.
We need better tools

There are literally dozens of VC-funded AI code review tools duking it out in the marketplace. While I think they are becoming even more essential at helping us find bugs in our apps, we need remember code review is also about "building shared understanding." These tools are not doing that and they really aren't trying to. We need new code review tools that focus on the other side of code review. Not just finding bugs, but helping the team understand what it is that they're putting into their codebase and guiding that massive flow of changes in the right direction.

DIY Pre-Loading for Faster Data Fetching

Jamund Ferguson — Fri, 17 Jun 2022 22:44:13 +0000

If you're struggling with slow page load times in your React app, I want to show you a technique that can shave off hundreds of milliseconds.

Here's how you can pre-load your data in the most optimal way without relying on any external dependencies.

First, the problem

We can break down the problem into three parts:

React applications often end up in large JavaScript bundles
Many components rely on external data
Data fetching won't usually start until your JS bundle finishes downloading and your components finish rendering

Here's a simple chart to help you visualize the problem. Look at how much happens before the data starts downloading.

What we noticed in our app at Amazon was that components would fire off data fetching in a useEffect while deeply nested in the component tree. That meant the fetch wouldn't start until between 50ms and 250ms after our ReactDOM.render() call. Furthermore, our huge JavaScript bundle took an additional 350ms (or more) to download and execute. Combining these together we saw a huge opportunity for improvement.

Measuring the Problem

The Chrome Web Inspector provides a number of tools that should make it easy to figure out if you're affected by this problem.

Check the Network Tab

First, find your main fetch call inside of the Network tab. Then go to the Timing section and look for "Started at". This shows how long it took us to send off our request after the page is loaded. You want this number to be as low as possible.

Dive into the Performance Timeline

Now run your app in the web performance inspector. Look at it carefully and see if you can recognize the problem:

What you want to look for is your main app file and your main data fetch call. Here our app is bundled in a file called vendor.f2843ed7.js and we're fetching data from /api/slow/data. In this contrived example it takes around 200ms between the time vendor.js starts downloading and the time our fetch call begins.

The chart above highlights two specific blocks of time that we can mitigate to optimize performance of our data loading.

The Solution

The solution we came up with could be broken up into two parts:

Kick off data fetching as early in our script as possible (i.e remove it from the React component lifecycle)
Parallelize data fetching with loading our JavaScript bundle

In order to accomplish the first of these we need some kind of global store. It doesn't need to be anything too fancy. In our case, we were already using redux, which we were able to dispatch actions to outside of the React tree as I'll demonstrate below.

In their simplest form most of the network-dependent components looked something like this:

// a simplified data loading example
function PageLevelComponent() {
   const dispatch = useDispatch();
   useEffect(() => {
       loadData().then((data) => dispatch(dataLoaded(data)))
   }, []);
   // ...
}

We ended up moving this loadData() call into our root app file. The same one that starts rendering the react component tree. You'll notice we're still relying on redux to store the data, but we reference the store directly for our dispatch method instead of getting it from context or hooks.

import { store } from "./store"

// start loading data immediately and dispatch it to the redux store
loadData(location.pathname).then((data) => store.dispatch(dataLoaded(data)));

// render the application with the same redux store
ReactDOM.render(rootEl, <Provider store={store}><App /></Provider>);

After making that change you'll see that the data starts downloading only shortly after the JS starts executing. There's no longer a large delay.

With this in place we asked ourselves if we could take it even further. The time to load our large JS bundle was clearly limiting how soon we were able to fetch our data. No matter how early we fired off the network request, the bundle still had to be downloaded and parsed before it was executed. Would it be possible to load our data in parallel with our JS somehow?

The Optimization:

Taking it to the next level required several clever steps to execute properly. First, we had to create a new entry in our webpack config. We called it preload.js. That preload.js needed to be as small as possible. Ideally no Redux, no Axios, etc.

entry: {
    "main": "index.js",
    "preload": "preload.js"
}

At this time we were still supporting IE11, which meant we would likely need to include a promise polyfill, a fetch polyfill of some kind and URLSearchParams. In our case we were using Axios and ran into trouble when we didn't include that in both bundles, because of slightly different error handling and promise implementations. All of that ended up bumping our preload file to around 11kb minified.

The contents of preload.js looked something like this:

import "./polyfills.js";
import { loadData } from "./xhr.js"

// kick off the promise and cache it in a global variable
window.__DATA_LOADER_CACHE__ = loadData(location.pathname);

And then in our main bundle later we would check for the presence of that global variable and if it exists use that instead of our loadData() method.

(window.__DATA_LOADER_CACHE__ || loadData(location.pathname)).then((data) => store.dispatch(dataLoaded(data)));

We built the preload script in such a way that it would be completely optional. If it didn't run at all the normal app could continuing running properly. But that did result in a handful of modules being duplicated. With a little more care we probably could have gotten the script down to around 2kb. Despite it not being perfectly tiny, the results were tremendous:

Your data becomes available to your application as soon as it's needed. And even in the case that your data call is still outstanding when the app is ready to go, your app will re-render as soon as it's done downloading. It's a much better user experience and the only trade-off is a tiny bit of awkward code.

How'd it turn out?

🏆 In the app we applied this to at Amazon our 90th percentile Time to Interactive went down by over 350ms. A huge savings for very little effort. I definitely recommend you figure out how to pre-load data in your application as well.

Notes

Check out Ryan Florence's When to Fetch talk for a more elegant solution for faster data loading
We ended up making a cache based on URL and query params and stuck that in the global variable including other data like any errors, etc.
It's important to log if you end up fetching the data URL twice, which can happen if you incorrectly duplicate your URL parsing logic 😬
I tried to reproduce this in vite but couldn't quite figure out how to split out the preload file. When I figure it out I'll post a demo of all 3 states.
Can't we just use link rel="preload" as="fetch" and call it good? I mean yes, try that way first! We couldn't get it working consistently, but that was a few years back and things seem better now.

Doing my Best Work as an Engineer with ADHD

Jamund Ferguson — Thu, 13 Jan 2022 23:32:41 +0000

I was diagnosed with ADHD in 5th grade. I was in Mrs. Henry's class and while I was certainly a bright student I had a horrible time staying focused. After falling out of my chair in class constantly and being fairly disruptive I eventually was diagnosed and put on medication, which helped me quite a bit. I stayed on medication on and off through elementary and middle school and into most of high school as well. I felt different when I was on that medicine. I could focus more. My thoughts weren't always racing. Sometimes things felt like they were going in slow motion. And I lost my appetite and developed a tic. Eventually I stopped taking them.

In both high school and college I was one of those students that felt like things came naturally, but I struggled immensely when it came to studying and even normal classroom participation. I'd blurt out answers. I'd struggle with any kind of reading or carefully following instructions. In higher level math classes I could never memorize basic formulas, but sometimes I was able to work them out myself when I needed to during a test. Often that just translated to me taking longer than everyone else to finish a test. In other classes I would find myself drawn to overachieving on some trivial task, while completely ignoring my actual responsibilities. While I could hardly focus on my class work I would lug giant computer books to school or spend hours fiddling with Linux at home as kid. College really wasn't much better, though when it came time to choose a major in college I was drawn to the Community & Environmental Planning program at the University of Washington partially because it followed Evergreen's model of narrative grading, which worked infinitely better for me.

Today I'm a successful front-end engineer that has worked at several large tech companies. Anyone you ask that I've worked with will say that I've had an outsized impact on their team (and likely the company as a whole). Unlike in school my accomplishments in tech have been measurable and I've been compensated well for my work. I also really really like my job and the various developer communities I've had the opportunity to be a part of. Despite all of that success, managing my ADHD symptoms has gotten more difficult over time.

I've found myself viscerally uncomfortable in long meetings, which seem to be a staple in modern "agile" development. My memory is foggy and I often forget people I've met or meetings I'm supposed to attend. Any kind of long documentation that I need to read, like instructions for setting up a new code base can be excruciating. I often end up taking short cuts and missing key details. Complex task management software fries my brain and I haven't quite figured out how to successfully manage my inbox. And even beyond that it's taken me years to finally learn the basic algorithms commonly taught in intro to CS courses. And jobs. Despite having worked at several companies for multi-year stints within those companies I struggle to stay content in the same position for more than 6 months at a time. I'm always looking at new opportunities. My mind is never still.

Let me share how I've been able to modify my circumstances and in some cases take advantage of my disadvantages to make the most of my career in tech with ADHD.

Working at big companies has given me more outlets for exploring opportunities

This one took me a while to accept, because I grew up in Seattle idolizing grunge and punk rocks icons who despised stuffy corporate culture. Working in some kind of overly political and bureaucratic office filled with finance bros and ivy leaguers was never going to appeal to me. What I found though after starting my career in smaller companies and startups was that large tech companies can offer far more flexibility. For me, always chasing new dreams, it meant that in the 5.5 years I was at PayPal for example, I was able to work in several different roles, learn new technologies, lead teams, host events and basically never get bored. I had a similar experience at Amazon, after 18 months on one fantastic team, I jumped to another project. Many large companies even have rotation programs where you get to move between teams every 6 months.

One thing that is hard for me about working for large companies is their love of acronyms. I try hard to avoid them (and I ask others to do the same).

If It's Confusing For Me It's Probably Also Confusing For Others

One of the big skills that's helped me in my career has been acknowledging when something is confusing. Maybe it's during a code review. Maybe it's a user interface that's too complex. Or an onboarding guide. Just say it. "Hey I don't understand this". Or "this is difficult for me to follow". It's kind of weird in some quarters for a supposedly senior engineer to just nope out of something because it's too confusing, but it forces really important conversations about architecture, about product design and really all of it. As a developer relations engineer being able to articulate when an API or integration guide is too complex is extremely valuable. Struggling to stay focused with my ADHD can end up being a super power when it comes to advocating for a better experience for others. My entire career in developer experience has been made by gently (and not so gently) encouraging my friends and colleagues to make things less confusing for myself and others.

Getting the Most of Meetings

Through my career in tech I've been invited to entirely too many meetings. Sometimes I've gotten frustrated and walked out when I didn't feel my time was being spent well. Working from home has made it much easier to tune out of bad meetings or avoid them altogether. I just can't sit still for that long and a bad meeting or especially stressful one will often dominate my mind for the rest of the day.

I live for good meeting agendas with clear outcomes and a limited number of people attending. Make sure everyone knows why they're there or if they can opt-out. Don't pressure people to attend that aren't absolutely needed. And provide some real clarity around what outcomes are expected by the end of the meeting. The exception to that is what I think of as a chit chat meeting, which really is just about getting to know someone. Those are always fine. We can make time for friends. All hands meetings though. I'd rather skip them.

Amazon's approach of having 20-30 minutes at the start of a meeting to read a document or fill out whatever things people forgot to do before the meeting worked really well for me. It takes away a huge number of potential distractions and forces everyone to pay attention at that moment and with tools like Quip you can comment on the document inline and even engage in focused conversations before the meeting even begun.

Managing Agile Ceremonies and Software

The meeting I've consistently struggled the most with is the sprint planning meeting or really any agile ceremony meetings (including standup). When we start busting out the backlog and assigning things to people it's just this immediate explosion of context all over the place that becomes extremely difficult for me to process. I also absolutely hate to commit to doing something for two weeks, which we all know may get interrupted or maybe I'll have a brilliant idea mid-sprint. I prefer a Kanban approach or the "trust me to do the right thing" approach, because I will. And then there's the retro meetings where we rehash everything, it's all so dreary honestly and rarely proves productive for the team in my experience.

Another aspect of modern agile development™ is task management software. PayPal used to use Rally, many companies use Jira. All of them offer similar features and usually get configured to inflict maximum developer pain. The purpose of this software should always be to help engineers do their job well. However, it's sold to and often rolled out by executives who want maximum visibility and rolled up stats about absolutely everything happening in the company. In practice this turns filing a simple bug report into an exercise in categorization and org-chart spelunking that me as an individual with ADHD has absolutely no time for. Sometimes I was lucky enough to be on teams where our product manager would be willing to keep Jira happy. Other times we were able to convince people to keep the process dead simple or allow us to bring in our own informal tools like Google Docs or Trello, which made it much easier to handle in my brain. Please allow your engineering teams flexibility over the tools they use. It's a relatively simple accommodation that can help neurodiverse folks so much.

Communication Style: And why I hate e-mail

I don't know what I can say about e-mail exactly. I always have thousands of unreads just sitting there. Sometimes it's nice to be able to search through them when someone says "did you see the e-mail about X". I feel like what happens is I see this never-ending Inbox and I'll read something supposedly important and then immediately it gets lost in my mind and in a sea of other e-mails I don't really care about. I know people use folders and maybe that could work for me? I do a bit better with my personal e-mail because it's Gmail and I can just ⭐ everything that I want to keep track of and it gets pinned to the top. That really helps me. I haven't quite bothered to figure out an equivalent with outlook yet. I just keep hoping it goes away. (That includes really carefully crafted tech newsletter too, sorry.)

If you want to talk to me, please reach out on slack or Twitter. Don't ever call me. Always give me whatever context I need to respond later without assuming I'll be immediately joining a discussion with you. Because, I will not be. I also don't put slack or work email on my phone for the same reason. My time is precious and while I'm easily distracted I'm trying hard not to be.

Hyper Focus is a Thing (Though Rarely Since Covid Hit)

Sometimes I feel like I could go a whole sprint getting distracted on a million tangents and then in the last day or two get super focused and knock out all of the features in no time at all. This is often the case with bugs. I'll get distracted from my normal sprint work and just go on a tangent squashing a whole bunch of bugs in a really short period of time. I work in bursts. I need time away from the computer. I take walks. I'm probably only really productive for about 8 hours a week. (I'm a 10x engineer, but only 1/10th of the time.) The rest of the time my mind is distracted thinking about politics or my family or an open source project or some new feature I want to build that has nothing to do with whatever I'm supposed to be working on. Part of being successful has been understanding how to take time away from the computer where my mind is still working out the problem, so that when I come back from literally laying on the floor or going for a walk, I'm all ready to go. Working from home always made this easier for me, but with covid and kids around a lot more and all the existential crises happening around it's honestly been pretty rough.

I love reading & learning, but in small, focused packages with few distractions

I remember when the A Book Apart series first came out and they published HTML5 for Web Designers. It was a really small book and only 150 pages. And then they released CSS3 for Web Designers which I remember reading on my phone in line at Old Navy. I had been reading tech books since I was in middle school, but these were some of the first I was able to really devour without having to completely force myself. Short. To the point. Beautifully laid out with plenty of white space and tasteful use of color. I love buying tech books like many of you, but struggle getting past about the first 100 pages or so. Usually I'll read that much and then just kind of skim the rest or skip around to an important chapter. I absolutely love short books. My favorite example recently was Sam Julien's Getting Started in Developer Relations. At 79 pages it's absolute perfection.

Anything that limits distractions or the length needed to hold my attention helps my learning. Frankly it's one of the reasons I'm so stoked about VR, you're completely immersed on a single task. Another example is attending conference talks in-person. I do a good job of not bringing work to conferences and I'm not especially extroverted, so sitting there watching a few talks usually works pretty well for me. (At least for about 4 or 5 hours until it becomes too much information!) Similarly in-person or highly interactive workshops have always been really productive learning for me. An in-person all day GitHub workshop was incredibly helpful for me up-leveling my git skills. Working through EpicReact when I was recovering from covid. I learned so much and was able to stay focused because I didn't have any work obligations distracting me from learning.

Other than that most of my learning comes from thinking and exploring, which is usually quite unstructured, and that's ok.

One on One Communication Has Always Been A Challenge

Because I often end up situations I'm not sure exactly what is proper and expected I rely a lot on my intuition to guide me. I also have tried to develop my emotional intelligence and adapt my approach in discussion based on how people seem to be responding. This is definitely helpful when teaching. It also makes me greatly prefer video calls over audio calls where I have a lot less visual cues I can respond to. I know that doesn't work for everyone and I understand that and adapt. One unfortunate trait many people with ADHD share is a tendency to go on long rants and in their enthusiasm talk over or interrupt other people. I do this a lot. To compensate I often summarize my thoughts at the end of speaking and also acknowledge and stop myself when I do interrupt someone.

Presentations & Teaching

My ADHD sometimes gets perceived to others as having an unrelenting enthusiasm for new things. And truly sometimes I feel like Dory from Finding Nemo where everything is new an exciting each time even though I may have already learned that thing before. That enthusiasm translates well into public speaking and giving presentations and generally getting people hyped on new technology, which thankfully is an important part of my job.

When it comes to actually preparing talks, I don't think I have any special techniques. Usually I find myself going for walks or drives and speaking the talk into existence even before writing slides or an outline. When I do write the slides I like to make outlines first and then fill them in with content later. Speaker notes help, though I rarely actually get them to work on the day of, I just practice them over and over (out loud ideally). I love the energy I get when giving a talk and feeding off questions and enthusiasm from the people in the room. After giving a talk though my brain is usually fried and I'm basically useless for the rest of the day.

Writing is a little bit different. It takes me like 400 hours to write a simple e-mail and then I also have a typo or something in it. Blog posts are different because when I feel like blogging usually some idea is bursting to come out of me and I can usually type it up in a couple of hours, no matter how long it is. (Though I find myself publishing hastily and revising a few times after publishing, like I did with this post.)

Setting Expectations

One of the best exercises I ever participated in a corporate environment was on my last team at Amazon where our manager asked us to present our personal user guide which is a thing. You can google it. And it's basically just setting expectations with your team about how you like to work, including how you want people to give you feedback and what energizes/drains you. I put mine up on github. While writing it out was really helpful for me , having space to communicate and acknowledge that everyone works and thinks and reacts a little bit differently was really powerful for our team. I would highly recommend it as an exercise.

In Summary

Living with ADHD has no doubt been a challenge. It's affected my relationships, education and career in ways that I'm not always happy about. Like so many of you dealing with this I've been able to make it work for me and sometimes I've been able to use my experience as an advantage. It's helped me see things through a fresh & empathetic perspective and other times it's forced me to cut out unnecessary processes or work that was really benefitting no one at all. I don't know if I'm grateful that I have ADHD, but I am glad my ADHD and I have come to a kind of mutual understanding. I'm used to it. I know it's there. And for the most part we get along.

If you are neurodiverse in some way what kind of accommodations have allowed you to be successful at work? What techniques help you make the most of that challenge? How did medication make your condition more manageable? How has your experience with ADHD changed over time. Would love to hear your experiences.

One Cool Trick to Speed Up Your Website Performance (Not Really)

Jamund Ferguson — Mon, 13 Dec 2021 20:00:36 +0000

The truly greatest bang-for-your-buck performance impact I ever had was removing two lines of JavaScript.

My Background

When I was at Amazon, I worked in the Seller Central org building tools to help companies sell their products. The app I primarily worked on was a complex multi-part form broken into numerous tabs with dozens of inputs dynamically populated based on product type, customer characteristics and various choices made along the way. The app was built with React and Redux, and the backend was a custom Java SpringMVC-based framework.

The Problem

As a company, Amazon has a strong culture of web performance, but it also values shipping code rapidly. These competing interests resulted in friction; it could be deeply frustrating to see a month's worth of work improving page performance wiped out by an unintended negative side effect from a new feature. When I started as the sole frontend engineer on my team, and one of a handful in the org, my primary focus was on frontend architecture and web performance. It was my responsibility to come up with sustainable ways to hit those goals without compromising our ability to ship code. At the time, we were regularly missing our web performance targets. Most of the team members were smart backend devs, but few had much experience with React, or with optimizing frontend performance.

Failed Attempts

I came in, as many new hires do, wanting to be the hero who stepped in and neatly saved the day. I started by looking for the easy, high-yield performance wins: are we using an optimized lodash build for webpack? Are we bundle splitting? Exactly how many fetch polyfills do we have in our bundle? I'd worked on performance in React apps before, and I had my mental checklist ready. The problem, though, was that the low hanging fruit wasn't yielding enough actual benefit. We shaved off 10kb here, 100kb there. Our bundle size dropped from 1.8mb to 1.5mb, and eventually all the way down to just over 1mb, but we still couldn't hit our performance goals. We relied heavily on real user monitoring to understand how users experienced our site. We eventually found that due to how users interacted with our app, our cache hit rate was fairly high. The reductions to the size of our JS bundle were definitely a good thing, but they weren't giving us anywhere near the improvements in how users were experiencing our performance that we wanted. There had to be something else that could speed us up.

Breakthrough

The breakthrough came, as they sometimes do, after I'd exhausted my checklist and started exploring areas I was unfamiliar with. I was looking for new and different ways to analyze what was and wasn't working in our app, and that's when I stumbled on the coverage tab in Chrome's web inspector. Finding it is a convoluted process; it's buried two menus deep in the Chrome DevTools three-dot menu under "More Tools", or you can reach it by activating the Command Menu in DevTools with ⌘P, typing > to see other available actions, and then typing coverage. Seeing its results for a first time were a revelation and I got excited enough to tweet about it joyfully.

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

The Coverage tab can show you unused JS and CSS on your page. Once you get into the coverage panel, by default you'll see both JS and CSS files. But you can also filter to just CSS.

What I saw there was that over 98% of our main CSS file went unused. I also realized that CSS file, on its own, was over 1mb. I'd been grinding away, paring down our JS bundle to the smallest possible size, but the CSS file was right there actually having a larger impact! The CSS coverage below comes from a different website, but it follows a similar trend)

The Problem with Large CSS Files

While it's pretty common to discuss the downsides of large JS bundles, large CSS bundles are arguably worse! CSS is a render blocking resource which means the browser is going to wait for that CSS file to be downloaded, parsed and constructed into a CSSOM tree before rendering the contents of the page. Whereas JS files these days are usually added to the end of the <body> or included with the defer or async tags, CSS files are rarely loaded in parallel with the page render. That's why it's imperative that you keep unused CSS out of your main CSS bundle.

There has been talk for years about including only "above the fold" or critical-path CSS on initial page load, but despite several tools that can try to automate this process it's not foolproof. When it comes to just avoiding including unneeded CSS I think many would agree CSS-in-JS approaches and even CSS Modules do a better job at this compared to the ever-too-common approach of having one large Sass or LESS file that contains all of the styles anyone might ever need for your site.

Pinning Down the Problem

My team's initial approach to styling was to have a single large Sass file with dozens of dependent stylesheets @imported in. That made it quite difficult to figure out exactly what parts we were or weren't using, and I spent hours scouring our CSS files looking for unused styling. Nothing looked obviously wasteful, and I certainly couldn't find a whole extra mb of unused style. Where else could the CSS be coming from? Was it from a shared header/footer that included extra styles? Maybe a JS-based CSS import somewhere? I had to find out.

Searching through our JS code, I found only 4 or 5 CSS imports. Our webpack config made sure that all CSS imported from inside our JS files ended up bundled together in one large file. In our main JavaScript entry file (index.js), I found 2 CSS imports that looked particularly suspicious. This isn't the exact code, but it was something very similar:

import 'semantic-ui/dist/styles.min.css'
import 'semantic-ui/dist/styles.css'

I had looked at this code and ignored it literally dozens of times. But given my new challenge to figure out where the extra CSS was coming from it stood out. Why were we importing this library at all? Did we even need it? And why were we importing it twice (both minified and non-minified)?

The first thing I did was comment out both of them. I ran npm run build and saw our CSS bundle drop from 1.25mb down to 30kb! It was ridiculous. This code was killing us. ☠️

Unfortunately, as you might predict, our website looked horrible after removing the CSS. We were relying on something in those CSS bundles. Next, I commented out each of them one at a time. Strangely, we needed to keep the non-minified one in there to avoid breaking the look & feel of the site, but at least I was making progress. We shaved off around 500kb of CSS just by removing one line.

Now began the more difficult part of removing our reliance on that UI library altogether.

What Was Left

Like many teams, we relied on an internal UI library that our app was already importing. I figured we could probably use that internal library to provide most, if not all, of the functionality we were getting from the external library.

An early approach I took was simply copy/pasting the whole built Semantic UI library CSS into a new file and then removing things we didn't need. That got me somewhere, but became increasingly difficult as the styles got more nested and complex. Eventually I removed the CSS imports completely, purposefully breaking the look of the site. That made it easy to identify which classes we were actually using. We took screenshots of the working site and then carefully compared them with the broken version.

It turns out we were primarily using three components:

The grid system
The navigation tabs
Modal dialogs

Once we figured which pieces of the library we were using, it was easy enough to search through our code base and see which components were relying on them. There were a lot that used the grid for example, but we had a drop-in replacement for those that only required a small class name change. In some other cases, we had to either add new CSS or move the HTML around a bit to get it to work with our other UI library. It ended up being about a month of work for a new team member to completely detach us from that external library. We carefully reviewed her work, compared before & after screenshots, and where there were minor style differences, ran it by a few team members to make sure the changes were close enough to the original to not block the change.

The Impact

After we shipped the changes we looked at our real user monitoring graphs and saw massive reductions in both our 50th and 90th percentile time to interactive measurements across the app. At the 90th percentile there was around half a second of reduction in TTI. After making so many changes that didn't seem to matter, it was so satisfying to finally have a solid performance win.

Removing that one UI library bundle probably ended up having a larger effect than any other single change I witnessed in my entire time working on web performance at Amazon.

The Takeaways

I've found it's very difficult to generalize web performance wins. How likely is it that your app is also double importing a large CSS library? You might as well check, but it's probably not happening. What I hope you take away from my experience here is the underlying factors that enabled us to find & fix this problem.

Don't just optimize to a checklist (Learn the tools!)

The easier part is process-related: you can't just optimize to a checklist. It's important to have checklists when you're working on performance work, because many apps can be improved by a straightforward, well-known list of simple improvements. You can and should leverage the work you've done in the past, and that the community around you has done to improve performance. But when you reach the end of your checklist, you need to develop the skillset to keep digging. Just because other apps you've worked on benefitted from change A or change B doesn't mean it will work in your next app. You have to understand your tools. You have to know the specific characteristics & architecture of your site. And you have to know your customers. Lighthouse probably told me early on in this process that I had too much CSS on the page. Without a clear understanding of how our CSS files were built and better tools for analysis I wasn't able to do much with that information. While checklists of common web performance mistakes can absolutely be helpful, teaching teammates how to use the tools available to analyze web performance in the specific, is much more powerful.

Have a strong web performance mandate

The other major takeaway, though, is about culture. To build performant applications, performance itself needs to be a first class KPI. I think many engineers enjoy optimizing things. It's really fun and difficult work. The results as we all know can be very inconsistent. I can't tell you how many times I promised to shave off 150ms from our experience, got that improvement when testing locally, but saw nothing or even a negative impact when the change actually went live. In many cases that can lead engineering or product managers to be weary of such promises. My org at Amazon had amazing leadership when it came to web performance. That mandate ensured that we had the buy-in we needed to keep going until we had the impact we wanted.

I don't expect this article to provide any magic bullets for those out there trying to optimize their apps, but I do hope it encourages you to keep digging until you find your own.

P.S. I want to give a shout out to my colleagues Scott Gifford and Michael Kirlin. Scott remains hugely influential engineer at Amazon in the web performance space and mentored me throughout my time there. Michael not only reviewed this article, but edited it extensively for clarity. Thank you friends!

Building 2D Websites for the Metaverse (or at least for the Oculus Quest Browser)

Jamund Ferguson — Fri, 26 Nov 2021 05:13:38 +0000

As a long-time web developer and non-gaming VR fan I'm really excited about the potential for the web on virtual reality platforms like the Oculus Quest. Last week I spent a few hours toying with my 2D tetris clone on the Oculus Quest browser and actually got it installed it as a Progressive Web App on my headset. I'm excited to show off how I got this to work and what I learned in the process.

Oculus Quest is Essentially an Android Device

The Oculus Quest is basically an Android smartphone that you strap to your face. To get started developing for the Quest, even on the web, you're going to want to download Android Studio and the Android SDK Platform Tools. You'll be using the adb command from time to time to confirm your device is properly connected, install your PWAs and make other advanced configuration changes. You also will need to enable developer mode for your device, which you need to do from the Oculus app on your phone. There's also another step in the Oculus settings menu where you'll need to enable USB debugging.

Oculus provides some desktop software called Oculus Developer Hub that simplifies a number of key developer tasks like verifying your connection, disabling the guardian, casting and taking screenshots.

It’s definitely a lot of steps, but after you've got all of this setup you're well on your way to building Oculus VR apps in 2D using web technology. It's exciting!

Browsing the 2D Web in VR

When you open up the Oculus Browser for the first time you might notice a few things that are unique about it compared to a normal web browser. The first is that it's capable of 3 browser windows side by side. So you're confronted with this 180° wall of browser windows which measures over 3000pixels in width. The default width of each window according to the oculus browser specs is unique at 1000px wide by 505px high. And as of right now you can resize them, but only the width. You’re stuck with that strange height. (Edit: Width/Height Resizing is now available as of Dec. 13, 2021.)

Try to pull up a few websites. If it's something interactive like my tetris game there's a good chance it won't quite work!!

If on the other hand you pull up a standard news site, blog or even the something optimized like the React Three Fiber Demo App they should all look and work great.

Debugging Local Code

Assuming you're building your app on your local computer you probably want to see those updates immediately in the oculus browser. To do that you need to setup a reverse proxy which forwards all traffic from a port on your Oculus device to one on your computer:

adb reverse tcp:3000 tcp:3000

With that you should be able to enter in URLs like http://localhost:3000 in the oculus browser and have them work perfectly, reading files off of your computer.

If you're using something like codesandbox or glitch to host your files it can be really helpful to use this feature of Oculus Developer Hub which lets you enter in a URL and have it open automatically on your headset.

Now comes the mind blowing part. You can inspect your oculus browser window from inside of Google Chrome. You simply go to
chrome://inspect/#devices and click "inspect" on your device instance. It really feels like magic.

I mostly used console.log to log my event listeners, but as far as I can tell the full JavaScript debugger along with the network and element inspectors. Because going back and forth between your computer and your headset is obviously kind of a pain, I found testing by interacting with the little preview app inside of inspector window actually saved a lot of time.

UX & Web API Considerations

✅ Now you have your app showing up in the Oculus browser and you're able to update and debug that app on your local computer. Here are some basic tips for optimizing that app for running in VR:

Use the PointerEvents API for user input
Make buttons and text Larger
Optimize for a wide screen

My initial tetris implementation relied on keyboard input to move things around. When first porting it over I started using mouse events like mousedown and mousemove and was surprised when they didn't work. I shouldn't have been surprised though. The Oculus Browser is running on an Android device. Instead of mouse events it supports Touch Events and the slightly cleaner PointerEvents API. Pointer Events give you have a single event for both touch and mouse events. They're fully supported in React and seem a little easier to work with than touch events, which support input from multiple touches simultaneously.

Once you get your user input working properly make sure to make your interactive elements larger. As mobile web browsing began to take off a decade ago, both Apple and Google provided UI guidelines for how users interact with their devices. One of the main ones was to give a lot of padding to buttons & other controls you expected the user would touch. This was to make sure when someone's finger didn't quite make the target your app would give them what they wanted anyway. This is even more important in VR where your controllers are in a constant state of motion. Make those inputs larger and given the blurry text we still have in VR, make your text larger as well.

My last realization is to consider the screen real estate you have in the Oculus Browser. You're dealing with 1000px wide, but only 505px high. It's a fairly wide screen, but it's really short. Scrolling in the Oculus Browser works fine, but I'd personally recommend designing for wide screen without having to scroll. Certainly for most games or more interactive apps you don't want to have to scroll to see some important part of the action. Think about how you can stretch your app out. Many tablet apps are designed to take advantage of space in landscape mode and I'm confident we'll figure out how to do this well for VR.

More To Learn

My tetris clone still isn't fully optimized for VR, but I made the buttons a lot bigger and migrated to use the Touch Events API so that pieces can be moved around as they are falling. I also got it installed as a PWA so I can run it next to other apps in my library. My next steps are to migrate to the Pointer Events API and to figure out how to optimize for all of that horizontal screen real estate!

Once I get that sorted out there are definitely a few more questions I want to dive into. Do I need the WebXR Gamepads API to capture the various buttons and trigger inputs from the oculus touch controllers? (Follow up: nope, they can't be accessed outside of immersive-vr mode.) Could I make a super wide game that spans 3 browser windows using postMessage or the Web Storage API? And then beyond that, is a 2D web for VR even a thing worth pursuing? How hard would it be to use something like a-frame or React Three Fiber with use cannon to make fully immersive 3D world? People are doing it, so why not you and me?

There are so many technologies generating enthusiasm right now in the world of web development, but I wouldn't sleep on building web apps for VR! Meta has sold over 10 million Quest 2 devices already and that growth seems to be sustainable. This is happening. What role is the 2D web going to have in virtual reality and the so-called metaverse? What about WebXR and the 3D web? It's up to us to build the future we want to see. So start building!

Generating Universally Unique Identifiers with JavaScript

Jamund Ferguson — Wed, 24 Nov 2021 23:19:24 +0000

For as long as I can remember the recommended way to generate unique universal Identifiers in node.js was to the uuid module. These IDs are useful in all sorts of scenarios including for database keys, filenames, URLs, etc. Recently both node.js and the browser began offering nearly identical APIs that will generate 36-character version 4 uuids without any dependencies.

Available in Chrome since July 2021 and coming soon other browsers is crypto.randomUUID(). There's a global crypto object that's available on the global self property. You can use that to generate a UUID like this:

self.crypto.randomUUID();

The UUID it generates is a v4 UUID per the spec and ends up with a string that looks something like this:

"0aa9d4f3-efdb-4a06-806c-5f8fa5f1767d"

You want to do the same thing in node? Instead of reaching for the uuid package. As long as you're on version 14.17 or newer, you can do this:

const { randomUUID } = require("crypto");
randomUUID(); // "0aa9d4f3-efdb-4a06-806c-5f8fa5f1767d"

It's cool see node and the browser adopting powerful APIs for crypto and improved randomness. I'll definitely be reaching for these in the near future!

You can read more in the WebCrypto section in the MDN or the crypto section in the node.js docs.

Redux Testing Lessons Learned: Render Components with a Real Store

Jamund Ferguson — Tue, 23 Nov 2021 22:19:33 +0000

This post is a follow up to Redux Testing: Hard Lessons Learned where I spoke about two important principles for testing redux apps: "Stop Testing your Disconnected Components" and "Build a Small Utility Library". Mostly we went through some of the key utilities that I use to make testing redux apps more manageable. This post will cover another area I called out in the first post: Render Components with a Real Store

For a long time I relied on redux mock store to preload data into my components for rendering during tests. This approach makes it easy to take a snapshot of a component with arbitrary data and ensure that it renders correctly. Where it completely fails is testing interactions.

What happens when I click the close the button or when I select that image? With redux mock store you have a special method named getActions that tells you what actions were fired, but that's it. Those actions don't actually make it to your reducers and they never update the UI. This makes your tests pretty frustrating to write. There's no good way to confirm that a component can transition from one state to another. You can only test snapshots.

The first and quickest way to solve this is to pass your actual redux store into the <Provider> you use to wrap your tests and then return it. For example:

import { render } from "@testing-library/react";
import { store } from "../app/store";

function renderWithContext(element) {
    render(
      <Provider store={store}>{element}</Provider>
   );
   return { store };
}

This immediately gives you all kinds of powers. The first one is the ability to dispatch actions to populate or otherwise your modify redux store. Because those actions are dispatched synchronously you can immediately assert that the UI was updated.

test("table should render all kinds of data", () => {
    const { store } = renderWithContext(<ResultsTable />);
    // expect() table to be empty
    store.dispatch({ type: "POPULATE_DATA", data: { /* ... */ })
    // expect() table to be full
});

The other thing it lets you do is assert that your redux store changed in response to an event that wouldn't normally affect the component you are testing. For example let's say you had a button that updated a counter, but that counter component lived somewhere else. We can pretty easily test that clicking the button updated the count in our store.

test("counter should update count", () => {
    const { store } = renderWithContext(<CounterButton />);
    expect(store.getState().count).toEqual(0);
    userEvent.click(screen.getByRole("button"));
    expect(store.getState().count).toEqual(1);
});

Now the issue with sharing your actual redux store is that the order of your tests shouldn't matter. You really want to run your tests in isolation. With the shared store approach if you dispatch an event in one test, the changes are propagated to all future tests. And that's why I ended up with the getStoreWithState method I showed in my previous article as a key utility.

// ...
export const store = configureStore({ reducer });
export function getStoreWithState(preloadedState) {
  return configureStore({ reducer, preloadedState });
}

There are two important parts here. The one that I mentioned before was the preloadedState option, which lets us render components in tests with state already setup in a specific way (similar to mock redux store). The second and more subtle accomplishment here is that we're giving our generated store access to the same reducers used by our app's store. This gives us an isolated store to use for each test that also has access to the full power of our application's reducers.

One benefit of this approach is that every time we test a component hooked into redux, we're also testing multiple reducers. It more economical and it more accurately reflects how our application actually works. Not to mention your tests are way easier to write this way. If you're used to testing with mock-redux-store this approach is going to give you a huge boost.

If you want to learn more about my approach to testing redux applications please watch my course Confidently Testing Redux Applications with Jest and TypeScript.

Redux Testing: Hard-Earned Lessons Learned

Jamund Ferguson — Tue, 23 Nov 2021 20:14:58 +0000

To celebrate the launch of my new course Confidently Testing Redux Applications with Jest & TypeScript I wanted to share some of the lessons I've learned about testing over my years of using redux in production react applications.

Almost everything I learned through experience was already discovered by others and put down in the Redux Style Guide which I highly recommend reading and sharing with your teams.

In particular I want to share four things that have helped me get to a place where I feel like I'm testing the right things without a lot of hassle. Here's that list:

Stop Testing your Disconnected Components
Build a Small Utility Library
Render Components with a Real Store
Prefer Integration Style Tests

One of the difficult things about bringing Redux into your apps is that any redux-connected component needs to be wrapped at some level in a redux <Provider>. That Provider ensures all components rendered in that tree use the same redux store. When you're building an app, you usually just add <Provider> at the top level and don't have to worry about it. When testing redux apps though it becomes a major pain. Each test for a redux-connected component has to be individually wrapped in its own provider.

Many teams get around this by exporting a smart connect()ed component and a basic (non-redux) version of the same component in the same file. They then just don't test the redux-connected version at all. Please don't do this.

Avoiding testing your redux-connected components is a mistake for two reasons. The most obvious is that you're not testing the version of your component that your customers are going to use. This means you lose some confidence in your tests. You're explicitly leaving out important cases. The next reason is that the redux hooks API, which provides a vastly superior developer experience to connect() doesn't support this pattern. It's unlikely that you'll be able to continue to separate your component that way as you move into the future.

A better approach is to create some utilities that simplify the way you setup and render your components. I use three in my course: renderWithContext, getStoreWithState, and getStateWithItems. These utilities help me work with state and context without cluttering my tests with complex setup code.

Let's start with the most simple one getStoreWithState:

import { configureStore } from "@reduxjs/toolkit";

const reducer = { /* ... */ }

export const store = configureStore({ reducer });

export function getStoreWithState(preloadedState) {
  return configureStore({ reducer, preloadedState });
}

Redux Toolkit includes a configureStore method that allows you to preload it with state. The createStore method in redux includes this option as well. In the old days I would rely on tools like redux mock store to generate redux stores for testing, but you don't need it. You can generate a store for your tests that includes exactly the same reducers as your app, but also comes pre-loaded with whatever state you need for your tests.

The next utility that you'll need is a way to render your components with state and context. For my tests I'm usually using React Testing Library, but the same approach works fine if you're using enzyme.

import { render } from "@testing-library/react";

export function renderWithContext(element, state) {
  const store = getStoreWithState(state);
  const utils = render(
    <Provider store={store}>
      {element}
    </Provider>
  );
  return { store, ...utils };

I've seen a lot of test suites that include a mountWithStore function inside of them, but I think you get a ton of benefit moving this into an app-wide utility file. It makes it a lot easier to pre-populate state consistently and provide any additional context that might be needed for your tests.

With these two utilities in place it's fairly straight forward to render a component with arbitrary state pre-loaded.

import { renderWithContext } from "../test-utils";

test("error banner should appear", () => {
    renderWithContext(<Header />, { errors: [{ /* ...  */ } ] })
    expect(screen.getByRole("alert")).toHaveTextContent("Could not load data");
});

The only other utility I found to improve on this a little bit is one that generates the whole app state for you, but lets you modify some piece you might want. Some apps put this state in a JSON file, which can be helpful, but having a utility function that lets you override some common parts has proven crucial. This will always be unique to your app, but here's one example of what that could look like:

export function getStateWithErrors(errors) {
  const state = {
    products: { /* ... */ },
    cart: { checkoutState: "READY", items: {} },
    errors
  };
  return state;
}

With that the test above might be written like:

import {
  renderWithContext,
  getStateWithErrors
} from "../test-utils";

test("error banner should appear", () => {
    const state = getStateWithErrors([{ /* ... */ }]);
    renderWithContext(<Header />, state);
    expect(screen.getByRole("alert")).toHaveTextContent("Could not load data");
});
test("error banner should not appear", () => {
    const state = getStateWithErrors([]);
    renderWithContext(<Header />, state);
    expect((screen.queryByRole("alert"))).toBeNull();
});

With this approach you can imagine making it easy to generate state where you only need to pass in a single error message while the function takes care of the rest.

That's a bit about how utility functions have helped me write manageable and possibly enjoyable tests for my redux apps without having to resort to tricks that have made my tests less reliable. The next article in this series is Render Components with a Real Store.

If you want to learn more about my approach to testing redux applications please watch my course on egghead.io.

Adding a REST API to your Vite Server in 5 Seconds

Jamund Ferguson — Tue, 23 Nov 2021 18:04:40 +0000

Like many others I've been blown way by the incredible performance and capabilities of vite as a tool for rapidly building out React apps. In my role as an egghead educator and a Developer Advocate at PayPal I'm looking for tools that install quickly, have minimal setup costs and let me start building immediately. vite does all that and more, but in the past I often run into one limitation: I need some kind of API to complement my apps.

I've been using express to build out APIs pretty much since it first came out. Checkout my course on using express 5 if you want a quick tutorial. Express makes it easy to build out APIs and it's super easy to add express support to your vite app. You just need a single plugin: vite-plugin-mix.

I promised 5 seconds, so get ready to copy & paste!

npm install -D vite-plugin-mix

Then in your vite.config.js file add this to your plugins array

import { defineConfig } from 'vite'
import mix from 'vite-plugin-mix'

export default defineConfig({
  plugins: [
    mix({
      handler: './api.js',
    }),
  ],
})

And then in api.js type:

import express from 'express';

const app = express();

app.get("/api/hello", (req, res) => {
  res.json({ hello: "world" });
});

export const handler = app;

Once you do that you can startup vite with npm run dev and like magic you'll have the ability to reference /api/hello on your local dev server. Like everything else in vite, if you make any changes to your API they'll be available immediately without having to restart anything. Just edit the code and call the route again and you'll see the latest!

One little note: I have only used vite so far for local development and can't personally vouch for it for production apps. If you're looking for something a bit more production ready you might want to check out fastify-vite which combines another popular API server, fastify with vite for one powerful and fast full-stack development tool.

Happy hacking friends!

Two Simple Tricks for Typing Redux Apps with Typescript

Jamund Ferguson — Fri, 23 Apr 2021 14:44:37 +0000

Despite having used Typescript and Redux separately for a few years I haven't always had a good experience putting them together. Recently, I stumbled on two tricks that have helped me immensely.

Generate Reducer Type from Initial State

When you're creating a new reducer you can use typeof to generate the type for the reducer from your initial state. This also encourages us to fully fill out our initial state, which I find helpful for quickly understanding the purpose of each reducer.

When you export your reducer make sure to include that generated type as its return type.

const initialState = {
   dogs: 4,
   name: "Callie",
   colors: ["red", "green", "blue"]
};
type MyReducer = typeof initialState;

export default function myReducer(state = initialState, action): MyReducer {
  // ...
}

If your initial state doesn't include all of the values, you can include them as placeholder values such as null. In those cases you can use as <type> to indicate the intended type for that piece of state.

For example const initialState = { person: null as Person };

Export Your Entire Redux State

Once your reducers are all individually typed, you can create and export a combined ReduxState type using Typescript's ReturnType utility. This type will contain information about every single reducer used in your application.

import { reducers } from "./reducers";
export const store = createStore(combineReducers(reducers));

export type ReduxState = ReturnType<typeof store.getState>;

Use this to type the state argument used by your selector functions, mapStateToProps or anywhere else that may be needed.

import { ReduxState } from "../store";

export const getDogs(state: ReduxState) {
   return state.myReducer.dogs;
}

A version of these same ideas (and many others) can be found in the Usage with Types section of the redux docs.

While it doesn't cover typescript (yet!), don't forget to check out my course Redux with React Hooks which shows how much simpler redux becomes when you drop the boilerplate.

What are your favorite typescript tricks when using Redux?

My first git alias

Jamund Ferguson — Fri, 16 Apr 2021 19:04:50 +0000

At work I'm often jumping back and forth between various branches and pull requests and I sometimes find myself struggling to remember the name of a recent branch I need to use.

For years I've used git reflog as a short-cut to look at my git history and identify my recent work. It works okay, but it's very hard to make sense of:

Other times I try to use git branch, but that doesn't give you much context about anything and of course it can be easy to drown in the large number of branches:

~/d/n/webapp (typescript ✔) git branch
  add-cognito-auth
  doritos
  eslint-prettier
  main
* typescript
  updated-husky

Recently I got frustrated by this and decided to find a solution and stumbled on this stackoverflow question, How can I get a list of git branches ordered by most recent commit?, which taught me two really useful techniques.

You can sort branches by commit date using git branch --sort=-committerdate which is great in an of itself (watch out for the - after sort= which puts the most recent branches first)
You can enhance this output a bit using this wild syntax git branch --sort=-committerdate --format='%(HEAD)%(color:yellow)%(refname:short) | %(color:bold green)%(committerdate:relative) | %(color:blue)%(subject)%(color:reset)' --color=always which I'm never going to remember.

Which led me to create my first git alias after over 12 years of using it. Here's how I did it and here's what it looks like:

git config --global alias.branches "branch --sort=-committerdate --format='%(HEAD)%(color:yellow)%(refname:short) | %(color:bold green)%(committerdate:relative) | %(color:blue)%(subject)%(color:reset)' --color=always"

That command added this to the boottom of my ~/.gitconfig file:

[alias]
        branches = branch --sort=-committerdate --format='%(HEAD)%(color:yellow)
%(refname:short) | %(color:bold green)%(committerdate:relative) | %(color:blue)%(subject)%(color:reset)' --color=always

Now when I type git branches I see this lovely output:

Git isn't always the easiest to use, but this alias has made it just a little bit better, for me anyway. What kind of aliases do you use?