Use ValueTuple element names in minimal route handlers

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Take the following minimal route handler:

app.MapPut("/todos/{id}", async ((int Id, string Title, bool IsComplete) inputTodo, TodoDb db) =>

Today, to upload an inputTodoo to this endpoint, you would need a JSON request body like the following because we don’t look for any TupleElementNameAttributes on the parameter:

{
    "Item1": 1,
    "Item2": "Support named items in ValueTuples",
    "Item3": false
}

Describe the solution you’d like

If we took the names of the ValueTuple elements into account, the request body could look like you’d expect:

{
    "Id": 1,
    "Title": "Support named items in ValueTuples",
    "IsComplete": false
}

Additional context

We have the same problem with ValueTuples returned from minimal route handlers. Today, the following would be serialized using Item1, Item2 and Item3 as the property values instead of the specified names.

app.MapGet("/todos/{id}", async (int Id, string Title, bool IsComplete)  (int id, TodoDb db) =>

[zyofeng]

Thanks @davidfowl. That’s similar to what I am doing atm,

        group.MapPost("{accountNumber}/transactions",
                (ISender sender, string accountNumber, GetTransactionsRequest body) => sender.Send(
                    new GetTransactionsQuery
                    {
                        AccountNumber = accountNumber,
                        PageSize = body.PageSize,
                        From = body.From,
                        To = body.To,
                        CurrentPage = body.CurrentPage
                    }))
            .WithName("Transactions");

        return app;
    }
    public record GetTransactionsRequest(DateOnly From, DateOnly To, int CurrentPage, int PageSize = 20);

Although I am kinda hoping I don’t have to create another request dto. Cheers

[eiriktsarpalis]

I don’t see how this might be possible to solve in the general case, for the reasons @davidfowl already mentioned. I’m also not sure how a custom JsonConverter might be able to work with ambiguity such as ((int foo, int bar), (int baz, int qux)). As far as the STJ converter infrastructure is concerned, both nested values are of type ValueTuple<int, int> and as such they will be dispatched to the same converter instance for serialization without any contextual information.

It might be worth pointing out that the source generator can in fact retrieve tuple label metadata from Roslyn, however such an approach would be problematic for a couple of reasons:

1. Contract divergence from the reflection-based serializer.
2. Converters either source generated or otherwise are still indexed by Type, and as such it would not be possible to address ambiguities like the one highlighted above.