You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 than sdui 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:
write compiler plugin to add common interface for the SDUI related types, for both schema, so the SDUI library can depend on the interface types, while the downstream feature modules can cast the concrete type to the interface type when using the SDUI components
parse the schema document after downloading either schema (using the tooling artifacts?) and extract the parts relevant to SDUI into a synthetic / stub schema that both schema modules include
The text was updated successfully, but these errors were encountered:
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:
you can use “schema-1” types from module “feature-2"
there is some coupling between "feature-1" et "feature-2" (when you reference a new type from "feature-2" , you might end up recompiling "feature-1")
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:
The text was updated successfully, but these errors were encountered: