Immutable-js: Map: Is it a Function or Class?

[papercuptech]

Both the ES6 source and immutable.js.flow declare Map as a class, and presumably sub-class-able.

However immutable.d.ts declares it as a module/function/interface, preventing sub-classing from it.

I'm using TS, and would like to sub-class Map.

Is Map not meant to be sub-class-able, or is the TS declaration incorrect?

[dsm0880]

I looking to do the same as @papercuptech. Sub-classing is my biggest issue with Immutable.js. We had to implement Records everywhere to get typing information but I could still not sub-class from a parent record.

const parentRecord = Record {a:1,b:2}
class Parent extends parentRecord{
a:number;
b:number;
constructor(a:number,b:number){
    super(
        {a:a,b:b}
    )
  }
}

Now I want to extend this Parent class:

const childRecord = Record {c:1,d:2}
class ChildClass extends Parent{
c:number;
d:number;
constructor(a:number,b:number,c:number,d:number){
    super(
        {a:a,
        b:b,
        c:c,
        d:d
      }
    )
  }
}

This obviously doesn't work but you can see what I'm getting at. Given it appears you are refactoring all this new code for Typescript what do you recommend moving forward for developers who want to use an immutable type but need to create a class hierarchy and get dot notation intellisense.

[leebyron]

Immutable.js doesn't support subclassing of Maps, Lists, and other collection types. The type constructors are functions (they don't need be called with new). The TS declarations are correct, the flow definitions are incorrect in this particular way but using the class definition made other desirable behaviors work with the flow checker.

Records can be sub-classed as a means of adding additional methods to the prototype, however subclasses cannot add new fields to the Record store and cannot perform work in a constructor (since every "mutation" results in the construction of a new Record). I typically recommend against subclassing Records and instead favor general purpose functions which accept the records as arguments - this approach is easier to type check, easier to scale in a codebase, and is more performant at runtime.

[leebyron]

Part of the confusion is the source text which was written before ES6/ES2015 was finished. It is using a non-compliant class transform which converts back to a prototypal function constructor

[dsm0880]

@leebyron Got it. I just want to give my thoughts on this if that's OK. I believe I understand (I may not) that we have separate programming styles here with functional and object oriented. Although libraries such as this one have revealed an alternate reality to me which is we instead work on spectrum and you can incorporate each style into your code. With that being said I personally don't see the value of Immutable.js as a functional programming library (you may not either) but instead an awesome library that prevents me from passing all my objects by reference and tearing out all my hair :) I may be missing the point but that is the beauty I see here. This is why I get confused by your answer because to me I'm inches away from reducing massive amounts of my typescript code if I could inherit class properties while maintaining immutability. Now you may say that last sentence is impossible given the inherent mutation that I'm asking for but then you have to ask yourself what do developers like myself do? Is the answer to code in a functional style? Maybe but I believe the unexpected popularity of your Records type as you noted in your 2016 road map document is likely due to a number of the reasons I pointed out above.