bufbuild/knit-ts

TypeScript client for Knit

knit-ts's Issues

Relation must have intermediate Value message

When defining a relation and using the protoc-gen-knit-ts plugin to process it, the following relation fails:

message GetQuoteFilmRequest {
    repeated buf.starwars.quote.v1.Quote bases = 1;
}

message GetQuoteFilmResponse {
    repeated buf.starwars.film.v1.Film values = 1;
}

service RelationService {
    rpc GetQuoteFilm(GetQuoteFilmRequest) returns (GetQuoteFilmResponse) {
        option (buf.knit.v1alpha1.relation).name = "film";
        option idempotency_level = NO_SIDE_EFFECTS;
    }
}

The plugin returns the error, where 11 is the number of fields in Film:

protoc-gen-knit-ts: GetQuoteFilm: relation must have exactly one field, found 11

However, this alternate longer definition works because it wraps the Film in an intermediate message.

message GetQuoteFilmRequest {
    repeated buf.starwars.quote.v1.Quote bases = 1;
}

message GetQuoteFilmResponse {
    repeated Value values = 1;
    message Value {
        buf.starwars.film.v1.Film film = 1;
    }
}

service RelationService {
    rpc GetQuoteFilm(GetQuoteFilmRequest) returns (GetQuoteFilmResponse) {
        option (buf.knit.v1alpha1.relation).name = "film";
        option idempotency_level = NO_SIDE_EFFECTS;
    }
}

When the relation is one-to-one like between Quote and Film, the intermediate Value message should not be needed?

Code gen always uses optional even for proto3 non-optional fields

When explicitly querying for non-optional fields in a knit request, the resulting Typescript response type has those fields marked as optional. This only seems to apply to fields that are a message type, scalar fields seem to work as expected in this case.

Support specifying transport or headers

There doesn't seem to be any way to specify headers on a request, for example, to provide authentication?

allow in createClient to use window.Fetch instead of fetch when available

Does createClient function have a way to use client window.Fetch instead of internal fetch?

the createPromiseClient function does allow it as it's passed through the createConnectTransport

Support default results for missing fields

When a service doesn't respond with a requested field, we should be able to default the field to the defined default for each type.

Context

While writing integration test mocks for knit endpoints, we often just want to mock sensible defaults without having to be explicit about the values and to just ensure type safety.