mostjs / prelude Goto Github PK

This would add some kb for sure, but the work there seems pretty solid and follows Fantasy Land. WDYT?

There's a jsnext:main field in package.json, but there should be a module field too.

See here https://github.com/rollup/rollup/wiki/jsnext:main.

While attempting to use @most/prelude's compose function to make my own switchMap, like

import { map, switchLatest } from 'most'
import { compose } from '@most/prelude'
const switchMap = compose(switchLatest, map)

I ran into an error and realized it was because map needs to take in multiple arguments. I got around the problem by writing my own compose function in the library, like this:

const compose2 = (f, g) => (...args) => f(g(...args))
const switchMap = compose2(switchLatest, map)

And we could do the same with apply:

const apply = (f, ...args) => f(...args)

or maybe

const applyArray = (f, argsArr) => f(...argsArr)

I realize I could still accomplish the same things by using prelude's compose/apply + the curry functions, but it would require additional steps and would be less convenient.

We could also add partial application:

const partial = (f, ...args) => (...rest) => f(...args, ...rest)

And it might be more than what's wanted or is necessary for prelude, but we could go further by defining a fold1 to help create a variadic compose:

// like foldl1 in Haskell
const fold1 = (f, arr) => {
  if (!arr.length) {
    throw Error('fold1 must only be applied to non-empty lists')
  }

  let acc

  for (let i = 0; i < arr.length; i++) {
    acc = !acc ? arr[i] : f(acc, arr[i])
  }

  return acc
}

const compose2 = (f, g) => (...args) => f(g(...args))

// compose function for when the function arity is unknown
const compose = (...fs) => fold1(compose2, fs)

Thoughts on changing and/or adding any of these?

Could we modify the structure of the build to enable modular imports (like what Ramda offers under ramda/src/...) so that all of @most/prelude isn't included when we only need a few utility functions from it?

The recent addition of the module field in #14 is not being used correctly.

The module field is suppose to point to code that "has ES2015 module syntax but otherwise only syntax features that browser/node supports." However the current module field points to the src folder - which still contains es6 features (e.g. let).

• https://webpack.js.org/guides/author-libraries/#final-steps
• https://github.com/rollup/rollup/wiki/pkg.module#wait-it-just-means-import-and-export--not-other-future-javascript-features

Maybe it would be better to also transpile the source to a lib folder where the code is all es5 expect for the es6 import/export syntax. Then that lib code could be exposed via the module field.