Catalog npm
PACKAGE EXPLORERView in registry

2belt

npm

Useful utility functions with strong FP support

Versions collected8
Direct dependencies7From release 1.0.1
Last observed20 Oct, 19:08 UTC

README

Current package documentation

2belt

A library of higher order functions that is immutable, minimalist and versatile

Under construction

This module is still under internal development. We are working on:

  • firming up the API
  • tree shaking
  • usable in all browsers

Available functions

  • filter(obj, fn(val, key))
  • reject(obj, fn(val, key))
  • map(obj, fn(val, key))
  • remap(obj, fn(val, key))
  • shuffle(arr)
  • sortBy(arr, key, desc?)
  • toPairs(obj)
  • fromPairs(arr)
  • groupBy(arr, keyFn, valFn)

How to use

Let's try to make it compatible with both CommonJS and ES6 module systems, with the following emphasis:

  • Default is CommonJS
  • CommonJS allows cherry pick
  • We'll keep it this way for 2belt foreverish, so users are not screwed by breaking changes

Possible usage patterns are:

const { filter, reject } = require('2belt');
const filter = require('2belt/filter');
const belt = require('2belt');

import * as belt from '2belt/es';
import { filter, reject } from '2belt/es';

If we ever decide to use module names like Enum, List etc, it would become

const { Enum, List } = require('2belt');
const { filter, reject } = require('2belt/Enum');
const Enum = require('2belt/Enum');
const filter = require('2belt/Enum/filter');

import { Enum, List } from '2belt/es';

Likelihood of using module names

For a standard library, making the user import each function individually is somewhat inconvenient. For example, if there are only 4 modules total, the user can always just import those 4 modules and be done, like in Elixir. The downside of housing the functions under modules is that the user has to search through the different modules for a function. Also it is somewhat convenient to have functions that work across different object types.

Decision:

  • let's stay with no module name for now
  • if the number of functions grow, we should move into modules because
    • there would be too many functions for users to import individually
    • it would be harder to remember without organization
  • unless we decide we want user to do import * as belt from '2belt/es';

Downloads & popularity

Awaiting observations

No metric observations yet

Download counts and popularity will appear here as the collector receives them.

Versions 8

Collected releases
VersionPublishedDirect dependenciesOpen version
1.0.1Registry latest28 Apr 20227
1.0.027 Apr 20229
0.2.110 Jan 20198
0.2.09 Jan 20198
0.1.314 Apr 20180
0.1.213 Apr 20180
0.1.121 Mar 20180
0.1.024 Feb 20180

Package advisories

0
No matching advisories collected

This describes our collected data; it is not a security assessment.

Metadata history

Meaningful changes
Current collected state Current

Observed since 20 Oct, 19:08 UTC

No superseded metadata states collected. Unchanged observations do not create new revisions.

Record identity

package:35d5248ff8e4c35790e3b482a2ed72ad467b50055e0b3eb2f28c1b71e792919b