Skip to content

Recommended patterns when using resolvers #4987

Open
@alina-zaieva

Description

@alina-zaieva

From our discussion related to #4967, my understanding is that while Relay resolvers can be used in many different ways, some of them are more idiomatic and have a lower risk of gaps or weird corner cases. I'd like to ask a few questions related to that, and I'd be happy to contribute to the docs afterwards so that this knowledge is captured somewhere 🙂

  1. Should all client-defined types be implemented either as "strong" or "weak" types, and "output" types (i.e., types declared in client schema extensions) should be avoided?
  2. When creating a resolver for a field that corresponds to a one-to-many edge to a strong type (i.e., SomeType.myField: [MyStrongType]), should the resolver return a list of { id: DataID } objects? And if the resolver is live, does it require the strong type resolver to also be live?
  3. When creating a live resolver that does some expensive work (e.g., doing a REST API call), should this expensive work be done in the body of the resolver or in the subscribe function?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions