SkillAgentSearch skills...

Fpx

Functional programming extensions for JS. Lightweight replacement for Lodash.

Install / Use

/learn @mitranim/Fpx
About this skill

Quality Score

0/100

Supported Platforms

Universal

README

Overview

fpx: Functional Programming eXtensions for JavaScript. Lightweight replacement for Lodash. Stuff that should be built into the language.

Features:

  • Higher-order functions for data structures.
    • Common FP tools like map, filter, and many more.
    • Compatible with arbitrary iterables such as lists, sets, maps, dicts.
  • Boolean tests for common types and interfaces.
  • Minifiable type assertions.
  • Type conversions.
  • Tuned for performance.
  • Small and dependency-free. Single file. Native JS module.

Differences from Lodash:

  • Supports arbitrary iterables and iterators, including sets and maps.
  • Type assertions and conversions.
  • Much smaller and simpler.

TOC

Usage

In browsers and Deno, import by URL:

import * as f from 'https://cdn.jsdelivr.net/npm/fpx@0.12.3/fpx.mjs'

When using Node or NPM-oriented bundlers like Esbuild:

npm i -E fpx
import * as f from 'fpx'
import * as f from './node_modules/fpx/fpx.mjs'

Why

  • Built-ins are insufficient.
  • Other libraries are too large.
  • Other libraries are annoying to use.
  • Other libraries lack vital tools.

Simplicity

Programs must be written for people to read, and only incidentally for machines to execute.

— Abelson & Sussman, "Structure and Interpretation of Computer Programs"

I believe that all code should strive to be simple and educational. This gives me a massive distaste for most code.

Fpx is tuned for brevity, readability, clarity in addition to performance. If you want to understand how this kind of library works, how higher-order functions work, how to manipulate JS data structures, Fpx should hopefully provide a good read.

Assertions

Assertions go a long way in debugging. Fail fast, catch bugs early. In asynchronous code, validating inputs as early as possible, instead of letting it fail mysteriously later, can save you hours of debugging.

Here's the traditional way of doing assertions:

function someHigherOrderFunction(fun) {
  if (typeof fun !== 'function') {
    throw TypeError(`expected a function, got ${fun}`)
  }
  // Actual code after the assertion.
}

someHigherOrderFunction({one: 10})
// uncaught TypeError: expected a function, got [object Object]

Annoying to type and really bad for minification. Some folks strip assertions from production builds, but I find the idea flawed. Even in production, failing fast is better than failing mysteriously, and assertions help with debugging when it inevitably fails.

Fpx provides a better alternative:

function someHigherOrderFunction(fun) {
  f.req(fun, f.isFun)
  // Actual code after the assertion.
}

someHigherOrderFunction({one: 10})
// uncaught TypeError: expected {"one":10} to satisfy test isFun

Much better. Easy to type with editor autocompletion, produces good error messages, and minifies really well. In a minified build, the function name will be mangled, which is good for bundle size. The mangled name is a non-issue with a source map, which you need for debugging anyway.

To support this style of coding, Fpx provides #req and a bevy of boolean tests.

Related Skills

View on GitHub
GitHub Stars13
CategoryDevelopment
Updated1y ago
Forks1

Languages

JavaScript

Security Score

65/100

Audited on Jun 20, 2024

No findings