DEV Community: Uzair Shamim

Memory Bank: Labels In HTML

Uzair Shamim — Sun, 12 Oct 2025 01:32:49 +0000

What is the right way to label something in HTML?

This came up in something I was working on recently. I always forget the best practices for labeling so I wanted to write this blog post to help me remember... and as a quick reference when I inevitably forget 😉.

Default Accessible Names

Some elements provide a default accessible name that can be used by screen readers to provide a label for a given element. For example in a button the value between the open and close tags is the default accessible name.

<button>this is a close button</button>

Sometimes the default accessible name is inaccurate and a separate label needs to be provided to give users accurate context. In these situations labels can help.

Imagine if the in the code above needed to have X as its text. This is not very informative to screen reader users and we need a better way to indicate what this button does. There are also many elements that do not have default accessible names, so we may need to provide labels for them as well.

Full post here: https://pureooze.com/blog/posts/2025-10-07-memory-bank-labels-in-html/

Navigating Technical Debt

Uzair Shamim — Sat, 04 May 2024 02:06:34 +0000

We don't spend enough time doing maintenance! We have too much legacy code! We only build new features and never cleanup the old things we made! We have too much technical debt!
Sound familiar? If you have been involved in any meaningful software development project – especially one that is large – you will have heard complaints like this.
It's a topic that many software developers (including yours truly) are passionate about.

I would be willing to bet that if you surveyed random developers at a conference, you would find that the majority of them consider technical debt to be a significant problem in their organization.
I would also be willing to bet that they could not agree on what the problem is and how to address it.
The issue is further complicated by the fact that many businesses seem to not care about tech debt.

In this post I want to explore the idea of technical debt. What is it? Can we measure it? What can we do about it?

What Is Technical Debt?

The term is used to describe things from "we don't use the shiny new framework" to "this code is not written in the style I like" and even "I inherited the code from someone else".
Let's start by looking at Ward Cunningham's original definition:

Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring.
The danger occurs when the debt is not repaid.
Every minute spent on code that is not quite right for the programming task of the moment counts as interest on that debt.
Entire engineering organizations can be brought to a stand-still under the debt load of an unfactored implementation, object-oriented or otherwise.

- Ward Cunningham

This definition focuses on technical debt being a trade-off when developing new features and that it is not always bad as long as its addressed promptly.
The problem though is that unlike financial debt, who is responsible for making sure an organization can handle more technical debt?
Can an organization be "technical debt" bankrupt?
When organizations start thinking of this in terms of "debt" they quickly realize that there don't seem to be any consequences of the debt, so they ignore it.

Steve Freeman (whose work I first encountered in the wonderful book Growing Object-Oriented Software, Guided by Tests) describes technical debt as an "Unhedged Call Option".

This definition highlights the unpredictability of cost.
Unlike debt – where we know what the interest rate will be – options could be infinitely more costly than doing the work in the first place.
I like this definition because it brings forth this idea that the cost can become due suddenly and without warning, and we need to understand where to focus our efforts because the "debt" is a disaster waiting to happen.

Lensing To Understand Technical Debt

Michael Feathers has a great post – Lensing to Understand – about how we change our focus to understand a system.
We focus on the high level system to identify potentially interesting areas and then drill down into details to investigate them.
Once we have a better understanding, we zoom back out to see how it affects the system as a whole.
The idea of "lensing" is really important when it comes to understanding technical debt.

In previous attempts of tacking technical debt, I have made the mistake of starting with a focus on very specific parts of a system.
Starting with a systems view and then drilling down into the details may be a better way to understand the system.
Where do people encounter the most issues?
Are some parts of the system riskier than others?
What parts of the system are most likely to change in the future?

These are the kinds of questions we need to be asking.
Too often we focus on bits of code and forget the context of the systems it's used in – which is extremely important.

So how do we identify risks in our codebase?
Adam Tornhill has a great talk on "Prioritizing Technical Debt" where he talks about how we can use metrics to identify risks in our codebase.
If we have a way to find out where to focus our efforts we can get a lot more value out of the work we do – allowing us to ship quicker and build high quality features.
I really liked this talk and I recommend watching it.

Adam has a few metrics that he uses to identify risks:

File Hotspots: Files that are changed frequently
Method Hotspots: Methods in hotspot files that are changed frequently
Complexity: Files that are hard for humans to understand

If we find places that meet all three of these criteria we have a high risk area that we should focus on.

Read the full version of this post on my blog: https://pureooze.com/blog/posts/2024-03-29-navigating-technical-debt/

A Simple List Render Optimization For React 🏎

Uzair Shamim — Sat, 22 Sep 2018 14:13:03 +0000

Cover photo by George Brynzan on Unsplash

Yesterday I was watching a talk by Ben Ilegbodu at React Alicante called Help! My React App is Slowwwww! in which Ben discussed some optimizations developers can make to help improve performance of React applications. He goes over many of the potential bottlenecks that may arise such as unnecessary DOM updates, reconciliation and unnecessary object creation. It’s a really interesting talk and I encourage you to watch it (link below) but what I found most interesting was his first point about unnecessary DOM updates.

When trying to optimize performance we look for actions that are slower than the majority of other actions and try to minimize the amount of times we perform these actions. It turns out updating the DOM is a very time consuming operation. It is in fact so time consuming that React has a process called reconciliation that exists to try and avoid unnecessary updates.

Unfortunately as Ben shows in his talk — and as I will show in this post — there are still situations where reconciliation will not be able to help us. However we don’t need to lose hope because there are some simple tweaks we can make to address the issue.

The 🔑 to Lists

This is a really handy trick you can use to optimize the rendering of list items in React. Suppose you have a page that displays a list of items and is defined as follows (click the button to see the code on codesandbox):

When the button is clicked, it will add an item to the list. This will then trigger an update to the DOM to display our new item along with all the old items. If we look at the DOM inspector while clicking the button we see the following (orange indicates the node is updating):

See how all the list items are updated? If we think about this for a moment this doesn’t actually seem like an ideal update. Why can’t we just insert the new node without having to update all the other nodes? The reason for this has to do with how we are using the map function in the List component.

See how we are setting the key for each list item as the index? The problem here is that React uses the key to determine if the item has actually changed. Unfortunately since the insertion we are doing happens at the start of the list, the indexes of all items in the list are increased by one. This causes React to think there has been a change to all the nodes and so it updates them all.

To work around this we need to modify the map function to use the unique id of each item instead of the index in the array:

And now when we click the button we see that the new nodes are being added without updating the old ones:

So what’s the lesson?

Always use a unique key when creating lists in React (and the index is not considered unique)!

🚨 Now there is one thing to address and that is the situation where you do not have a truly unique id in your arrays. The ideal solution is to find some unique key which may be derived by combining some values in the object together. However in certain cases — like an array of strings — this cannot be possible or guaranteed, then you must rely on the index to be the key. 🚨

So there you have it, a simple trick to optimize list rendering in React! 🎉

If you liked this post be sure to follow this blog and follow me on twitter.

P.S.: Looking to contribute to an open source project? Come contribute to Saka, we could use the help! You can find the project here: https://github.com/lusakasa/saka

Integration Testing Browser Extensions with Jest

Uzair Shamim — Sat, 18 Aug 2018 02:44:53 +0000

Previously I wrote about how I became the maintainer of Saka, an open source browser extension that allows users to search through and load open tabs, browsing history and bookmarks. I talked about how I came up with a solution for unit testing the extension to give me confidence with code changes. I also mentioned that there were issues with integration testing that I ran into which made it difficult to test components that relied on browser APIs.

Today I am happy to report that I have found a way to perform integration testing on extensions and want to share it with you in this post. But before we go down that particular rabbit hole lets first discuss integration testing and why it is useful for validating software.

The Testing Trophy

Kent C. Dodds has written about something he calls the 'Testing Trophy'. If you have heard of the testing pyramid before this is a similar concept - it's a visualization of how you should prioritize the different types of testing in applications. The title of Kent's post says it all:

Write tests. Not too many. Mostly integration.

Why does he say this? Kent notes the problem with unit tests is that they only prove individual units work as expected- they do not prove that the units can work together as a whole. Integration testing on the other hand proves that all the components in our project can actually work together as expected.

The Need For Integration Testing

Let's leave the world of software and look at a real world example. Suppose we wanted to build a sink for a bathroom. There are 4components to this sink: the faucet, the basin, the drainage system and the water line. Since the drain and water line come with the building we only need to worry about adding the faucet and the basin.
We go to the store and pick a faucet and basin that we like. We bring them on site and assemble each individually. We confirm that the faucet and basin each work as expected and that they have no defects. Finally we assemble the full sink - hooking up the faucet to the water line and the basin to the drainage. After all our labor we are excited to see our sink in action so we turn on the faucet and what happens? Well…

Oops! While we did check to see that the faucet and basin work on their own we forgot to check if the two were actually compatible. This is why integration testing is valuable — it proves that different components, modules and libraries work together as expected.

Kent C. Dodds — Write tests. Not too many. Mostly integration.

Ulrika Malmgren — X Unit Tests, 0 Integration Tests

Solution

Since writing my last post I have managed to get Jest working with Preact, the framework used to create Saka. Jest is a modern testing framework that can run in Node or JSDOM. I will also be using the dom-testing-library to perform the rendering and assertions on my components.

Just keep in mind that while my specific solutions will be tailored for Preact, they will still work for other frameworks — especially React — with slight modifications for framework specific libraries.

There is an example Preact extension with Jest setup for reference here: https://github.com/pureooze/extension-testing-example

Installation

You don’t need to install the preact packages if you use a different framework

First you need to install the required dependencies:

yarn add --dev babel-jest babel-plugin-transform-class-properties babel-plugin-transform-react-jsx babel-preset-env babel-preset-react jest sinon-chrome

If you are using Preact you need to also run the following:

yarn add --dev preact-compat preact-render-to-string preact-test-utils preact-testing-library

Note that just like in the previous post we will be using sinon-chrome to mock all browser APIs.

Configuring Jest

For Preact only, not required for React.

With Jest installed you now need to create a config to tell jest how to deal with parsing Preact. If you use another framework like React you don’t need to do this. Create a jest.config.js file in the root directory of your project with the following contents:

Notice the transform property is telling Jest to apply a custom transformer on all JSX files. To make it work we also need to create a jest.transform.js file:

Create The Commands

Add the following npm scripts to your package.json so that jest can be run from the command line:

Create The First Test

Jest is smart enough to scan your project and run any files it finds with the .test.js extension. Create a new file called Main.test.js in the tests directory of your project with the following contents where the import Main is the component you want to test:

Once the file is created, open a terminal in the root of your project and run the command:

yarn test:watch

You should see jest output something similar to this (assuming the test you created passed):

Congrats! Jest has successfully run and created a snapshot for the test. Jest has created a snapshots directory where all the snapshots are stored. If you open one of them you will see something like this:

The next time the test runs, Jest will compare the existing snapshot to the snapshot it takes at runtime and notify you if a difference is detected.

Conclusion

Integration testing is valuable when we want to assert the compatibility of the components we create. As Kent C. Dodds writes:

Write tests. Not too many. Mostly integration.

You can use Jest to achieve this for modern Javascript projects and browser extensions are no different. With the help of sinon-chrome you can mock out any extension APIs that are used by your components.

If you liked this post be sure to follow this blog and follow me on twitter.

P.S.: Looking to contribute to an open source project? Come contribute to Saka, we could use the help! You can find the project here: https://github.com/lusakasa/saka

Unit Testing Browser Extensions

Uzair Shamim — Fri, 25 May 2018 05:19:29 +0000

In April I became the maintainer of Saka, a browser extension that allows users to search through their tabs, bookmarks and history. The original goal of Saka was to provide an elegant tab search but this soon evolved to include recently closed tabs, bookmarks and history when the original maintainer eejdoowad recognized that users search for tabs the same way they search bookmarks and history. This was an important insight and it has helped make Saka a valuable productivity tool.

When I became the maintainer I was surprised at the absence of tests in the project. There were several components with complicated logic but no tests to be found anywhere. One of the most important things I have learned as a developer is that tests are the easiest ways to write reliable, easy to refactor code. Was the old maintainer just lazy? Did he simply not care about the quality of his code? No. The opposite in fact, he cared a lot.

The issue is that the lack of documentation on the topic means that almost no one is able to test their extension. Having no confidence in my ability to make changes without breaking the code, this was a big problem. But as fate would have it after trying a dozen different approaches I ended up finding a solution.

Why We Test

As developers we want to be sure that the code we write today is not going to become a burden to maintain later in the lifetime of the application. One way we avoid creating these burdens is by writing tests. The great thing about tests is that outside of just verifying the behavior of functions, tests allow us to provide documentation for future developers. For example by creating unit tests we declare the valid inputs and outputs for a given function. This makes it easier to refactor code because we can have confidence that our code is working correctly when all our tests pass.

The Testing Approach

This post will focus on setting up the environment and writing some basic unit tests. I do not have a solution to perform Integration Testing on browser extensions as there are issues with attempting to access WebExtension APIs from a webpage when running in Chrome.

Solution

In my search for a solution to testing Saka, I went through several different testing libraries like Jest, Mocha and Jasmine. One of the biggest challenges for me was that Saka is written using Preact, which causes compatibility issues with other libraries. But after following several examples online, I was finally able to put together a solution using Karma and Jasmine.

Prerequisites

In order to use this solution, your project should use Webpack. The example uses version 4 but this may still work with older versions. While I have not tried, it should be possible to make this work with Gulp after some configuration to make sure everything is bundled properly. You can find a sample webpack config here.

Karma + Jasmine

If you are not already familiar with it, Karma is a tool that allows executing JavaScript code in a browser for testing purposes. While it can execute code, it is not capable of testing the code and instead relies on third party libraries like Jasmine and Mocha. When developing Saka I chose Jasmine because I had previous experience using it in other projects.

The first step to getting Karma and Jasmine setup is to install them:

yarn add jasmine karma karma-chrome-launcher karma-jasmine karma-spec-reporter karma-webpack babel-loader --dev

Before Karma can start running tests it needs to know what configuration parameters to use. In order to provide these, create a karma.conf.js file in the root of the project. I have provided a sample config here. Note that Karma is capable of running Jasmine on its own, it just needs to be told to use it via the frameworks configuration property.

Chrome

Those of you who actually read the karma config may notice that it specifies Chrome as a requirement:

browsers: ["ChromeHeadless"]

As I mentioned earlier, Karma requires an actual browser to run the JavaScript code. This line tells Karma that it should look for Chrome on the system it is running on and launch it in headless mode. The benefits of using headless mode are that you can use the system when the tests are running, instead of being interrupted every 2 seconds when a new test starts to run. Seemed like an obvious win to me.

Adding A Test

To start adding tests, create a JavaScript module using the code in this example under the src directory of your project. As the name suggests the sum function will simply add up all values passed to it and return the sum.

Create a test directory in the root of your project - this is where all the tests will live. Take a look at the karma config file and note this line. It tells karma that to load the tests it must use the test/index.test.js file as the entry point. In the index.test.js file add the following code to import all files inside the test directory ending in .test.js.

With the config out of the way, add a new file simpleModule.test.js in the test directory like this. This file will house the tests for all the functions in the simpleModule.js file. The describe blocks are used to categorize the tests in the Jasmine logs so that it is easier to tell which modules have failures. Individual tests are located within the it() function which needs a description as the first argument and the test function as the second argument. To learn more about how to write tests using Jasmine you can consult the documentation.

Running Tests

In order to run tests the karma executable can be called directly with the path to the config file passed in as an argument. While this works, a more elegant solution is to add the command to the npm scripts in the package.json file like this. You should now be able to just run yarn test and see the output from Karma like below.

Testing With WebExtension APIs

The problem that developers run into when attempting to test extensions is having to deal with the WebExtension APIs in tests. The problem is that the environment the tests run in - that is as a webpage in chrome - does not have access to the APIs. This becomes an issue as Jasmine will throw an error because anything with browser.* will be undefined.

To overcome this issue you need to install sinon-chrome, a library which enables mocking out these APIs.

yarn add sinon-chrome --dev

Create a new module in the src directory called popup.js with the following code. Notice how the getUrl function relies on the browser.runtime.getURL API. We are going to use sinon-chrome to mock the response the browser would return.

Create a new file called popup.test.js in the test directory to store all the tests for the popup.js file you just created. Add the following code to the test file and notice how the browser API is mocked by sinon-chrome. For every test that uses the WebExtension APIs, you must specify what each API should return when Jasmine encounters it, allowing you to bypass the issue with the APIs not being defined.

Run yarn test and you should see the following results from the tests:

And there you are, free to test your chrome extension without having to fear the extension APIs.

Future Work

While this setup with Karma, Jasmine and Chrome works, it is not an ideal solution. There are some benefits in using Jest, a modern testing library that runs entirely in Node thus eliminating the need for a test runner and browser. Unfortunately, Jest has some compatibility issues with Preact so for the time being I have put it on the back burner. Hopefully I can find some time to migrate the tests to use Jest because I think it will make for a good blog post.

You can download Saka for Chrome here and for Firefox here