Immutable data encourages pure functions (data-in, data-out) and lends itself to much simpler application development and enabling techniques from functional programming such as lazy evaluation.
While designed to bring these powerful functional concepts to JavaScript, it presents an Object-Oriented API familiar to Javascript engineers and closely mirroring that of Array, Map, and Set. It is easy and efficient to convert to and from plain Javascript types.
In order to better explain what kinds of values the Immutable.js API expects and produces, this documentation is presented in a statically typed dialect of JavaScript (like Flow or TypeScript). You don't need to use these type checking tools in order to use Immutable.js, however becoming familiar with their syntax will help you get a deeper understanding of this API.
A few examples and how to read them.
All methods describe the kinds of data they accept and the kinds of data they return. For example a function which accepts two numbers and returns a number would look like this:
sum(first: number, second: number): numberSometimes, methods can accept different kinds of data or return different kinds of data, and this is described with a type variable, which is typically in all-caps. For example, a function which always returns the same kind of data it was provided would look like this:
identity<T>(value: T): TType variables are defined with classes and referred to in methods. For example, a class that holds onto a value for you might look like this:
class Box<T> {
constructor(value: T)
getValue(): T
}In order to manipulate Immutable data, methods that we're used to affecting
a Collection instead return a new Collection of the same type. The type
this refers to the same kind of class. For example, a List which returns
new Lists when you push a value onto it might look like:
class List<T> {
push(value: T): this
}Many methods in Immutable.js accept values which implement the JavaScript
Iterable protocol, and might appear like Iterable<string> for something
which represents sequence of strings. Typically in JavaScript we use plain
Arrays ([]) when an Iterable is expected, but also all of the Immutable.js
collections are iterable themselves!
For example, to get a value deep within a structure of data, we might use
getIn which expects an Iterable path:
getIn(path: Iterable<string | number>): unknownTo use this method, we could pass an array: data.getIn([ "key", 2 ]).
Note: All examples are presented in the modern ES2015 version of JavaScript. Use tools like Babel to support older browsers.
For example:
// ES2015
const mappedFoo = foo.map(x => x * x);
// ES5
var mappedFoo = foo.map(function (x) { return x * x; });Lists are ordered indexed dense collections, much like a JavaScript Array.
Immutable Map is an unordered Collection.Keyed of (key, value) pairs with
O(log32 N) gets and O(log32 N) persistent sets.
A type of Map that has the additional guarantee that the iteration order of entries will be the order in which they were set().
A Collection of unique values with O(log32 N) adds and has.
A type of Set that has the additional guarantee that the iteration order of
values will be the order in which they were added.
Stacks are indexed collections which support very efficient O(1) addition
and removal from the front using unshift(v) and shift().
Returns a Seq.Indexed of numbers from start (inclusive) to end
(exclusive), by step, where start defaults to 0, step to 1, and end to
infinity. When start is equal to end, returns empty range.
Returns a Seq.Indexed of value repeated times times. When times is
not defined, returns an infinite Seq of value.
A record is similar to a JS object, but enforces a specific set of allowed string keys, and has default values.
A Record.Factory is created by the Record() function. Record instances
are created by passing it some of the accepted values for that Record
type:
Seq which represents key-value pairs.
Seq which represents an ordered indexed list of values.
Seq which represents a set of values.
The Collection is a set of (key, value) entries which can be iterated, and
is the base class for all collections in immutable, allowing them to
make use of all the Collection methods (such as map and filter).
Keyed Collections have discrete keys tied to each value.
Indexed Collections have incrementing numeric keys. They exhibit
slightly different behavior than Collection.Keyed for some methods in order
to better mirror the behavior of JavaScript's Array, and add methods
which do not make sense on non-indexed Collections such as indexOf.
Value equality check with semantics similar to Object.is, but treats
Immutable Collections as values, equal if the second Collection includes
equivalent values.
True if maybeImmutable is an Immutable Collection or Record.
True if maybeCollection is a Collection, or any of its subclasses.
True if maybeKeyed is a Collection.Keyed, or any of its subclasses.
True if maybeIndexed is a Collection.Indexed, or any of its subclasses.
True if maybeAssociative is either a Keyed or Indexed Collection.
True if maybeOrdered is a Collection where iteration order is well
defined. True for Collection.Indexed as well as OrderedMap and OrderedSet.
True if maybeValue is a JavaScript Object which has both equals()
and hashCode() methods.
True if maybeSeq is a Seq.
True if maybeList is a List.
True if maybeMap is a Map.
True if maybeOrderedMap is an OrderedMap.
True if maybeStack is a Stack.
True if maybeSet is a Set.
True if maybeOrderedSet is an OrderedSet.
True if maybeRecord is a Record.
Returns true if the key is defined in the provided collection.
Returns the value at the provided key path starting at the provided collection, or notSetValue if the key path is not defined.
Returns true if the key path is defined in the provided collection.
Returns a copy of the collection with the value at the key path removed.
Returns a copy of the collection with the value at the key path set to the provided value.
Returns a copy of the collection with the remaining collections merged in.
Returns a copy of the collection with the remaining collections merged in,
calling the merger function whenever an existing value is encountered.
Like merge(), but when two compatible collections are encountered with
the same key, it merges them as well, recursing deeply through the nested
data. Two collections are considered to be compatible (and thus will be
merged together) if they both fall into one of three categories: keyed
(e.g., Maps, Records, and objects), indexed (e.g., Lists and
arrays), or set-like (e.g., Sets). If they fall into separate
categories, mergeDeep will replace the existing collection with the
collection being merged in. This behavior can be customized by using
mergeDeepWith().
Like mergeDeep(), but when two non-collections or incompatible
collections are encountered at the same key, it uses the merger function
to determine the resulting value. Collections are considered incompatible
if they fall into separate categories between keyed, indexed, and set-like.