Typescript like Partial utility type functionality

[ronnyek]

Please excuse me if something like this is already in the works, or is achievable today (if so, I'd love pointers to how). I did google search it, as well as searching issues here, but as Partial is already a language construct for partial classes, there was a lot of "noise", and may have missed it

In building many API based applications, I frequently find myself needing to request/return objects that effectively are subsets of the bigger picture (whether to provide more concise API's, to filter sensitive data, etc). Typically I think its pretty common for people to build separate objects and either pull data out into those structures, or map values to/from those types via something like automapper, or manual means.

In more recent development experience, I've had the opportunity to experience typescripts' Partial<T> (Partial), and it struck me how you continue to get the type safety, but have the ability to provide subsets of the type around, but still deal with that type in a typesafe way.

Seems like Partial<T> wouldn't solve every problem (eg, knowing about the existence of a field that exists as a part of the parent object, or restricting which fields could be provided say to a request object), but I think being able to deal with object more generically, while still maintaining type safety could be extremely useful in lots of areas. Also seems like the ability to not have to copy values from somethign like a DTO to api response object would be advantageous.

Can record with'ers take records of other types and map fields over with same type and name? (or is it always a anonymous object)

I'm just looking for ways to solve problems more elegantly then instantiating an object, and copying some subset of properties over to new object.

[333fred]

This sounds a lot like the roles proposal: #1711, which would allow you to provide a "role" overlay for a base type.

[ronnyek]

That may be... I've deferred to questions on that topic, as it seems like the writeup for the proposal seems like the examples address very specific situations... but implementation of said proposal may had be able to support what I was hoping to be able to do.

[YairHalberstadt]

I think that there's a lot of different things going on here, and it's worth separating them out. I see at least:

1. I want to expose a subset of a types functionality.
2. I want to map from one object to another object automatically.

For the first, interfaces are a good solution. If you don't own the type, you can't implement interfaces on it, but roles or extension interfaces might help there.

For the second, existing solutions like Automapper do this using reflection. I would like to see some SourceGenerator based solutions, but given the complexity and amount of configuration necessary in this area I wouldn't like to see it in the language itself.

[ronnyek]

My point was that mapping shouldn't be necessary in the first place. In my mind, the idea you'd map data onto one object (say data types mapped up to entity framework for example) and then map it to another object for returning to customers. It's excessive instantiations... and such a common thing that happens.

Source generator could easily solve the mapping concern, and there are projects that already do this to some degree (like InlineMapper)

[HaloFour]

Roles are probably the closest you'll get to something like that, depending on how they're implemented. And that's largely because they seek to layer behavior on top of an existing type. But I don't think they intend to remove or limit the members from the underlying type, only extend what that type offers. But all of that is still early in the design phase so who knows what it will eventually look like.

Beyond that I don't think you can avoid converting to another type, whether that be through mapping or delegation. TypeScript can get away with stuff like this because the types don't exist so it can kind of do whatever it wants, at the end of the day they're just property bags and those "hidden" members are still there.

[ronnyek]

@HaloFour makes sense.
Also miss intellectual c# and .net conversation from IRC (or was it jabbr?) days =) (assuming this is the SAME halofour from IRC)

[HaloFour]

@ronnyek

Also miss intellectual c# and .net conversation from IRC (or was it jabbr?) days =) (assuming this is the SAME halofour from IRC)

Yep. Still there, too, although rarely active. There's also a community on Gitter and Discord, both of which include members of the C# design team.