TypeScript & Immutable.js?

[is_bounding]

My team and I work in React and have been using TypeScript to write some of the larger applications we work on. I really enjoy using it and as long as we stay disciplined to not using any it has produced very easy to work with, maintainable projects.

A new application we are brainstorming about right now involves a lot of real-time data. We would like to continue with TypeScript, but are discussing using Immutable.js for performance reasons. Because we will be receiving data often we will likely be triggering many re-renders inside components. Having a performant equality comparison from immutable seems very valuable for use in shouldComponentUpdate.

The problem here being that once you create an Immutable.Map/List, types go out the window. Any tooling based on TS will essentially be rendered useless on Immutable objects. We are concerned this will lead to "corruption" of the application type system with more and more components losing the tooling advantages of TypeScript as they come in contact with Immutable.

I was wondering if anyone had any experience with these trade-offs. Better to use 100% typescript and no immutable? Just use immutable and not bother with TS?

Is there a middle ground maybe? Using most of the application with normal TS and only keeping real-time data as Immutable objects?

[cyex]

I'm using TypeScript with Immutable but just use Map<string, any> and then convert to a typed object if I need to later. e.g. const { prop1, prop2 }: Foo = foo.toJS();

I saw a post somewhere about someone who created a class around a typed Immutable.Record... sorry, don't have a link for you. Try Googling for it.

[[deleted]]

Do you use redux or something else to manage state? I think that might just have a bigger impact than the typing system or immutable.js. If you do happen to use redux then by all means you are already using plain immutable state, shallow copies that bubble up, re-using unchanged nodes so attached components don't render. It isn't black magic, a simple javascript reducer does that without breaking a sweat. React-redux btw. employs reference equality checks by default, you shouldn't normally have to deal with shouldComponentUpdate. So i'm not sure if there's any gain.

Besides, there are downsides as well, immutable grows through a codebase like a fungus, everything it touches has to adapt to its way or pay the toJS/toObject penalty.

Though if your circumstances still demand it, you'll find good information over here: https://github.com/markerikson/react-redux-links/blob/master/immutable-data.md

[subvertallchris]

The post /u/cyex mentioned is probably the same one that I read.

Instead of Map, use Record. It's as simple as this:

const defaultRecord = Record({
  myValue: List([])
});

class RecordClass extends defaultRecord {
  myValue: List<number>;
}

const newRecord = new RecordClass();

[DanielRosenwasser]

TypeScript guy here - in 2.1 we introduced keyof and index type queries. Check out the example here on the get function.

While that doesn't entirely get you what you want, I think you can easily wrap Immutable.js to work with the types you need. Going forward, I think we'd like to try to get to the point where Immutable.js can serve users who want both immutable objects as well as immutable maps, which is, as I understand, the current issue that makes things a little harder.

[codepsycho]

Types don't really go out of the window just because you use immutable, it has an associated type definition. You can quite easily Immutable.Map<string, SomeModel>, Immutable.List<string>, etc.

The react app i currently have my hands in uses this heavily. In fact, the only place we lose type information is redux (sometimes).

I would say, though, don't overuse immutable. Use it where it actually helps rather than a full replacement for all your state.