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 "design" of extensions tries to optimize for extensions being
supported, but not getting in the way. The assumption is that the
most code are likely to not want to care if something is an extension or
a proper definition. So a type is still just one object, regardless of
whether it's components comes from both a definition, an extension or
a mix of those. However, each type lists how many extensions it's
been built from, and each direct component of the type lists if it
comes from an extension.
In other wordds, it's easy to ignore whether something comes from
extensions or not, but it's easy to know if a particular type element
was originally defined in an extension or not. Rebuilding a particular
extension however do require to iterate on the elements of the type
and filter those that belong to the extension we care about.
Alternative designs have been considered:
- having extensions be completely distinct objects from definitions.
However, it feels painful that for a given type name you'll always
have to potentially deal with multiple objects (a definition and a
list of potential extensions).
- Have a hierachy where we have an object for each type, but also
separate object for defintiion and extensions. The "type" object
would point to it's constituent (definition and/or extensions)
but would also have methods to conveniently access all the
elements of the type. In other world, we'd have `ObjectTypeDefinition`
and `ObjecTypeExtensions`, both of which my have `fields`, and
then we have `ObjectType` that points to (at most) an
`ObjectTypeDefinition` and some `ObjectTypeExtensions` and also
expose `fields` which is just a merged iterator over the fields
in the definition and extensions.
In term of exposing extension, this would be fairly clean.
However, this require a lot of reorganisation of the library
and quite a bit of new absctractions. Concept like `SchemaElement`
gets a bit more complicated (you don't want `schema.allSchemaElement`).
to return both `ObjectType` _and_ `ObjectTypeDefinition`/`ObjectTypeExtension`
because that would duplicate things, but you still want to think of
all of those as "schema elements" in other context, and it's unclear
how to not make all of this overly complex. The 'parent' of elements
like fields also become a more complex thing, etc...
- A mix of previous points where you only have `ObjectTypeDefinition`
and `ObjectTypeExtension`, but `ObjectTypeDefinition` has methods
like `ownFields` and `fields` (the later return both `ownFields` and
the extensions fields).
While this simplify some of the question of the previous point
but not all of them (this still complicate the hiearchy quite a bit)
and this introduces other awkwardness (for instance, having
`directives` on an `ObjectTypeDefinition` also including the
directives of the extensions can be a tad suprising at first, but if
you call it `allDirectives` to avoid the confusion, now you get some
inconsistencies with other elements so it's not perfect either.
Tl;dr, while the current design has minor downside, the alternative have
other ones and feels more complex overall.
0 commit comments