DEV Community: traeop

Fast search, filter & sort for large client-side collections in JavaScript

traeop — Fri, 27 Feb 2026 23:00:42 +0000

Hey everyone!

I'd like to share an npm package I built for working with large collections of 100K+ items on the client side.

The problem

Sometimes the server sends back a huge array 100K+ items. And you need search, filter, and sort on the client side.

The issue is that standard JS methods like .filter() or .sort() go through the whole array every time. On small data it's fine, but on large arrays the UI starts to feel slow.

What this package does

It has three parts, and you can use each one separately or all together:

TextSearchEngine — text search. Builds an index once, then searches through it instead of scanning the full array every time.
FilterEngine — filtering by one or more fields. Indexed fields are looked up directly without going through the whole array.
SortEngine — sorting. For a single field it uses a pre-built index, for multiple fields it falls back to a regular sort.

The key idea: the index is built once when you pass in the data. After that, every search, filter, or sort call works against that index — not the raw array.

No dependencies. If you only need search — import only search. Filter and sort code won't end up in your bundle.

Usage

All three together with `MergeEngines`

import { MergeEngines } from "@devisfuture/mega-collection";
import { TextSearchEngine } from "@devisfuture/mega-collection/search";
import { FilterEngine } from "@devisfuture/mega-collection/filter";
import { SortEngine } from "@devisfuture/mega-collection/sort";

interface User {
  id: number;
  name: string;
  city: string;
  age: number;
}

const engine = new MergeEngines({
  imports: [TextSearchEngine, FilterEngine, SortEngine],
  data: users,
  search: { fields: ["name", "city"], minQueryLength: 2 },
  filter: { fields: ["city", "age"], filterByPreviousResult: true },
  sort: { fields: ["age", "name"] },
});

engine.search("john");
engine.filter([{ field: "city", values: ["Miami", "New York"] }]);
engine.sort([{ field: "age", direction: "asc" }]);

Data is passed once — no need to pass it again on every call.

Use only what you need

Search:

import { TextSearchEngine } from "@devisfuture/mega-collection/search";

const engine = new TextSearchEngine({
  data: users,
  fields: ["name", "city"],
  minQueryLength: 2,
});

engine.search("john"); // search across all fields
engine.search("name", "john"); // search in a specific field

Filter:

import { FilterEngine } from "@devisfuture/mega-collection/filter";

const engine = new FilterEngine({
  data: users,
  fields: ["city", "age"],
  filterByPreviousResult: true,
});

// second call filters inside the result of the first one
engine.filter([{ field: "city", values: ["New York"] }]);
engine.filter([{ field: "age", values: [22] }]);

Sort:

import { SortEngine } from "@devisfuture/mega-collection/sort";

const engine = new SortEngine({
  data: users,
  fields: ["age", "name", "city"],
});

engine.sort([
  { field: "age", direction: "asc" },
  { field: "name", direction: "desc" },
]);

When does it make sense to use this?

When the data is large enough that you actually feel the lag. For a few hundred items, plain JS is perfectly fine. This starts to matter somewhere around tens of thousands of items and up.

How to organize your Electron project with Modules

traeop — Sun, 08 Feb 2026 14:19:49 +0000

Hey everyone!

I wanted to share a project I've been working on that might help building Electron applications.

What I Built

electron-modular is a simple DI lib for Electron's main process. Think NestJS/Angular style architecture but specifically designed for Electron and this is simple solution.

Why Does This Exist?

When developers building a Electron apps and the main process sometimes became a mess and I want to better organize architecture especially when the project grows and something like this happens:

Services with tangled dependencies
IPC handlers scattered everywhere
Window management logic duplicated
Many dependencies
Sometimes hard to test anything

Of course, you can build it correctly if you have the right skills, but it would be nice to have a defined structure similar (NestJS/Angular).

So, what It Does

Organize code into feature modules:
RestApiService service from another module

import { Injectable } from "@devisfuture/electron-modular";
....
@Injectable()
export class RestApiService {
  ....
  async get<T>(
    endpoint: string,
    options: RequestOptions = {},
  ): Promise<T | undefined> {
    const response = await fetch(endpoint, options);

    if (response.error !== undefined) {
      console.error("Error fetching data:", response.error.message);
      return;
    }

    return response.data;
  }
  ....
}

Dependency injection token

const USER_REST_API_PROVIDER = Symbol("USER_REST_API_PROVIDER");

TUserRestApiProvider using for Factory Provider within the UserModule. This is like an abstraction between the UserModule and RestApiService

type TUserRestApiProvider = {
  get: <TUser>(
    endpoint: string,
    options?: TRequestOptions,
  ) => Promise<TUser>;
};

UserModule is a feature module that encapsulates all user-related logic, including services, data fetching, IPC communication and so on (see detail in repo)

import { RgModule} from "@devisfuture/electron-modular";
....
@RgModule({
  imports: [RestApiModule],
  ipc: [UserIpc], // IPC communication handlers
  windows: [UserProfileWindow],
  providers: [
    UserService,
    {
      provide: USER_REST_API_PROVIDER,
      useFactory: (restApiService: RestApiService): TUserRestApiProvider => ({
        get: (endpoint, options) => restApiService.get(endpoint, options),
      }),
      inject: [RestApiService],
    },
  ],
})
export class UserModule {}

Automatic dependency injection

import { Injectable, Inject } from "@devisfuture/electron-modular";
....
@Injectable()
export class UserService {
  constructor(
    @Inject(USER_REST_API_PROVIDER) private auth: TUserAuthProvider,
    private db: DatabaseService
  ) {} // Dependencies auto-injected!
}

Dedicated IPC handlers

import { IpcHandler } from "@devisfuture/electron-modular";
....
@IpcHandler()
export class UserIpc {
  constructor(private userService: UserService) {}

  onInit({ getWindow }) {
    // Group all user-related IPC here
  }
}

Window lifecycle management

import { WindowManager } from "@devisfuture/electron-modular";
....
@WindowManager({
  hash: 'window:user-profile',
  isCache: true,
  options: { width: 600, height: 400 }
})
export class UserProfileWindow {
  onWebContentsDidFinishLoad(window) {
    // Lifecycle hooks!
  }
}

Why Provider Pattern?

The provider pattern is useful when:

You want to share only specific methods, not entire services
You want better encapsulation and clear module boundaries

Instead of exposing a full service, you expose only what's needed:

{
  provide: USER_REST_API_PROVIDER,
  useFactory: (restApi: RestApiService): TUserRestApiProvider => ({
    get: (endpoint, options) => restApi.get(endpoint, options),
  }),
  inject: [RestApiService],
}

Resources

GitHub: https://github.com/trae-op/electron-modular
NPM: https://www.npmjs.com/package/@devisfuture/electron-modular
Simple Example App: https://github.com/trae-op/quick-start_react_electron-modular
Full-featured starter: https://github.com/trae-op/electron-modular-boilerplate

Try It Out

npm install @devisfuture/electron-modular

The README has a full guide and examples.

I'd love your feedback! What are the alternatives, and are they easier to use?
I hope you guys like it! Positive feedback and GitHub stars would mean a lot to me )
I’ve been trying to create something that would be simple to use.