DEV Community: Ahmed Sayed

From Issue to Merge: Propagating HTTP Status Through OpenSeadragon

Ahmed Sayed — Fri, 25 Sep 2026 12:26:33 +0000

Working on a personal project is one thing.

Contributing to an established open-source codebase is different. You have to understand existing behavior, preserve established contracts, write tests that fit the project, and respond to review from people who maintain the codebase.

Recently, I contributed to OpenSeadragon, an open-source JavaScript viewer for high-resolution and zoomable images.

The contribution started with a relatively small problem:

When a TileSource failed to open, the HTTP status code was not available to consumers of the open-failed event.

That information can be useful when an application needs to distinguish between different kinds of failures, such as authentication or authorization errors.

🔎 Tracing the Problem

The first step was not changing code.

I needed to understand where the information was being lost.

The failure originated from an XHR request where the HTTP status was already available through xhr.status.

However, the TileSource failure event did not expose that status, and when the failure propagated to the Viewer, the information was still missing.

So the change needed to follow the existing event flow rather than introduce a separate error mechanism:

XHR failure
   ↓
TileSource "open-failed"
   ↓
Viewer "open-failed"

The goal was simple:

xhr.status
   ↓
event.status

🛠️ Making the Smallest Useful Change

The implementation added an optional status field to the TileSource open-failed event and propagated it through the Viewer event.

The TypeScript definitions were updated as well, so the public API and its type declarations remained aligned.

The change also covered specialized TileSources such as IIP and Iris, where failures needed to propagate the same information.

This was deliberately kept focused. Instead of redesigning OpenSeadragon's networking layer, the contribution extended the existing failure path with the information the caller needed.

🧪 Testing the Behavior

A regression test was added for a failed resource returning HTTP 404.

The test verifies that:

event.status === 404

It also keeps the existing failure behavior intact by checking that the failure message is still displayed and logged.

After the implementation and review changes, the basic module tests passed, followed by the full test suite with 390 tests passing. TypeScript definition checks also passed.

👀 Working Through Code Review

The interesting part of an open-source contribution does not end when the code works.

The maintainer review raised an important implementation detail around accessing xhr.status inside the existing error handling path.

There was also a broader discussion about error propagation across different TileSource implementations and whether the project should eventually move away from passing around the old XHR object.

That larger architectural discussion was intentionally kept outside the scope of this PR.

I addressed the requested changes, propagated the status through the additional TileSource implementations, updated the API documentation, and reran the tests.

The changes were approved, and PR #2972 was merged into OpenSeadragon's master branch on September 14, 2026.

📌 What I Took Away

This contribution reinforced something I had already started learning from browser engineering:

Good open-source work is often less about writing a lot of code and more about understanding the code that is already there.

The valuable part of this contribution was not adding a large feature.

It was:

tracing an existing execution path,
identifying where useful information was being dropped,
making a small API-level change,
keeping related implementations consistent,
adding a regression test,
responding to maintainer feedback,
and validating the result before merge.

That process is what I wanted to experience by contributing to a real-world codebase.

🔗 Issue: OpenSeadragon #2541

🔗 Pull Request: OpenSeadragon #2972

OpenSource #JavaScript #SoftwareEngineering #WebDevelopment #GitHub #OpenSeadragon #FrontendEngineering

Beyond a Country Explorer: Accessibility & Architecture in React

Ahmed Sayed — Fri, 25 Sep 2026 12:20:18 +0000

A country explorer can look like a simple React project: fetch some data, render a list of countries, and add a search field.

But building a frontend that remains accessible, predictable, and maintainable requires thinking beyond the visual interface.

Here is how I structured my Rest Countries application with a focus on component boundaries, user interaction, and accessibility.

⚡ The Architecture Highlights:

Feature-Oriented Structure: Country-related functionality is organized around the feature itself, separating the data layer, application logic, and UI components instead of grouping everything by file type.
Custom State Logic: Country filtering and selection are handled through a dedicated useCountries hook, keeping stateful behavior separate from presentation.
Keyboard-Accessible Region Selection: The custom region selector supports keyboard interaction including ArrowUp, ArrowDown, Home, End, and Escape, providing an interaction model closer to a native control.
Focus Management: Focus is deliberately managed when navigating between the country list and country details. When returning from a country detail view, focus can be restored to the element that originally triggered the navigation.
Semantic Interaction: Interactive elements use appropriate HTML semantics and accessible labels rather than relying only on visual styling to communicate their purpose.
Controlled UI Boundaries: The country grid, controls, and country detail view have separate responsibilities, making the interface easier to reason about and modify.
Intentional Interaction Design: Country information remains selectable and usable as text, while the country flag acts as the primary interactive target for opening details. This avoids turning an entire information card into an unnecessarily large interactive control.

📊 The Result:

A React country explorer designed not only to display data, but to provide a more predictable experience for keyboard users while maintaining clear boundaries between state, UI, and interaction logic.

The project is built with accessibility as part of the architecture rather than as a final visual polish step.

🔗 Live Demo: https://ahmed-rest-countries.vercel.app/

💻 GitHub Repo: https://github.com/a-sayed123/Rest_Countries_API

React #Accessibility #FrontendArchitecture #WebDevelopment #CleanCode #A11y

Beyond a Basic Weather App: Architecture & Resilience in Vanilla JavaScript

Ahmed Sayed — Mon, 14 Sep 2026 20:37:24 +0000

A weather app is often seen as a simple tutorial project, but turning it into a resilient, maintainable frontend application requires solving real-world challenges beyond simply displaying weather data.

Here is how I architected my Weather Application with a focus on reliability, separation of concerns, and controlled data flow.

⚡ The Architecture Highlights:

Modular Application Structure: The application is divided into focused modules for application control, UI management, API communication, validation, and weather-related logic instead of placing everything inside a single script.
Decoupled API Layer: External API communication is isolated from the UI and application logic, making the data layer easier to reason about and maintain.
Debounced City Search: Search input is debounced to avoid unnecessary geocoding requests while the user is typing.
In-Memory Data Handling: Frequently used location data can be reused without repeatedly requesting the same information, helping reduce unnecessary network traffic.
Explicit UI States: Loading, successful responses, validation failures, and API errors are handled as explicit application states rather than being left to accidental UI behavior.
Large Dataset Optimization: Instead of shipping an unnecessarily large city dataset, I filtered the original dataset of roughly 50,000 cities down to 11,399 cities with a population above 50,000, resulting in a dataset of about 766 KB.
Separation of Responsibilities: Application control, UI rendering, API communication, and domain logic are kept separate so that changes in one part of the application do not unnecessarily affect the others.

📊 The Result:

A modular Vanilla JavaScript weather application with clearer boundaries between responsibilities, controlled network usage, predictable UI behavior, and an architecture that can evolve without turning the application into a single tightly coupled codebase.

🔗 Live Demo: https://weather-app-v2nd.vercel.app/

💻 GitHub Repo: https://github.com/a-sayed123/weather-app

JavaScript #FrontendArchitecture #CleanCode #WebDevelopment #SoftwareEngineering