SubscribeFieldConfig resolve shouldn't be required about nexus HOT 3 OPEN

Resolve in subscription resolvers is mostly useless, everything is handled through subscribe.

As I understand it, this isn't always true, subscribe sets up the subscription, but the resolve is used to format the data from the published event into the actual shape needed to fulfill the subscription query. If these do map 1:1, for now you can just add an identity function: resolve: t => t as a property the config.

I don't have any strong opinions here, if this is a common enough case I can consider making this optional - didn't really spend as much time thinking about the guarantees around type-safety in subscriptions as in the rest of the schema.

from nexus.

@tgriesser Yesterday, I also stuck with this problem. My subscription returns data from the async iterator as it's needed for the target type. Maybe resolver should be t => t by default?

from nexus.

Ideally resolve is required when the event payloads returned by subscribe are not 1:1, and otherwise optional (possibly even hidden).

Achieving this will require some advanced techniques though, and would probably be out of scope for @nexus/schema.

Need to think it through but roughly I think: 1) we can use the TSC API to extract return type from subscribe 2) compare with return type of what resolve wants 3) require resolve if they differ meaningfully.

That is non-trivial to make robust and performant, but not so bad.

We'd want @nexus/schema to make this possible but the work involved here is, again, out of scope. Only Nexus framework goes to the level of using the TSC API right now.

I think @tgriesser's suggestion is a great one for @nexus/schema users.

I'll leave this issue here for a bit, but probably migrate it to the Nexus repo soon.

from nexus.