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

@jdeniau I spent a lot of time ongetIn 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 thejd-feat-tsMapObject branch.

If you want to continue on the subject, there are still some issues with constructor likeMap(List(List(['a', 'A']))), but the worst thing for me is theObjectLikeMap interface, which seems really weird.
The best solution for me would be to have a uniqueinterface 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 (especiallyset andsetIn), but can be declared later.

Was able to push my changes.

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

What's the issue withMap(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 theGetMapType<S> that is not generic and could not be reused for Record, List, etc. as it is tied to theObjectLikeMap, but your implementation is great : it does simplify a LOT thegetIn function.

AboutMap(List(List(['a', 'A']))), IIRC, It should matchMap(collection: Iterable<[K, V]>) but it doesn't asList(['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 thatMap 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 tofromJS 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 withfromJS since it'll sometimes get in the way, in the sense of "I know this is astring but I have to check because TS says it's astring | 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 typesfromJS andtoJS, as well as adding support forupdate.

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 suremerge & co work properly.

@leebyron Thanks for looking and identifying these issues withgetIn.

In honesty I changingnever tounknown would be best here, and keeping the current object-all-the-way-down path as helpful but not stopping you from usinggetIn otherwise.

My reasoning is we're dealing with both string literal types like"car" and then generic types likestring. With the[...T] syntax (microsoft/TypeScript#39094) I had to make itReadonlyArray<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 ifstring extends "a" | "b" | "c", it doesn't and returns never.

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

I wonder if there's a better way of typinggetIn, 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

typeArr=readonlyunknown[];typeGetInType<T,KeyPathextendsArr>=KeyPathextends[inferU]    ?UextendskeyofT       ?T[U]      :'fail 1'    :KeyPathextends[inferK, ...inferRest]      ?KextendskeyofT         ?GetInType<T[K],Rest>        :'fail 2'      :'fail 3'// ---constobj={foo:{list:[1,2,3],listObj:[{name:"alex"},{name:"sam"}],},num:123,};typetest=GetInType<typeofobj,['foo','list']>;

So, the type oftest isnumber[]

Playground Link

For ImmutableJS, I guess we could replaceT[U] by something likeT.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 athttps://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.