DEV Community: Amanda Jayathilaka

Add Fast Fuzzy Search to a Directory Site with Fuse.js published: false

Amanda Jayathilaka — Sat, 24 Oct 2026 09:10:25 +0000

Build a typo-tolerant, debounced search box for a listing site using Fuse.js and vanilla JavaScript.

When a directory has hundreds of listings, users want to type "dalas" and still find Dallas. Fuse.js gives you fuzzy matching in a few lines.

I added this to a bank branch directory where people search by city, street, or branch name.

Install

npm install fuse.js

Set up the index

import Fuse from "fuse.js";

const branches = [
  { name: "Chase Bank, Dallas", area: "LBJ and Abrams" },
  { name: "Chase Bank, Chicago", area: "Lawrence and Kedzie" },
  { name: "Chase Bank, Las Vegas", area: "Centennial Crossroads" },
];

const fuse = new Fuse(branches, {
  keys: ["name", "area"],
  threshold: 0.35,
  ignoreLocation: true,
});

Debounce the input

Without it you re-run the search on every keystroke.

function debounce(fn, delay = 200) {
  let timer;
  return (...args) => {
    clearTimeout(timer);
    timer = setTimeout(() => fn(...args), delay);
  };
}

Wire it up

<input id="search" type="search" placeholder="Search by city or street">
<ul id="results"></ul>

const input = document.querySelector("#search");
const list = document.querySelector("#results");

const render = (items) => {
  list.replaceChildren(
    ...items.map(({ item }) => {
      const li = document.createElement("li");
      li.textContent = `${item.name} (${item.area})`;
      return li;
    })
  );
};

input.addEventListener(
  "input",
  debounce((e) => {
    const q = e.target.value.trim();
    render(q ? fuse.search(q).slice(0, 10) : []);
  })
);

textContent keeps user input and data from being interpreted as HTML.

Tuning

Lower threshold means stricter matching, higher means more forgiving.
Weight important keys: { name: "name", weight: 2 }.
For tens of thousands of records, consider a server-side search or a worker thread.

Clean and Validate US Phone Numbers in JavaScript (and Catch Broken Data

Amanda Jayathilaka — Sat, 24 Oct 2026 08:34:43 +0000

Normalize messy phone numbers, flag invalid ones, and generate tel links with plain JavaScript.

Scraped or hand-entered phone data is messy. While building a directory of bank branches, I found numbers that were one digit short. Users would have tapped a tel: link and reached nothing.

Here is a small toolkit to prevent that.

Normalize

function normalizeUS(raw) {
  let digits = String(raw).replace(/\D/g, "");
  if (digits.length === 11 && digits.startsWith("1")) digits = digits.slice(1);
  return digits.length === 10 ? digits : null; // null = invalid
}

normalizeUS("(281) 646-6600");  // "2816466600"
normalizeUS("+1 281-646-6600"); // "2816466600"
normalizeUS("281-646-660");     // null  (only 9 digits)

Format for display and links

function formatUS(digits) {
  return `${digits.slice(0, 3)}-${digits.slice(3, 6)}-${digits.slice(6)}`;
}

function telHref(digits) {
  return `tel:+1${digits}`;
}

Audit a whole dataset

function auditPhones(rows) {
  return rows
    .map((r) => ({ ...r, clean: normalizeUS(r.phone) }))
    .filter((r) => r.clean === null);
}

const broken = auditPhones([
  { name: "Branch A", phone: "281-646-6600" },
  { name: "Branch B", phone: "972-690-860" },
]);
console.log(broken); // [{ name: "Branch B", ... }]

Go further

For international support or strict validation, use libphonenumber-js:

import { parsePhoneNumberFromString } from "libphonenumber-js";

const p = parsePhoneNumberFromString("281-646-6600", "US");
console.log(p?.isValid(), p?.format("E.164"));

Takeaways

Validate at import time, not at render time.
Store the clean digits and format on output.
Log invalid rows so you can fix the source.
A US number is exactly 10 digits after removing the country code.

Programmatic Pages: Generate a Static Directory Site from JSON with Node.js

Amanda Jayathilaka — Sat, 24 Oct 2026 08:15:24 +0000

Turn one JSON file into hundreds of static HTML pages and a sitemap using a small Node.js script.

Directories are a perfect fit for static generation. One data file, one template, hundreds of fast pages. No framework needed.

This is the same idea behind a branch directory I run for Chase Bank locations.

Project layout

data/branches.json
build.js
dist/

The data

[
  { "slug": "dallas", "name": "Chase Bank, Dallas", "area": "LBJ and Abrams", "phone": "972-690-8600" },
  { "slug": "katy", "name": "Chase Bank, Katy", "area": "Fry and Morton", "phone": "281-646-6600" }
]

The build script

import { readFileSync, writeFileSync, mkdirSync } from "node:fs";

const SITE = "https://example.com";
const branches = JSON.parse(readFileSync("data/branches.json", "utf8"));

const esc = (s) =>
  s.replace(/[&<>"']/g, (c) => ({ "&": "&amp;", "<": "&lt;", ">": "&gt;", '"': "&quot;", "'": "&#39;" }[c]));

const page = (b) => `<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>${esc(b.name)} | Phone Number and Location</title>
  <meta name="description" content="Find the location and phone number for ${esc(b.name)}.">
  <link rel="canonical" href="${SITE}/${b.slug}/">
</head>
<body>
  <h1>${esc(b.name)}</h1>
  <p>${esc(b.area)}</p>
  <p><a href="tel:${b.phone.replace(/\D/g, "")}">${esc(b.phone)}</a></p>
</body>
</html>`;

mkdirSync("dist", { recursive: true });

for (const b of branches) {
  mkdirSync(`dist/${b.slug}`, { recursive: true });
  writeFileSync(`dist/${b.slug}/index.html`, page(b));
}

const sitemap = `<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
${branches.map((b) => `  <url><loc>${SITE}/${b.slug}/</loc></url>`).join("\n")}
</urlset>`;

writeFileSync("dist/sitemap.xml", sitemap);
console.log(`Built ${branches.length} pages`);

Run it with node build.js.

Avoid thin content

Programmatic SEO fails when every page says the same thing with the city name swapped. Add something genuinely useful per page: real hours, nearby branches, services, or a map.

Next steps

Add a unique meta description per page.
Add JSON-LD structured data.
Submit the sitemap in Google Search Console.

How to Add LocalBusiness JSON-LD Schema to a Directory Website

Amanda Jayathilaka — Sat, 24 Oct 2026 07:32:00 +0000

Add structured data to your directory pages so search engines understand each location's name, address, and phone number.

If you run a directory site, structured data helps search engines understand what each page is about. Done right, it can make your listings eligible for richer search results.

I applied this to a Chase Bank branches directory, where every page represents one physical location.

Pick the right type

Schema.org has BankOrCreditUnion, which fits a bank branch. For other businesses use LocalBusiness or a more specific subtype.

Example JSON-LD

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BankOrCreditUnion",
  "name": "Chase Bank, Dallas",
  "telephone": "+1-972-690-8600",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "LBJ Freeway and Abrams Road",
    "addressLocality": "Dallas",
    "addressRegion": "TX",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 32.9,
    "longitude": -96.77
  }
}
</script>

The values above are examples. Use your own verified data.

Generate it from your data

Do not hand-write this for every page.

function buildSchema(branch) {
  return {
    "@context": "https://schema.org",
    "@type": "BankOrCreditUnion",
    name: branch.name,
    telephone: branch.phone,
    address: {
      "@type": "PostalAddress",
      streetAddress: branch.street,
      addressLocality: branch.city,
      addressRegion: branch.state,
      addressCountry: "US",
    },
  };
}

const tag = `<script type="application/ld+json">${JSON.stringify(buildSchema(branch))}</script>`;

Validate it

Test every template with Google's Rich Results Test and the Schema Markup Validator before you publish thousands of pages.

Common mistakes

Marking up data that is not visible on the page.
Using an incomplete phone number. Use the international format.
Duplicating the same schema block across different pages.
Forgetting to escape quotes in names and addresses.

Structured data will not magically rank a page, but it removes ambiguity, and that is worth the 20 minutes.

Build a "Nearest Branch" Finder in Vanilla JS with the Haversine Formula

Amanda Jayathilaka — Sat, 24 Oct 2026 07:20:11 +0000

Sort bank branches by distance from the user's location using the Geolocation API and the Haversine formula, with no libraries.

Every location directory eventually needs a "find the nearest one" feature. You do not need Google Maps or a heavy library for it. The Geolocation API and one small formula are enough.

I used this approach on a Chase Bank branch directory I maintain, where each branch has coordinates and users want the closest one first.

The data

const branches = [
  { name: "Chase Bank, Dallas", lat: 32.9, lng: -96.77 },
  { name: "Chase Bank, Katy", lat: 29.79, lng: -95.82 },
  { name: "Chase Bank, Chicago", lat: 41.97, lng: -87.72 },
];

The Haversine formula

It calculates the distance between two points on a sphere.

const EARTH_RADIUS_MILES = 3958.8;
const toRad = (deg) => (deg * Math.PI) / 180;

function distanceMiles(a, b) {
  const dLat = toRad(b.lat - a.lat);
  const dLng = toRad(b.lng - a.lng);
  const h =
    Math.sin(dLat / 2) ** 2 +
    Math.cos(toRad(a.lat)) * Math.cos(toRad(b.lat)) * Math.sin(dLng / 2) ** 2;
  return 2 * EARTH_RADIUS_MILES * Math.asin(Math.sqrt(h));
}

Sort by distance

function sortByDistance(userPos, items) {
  return items
    .map((item) => ({ ...item, distance: distanceMiles(userPos, item) }))
    .sort((a, b) => a.distance - b.distance);
}

Get the user's location

navigator.geolocation.getCurrentPosition(
  (pos) => {
    const user = { lat: pos.coords.latitude, lng: pos.coords.longitude };
    const nearest = sortByDistance(user, branches).slice(0, 5);
    console.table(nearest);
  },
  (err) => console.warn("Location denied:", err.message),
  { enableHighAccuracy: false, timeout: 8000 }
);

Tips

Always handle the denied-permission case and fall back to a city search.
Geolocation only works on HTTPS.
Haversine is accurate enough for straight-line distance. For driving distance you need a routing API.
With thousands of points, filter by a bounding box first, then run Haversine on the survivors.

That is all it takes. Happy building!

Testing, Observability, and Scaling

Amanda Jayathilaka — Sat, 24 Oct 2026 04:08:40 +0000

API tests should cover valid AVIF files. Include corrupted files and unsupported formats. Test large dimensions and transparency. Verify the output MIME type. Check that generated JPG files decode successfully.

Track latency, failures, and output sizes. Monitor CPU and memory utilization. Use structured logs for operational analysis. Avoid collecting unnecessary personal information. Performance dashboards help identify processing bottlenecks.

When demand increases, consider worker queues. Separate conversion workloads from web request handling. Apply concurrency limits to background workers. Store outputs in suitable object storage. Use temporary links with expiration when appropriate.

A production-grade AVIF to JPG API requires careful engineering. Secure validation protects the service. Resource controls support operational stability. Consistent responses simplify client integration. Monitoring helps maintain reliable performance as workloads grow.

Protecting Resources and Uploaded Data

Amanda Jayathilaka — Sat, 24 Oct 2026 02:36:56 +0000

Image processing can consume substantial resources. Apply request size limits and pixel limits. Set suitable timeouts for uploads and conversion. Limit simultaneous jobs using bounded concurrency. Monitor memory usage during peak traffic.

Store temporary files outside public directories. Generate server-controlled filenames. Restrict filesystem permissions appropriately. Remove temporary files after completion. Validate downloaded files before exposing results.

Privacy policies should explain retention periods. Use encrypted transport for API requests. Protect stored files with appropriate access controls. Avoid public links for sensitive images. Rate limiting can reduce abusive request patterns. Authentication may be necessary for private services.

Dependencies require regular maintenance. Review security advisories for image-processing libraries. Keep production environments patched. Test updates against a representative image collection.

Best AVIF to JPG converter

Designing API Responses and Errors

Amanda Jayathilaka — Sat, 24 Oct 2026 02:00:08 +0000

Consistent responses make integrations easier. Return JPG bytes for successful conversions. Use an appropriate content type. Set attachment headers when downloads are intended. Document whether metadata is preserved.

Invalid requests should receive clear status codes. Unsupported formats can return HTTP 415. Missing files can return HTTP 400. Oversized requests can return HTTP 413. Unexpected server failures should return HTTP 500. Avoid returning stack traces to clients.

Error messages should explain corrective actions. Logs can contain additional diagnostic information. Never log uploaded image contents unnecessarily. Avoid including sensitive filenames in public responses. Request identifiers help connect errors with server logs.

For asynchronous processing, return a job identifier. Clients can poll a documented status endpoint. Completed jobs can provide temporary download links. Expiration policies should be explicit.

This is a example AVIF to JPG converter for beginners.

Converting Images with the HTML Canvas API

Amanda Jayathilaka — Fri, 23 Oct 2026 15:16:18 +0000

The Canvas API provides a straightforward browser-based solution. Developers can load images into an HTML image element. The browser then draws images onto a canvas. The canvas can export supported image formats. JPG output is available through toBlob().

async function convertAvifToJpg(file, quality = 0.9) {
const imageUrl = URL.createObjectURL(file);

try {
const image = new Image();

image.src = imageUrl;

await image.decode();

const canvas = document.createElement("canvas");

canvas.width = image.naturalWidth;
canvas.height = image.naturalHeight;

const context = canvas.getContext("2d");

if (!context) {
  throw new Error("Canvas is unavailable.");
}

context.drawImage(image, 0, 0);

const blob = await new Promise((resolve, reject) => {
  canvas.toBlob(
    (result) => {
      if (result) resolve(result);
      else reject(new Error("JPG encoding failed."));
    },
    "image/jpeg",
    quality
  );
});

return blob;

} finally {
URL.revokeObjectURL(imageUrl);
}
}

This example assumes browser support for AVIF decoding. The quality argument typically ranges between zero and one. A value near 0.9 often provides useful quality. Actual output depends on browser encoding implementations. Canvas output also depends on available memory. Production applications should enforce reasonable image dimensions.

We can create AVIF to JPG converter using that.

Why JavaScript Developers Need Image Conversion

Amanda Jayathilaka — Fri, 23 Oct 2026 14:05:09 +0000

Modern web applications handle many image formats. AVIF provides efficient compression and excellent visual quality. However, some applications require JPG output. This often happens during uploads or image processing. Converting images helps maintain compatibility across different systems. JavaScript provides several ways to perform this conversion. Developers can use browser APIs or server-side libraries. The best approach depends on application requirements.

AVIF to JPG conversion involves decoding and re-encoding image data. The decoder reads the original AVIF image. The encoder creates a new JPG representation. During this process, image dimensions can remain unchanged. Developers can also resize images when necessary. Output quality depends on the encoding configuration. JPG compression may introduce visible artifacts. Therefore, conversion settings deserve careful consideration.

Frontend applications can perform conversions before uploading files. This reduces unnecessary server-side processing. However, browser support must be considered. Some environments lack suitable AVIF decoding capabilities. Backend conversion provides greater control over processing. It also supports consistent output across client devices.

A reliable implementation should validate file types. It should handle decoding errors gracefully. Developers should also manage memory consumption. Large images can require substantial processing resources. Clear error messages improve the user experience. These considerations make image conversion more dependable.