4 ms·

In my opinion the top rated comment is right on point there: "I’d say that ImmutableJS is your anti-pattern here, not FP in JavaScript as a whole."

deleted 9y ago
[deleted]
yomly 9y ago
I agree - I use ImmutableJS in one of my projects and the pros vs cons are substantial - it's hard to keep track of when something is Immutable or not and it has been slowly infecting more and more of my codebase. I would be interested in hearing strategies of mitigating this, my first step has been to let Immutable creep through the project, but adopt a convention of creating a layer through which guarantees JS output - anything that is logic related in my redux layer is Immutable, anything which is in my presentational react layer is JS. The difficulty then, is at input points where I need to always remember to deal with nested data structures too. It feels like a type checker would be of great use here to add additional guarantees about any data
- acemarke 9y ago
  Interesting you should say that. I wrote a Reddit comment about a year ago listing reasons why I generally advise against use of Immutable.js, and the "infectious" API is exactly one of the reasons that I listed ( https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abramov_redux_is_not_an_architecture_or/d51g4k4?context=3 https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra... ). Also worth noting that if you are going to do Immutable -> POJO conversions, you should avoid using `toJS()` as much as possible. The conversion process is expensive, _and_ it always creates new object references. Either use `getIn()`, or use memoized selectors to ensure the conversion only happens when the data actually changed.
  - yomly 9y ago
    Yep memoized selectors was on my list of things to look at - great tip! My philosophy is when providing the POJO from the immutable data structure is to select the absolute minimum from the bigger object, which I suppose is in line with your advice on using getIn

deleted 9y ago

[deleted]

yomly 9y ago

I agree - I use ImmutableJS in one of my projects and the pros vs cons are substantial - it's hard to keep track of when something is Immutable or not and it has been slowly infecting more and more of my codebase. I would be interested in hearing strategies of mitigating this, my first step has been to let Immutable creep through the project, but adopt a convention of creating a layer through which guarantees JS output - anything that is logic related in my redux layer is Immutable, anything which is in my presentational react layer is JS. The difficulty then, is at input points where I need to always remember to deal with nested data structures too. It feels like a type checker would be of great use here to add additional guarantees about any data

acemarke 9y ago
Interesting you should say that. I wrote a Reddit comment about a year ago listing reasons why I generally advise against use of Immutable.js, and the "infectious" API is exactly one of the reasons that I listed ( https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abramov_redux_is_not_an_architecture_or/d51g4k4?context=3 https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra... ). Also worth noting that if you are going to do Immutable -> POJO conversions, you should avoid using `toJS()` as much as possible. The conversion process is expensive, _and_ it always creates new object references. Either use `getIn()`, or use memoized selectors to ensure the conversion only happens when the data actually changed.
- yomly 9y ago
  Yep memoized selectors was on my list of things to look at - great tip! My philosophy is when providing the POJO from the immutable data structure is to select the absolute minimum from the bigger object, which I suppose is in line with your advice on using getIn