pragmatic-fp-ts
v1.10.3
Published
Opinionated functional programming library with easy use in mind
Downloads
1,704
Maintainers
Readme
pragmatic-fp-ts
A library for functional programming in TypeScript. Curried, argument-last, pure, total functions that never mutate any data, Maybe/Either/Chain monads, FutureEither/FutureMaybe monad-likes.
There's not enough JavaScript libraries to choose from. -- no one, never
This is a quick implementation of most of the FP tools I need in may daily work. Typings are kept as as simple as possible, although this may include some dirty castings under the hood. Still, it is quite shiny when seen from the outside.
How to get
It's on npmjs.com, so you should know the drill.
- npm:
npm install --save pragmatic-fp-ts
- yarn:
yarn add pragmatic-fp-ts
Alternatively, include it in your webpage via ~jsdelivr~:
<script src="https://cdn.jsdelivr.net/npm/pragmatic-fp-ts@1/dist/pragmatic-fp-ts.min.js"></script>
Deno
Alternate source format created automatically with Denoify.
import * as f from "https://github.com/hermann-p/pragmatic-fp-ts/raw/master/deno_lib/main.ts"
Breaking changes
1.0
- functions no longer return Maybe monads as default
- some function names changed
Maybe.match
andEither.match
no longer automatically catch errors, so they can be used as to throw when absolutely needed without leaving the monads' flow.- monads support transforming themselves when given a monad constructor
Usability primer
An elaborated readme will follow. Until then, you can see the auto generated docs on github.
Differences to ramda
- written in TS from the beginning with emphasis on inferring types
over just being
any
- a very small set of functions is not implemented (at the time of
writing, flavours of
merge
are the most noteworthy, although apipe
function exists) - very little function names differ
innerJoin
behaves more like one would expect from an inner database joincompose
andpipe
use monadic-style infix composition instead of just accepting arguments. This allows for type-checked composition of an arbitrary number of functions in contrast to ramda's "list overloads" approach- return types look much cleaner and are arguably more readable by
avoiding constructs like
Curry4<Map<Filter<...
and being more like<A,B>(value: A) => B[]
- no support for fantasy-land objects
Plans for the future
- auto-infer even more types (although it's already quite good)
- improve typing even more once TS implements variadic types
- implement some more helpful functions found e.g. in lodash or Clojure
- greater use of transducers
- introduce lazyness, gradually change from type-overload hell to abstractions
History
1.10
Type-generating Validator returning Either
monads with detailed, extensive
parsing error messages on failure.
1.5
Transducers
Although typing them is a bit of a PITA, transducers are a valuable addition for performance aware functional programmers. The first transducers implemented are:
- map
- filter
- drop
- take
- flatMap
- flatten
which behave just like their non-transducing counterparts, as well as
transformList
which wraps the step of composing and applying a list of
transducers over arrays.
Mutables
Mutables are for those situations where a clean functional solution is inconvenient to implement. They wrap a value and expose methods to mutate that value as well as a value accessor. After soon as the value is accessed for the first time, subsequent calls to the mutating functions will raise an Exception so we can still consume all the data safely.
Misc
Some minor bugfixes, extended functionality of keys
and values
, some
improved typings, most notably for the update
function.
1.4
Add cycle
to create infinite sequence and a naive dummy infinite array type.
1.3.5
Figured out how to setup webpack to create a browser bundle.
1.3.4
Removed mori
dependency. The runtime library is now completely self-contained.
As a Clojure guy I relied on some of mori's functionality for the heavy lifting
of deep get/set/update/equal operations.
Sadly, to use mori's high performance algorithms, data had to be cast to mori
data and back to JS-data after finishing, crippling performance within large
data sets, so these functions are now completely re-implemented in "plain
TypeScript" with a recursive, queue-based approach to path-getting.
Deep equality implementation is based on
epoberezkin/fast-deep-equal
1.3
Added quick intersection testing functions.
1.2
Implemented monadic Futures.
1.1
- Deprecated the function name
bind
of monads, calling it_
instead. Although functional programmers should not have run into any problems with it, the namebind
might confuse people coming from object oriented JavaScript programming, expecting function-this-argument-binding instead of monadic binding. The old name is still kept to keep older code from breaking too much. Composition is arguably easier to read this way. - Introduced
flow
,pipe
, andcompose
, so now we should now be able to do anything with this lib we can do with ramda. - Still missing
mergeXXX
, as I still need to find performant ways to do so. I have a history with lodash'smerge
crippling one of my web apps' performance, and don't want anyone to run into similar issues, especially myself :D
1.0
- ~100 new functions
- some concept changes, see breaking changes
Collaboration
- If you miss any FP construct, feel free to open an issue or PR. It's probably missing because I forgot to implement it/didn't need it yet. If it makes sense to me to have it here, I'll implement it.
- Comments/PRs are very welcome, especially if you want to improve the docs.
License
MIT