Open ychescale9 opened 3 months ago
Thanks for reporting this. I don't have an immediate idea of what's the best course of action for you (I think maybe the question can be generalized to "how to share code from 2 separate schemas with common types"), but SDUI in general is definitely something we want to keep under our radar.
Quick note: I think my favorite solution there would be a single schema. That would have 2 issues:
For 1. I wonder if we could use some tooling to restrict types for consumers, potentially based on @requiresOptIn
.
For 2., I'm not sure unless we introduce the possibility to generate types in "intermediate" modules compared to today generating all schema types in the "schema" module.
Use case
Imagine a monorepo with 2 apps, where each app has its own endpoint and graphql schema.
We want to build an app-agnostic server-driven UI framework
:sdui
where we have Composables that depend on some common types in both the 2 schemas:The
:sdui
module would include graphql fragments:and Composable functions that render the generated fragment:
The problem is since each schema needs to have its own service, a downstream module (
:sdui
) would have to choose to use one of the 2 schemas (and service) in order to get the metadata to for generating the code for the fragment, in order to avoid duplicated types from the 2 schemas. This also has a cascade effect where the consumers of:sdui
also needs to add the same service / schema as the ones used in:sdui
, so if a feature module uses a different schema / service thansdui
it would have to depend on both schemas and declare both services, which expose a lot of types and queries that aren't relevant to the feature module and its app.Describe the solution you'd like
I'm not sure exactly what solution I'd like TBH. Perhaps a mechanism to merge a "synthetic" schema from a 3rd module into both schema modules' services, and also allow a library to depend on the "synthetic" module for declaring fragment and generating code that can be consumed by downstream modules that depend on either schema / service?
I've played with a couple of ideas but didn't get far: