My philosophy when designing APIs and libraries is to make it as easy to use as possible, but as difficult to use INCORRECTLY as possible. When I used to make plugins with jQuery, there would often be guards on functions to ensure that the data passed in met the function's expectations:
I recently published a utility Human Agent Review Tool that helps keep track of the code I've actually reviewed while working with coding agents.
In the previous article, we discussed the geometric series as an example of an infinite series that
What happens to SEO when the crawler itself becomes one of your primary consumers?
When we last looked at the On the Addition of Fractions, I covered a proof that the harmonic series
Accessibility problems usually have recognizable solutions. A button needs an accessible name, text needs sufficient contrast, and a modal needs sensible focus management.
When writing React code, we often need to pull data from an API and manipulate that data to better match how we want to present it. Now that React hooks are ubiquitous, I have seen a lot of that data manipulation move into hooks that get re-used in multiple components.
We all end up doing it: // TODO implement this function, or // TODO handle this edge case. Often as we write code, we use TODOs to track ephemeral work, and typically clean them up as we go along. But sometimes we keep that TODO around, and it ends up in main. Then what?
In a previous article, I discussed Surfaces as an abstraction on APIs and how we could measure complexity as the size of that surfaces' perimeter – the "visible" part of the API to consumers. I shared this article with a colleague who I was actively working closely with on a new implementation of a design system. They has some interesting feedback on different ways of reducing complexity of certain APIs that I felt compelled to revisit this topic.
I've discussed full and partial objects before on this blog, and in this article I'm going to investigate a common factory pattern in Typescript that can lead to type-holes. When writing tests or complex components, I'll often create prop factory utilities.