Working today on seeing if getIn can be improved or implementing the other functions

@jdeniau I spent a lot of time on getIn but finally(!) found a solution using a new TS feature called variadic tuple types: microsoft/TypeScript#39094

Mind if I have write access to your fork so I can push my changes?

Happy to work more on this with you as well, if you have a good idea of what else needs implementing in order to review & merge.

@mbullington I gave you access on my fork. You can push on the jd-feat-tsMapObject branch.

If you want to continue on the subject, there are still some issues with constructor like Map(List(List(['a', 'A']))), but the worst thing for me is the ObjectLikeMap interface, which seems really weird.
The best solution for me would be to have a unique interface Map that handle both key/value sequence and also the object constructor, but I didn't handle that without breaking actual interface.
If we keep the two different interfaces, then all other method should be declared and are missing here (especially set and setIn), but can be declared later.

Was able to push my changes.

Thinking about ObjectLikeMap, I think it's hard to integrate them because it's limited to string | number, while Map can have arbitrary key values.

What's the issue with Map(List(List(['a', 'A'])))? Haven't tested it but curious which constructor does it use?

Nice implementation ! One think I'm not sure about (and something I did added) is the GetMapType<S> that is not generic and could not be reused for Record, List, etc. as it is tied to the ObjectLikeMap, but your implementation is great : it does simplify a LOT the getIn function.

About Map(List(List(['a', 'A']))), IIRC, It should match Map(collection: Iterable<[K, V]>) but it doesn't as List(['a', 'A']) does not match the tuple [K, V] (as it's a List).

@bdurrer I will open a discussion or a wiki page once this is merged to keep the CHANGELOG light

Thanks all and @jdeniau for working on this!

I can understand the argument that Map isn't the place for these and wanting to keep the typing aligned with the ES6 Map, so it's not without a good discussion.

I think the main goal of this is to enable strong typing for the "immutable POJOs," which in a lot of cases due to fromJS is how people use Immutable. @acusti There's no ES6 Map equivalent for that.

Right now it's hard to justify using the Immutable typing with fromJS since it'll sometimes get in the way, in the sense of "I know this is a string but I have to check because TS says it's a string | number" So this PR makes a world of difference there.

For people like @bdurrer 's use case I'd hate to flip this around, trading one alienated use case for another. If we can strike a balance (which I hope we've done?) both groups will be able to work productively.

I've been playing around with an internal version for Mapbox Studio that recursively types fromJS and toJS, as well as adding support for update.

I'd love some feedback on if these should be added or if the from/toJS logic is even correct:

https://gist.github.com/mbullington/631dd21f910e594b29fb97dd6f3e62e8

I took a stab at making sure merge & co work properly.

@leebyron Thanks for looking and identifying these issues with getIn.

In honesty I changing never to unknown would be best here, and keeping the current object-all-the-way-down path as helpful but not stopping you from using getIn otherwise.

My reasoning is we're dealing with both string literal types like "car" and then generic types like string. With the [...T] syntax (microsoft/TypeScript#39094) I had to make it ReadonlyArray<string | number | symbol> to get the path type looking like ["a", "b", "c"] using literals. Otherwise it would use [string, string, string], so when we check if string extends "a" | "b" | "c", it doesn't and returns never.

This could present issues with typing getIn for non-object-all-the-way-down structures.

I wonder if there's a better way of typing getIn, I wonder if there's TS office hours or someone we could ask given Immutable's popularity as a project.

Hi @mbullington

You can get the type of the given key path of a plain JS object like

type Arr = readonly unknown[];

type GetInType<T, KeyPath extends Arr> =
  KeyPath extends [infer U]
    ? U extends keyof T 
      ? T[U]
      : 'fail 1'
    : KeyPath extends [infer K, ...infer Rest]
      ? K extends keyof T 
        ? GetInType<T[K], Rest>
        : 'fail 2'
      : 'fail 3'

// ---
const obj = {
  foo: {
    list: [1,2,3],
    listObj: [{name: "alex"},{name: "sam"}],
  },
  num: 123,
};

type test = GetInType<typeof obj, ['foo', 'list']>;

So, the type of test is number[]

Playground Link

For ImmutableJS, I guess we could replace T[U] by something like T.get(U).

What's the status on this? Looks like it would be highly beneficial for a project my team is working on

@jbaca303 it's a work in progress but it's really complex to make this work properly.

Don't expect it to be done in the next few weeks, but if you would like to try it on your project, every return would be appreciable.

@jbaca303 it's a work in progress but it's really complex to make this work properly.

Don't expect it to be done in the next few weeks, but if you would like to try it on your project, every return would be appreciable.

Thanks for the quick update. Totally understand that this complex. Thank you guys for working on this, really appreciate it!

I am using this for nearly 2 years now at https://github.com/mapado internally.

I think it is time to go public now. I will release a RC on a 5.0 version to have some community return on this.

Thanks you all for your patience.