“Agents are so good now! I’m sure if you asked model of the week to do that for you it would crush it!” – Everyone I talk to AI about
With how good models are now I have to agree, but it’s beyond a question of fidelity. I would believe that whatever new ultra coding model given the right context, tools, skill files, hooks, etc would 100% be able to execute on the tasks. The question for me becomes: if I already know what I want to do, what’s the tradeoff between just doing it and trying to explain to an agent how to do it?
LLMs have found their ecological niche in my development environment as an effective “research assistant” that I can delegate factual research tasks to. With some of the available MCP connectors in most agent harnesses, it’s so easy to ensure that an agent has access to tools it needs to see monitoring data, database DDL, database data, code patterns, and even institutional knowledge. Those natural questions that come up when planning a feature such as “How much extra write traffic to this table will I introduce with this change” or “How many times does this job I’m adding a new query to run in a day” can be delegated to an agent on the spot leaving me to return to whatever train of thought I was already in.
As much as I really want to say that all LLM generated code is garbage slop code not worth any real developers time, that’s not an intellectually honest opinion either. The reality is LLMs and agent harnesses like Claude Code are now write decent code for the most part. Agents can still struggle to write concise code that’s informed by knowledge of a given business task, and the code LLMs generate does tend towards the over-engineered at times, but for most businesses that’s probably a fine tradeoff. Agents are especially effective with changes where the work of discussing what change needs to be made is more work than the change itself: copy changes, repeatable changes to several files, etc. If we are heading towards a world where those sorts of tasks can be executed by an agent being driven by a non developer, and reviewed by developer teams, that seems overall like a win to me.
The key factor that makes these tasks worth an agent doing for me is they, typically speaking, don’t take context on the codebase and the business away from me as a developer. Adding meta tags to a bunch of buttons, asking claude to rewrite an array map using a functional interface, or reviewing an AI written PR that adds a small conditional fixing some Sentry error that’s been kicking around aren’t going to reduce my ability to understand the system that a codebase is representing and the business need that it’s trying to solve.
It’s only a given then that where I don’t like LLM and agent driven work is tasks that do require my own expertise of the codebase, software development practices, or my experience. Claude Code could, with some non zero amount of quality, create for me a large sized epic that adds functionality to the app. It then could, in theory, automatically execute on those pieces of work autonomously and in parallel. I could orchestrate 15 agents all working together, giving each other code reviews, with a designer agent and a supervising agent, to get the work done. I do 100% believe agents could do this and produce a reasonable product. In fact, I’ve contracted my services out on the side and basically done just that, and the product worked well enough to make the client happy.
Where LLMs fall flat for me is not fidelity. The tradeoff between developer context and LLM speedup just isn’t worth it, and that’s being generous and assuming that agentic workflows like what I describe above do actually speed up work (With the data that I have seen I’m not convinced the speed up is real but I would believe it can given the right org).
The best developers thrive on institutional knowledge. They know their code is legacy the moment it’s shipped to production. They know that the needs of the business are going to change in a few months. They’re ready for half of their project to get de-prioritized for a company wide priority project. They know how much over or under engineering they need to do for a project by reading the context of that project against the business. LLMs are just kind of bad at that stuff. LLMs don’t know that your PM has a tendancy to under-estimate the effort of projects, or that at a company all hands if you read between the lines you know that your team is going to have to do support work for another team for a quarter. Company and office politics, org structure, and the ego of people leading projects are important inputs that can have a real effect on the code you write. And the verbose and winding nature of LLM code doesn’t lend itself well to the fuzzy nature of how work really gets done in an software shop.
All that being said, I don’t believe in the type of “developer powerscaling” that tends to happen in conversations like this. The Primeagean Pirate Software Yandere Dev Linus Torvalds Jonathan Blow epic pwn your code sucks cause you write javascript is a toxic part of the wider culture of software that I hope dies and never comes back. This is work for most people at the end of the day, and if the way you choose to get work done (or need to get work done if you work at a company like that) is to spin up 5 claude code agents and prompt…you gotta do what you gotta do. A non zero amount of my token usage at work is simply so that I can say I tried to do something with AI. I will say that I think going forward what’s going to separate mid level from senior developer is a desire to struggle through problems yourself and seek that deeper meaning, even if only to be able to better control agents that go off the rails.
]]>In my first ever web course in university, my TA in the very first lab told us something that is really core to what I mean here:
React is not a framework, its a UI library.
For a long time I relegated this fact to something I could say at dev trivia games or over lunch with co-workers, but this idea is really deep. React isn’t an opinionated way to build a front end. React isn’t a way to manage how data flows through an application. React isn’t a tool to build entire applications. What React is is a library to manage the lifecycle of UI. All the fancy hooks and contexts are just there to help you manage how your UI changes over time in a (mostly) declarative way.
Since React itself doesn’t have any opinions about what you do outside of how it expects you to manage this visual lifecycle, in larger orgs what tends to happen is that the Front End codebase gets more and more chaotic. I won’t go as far to say it gets messy or unclean, as long as an org has good coding standards the code itself can make sense be quite clean. What I mean is that over time there isn’t a unified way to do the things a large application needs to do, particularly at the boundary between front end and back end. React doesn’t have an opinion about how you fetch data from the backend, so what will happen is some teams fetch their data using custom hooks, and others write large useEffects that fetch data, and others leverage tools like Redux to manage their data. When Contexts were introduced teams started to favour that instead of Redux as a way to manage their data, and again React really has no care in the world about how you pass data down to its components.
What’s even stickier is that because React doesn’t care how you do all this, it’s hard to fix. The best you can do is release an org wide guideline on when to reach for what tools, but theres nothing in React itself that can enforce any of these patterns unless you build it yourself (for example using a pattern like Flow, but if you’re doing that you might as well just use Redux). I also have found that despite how powerful frameworks like Next.js are, they still don’t really solve this problem since the front end of a Next app is essentially still just React. Next solves for the problem of how routing and pages should work on your frontend, and it does provide a pretty thin API layer, but it doesn’t give you an opinionated way to organize how data flows through the application.
Strong React developers usually have a great sense of what makes a component “Reactive”, this idea of writing a declarative pure function that perfectly describes how a visual element should look and how it should change over time. That “Reactive” paradigm just doesn’t extend to the larger concerns of a front-end. React gives you nice ways to tell a component to look like its loading something while data isn’t available, through useEffects to fetch the data and <Suspense> to manage what a loading state looks like. That’s its strength and why its so popular. The reality is, you can also use React to manage other parts of your application, and it does that job just fine. Not great, but fine. Custom hooks that call out to databases, backends, and services are a great abstraction for a lot of cases, but its not something react FORCES you do use.
That’s not a problem at all, but knowing that React doesn’t force your hand is key here. Once we are outside of the component, we are just in JavaScript land. Once we acknowledge that landscape, we can survey it with clear eyes and pick a better tool as our needs fit.
]]>The following lessons, mantras, koans, hot tips, and nuggets of advice are the result of what has been an eternal dialogue with myself. Take these not as hard truths, but as directions or interpretations of an attempt to resolve the dissonance in myself.
Note: After writing this I noticed a shocking resemblance to some of the advice in The Pragmatic Programmer so go check that out if you like the vibe here
You should strive to write clean code. The act of coming up with good function, class, and variable names makes you think about your code more and then makes you write better code which makes you think about your code more and your names more and it’s all a lovely run on sentence of a loop that keeps improving and improving itself. Worship at the altar of clean code. Strive for perfection.
Learn every prayer, every verse, and every single interpretation and sect in the Theology of Clean Code. Once you do, become an godless anarchist. There are no rules or laws. The doctrine of Clean Code is a flawed one, and the only way forward is to form a voluntary association of code. Clean Code is merely a social construct. Clean Code is whatever makes sense for the code you are writing. Throw away the oppressive and frankly outdated word of Uncle Bob and embrace the chaotic and beautiful world of unclean code.
You won’t have time to make it perfect, so make it good enough. It’s always going to be bad, and even if code is self documenting and all that good stuff, code always changes and good function names change. All it takes is one new line of code to completely change the meaning behind a function name. So, learn to live with bad code.
I’m a bit spoiled in the sense that the first workplace of mine in the industry was a very healthy one. We were encouraged to learn and grow as developers, and there were a plethora of company wide initiatives such as Dev Talks, Hackathons, and Study groups to foster that. However what I did learn from the silver spooned experience is that you should want to work at an organization where this is the case. Working in software is about constantly staying up to date with modern tech, and you should be always learning. There is no perfect piece of software, and the process of making software is one of perpetual skill building. Every project and feature carries some lesson with it, and if your workplace is helping you learn those lessons you should try and stick around.
Software developers, at least at the time I’m writing this, are paid pretty well. Senior Developers in Canada make significantly more in salary than 99% of the labour force. In terms of just raw time and salary, code is expensive. It takes a team of 5 developers 2 weeks (the average sprint length) to build what product teams would consider a feature, and that’s being very generous in terms of scoping. Larger pieces of functionality can take upwards of 6 months, at which point the organization has probably spent $500,000 on just salary.
There’s also costs to actually letting people use that code. CPU time costs money! We need that CPU time to run tests, run CI/CD, make builds, run a staging server, run a production server, and possibly other environments such as sandboxes. It’s all expensive! This is why real pressures to build products people want to pay for and to build things quickly and descope aggressively always end up arising in these projects.
What you started working on was probably a cool tool that made peoples lives easier. Something that eased a pain in the real world, and as a software developer you should ideally love the challenge and reward that comes with expressing that real world pain into the logical domain of a programming language. In the software world, you can control the laws of the universe and solve that problem with absolute certainty. Time passes, the product gets sold, and eventually economics plays into how the product and organization operate. Turns out, you need to make money to pay for all that expensive code. Features get paywalled, pricing schemes are changed and introduces, and at least in my experience it starts to feel like the think that makes the app useful is now gated behind enterprise / mid market size corporate customers, and the average user who found the tool awesome in the first place is left in the dust. This really sucks as the engineer, since I would hope you derive some value from making something people actually like rather than some list of required features to make some important deal work out.
I really like writing code. I really like trying to figure out how to make something work, from the smaller things like trying to implement a function to larger scale system design. The name of the beast is managing complexity and the only thing you can do to slay it is have an undying craving for simplicity. It doesn’t really matter what you actually work on:
If you have the right attitude, interesting problems will find you. source
Some of my peers will often tell me they wouldn’t work in X field or don’t want to work in Y language. The thing is the core problem in development never changes, it’s always about managing complexity. Every language, environment, tool, and stack is just trying to do that in a different way for a different use case. So, embrace the fun in all problems.
The day to day, or even week to week, of coding is really fun. Technical problems appeal to people who like to find interesting problems, and its a joy to solve them. What puts a dark stain on my heart is when I step back from the work and look at a wider scale of what I’ve worked on and see it amounts to something I don’t like. In my case I spent weeks working on really interesting problems in Typescript/React only to realize what I built was a mechanism by which we can make the app frustrating to use for our “small fish” customers. I want to be clear here, I worked on a team that specifically dealt with Billing and Growth, so my perspective is very skewed. By all customer accounts our product was still great, but still! I don’t enjoy writing paywalls just as much as I don’t enjoy writing data tracking software or software that generates ad content. The comparison has been beaten beyond death but working as a developer can feel like living in a Quarter over Quarter loop of Frankenstein.
Your job as a developer is to communicate the technical perspective of any problem. You know something others don’t, and its your job to explain that to them. This is really hard, and a lot of people stop at the first step. The first step is really easy. Most people know something that other people don’t. Get to the second step and get good at explaining it to others! The people around you will have varying levels of ability to understand technical content, and it takes a lot of work to cater your explications to that understanding. But if you can’t make everyone involved with a project understand the technical stuff, even at a high level, you aren’t doing your job.
Learn how your environment works. Learn keyboard shortcuts. Learn how to use your computer effectively. Learn how to edit text effectively and quickly. Learn tools to ease your work. If you have a frustration, find or make a tool that solves your pain point. If you don’t have time to make a tool, complain to your co workers about it, someone else might have the time (or you might be lucky enough to have a Developer Experience team who’s job it is to fix your problems).
Learn how to find documentation. Learn to read documentation. Learn to write good documentation. Find help at the right times. If you come to someone else with a problem, at least try to have solved it yourself first. Someone else probably had your problem, go find the solution out there.
Don’t spend more than around an hour stuck on a problem. Don’t spend any less than around an hour stuck on something. Allow yourself to be frustrated with problems, them let them sit and come back to them. Don’t try to fix that one last thing at 4:45, chances are you will fix it in 5 minutes the next morning.
]]>One of the more challenging parts of actually working as a developer is the need to understand the technologies you are using and creating on a very deep level in order to be able to developer new software, answer questions and communicate capabilities to other people. Instead of writing the minimal level of software needed to get a rubric mark for a piece of logic or code, thousands of real people are engaging with your application and it needs to be robust, extendable, and cleanly written enough that you can effectively maintain it. I like the way that Steve McConnell puts it in Code Complete:
Software’s Primary Technical Imperative is managing complexity.
Software is so complex that no one person can even really understand it. The only way we can even begin to get a foothold is to divide that complexity into simple and understandable parts, and organize those simple parts into a system.
A great source of examples for how this is even accomplished is found by actually diving in to
the weeds of how a particular problem works. Some problems are so difficult that nobody has
really solved it, and looking at the various approaches can tell you the different ways
people have attempted to solve those problems. I wanted to learn some of these general techniques by looking into the functions, classes, libraries, and technologies I use everyday and take for granted. I’ve found that by asking questions like “How does useState work and what problem was it created to solve” I can get a foothold into how I’m even supposed to something in the first place.
The process of looking deeper can also lead to connections with new techniques or technologies in of itself. I barely remembered binary arithmetic from my 2nd year Computer Science courses, but I had a reason to learn about it when writing my post on data serialization. Diving into when something is useful by seeing it actually used is so much more motivational for learning.
Going forward I think I’ll do something closer to a post a week. I may do a challenge like this in the future if I find I’m slacking or have a bunch of topics I wanna write about. I wanna do longer style posts I construct over a few days so I can go into more detail about some of the thing I look into. I found myself writing long paragraphs only to delete them because I felt it was a rabbit hole that didn’t need to be gone down to get a point across. Hopefully you found those posts informative!
]]>struct Point {
int x;
int y;
}
void movePoint(Point* point, int x, int y) {
// operates on a specific point by going to its location in memory
point->x += x;
point->y += y;
}However, program memory is specific to the machine (and process!) the program is running on. Suppose that movePoint() was actually a function running on a different
machine that we could call. I could pass in a memory location to a Point at some location like 0x1FFFFF21, but on that other machine where movePoint()
lives 0x1FFFFF21 could be the location of some completely different data. So, how can I represent the data running in memory on my computer so that other
machines (maybe over the network) could understand it?
As a sidenote, we might still run into this problem with only one machine. If I were to write the memory location 0x1FFFFF21 to a file, and have my movePoint() function read from that file to get that memory location, that memory location might not make sense by the time movePoint() gets to it. This is especially the case if movePoint() is invoked by a different process than the one that wrote the memory location to disc. Memory is really only relevant to the exact same process you are running in, and persisting a memory location probably isn’t a good strategy.
One thing we could do is take our data, like our Point struct, and write out its data in a binary format. We could pass movePoint() a long sequence of bits
and as long as movePoint() knows how to decode that data it could do calculations with it.
We could accomlish this with JSON. We take our data, and represent it using JavaScript(‘s) Object Notation, then just encode that representation
as a bunch of bytes. For example, a Point object could look like:
{
"x": 2,
"y": 3
}For the sake of demonstration, lets use a more complicated example. We could take a PHP class:
class User {
public string $name;
public int $totalVictoryRoyales;
public array $nicknames;
}and encode it in JSON as:
{
"name": "Harris",
"totalVictoryRoyales": 0,
"nicknames": ["duckypotato", "ducky"]
}Now that I have some JSON text that represents my data, however in text form we still need to turn it into binary so that languages other than Javascript
can make heads or tails of it. We could just encode each of those ASCII bytes and send a big long message, but we can do slightly better. One algorithm that takes some JSON and gives us a binary encoding is MessagePack . What we do in MessagePack is use byte control codes to tell the
receiver of the message what kind of data will follow and how much of it there is. If we did this in spoken language, it would be like we said: “I’m about to tell you 5 words”, then we said “Hello My Name Is Harris”.
Our original
message above occupies 77 bytes with whitespace removed. Let’s walk through MessagePack and see how many bytes we can shed! Running our message through
MessagePack gives us a 63 byte message:
83 a4 6e 61 6d 65 a6 48 61 72 72 69
73 b3 74 6f 74 61 6c 56 69 63 74 6f
72 79 52 6f 79 61 6c 65 73 00 a9 6e
69 63 6b 6e 61 6d 65 73 92 ab 64 75
63 6b 79 70 6f 74 61 74 6f a5 64 75
63 6b 79The first byte 83 is a code that indicates that the following message is an Object with 3 fields, the first 4 bits give us 8 for object and the last 4 bits tell us the number of fields.
Next, we have a4. The first four bits a0 tell us that we have a string that is 4 bytes long (see the pattern yet?). This means the bytes 6e 61 6d 65
represent name in ASCII, the name of our field! In the following byte we see a6, which is a 6 byte string, so 48 61 72 72 69 73 must stand for my name (Harris).
Now, the next byte is b3. The first 4 bytes of this number is still a0, which means we are still looking at a string, and that string is b3 - a0 = 13 bytes
long (thats 19 in decimal). This is the bytes 74 6f 74 61 6c 56 69 63 74 6f 72 79 52 6f 79 61 6c 65 73 which is our field name totalVictoryRoyals. Next we have
00, 0 being a code for positive fixed integer and our value being 0. Just like before, a9 is telling us we have a 9 character string which is the
name of our array, nicknames.
The next byte is 92. 90 tells us we have an array, and 02 tells us that array has two elements. Those two elements are encoded just like before, we have
two strings.
That’s a lot to follow, so lets break it down like this:
| Code | Meaning | Value |
|---|---|---|
| 83 | Object w/ 3 fields | |
| a4 | 4 character string | 6e 61 6d 65 |
| a6 | 6 character string | 48 61 72 72 69 73 |
| b3 | 19 character string | 74 6f 74 61 6c 56 69 63 74 6f 72 79 52 6f 79 61 6c 65 73 |
| 00 | integer whos value are all the lower order bytes | 0 |
| a9 | 9 character string | 6e 69 63 6b 6e 61 6d 65 73 |
| 92 | 2 element array | ab 11 Char String, a5 5 Char String |
Not bad! We can shed a LOT more bytes with things like ProtocolBuffer which can pack our same message into a lot fewer bytes. These protocols do this by not encoding the names of our fields. Instead, we specify ahead of time using a schema definition what our objects are going to look like. For example,
message User {
required string name = 1
required int64 totalVictoryRoyales = 2;
repeated string nicknames = 3;
}Now, when we go to encode totalVictoryRoyals, instead of having to encode all whopping 19 bytes of that field, we simply encode the 2 from our
schema. This is called a Field Tag. Then, the ProtocolBuffer library can look up what that 2 means, and decode the bytes properly. By avoiding the 32 bytes we needed JUST to encode field names, we can pack our message into a lot less bytes. We can also save our byte to indicate that we have encoded an object
because the ProtocolBuffer schema is already encoding that.
It might look something like this
0a 06 48 61 72 72 69 73 10 00 1a B0
64 75 63 6B 79 70 6F 74 61 74 6F 0A
1a 05 64 75 63 6B 79 0Awhich breaks down as
| Code | Meaning | Value |
|---|---|---|
0a |
Field Tag 1, Type String | length: 06: 48 61 72 72 69 73 (Harris) |
10 |
Field Tag 2, Type Int | 00 |
1a |
Field Tag 3 | length: B0: 64 75 63 6B 79 70 6F 74 61 74 6F 0A (duckypotato) |
1a |
Field Tag 3 | length: 05: 64 75 63 6B 79 0A (ducky) |
Note that we also don’t need to encode any information about our last 2 fields being part of an array. Since we tagged them as being in field tag 3,
ProtocolBuffer can figure out it needs to place them inside an array. So, our byte count is down to 32. Not so bad.
Okay, we just spent a LOT of time in the weeds of how we can encode information in binary. I’m a little worn out from writing that, and you’re probably a little confused. Let’s take a massive step back and get some context for why we care.
We want to be able to encode data in such a way that it can still be relevant to something that is not the same OS level process that created that data. This situation can come up as:
We could do this decently enough with the built in serialization that some languages come with, such as Java’s built in serialize that Akka uses. WE can use JSON encodings like MessagePack to compatability with most web services. We can also use ProtocolBuffer to drastically reduce the amount of space messages take up, at the cost of the up front setup needed to write custom schemas and run a compiler to turn those schemas into language specific decoders.
I made heavy use of the examples that Martin Kleppmann uses in Chapter 4 of Designing Data Intensive Applications, with some small modifications made so I had to work through the bytes myself. You should definitely read this book!
]]>From the MDN Docs:
The
Promiseobject represents the eventual completion (or failure) of an asynchronous operation and its resulting value.
This comes up if you want to query an external API: retrieving data over the network is asynchronous. Javascript’s Fetch API
uses Promises to provide the data from requests once it becomes available. Not only that, but the async/await pattern that was introduced in ES2017
makes use of Promises under the hood. Use that syntax to avoid 👹callback hell👹.
A promise is really just any object or function that implements a .then() method. That .then() method needs to accept two arguments: onFulfilled and onRejected.
So, our mental model so far is:
const Promise = {
then: (onFulfilled, onRejected) => {
//
}
}If you’re unfamiliar with Javascript or this syntax, here is a good resource
onFulfilled and onRejected need to behave in specific ways. onFulfilled needs satisfy:
onRejected is the same, except we call it when the Promise is rejected. These functions are provided by whoever is creating the promise. This means we can supply the
success / error behavior the promise should have in the form of callbacks. then() has access to the current state of the promise, which means a promise has to keep some
internal state with transitions. This diagram shows what state machine
this object has to implement. So, then() looks something like:
const Promise = {
then: (onFulfilled, onRejected) => {
if(Promise.is_fulfilled() && Promise.didNotCallOnFulfilled()) {
onFulfilled(Promise.result)
}
}
}We could go down a rabbit hole of expanding this mental model, but here’s a great article walking through what a Promise implementation would look like. We have enough now to see how we could aggregate promises.
Here’s the situation I was in. I was writing a function that was restricted to returning something with a type of Promise<DataType[]>. However, the only way I could
get access to any elements of DataType was a function that returned Promise<DataType>. In code:
async function getDataItem(dataId): Promise<DataType> {
// A working implementation
}
async function getDataArray(dataIds): Promise<DataType[]> {
// how do I convert return values from the above function into what I need?
}Luckily, the Promises API has a function that can perform this aggregation: Promise.all().
Given an iterable of Promises as input, we get back a single promise that will resolve to the array of results. So, we can call our first function to get individual data items from our API,
then package all of those promises into a single promise. The great part is that performance wise this isn’t even that bad: as soon as we call our first function, thats it! It spits back a
promise that will eventually resolve, and each of those requests aren’t blocking each other. We are doing them in parallel! That looks something like this:
async function getDataItem(dataId): Promise<DataType> {
// A working implementation
}
async function getDataArray(dataIds): Promise<DataType[]> {
const promises: Promise<DataType>[] = [];
dataIds.forEach((id) => {
promises.push(getDataItem(id));
});
const aggregatePromise = Promise.all(promises);
return aggregatePromise;
}Pretty neat! The aggregate promise will reject if any of the individual requests reject, and will resolve when every one of the promises have been fulfilled. The promise API
also has some other functions such as .any() returning the first promise that resolves, race() which resolves when any of the provided promises resolve, and
allSettled() which returns a promise that resolves to an array containing the promises result (reject or resolve).
Extra fun fact, Promises aren’t supported on internet explorer! ☠️ RIP ☠️.
const { data, loading } = useGetData();
const userId = data.id;
const { relatedData } = useGetRelatedDataForUser(userId);Often it’s useful to write a custom react hook that interacts with any external data sources. However, in this particular situation I needed to use some data from one API endpoint to fetch data from a second endpoint. The problem comes with the loading variable that indicates if our API request is still in progress. data is going to be undefined as long as we aren’t loading, which means in order to use our second hook we need to wait. Okay, easy enough right?
const { data, loading } = useGetData();
if (!loading){
const userId = data.id;
const { relatedData } = useGetRelatedDataForUser(userId);
}Unfortunately if you try to run this, you might see something like the following in the console:
🚨🚨 THIS BREAKS THE RULES OF HOOKS 🚨🚨 READ THE RULES OF HOOKS 🚨🚨
Having seen this error and other related errors in my console before, I thought I would actually learn why the rules exist, and lucky for me our facebook overlords figured people might wonder why the rules exist. Here are some other amazing resources I used while figuring this out.
The basic problem is this: how do we distinguish calls to the same hook that are controlling a different state value? For example:
const ClickCount = () => {
const [rightCount, setRightCount] = useState(0);
const [leftCount, setLeftCount] = useState(0);
return (
<>
<div>{`Right: ${rightCount} Left: ${leftCount}`}</div>
<Button onClick={()=>{setRightCount(rightCount+1)}} />
<Button onClick={()=>{setLeftCount(leftCount+1)}} />
</>
);
}React needs to keep track of which state values corresponds to which useState call. If I try to access one of leftCount and rightCount, React needs to access the correct state value.
React does this by keeping a linked list of hooks, and relying on the hooks always being called in the same order. In fact, component state itself is kept as a linked list. When hooks are called, we append a state to the linked list of hook states, and then move to the next spot in the linked list. This explains why we can’t have hooks in conditionals: if we allowed hooks in conditionals, we could be at the wrong state node for the state we are calling!
What about the other rule: we can’t have hooks outside react function components. Well this is easy to explain with what we know now. Hooks need to be associated with the state of some component in order to work. If we call them outside of a react component, the react engine won’t be able to make this association since it really isn’t associated with any react component.
Hopefully thats not too hard to follow. I know I had a tough time grappling with all the resources I used.
So, how did I fix my initial problem? I wish I had a nice answer, but it came down to using useEffect with a whole lot of null checks sadly. The solution was not nearly as interesting as my investigation into Hooks.
-N points on your mark and you never really had to deal with the issue. However, now that I’m working I’ve had to experience the fallout of bad code. Nothing as jarring to a new developer like myself as coming in to work the next day and hearing you broke something for 30+ important customers 😓.
The actual issue was pretty small and simple:
function findItem(array, id){
return array.find(item => item.id = id).name || DEFAULT_ITEM;
}
This little snippet prevented a core page in the app from rendering. The array in question contained configuration info for a series of supported integrations, and given the account had an unsupported integration value we would default to DEFAULT_ITEM. The original check was:
function findItem(array, id){
return array.find(item => item.id = id) || DEFAULT_ITEM;
}
For those unfamiliar with Javascript’s Array.find():
The find() method returns the first element in the provided array that satisfies the provided testing function. If no values satisfy the testing function, undefined is returned.
My initial thinking was: if find() returns undefined, it means we didn’t find something to match, we “short circuit” and evaluate the right hand side of the expression, which will return the DEFAULT_ITEM. However, I later realized the component which would call this function would need the .name value of the config object. I added that evaluation in without checking that my logic was still valid: in my head I assumed that my || would still catch any unsupported values. I didn’t stop to asses that my previous logic was still valid, and I didn’t write a test that enforced that logic in code. Lo and behold when find() doesn’t pass the predicate function and we try to access undefined.name the component doesn’t render 💀.
And, it ended up shipping.
Really this is a silly mistake that could have been caught by me writing that unit test, or caught in PR, or with more testing on our Sandbox. Before writing the initial function I should have written a test that might have caught this mistake, but I didn’t! To be fair, the people who reviewed this could have also noticed this, but the issue only came up with unsupported integrations and the accounts I set up for testing all used supported integrations.
My takeaways:
So, a small mistake but I finally learned something that I’ve probably read and heard hundreds of times: WRITE TESTS!
]]>