I see! Well, clearly I wasn't thinking about it from a library maintenance perspective, and instead was just seeing it from my own perspective as a user of the library! Thanks for clarifying the downsides of my suggestion!

I wasn't going to make use of the chaining syntax myself. I was piping and composing utilities together, so for me, your example would have looked something like this:

const toSort = (obj) => obj.sort();
const getValues = (obj) => obj.getValues();
const toList = (obj) => obj.toList();
const slice = (num) => (obj) => obj.slice(num);

const pipeline = pipe(
  toSort,
  getValues,
  toList,
  slice(1),
);

pipeline(Map(xxx));

This isn't really how I'm using immutable.js though! I'm mostly just making use of its .get and .set method to make lenses with Ramda. So like:

const immutableJSLens = (prop) => lens(
  (store) => store.get(prop),
  (value, store) => store.set(prop, value),
);

const ALens = immutableJSLens('a');
const BLens = immutableJSLens('b');
const ABLens = compose(ALens, BLens);

const immutableState = fromJS({ a: { b: 1 } });

set(ABLens, 2, immutableState); // { a: { b: 2 } }

I'm realizing now that the full weight of immutable.js may be too heavy for the simple application I'm trying to use it for. I don't think dynamic import will work since I want to initialize my state as an immutable object right away, and that would have to happen before the UI loads.

Uh oh!

Extract sort function from Collection types #1961

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions