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
Core CUE generators - like OpenAPI - generally rely on whether a field is a definition or not to decide whether to generate it as a top-level type. Cuetsy has, thus far, decided to go the attribute-driven approach.
There are pros and cons to each approach, but recently i've been noticing that when a given schema is targeted for multiple output languages (as it is in Grafana, TS and Go), having a divergence in how this works can make for some toil and potential for inconsistency.
In general i still want to keep cuetsy attribute-centric, but it does make sense to me that we might add a configurable mode where visited definition fields are treated as being @cuetsy(kind="interface"). (Or, if we're allowing configurability, maybe we allow the default to be either interface or alias 🤷 )
Not actually sure if this is a good idea, but getting it written down in any case.
The text was updated successfully, but these errors were encountered:
sdboyer
changed the title
Consider adding config option to automatically generate definitions as interfaces
Add config option to automatically generate definitions as interfaces (maybe)
Nov 2, 2022
this becomes really a problem when we want to ask external developers to write schemas for, for example, Plugins.
This stays uncategorised until we decide to pick it up.
Downside of waiting too long is the fact that a bunch of schema will need re-writing to be sure they comply with the standard way of declaring that something should be part of the interface
Core CUE generators - like OpenAPI - generally rely on whether a field is a definition or not to decide whether to generate it as a top-level type. Cuetsy has, thus far, decided to go the attribute-driven approach.
There are pros and cons to each approach, but recently i've been noticing that when a given schema is targeted for multiple output languages (as it is in Grafana, TS and Go), having a divergence in how this works can make for some toil and potential for inconsistency.
In general i still want to keep cuetsy attribute-centric, but it does make sense to me that we might add a configurable mode where visited definition fields are treated as being
@cuetsy(kind="interface")
. (Or, if we're allowing configurability, maybe we allow the default to be either interface or alias 🤷 )Not actually sure if this is a good idea, but getting it written down in any case.
The text was updated successfully, but these errors were encountered: