DEV Community: Tejas Kadam

sort-filter-lite: headless sort, filter, and pagination for data tables

Tejas Kadam — Tue, 11 Aug 2026 04:32:42 +0000

Every data table ends up with the same hand-rolled sort/filter/pagination logic, rewritten slightly differently in every project. I got tired of it, so I pulled it into a small package.

sort-filter-lite is headless - no components, no rendering assumptions. Just pure functions that work on plain arrays of objects, so it drops into React, Angular, Vue, or vanilla JS the same way.

import { sortBy, filterBy, paginate } from 'sort-filter-lite';

const active = filterBy(users, { key: 'active', operator: 'eq', value: true });
const sorted = sortBy(active, { key: 'age', direction: 'desc' });
const page = paginate(sorted, 1, 20);
// { items, page, pageSize, totalItems, totalPages, hasNextPage, hasPrevPage }

A few design notes:

Every function returns a new array - nothing mutates the input.
Default sort handles numbers, dates, and case-insensitive strings automatically. Custom comparator when you need it.
Filters support eq, neq, gt, gte, lt, lte, contains, startsWith, endsWith, in, notIn - combined with AND semantics.
paginate clamps out-of-range pages instead of throwing, so "page 0" or "page 999" don't blow up your UI.

Fully typed, zero runtime dependencies, 24 tests, 98% coverage, CI on Node 18 and 20.

GitHub: https://github.com/tejas821/sort-filter-lite
npm: npm i sort-filter-lite

This is package #4 in a small series of open-source utility packages I've been shipping. Feedback welcome - especially if you spot an edge case I missed.

The cross-field form validators Angular doesn't ship (so I built them)

Tejas Kadam — Tue, 11 Aug 2026 04:04:56 +0000

Third small package in a series I started a couple weeks back (rule-lite, then entitlement-lite). This one's about Angular Reactive Forms.

Angular ships plenty of single-field validators - required, min, pattern - but almost nothing for cross-field rules. The moment a form needs "end date can't be before start date," or "state is required only if country is US," or "no two line items can share the same SKU," teams either hand-roll a one-off group validator per form or reach for a much heavier form library.

So I made validators-lite. Three group/array-level validators, each returning a plain ValidatorFn:

const form = new FormGroup({
  start: new FormControl(''),
  end: new FormControl(''),
}, {
  validators: [dateRange('start', 'end')],
});

form.errors; // { dateRange: {...} } if end is before start

conditionalRequired and uniqueInArray work the same way - conditionalRequired('country', 'state', c => c === 'US') marks state required only when the condition is true, and uniqueInArray() fails a FormArray when two entries have the same value (or the same field, for arrays of objects).

One thing worth calling out: it has no hard dependency on @angular/forms. The validators are typed structurally against a minimal AbstractControlLike interface (.value, .get()), so any real FormGroup or FormArray satisfies them without an adapter - and the package stays usable in tooling that doesn't have Angular resolvable at type-check time.

Repo: https://github.com/tejas821/validators-lite
npm: https://www.npmjs.com/package/validators-lite

If you've hand-rolled similar validators or have thoughts on the API, I'd like to hear it.

I built a tiny permission checker so I'd stop writing "if user.role === admin" everywhere

Tejas Kadam — Thu, 30 Jul 2026 18:39:36 +0000

Second small package in a series I started last week (first one was rule-lite, a JSON rule evaluator). This one's about permissions.

Here's the thing about "can this user edit this invoice" - it sounds like a yes/no role question but it almost never is. It's really "can this user edit this invoice, AND do they own it, AND is it under some approval limit." Plain role-based permissions handle the first half fine. Then the second half turns into random if-checks scattered across the codebase, and six months later nobody remembers why that one check exists.

So I made entitlement-lite. Small idea: roles hold permissions like normal, but any permission can also carry an optional condition.

const engine = new EntitlementEngine([
  {
    name: 'contributor',
    permissions: [{
      action: 'edit',
      resource: 'invoice',
      condition: { field: 'resource.ownerId', operator: 'eq', value: 'u1' }
    }]
  }
]);

engine.can(subject, 'edit', 'invoice', { resource: { ownerId: 'u1' } }); // true

No condition on a permission? It's just a normal role check. Condition present? It gets evaluated at request time using rule-lite (the package I put out last week). I didn't want to write a second rule engine just for this, so it reuses the first one.

Also supports wildcards so you're not stuck writing { action: 'view' }, { action: 'edit' }, { action: 'delete' }... for an admin role - { action: '*', resource: '*' } covers it.

It's deliberately not trying to be OPA or Casbin. Those are the right call for big multi-service auth systems. This is for the much more common case: one app, a handful of roles, a few conditions that need actual logic instead of hardcoded ifs.

Repo: https://github.com/tejas821/entitlement-lite
npm: https://www.npmjs.com/package/entitlement-lite

If you've built something similar or have opinions on the API (especially the wildcard matching or how conditions merge into context), I'd like to hear it.

Why I stopped hardcoding conditional logic in enterprise forms (and open-sourced the fix)

Tejas Kadam — Wed, 29 Jul 2026 18:13:10 +0000

Every enterprise app I've worked on eventually hits the same wall: a form or workflow that needs conditional logic — "show field B if A is High," "require C unless D is Approved," "disable E for 30 days after F." The first version is always a few *ngIf*s. Six months later it's an unmaintainable tree of nested conditionals that only the original author fully understands.

I've rebuilt the fix for this three times now, most recently as the rule engine behind a compliance platform's dynamic audit checklists. This time I pulled the core idea out into a standalone package — rule-lite (https://github.com/tejas821/rule-lite) — because the problem is common enough that it shouldn't need reinventing per project.

The core idea

Rules are data, not code:

{
  "all": [
    { "field": "user.age", "operator": "gte", "value": 18 },
    {
      "any": [
        { "field": "user.role", "operator": "eq", "value": "admin" },
        { "field": "user.country", "operator": "eq", "value": "IN" }
      ]
    }
  ]
}

import { RuleEngine } from 'rule-lite';

const engine = new RuleEngine();
engine.evaluate(rule, { user: { age: 25, role: 'guest', country: 'IN' } }); // true

That's the whole API surface: AND/OR/NOT compose to unlimited depth, a dozen built-in operators (eq, gt, in, contains, exists...), and a registerOperator hook for anything domain-specific. Zero runtime dependencies, framework-agnostic — same rule JSON works from an Angular service, a Node backend doing entitlement checks, or a CLI validation script.

Why object-shaped conditions, not a compact DSL

I considered three shapes before settling on this one:

A string DSL ("age >= 18 && country == 'IN'") is the most compact to author, but needs a parser, isn't safely JSON-serializable without escaping, and is hard to validate before evaluation.

A JsonLogic-style array DSL ({"and": [{">=": [{"var": "age"}, 18]}]}) is what JsonLogic itself does — very compact, but genuinely unreadable without the spec open next to it.

Object-shaped conditions ({ field, operator, value }) — what shipped — are more verbose JSON, but self-documenting and trivial to build a form-builder UI around: a select for field, a select for operator, an input for value. That's the actual use case I care about — dynamic forms and business rules that a product or config team, not just engineers, eventually needs to author.

Readability and "can someone configure this without reading a spec" won over raw compactness.

What's next

I'm using this as the first entry in a small "-lite" family of enterprise-focused utility packages — next up is an RBAC/ABAC permission checker that uses rule-lite internally for attribute-based conditions.

If you build dynamic forms, feature flags, or business-rule systems in TypeScript and this shape of problem sounds familiar, I'd genuinely like feedback on the API — especially the operator set and whether the all/any/not composition covers real cases you've hit.

Repo: https://github.com/tejas821/rule-lite
npm: https://www.npmjs.com/package/rule-lite
Full design write-up: https://github.com/tejas821/rule-lite/blob/main/CASE_STUDY.md