immutable.md

I recently converted a bunch of stores from Fluxxor to Redux with Immutable JS state. Immutable JS requires the use of a get() method to get keys of Immutable maps/arrays, which meant part of the Fluxxor->Redux conversion was doing one of the following in any component that now uses Immutable state:

1. Convert the Immutable JS object to a POJO with toJS(). This required the least amount of code changes, but then means that anything that later accesses the object can't use the often-useful Immutable JS API (instead having to use Lodash/etc, which theoretically should never be needed with Immutable objects)
2. Repace foo.attr with foo.get('attr'). This unfortunately was pretty error-prone, as any leftover .attr accesses wouldn't throw (instead just always being undefined). It also makes it harder to make properly generic components that could be reused in applications that don't use Immutable JS.
3. Use Record types to allow attribute access. I didn't go with this option because I didn't want to have to codify the shapes of all of my API resources; it's a ton of boilerplate for the sake of saving a get() call.

My current code now has a mix of the first and second options, which is a bit confusing. It'd be good to standardize on one way of consuming Immutable JS objects in code.

Theoretically, most (though likely not all) of the usages of Immutable JS's API that is currently in component logic could be in Reselect selectors - e.g. sorting or formatting, which makes the first option a bit more promising.

I could also use a higher-order component that converts Immutable props to POJOs, as was suggested to me on Twitter: https://twitter.com/katyemoe/status/701912635382611972. This wouldn't have to be used everywhere, just places where it's known that we don't need access to Immutable JS APIs.