Albex

01Overview

Albex is a full-text document search engine shipped as a 33 KB WebAssembly binary. It runs entirely in the browser: streaming parsers turn eleven file formats into an index, a four-stage pipeline answers queries in under 5 ms, and nothing the user drops ever leaves the machine — no upload, no telemetry, no network call after the initial .wasm fetch.

Albex exposes one primary class — AlbexEngine — that wraps the WebAssembly module and orchestrates indexing, search, persistence, and the adaptive runtime. Additional opt-in helpers (AlbexEngineWorker, AlbexPool, TieredStore, BloomGpu) are exported from subpath entry points so consumers only pay for what they use.

Install, import, use. The WASM binary travels with the npm package and your bundler (Vite, Webpack 5+, Next, esbuild, Rollup, Parcel 2, Bun, Deno) resolves it automatically through import.meta.url. No assets to copy. No paths to remember.

How it works — three steps, no server

Features

The OCR companion

@albex/ocr wraps Tesseract.js as an opt-in companion. Scanned PDFs and images become searchable. The core stays 33 KB — Tesseract loads only the first time you call enableOcr(engine), then cached forever in IndexedDB. Six languages auto-loaded by demand. Still 100 % local, zero backend.

What's new in v0.3.0 (2026-05-30)

02Install

No backend required. No data leaves the browser. One package, one command:

npm install albex
# or
pnpm add albex
# or
deno add npm:albex

To add the optional OCR companion for scanned PDFs and images:

npm i albex @albex/ocr

npm entry points

Albex ships multiple subpath exports so each feature can be tree-shaken independently. Import only what you use.

03Quick start

Up in under a minute:

import { AlbexEngine } from "albex";
const engine = await AlbexEngine.create();
for (const file of input.files) {
  await engine.indexFile(file);
}
const hits = engine.search('"clausula novena" | rescisión');
for (const h of hits) {
  console.log(h.documentName, h.location, h.score, h.snippet);
}

Or the explicit constructor form, with options:

import { AlbexEngine } from "albex";

const engine = new AlbexEngine();
await engine.init();

await engine.indexFile(myFile);
const results = engine.search('contrato', { windowed: true });

04Query syntax

One small query language, five patterns:

05Supported formats

What goes in — eleven formats, each with a parser tuned to how the format behaves in the wild:

06API reference

Constructor

import { AlbexEngine } from "albex";

// Zero config — the WASM binary ships with the package and your bundler
// (Vite, Webpack 5+, Next, esbuild, Rollup, Parcel 2, Bun) resolves it
// automatically through `import.meta.url`. No assets to copy, no URL to
// configure, no path to remember.
const engine = new AlbexEngine();
await engine.init();

// Optional overrides — only if you want tier auto-selection or a CDN.
// new AlbexEngine({ wasmBaseUrl: "/assets" })  // serve the 6 variants yourself
// new AlbexEngine({ wasmUrl: "https://cdn.example.com/albex_wasm.wasm" })

AlbexOptions

Lifecycle

await engine.init();
// engine.tier         → 'mini' | 'std' | 'pro'
// engine.simdEnabled  → boolean
// engine.gpuEngaged   → true after the first search that uses WebGPU

Indexing

const input = document.querySelector('input[type=file]');

input.addEventListener('change', async () => {
  for (const file of input.files) {
    const doc = await engine.indexFile(file);
    console.log(`${file.name}: ${doc.chunks} chunks, hash=${doc.contentHash}`);
  }
});

// Idempotent: re-indexing the same file is a no-op and returns the existing
// IndexedDocument (matched by FNV-1a content hash).

IndexedDocument

Search

// Synchronous fast path — best for small corpora and tests.
const results = engine.search('"contrato marco" | rescisión', { windowed: true });
for (const r of results) {
  console.log(`[${r.score}] ${r.documentName} · ${r.snippet}`);
}

// Cooperative streaming search — main thread stays at 60 fps.
for await (const r of engine.searchCooperative('contrato', { frameBudgetMs: 8 })) {
  renderResult(r);   // render incrementally as results arrive
}

SearchOptions

SearchResult

Tuning knobs

Incremental updates — remove · replace · compact

Indexing is idempotent (content-hash dedup is automatic). Documents can be removed individually without rebuilding the entire index. Reclaim storage on demand with compact().

engine.removeDocument('contract-2024-03.pdf');
engine.removeDocument(doc.contentHash);  // by hash also works

engine.removeDocument('old.pdf');
engine.compact();  // bytes freed; subsequent indexFile sees real headroom

Persistence — snapshots on OPFS & IndexedDB

The full engine state can be serialised to a binary blob and restored later. OPFS is preferred (zero-copy writes); IndexedDB is the universal fallback. A 16 MB snapshot typically restores in tens of milliseconds — far faster than re-parsing the documents.

if (!await engine.load('my-corpus')) {
  console.log('No snapshot yet; starting fresh');
}

Introspection — getStats() & getLastSearchStats()

EngineStats

SearchStats

Adaptive runtime — profile detection & helpers

The library exposes pure helpers from the same package so consumers can read the device profile, override tier selection, or build their own UI around resource state. None of them require an initialised engine.

import { detectProfile } from 'albex';
const profile = await detectProfile();
console.log(profile.memoryGB, profile.wasm.simd);

const tier = pickTier(profile);
const workers = pickWorkerCount(profile);
if (shouldUseGpu(profile, engine.getStats().chunks)) { /* … */ }

DeviceProfile

Off-main-thread — AlbexEngineWorker

import { AlbexEngineWorker } from 'albex/worker';

// Same zero-config pattern as the main engine — the worker runtime URL is
// the only thing you must point at (so the bundler can spawn it).
const engine = new AlbexEngineWorker({
  workerUrl: new URL('albex/worker-runtime', import.meta.url),
});

await engine.init();
const results = await engine.search('contrato', { windowed: true });

Parallelisation — AlbexPool

import { AlbexPool } from 'albex/pool';

const pool = new AlbexPool({
  workerUrl: new URL('albex/worker-runtime', import.meta.url),
  workers: 'auto',   // cores/2 clamped [1, 8]
});
await pool.init();

await pool.indexFile(fileA);                   // sharded round-robin
await pool.indexFile(fileB);
const results = await pool.search('contrato'); // map-reduce across shards

Large corpora — TieredStore

import { AlbexEngine, TieredStore } from 'albex';

const engine = new AlbexEngine();
await engine.init();

const store = new TieredStore(engine, { evictThreshold: 0.85, hotFloor: 4 });
await store.init();

await store.indexFile(file);          // persists original blob in OPFS
await store.promote('older-doc.pdf'); // brings warm doc back to engine

GPU acceleration — BloomGpu (advanced)

Typed error hierarchy

Every error thrown by Albex extends AlbexError. Switch on the kind discriminator (which survives structuredClone across worker boundaries) or use instanceof against the subclasses.

import {
  AlbexError, AlbexInitError, AlbexParseError,
  AlbexUnsupportedFormatError, AlbexCapacityError,
} from 'albex';

try {
  await engine.indexFile(file);
} catch (e) {
  if (e instanceof AlbexUnsupportedFormatError) {
    console.warn(`Unsupported: .${e.ext}`);
  } else if (e instanceof AlbexParseError) {
    console.warn(`Failed to parse ${e.format}:`, e.message);
  } else if (e instanceof AlbexCapacityError) {
    console.warn('Engine full — upgrade tier or use TieredStore');
  } else throw e;
}

07Architecture

Albex is a full-text search engine that lives entirely in the user's browser. That sentence is the thesis. Every other choice — the algorithms, the memory model, the absence of an allocator — is a corollary of it. Four axioms follow:

1. Zero server. No back-end ever. Documents never transit the network.
2. Human latency. Searches must answer within ~100 ms — the perception threshold for "instant".
3. Reduced footprint. Bytes shipped to the browser are a tax on every page load.
4. Adapts to the machine. The same package runs on a Chromebook and a Mac Pro, picking what each can support.

The layer map

The codebase is split into six layers. Dependencies flow strictly upward: a layer never calls down into the one below it. This is what lets the algorithm layer be testable without WASM, and the adaptive layer be evolved without touching Rust.

The search pipeline — from query to ranked results in four stages

The cost ladder is deliberate: the cheapest filter runs first on every chunk; the expensive ones only on what survives. A typical search tests 100 000 chunks but runs the Bitap matcher on under 1 % of them. The Bloom filter is the gatekeeper that keeps total search latency under 10 ms even on big corpora.

The pipeline itself is resumable: searchBegin sets up token state, searchSlice(N) processes N chunks and returns done=0/1. That lets searchCooperative yield to the scheduler between slices (frame budgeting) without blocking a paint. It honours an optional GPU candidate mask and a tombstone bitset, then funnels survivors into scoring and the top-K heap.

Bloom filter — 64-bit probabilistic gate

A Bloom filter answers "could the pattern be here?" in two machine instructions: an AND and a compare. We use a single u64 per chunk, with each character mapped to one of 64 buckets by c & 0x3F. A chunk passes iff (chunkBloom & queryBloom) == queryBloom.

The hash function is intentionally trivial. A cryptographic hash would give better distribution but cost 10–100× more CPU. The Bloom runs on every chunk in the corpus — sometimes 100 000 times per query — so raw speed wins over perfect distribution.

For typical European text the filter rejects 80–95 % of chunks before the more expensive Bitap stage. False positives are unavoidable but harmless: Bitap discards them at no extra cost.

Bitap — bit-parallel fuzzy match

The Shift-Or / Wu-Manber algorithm keeps the matching state inside a single u64 register. Each text byte advances the state with a shift + OR + AND — no backtracking, no per-character allocations, no branches dependent on the data.

We extend it to k errors (substitution, insertion, deletion) by maintaining k+1 parallel registers. Albex caps k at 3: more produces noise on short queries and multiplies the linear cost. Pattern length is capped at 64 bytes — the width of the register. Longer queries are truncated with a truncated flag the host can surface in its UI. The error budget is adaptive: tokens of ≤5 characters match exactly, ≤8 allow 1 error, longer allow up to 3.

Scoring and top-K

Each survivor gets a capped sum (0–1000) of components: base accuracy (−200 per average edit), word-boundary bonus, term frequency, document position, phrase proximity (close + in order), and an approximate IDF from per-Bloom-bit document frequency. Weights are hand-tuned.

Results stream into a fixed-size min-heap: insert is O(log K), and when full a new hit only displaces the current worst. A final heap-pop yields the K best in descending order — O(k log k), versus the O(k²) selection sort an earlier version used (27× faster than insertion sort in practice).

Accent folding and stemming

fold_utf8_char maps each code point to a lowercase ASCII base: Latin-1 Supplement and Latin Extended-A (Polish, Czech, Turkish…) collapse to a/c/e/n/o/s/u/z. Accented search is free — acción and accion fold to the same bytes. The same fold runs at index and query time.

The optional Spanish stemmer is a handful of high-impact Snowball-Spanish suffix rules, inlined (~150 bytes vs the full 6 KB state machine). Applied only to query tokens, never to indexed text, so snippets stay faithful — recall improves because the query reduces to a shared prefix that still matches the original word.

Memory model — BSS-only, no allocator

The default wasm32-unknown-unknown target has no OS to call for memory. Pulling in std would drag in dlmalloc or wee_alloc, inflate the binary, add allocation overhead, and introduce a failure mode (OOM) that is hard to surface cleanly to JavaScript.

Instead, every storage region is a zero-initialised static array — TEXT_POOL (16 MB), CHUNKS, NAME_POOL, CHUNK_SIG. Because the BSS segment is described in the binary but not stored, a .wasm with 16 MB of static arrays still weighs ~33 KB on disk. At runtime the WebAssembly linear memory grows to accommodate the layout (~20 MB for std tier), but this grow happens once at instantiation — no per-call allocation, no fragmentation, no OOM during a search.

The trade-off: capacity is a fixed ceiling. Exceeding it is a silent stop, not an error. That is acceptable because the user already chose a tier; a "give me more space" feature would mean an allocator, which would mean fragmentation and unpredictable latency.

The JS ↔ WASM bridge

The entire JS↔WASM data plane is one 64 KB shared byte buffer — the scratchpad. The dance is always: getBuffer(size) → a pointer; JS writes bytes there; JS calls the action (setPattern(len), feedXmlBytes(len), search()); WASM reads the scratchpad, processes, stores results; for output it writes back and JS reads it. No JSON across the boundary — just offsets and lengths. That is what keeps the boundary cost near zero.

At init() the exports contract is validated before the engine returns: memory is a real WebAssembly.Memory, every required export exists, and the ABI version matches. A mismatched binary fails loudly here instead of crashing later inside indexFile.

Adaptive runtime — same package, different machines

Albex ships six variants of the main WASM binary (three capacity tiers, each with and without SIMD) plus the lazy PDF module. The browser fetches one variant per init() call, picked from the device profile.

SIMD sits on top of every tier: the runtime probes for WebAssembly v128 by attempting to validate a tiny module that uses it. If it validates, the engine fetches albex_wasm_<tier>_simd.wasm — a binary built with -C target-feature=+simd128. The inner loop of the Bloom batch is branchless precisely so LLVM can auto-vectorise it.

WebGPU pre-filter — Bloom on the GPU when it pays off

The Bloom check on 100 000 chunks is embarrassingly parallel: each test is independent. A WGSL compute shader can run all 100 000 of them in a single dispatch. The result is a packed bitset of candidates; the CPU then runs Bitap only on those.

Engaging the GPU has a fixed cost (upload + dispatch + readback, ~3–5 ms). Below ~20 000 chunks the CPU wins. Above it, the GPU gives a 5–10× speedup. The default threshold is exactly that break-even point, but it is exposed as gpuThreshold for tuning.

The candidate mask is single-shot: it applies to the next searchBegin and is automatically cleared at the end of the last slice. That prevents stale masks from silently corrupting an unrelated next search if anything ever goes wrong in the JS layer.

PDF and OCR path

The PDF module is a separate WASM binary fetched only on the first PDF — users who never touch PDFs never pay for it. It wraps pdf-extract/lopdf to pull vector text per page. Built with panic=abort, so a malformed PDF traps the instance; the host catches that, discards the poisoned instance, and (if OCR is wired) falls back to extracting embedded page images via lopdf — recovering content pdf-extract could not.

The OCR orchestrator (@albex/ocr, wired via engine.attachOcr(adapter)) manages a pool of Tesseract.js workers and feeds them the JPEG/JPEG2000 image XObjects the PDF module extracts per page. Two modes: scanned-PDF (image-only files) and hybrid (OCR on top of vector text). Best-effort: one failed image never stops the page, one failed page never stops the document. A lightweight script / letter-frequency heuristic guesses the language so the orchestrator loads the right Tesseract traineddata — picking the wrong model is the single biggest hit to OCR accuracy. Tesseract itself (~3.5 MB, LSTM engine compiled to WASM) is loaded lazily via await import("tesseract.js") only when enableOcr() has been called and a scanned image needs recognising.

Rust + TypeScript — when each language wins

Some parsers live in Rust; others live in TypeScript. The rule is not "Rust for important things". It is: which primitive of the host environment wins for this operation?

DOCX, XLSX and PDF go to Rust because the source files can be hundreds of megabytes and streaming a state machine is the only way to handle them. Markdown, HTML, JSON, CSV, EML and RTF go to TypeScript because they fit comfortably in memory and V8 gives us String.prototype.replace with JIT-compiled regex, which beats any hand-written WASM parser for documents of typical size.

08Storage & identity

Three primitives keep the engine honest across sessions and across repeated uploads: OPFS for snapshots, IndexedDB as the fallback, and a 64-bit content hash for deduplication. None of them are configurable surface area — they're internal contracts you should understand when reasoning about what the engine actually does.

OPFS & IndexedDB — why both

When you call engine.save("my-corpus"), the engine serialises the entire index (chunks, document table, text pool, Bloom filters) to a single binary blob and writes it to browser storage. engine.load("my-corpus") reads it back and memcpy's it into the BSS arrays. A 16 MB corpus restores in tens of milliseconds — orders of magnitude faster than re-parsing 50 DOCXs.

The router lives in src/persistence.ts and detects navigator.storage.getDirectory at runtime. If present → OPFS path. Otherwise → IndexedDB. Both paths satisfy the same contract (savePersisted / loadPersisted / deletePersisted / listPersisted), so calling code is identical.

Two distinct uses of OPFS

The persistence backend serialises the engine state: chunks, Bloom filters, doc table. TieredStore uses OPFS differently — it stores the original file blobs, so an evicted document can be promoted back without asking the user to re-pick the file. Two stores, two purposes, same OPFS API.

FNV-1a 64-bit — why this hash

Every call to engine.indexFile(file) hashes the raw bytes before any parsing. If a document with that hash already lives in the index, the engine returns the existing entry and skips the work. This makes indexFile idempotent and safe to call repeatedly — drag the same DOCX twice, the index stays clean.

Why non-cryptographic is fine here

We don't need adversarial collision resistance. The threat model for a content hash in a deduplication store is "the user accidentally dragged the same file twice", not "an attacker is crafting two distinct files that hash the same to confuse the index". If an attacker could exploit a deliberate collision, the worst case would be that their second file does not get indexed — there is no path to elevation of privilege, data leak or denial of service.

SHA-256 would cost 3× the throughput for zero added safety in this scenario. We chose throughput. The same logic is used by Git for object identification (well, until SHA-256 transition, but Git's case IS adversarial), by SQLite for ROWID generation, by countless databases for dedup.

Where the hash surfaces

Two places. First, internally during indexFile — the dedup check. Second, on the returned IndexedDocument.contentHash field. The host can pass that hash to engine.removeDocument(hash) as a stable identifier that survives rename: if your user uploads same-contract-renamed.pdf and you want to remove the previously-uploaded contract.pdf that contains the same bytes, the hash matches even though the names don't.

09Capacity & numbers

Default limits for the std tier (mini and pro scale ×0.25 and ×8 respectively):

Performance figures

10Guides — recipes by use case

From install to advanced setups: cooperative search, worker pool, big-corpus tiering, and integration in React / Angular. Every recipe starts with npm install albex.

ESM / TypeScript

import { AlbexEngine } from "albex";

// 1. Construct + init. The WASM ships with the package and your bundler
//    resolves it through import.meta.url — Vite, Webpack 5+, Next, esbuild,
//    Rollup, Parcel 2, Bun all handle this automatically. No assets to copy.
const engine = new AlbexEngine();
await engine.init();

// 2. Index files from drag-and-drop or <input type="file">.
const input = document.querySelector("input[type=file]");
input.addEventListener("change", async () => {
  for (const file of input.files) {
    const doc = await engine.indexFile(file);
    console.log(`Indexed ${doc.name}: ${doc.chunks} chunks`);
  }
});

// 3. Search.
const results = engine.search('"contrato marco" | rescisión', { windowed: true });
for (const r of results) {
  console.log(`[${r.score}] ${r.documentName} — ${r.snippet}`);
}

// Tweak relevance.
engine.setMaxErrors(1);     // tighter fuzziness
engine.setThreshold(400);   // only return strong hits
engine.setMaxResults(100);
engine.setLanguage("es");   // light Spanish stemming on queries

// Inspect what was loaded.
console.log(engine.tier);          // 'std' by default
console.log(engine.simdEnabled);   // boolean
console.log(engine.gpuEngaged);    // true once first search uses WebGPU

// Want tier auto-selection? Serve the 6 binaries yourself and pass wasmBaseUrl.
// The engine then picks mini/std/pro based on navigator.deviceMemory.
//   new AlbexEngine({ wasmBaseUrl: '/assets', tier: 'auto', simd: 'auto' })

Cooperative search

// Cooperative search — yields to the scheduler between slices so the UI
// thread keeps a chance to paint during long scans. NOTE: results arrive
// in one batch after the search completes; the async iterator exists so
// callers can break early. True incremental streaming is on the backlog.

for await (const r of engine.searchCooperative(query, { frameBudgetMs: 8 })) {
  renderResultCard(r);
  if (results.length >= 50) break;   // stop early — engine cleans up
}

// Wire it into a search input with debounce.
let abortToken = 0;
input.addEventListener("input", async () => {
  const token = ++abortToken;
  const query = input.value.trim();
  resultsEl.innerHTML = "";
  if (!query) return;

  for await (const r of engine.searchCooperative(query, { frameBudgetMs: 8 })) {
    if (token !== abortToken) break;   // newer query started — stop
    appendResult(r);
  }
});

Persistence

// First visit: index the user's documents normally.
for (const file of files) {
  await engine.indexFile(file);
}

// Save a snapshot to OPFS (preferred) or IndexedDB (fallback).
await engine.save("my-corpus");

// On subsequent visits: load instantly instead of re-indexing.
const restored = await engine.loadOrInit("my-corpus");
if (restored) {
  console.log(`Restored ${engine.getStats().documents} documents`);
} else {
  console.log("No snapshot yet, starting fresh");
}

// List all snapshots in this origin.
const names = await engine.listSnapshots();

// Delete one explicitly.
await engine.deleteSnapshot("old-corpus");

Web Worker

// Run the engine in a Web Worker. Same surface, every call returns a
// Promise. Main thread never blocks on indexing or search.
import { AlbexEngineWorker } from "albex/worker";

// Only the worker runtime URL is required so the bundler spawns it.
// The main WASM is resolved automatically inside the worker.
const engine = new AlbexEngineWorker({
  workerUrl: new URL("albex/worker-runtime", import.meta.url),
});

await engine.init();
await engine.indexFile(file);
const results = await engine.search("contrato", { windowed: true });

// Streaming search works through the Worker too.
for await (const r of engine.searchCooperative("contrato", { frameBudgetMs: 8 })) {
  render(r);
}

// Dispose when done (TC39 Symbol.dispose).
engine[Symbol.dispose]();

Worker pool

// AlbexPool shards documents across N workers. Searches map-reduce.
// Best for large corpora on multi-core machines.
import { AlbexPool } from "albex/pool";

const pool = new AlbexPool({
  workerUrl: new URL("albex/worker-runtime", import.meta.url),
  workers:   "auto",   // = cores/2, clamped [1, 8]
});

await pool.init();
console.log("Shards:", pool.workerCount);

// Documents are sharded round-robin.
for (const file of files) {
  await pool.indexFile(file);
}

// Search broadcasts to every shard; coordinator merges top-K.
const results = await pool.search("contrato", { windowed: true });

// Aggregate stats across shards.
const stats = await pool.getStats();
console.log(`${stats.documents} docs across ${pool.workerCount} shards`);

// Remove documents — the pool finds the shard that owns it.
await pool.removeDocument("old-contract.docx");

// Compact every shard at once.
await pool.compact();

// Stream results from a pooled search.
for await (const r of pool.searchCooperative("contrato")) {
  render(r);
}

Big corpora — TieredStore

// TieredStore keeps hot documents in the engine and warm ones in
// OPFS. When the engine fills past evictThreshold, the LRU document
// is removed from RAM but its original blob stays persisted.
import { AlbexEngine, TieredStore } from "albex";

const engine = new AlbexEngine();
await engine.init();

const store = new TieredStore(engine, {
  evictThreshold: 0.85,   // start evicting when 85 % full
  hotFloor: 4,            // never evict the last 4 docs
});
await store.init();

for (const file of files) {
  await store.indexFile(file);   // persists blob + adds to engine
}

// Bring a warm document back into the engine on demand.
const promoted = await store.promote("old-contract.pdf");
if (promoted) {
  // Now searchable in the engine again.
  engine.search("clausula");
}

// Inspect the tier balance.
const stats = store.getTierStats();
console.log(`${stats.hot} hot · ${stats.warm} warm · ${stats.totalBytes} bytes`);

// Forget a document entirely (engine + OPFS).
await store.forget("expired.pdf");

React

import { useEffect, useRef, useState } from "react";
import { AlbexEngine } from "albex";

export function DocSearch() {
  const engineRef = useRef(null);
  const [hits, setHits] = useState([]);
  const [ready, setReady] = useState(false);

  useEffect(() => {
    const e = new AlbexEngine();
    e.init().then(() => {
      engineRef.current = e;
      setReady(true);
    });
    return () => engineRef.current?.[Symbol.dispose]();
  }, []);

  async function handleFile(ev) {
    for (const file of ev.target.files) {
      await engineRef.current.indexFile(file);
    }
  }

  function handleSearch(q) {
    setHits(engineRef.current?.search(q, { windowed: true }) ?? []);
  }

  if (!ready) return <p>Loading…</p>;
  return (
    <div>
      <input type="file" multiple onChange={handleFile} />
      <input onChange={e => handleSearch(e.target.value)} />
      {hits.map(h => (
        <div key={h.documentName + h.location}>
          <b>{h.documentName}</b> — {h.snippet}
        </div>
      ))}
    </div>
  );
}

Angular

import { Component, OnInit, OnDestroy } from "@angular/core";
import { AlbexEngine } from "albex";

@Component({
  selector: "app-search",
  template: `
    <input type="file" multiple (change)="onFiles($event)" />
    <input (input)="onQuery($event)" placeholder="Search…" />
    <div *ngFor="let h of hits">
      <b>{{ h.documentName }}</b> — {{ h.snippet }}
    </div>
  `,
})
export class SearchComponent implements OnInit, OnDestroy {
  private engine!: AlbexEngine;
  hits: any[] = [];

  async ngOnInit() {
    this.engine = new AlbexEngine();
    await this.engine.init();
  }

  ngOnDestroy() {
    this.engine?.[Symbol.dispose]();
  }

  async onFiles(event: Event) {
    const files = (event.target as HTMLInputElement).files!;
    for (const file of Array.from(files)) {
      await this.engine.indexFile(file);
    }
  }

  onQuery(event: Event) {
    const q = (event.target as HTMLInputElement).value;
    this.hits = this.engine.search(q, { windowed: true });
  }
}