dataconnect: Export all generated types/enums at root and convert Enums to TS-idiomatic string unions

[vzsolt1981]

Operation response types, model shapes, and enum definitions are generated internally but not cleanly re-exported at the top-level index module. Developers are forced to use utility types like Awaited<ReturnType> or deep internal imports just to type component props, state, or helper functions.

GraphQL enums are currently generated as standard TypeScript enum constructs. In modern TypeScript, standard enums carry runtime overhead, nominal typing quirks, and poor ergonomics when passing raw strings (e.g., from API payloads, form inputs, or route params).

[aalej]

Thanks for the feedback! I tried reproducing the behavior you mentioned and I was able to reproduce parts of it and here are my findings. I am using this mcve - https://github.com/aalej/issue-10908

Operation response types, model shapes, and enum definitions are generated internally but not cleanly re-exported at the top-level index module.

For operation response types and enum definitions: Operations response types and enums are exported at the top level index.d.ts

• operations response types: https://github.com/aalej/issue-10908/blob/ed89858a5daae6221a7ae3fa9a08e545f3df8104/my-react-app/src/dataconnect-generated/index.d.ts#L20-L46
• enums: https://github.com/aalej/issue-10908/blob/ed89858a5daae6221a7ae3fa9a08e545f3df8104/my-react-app/src/dataconnect-generated/index.d.ts#L12-L16

If these aren't being cleanly exported in your generated SDK, there might be a specific edge case or bug. Could you share a code snippet showing your import statements or a snippet of your generated index.d.ts? Let me know in case I may have misunderstood this feedback

For model shapes: This is true, the model shapes aren't generated as stand alone types. Using the mcve as reference, I would expect an Item type, but instead the properties are inline inside operation response types

GraphQL enums are currently generated as standard TypeScript enum constructs. In modern TypeScript, standard enums carry runtime overhead, nominal typing quirks, and poor ergonomics when passing raw strings (e.g., from API payloads, form inputs, or route params).

This is also true, currently enums are generated as TypeScript enum constructs which carry nominal typing quirks and runtime overhead.

[vzsolt1981]

Hey.

let's say i have an item schema with a query:

type Item @table {
  createdAt: Timestamp! @default(expr: "request.time")
  name: String! @col(dataType: "varchar(50)") @searchable(language: "hungarian") @unique
  note: String @searchable(language: "hungarian")
  unit: InventoryUnit!
  updatedAt: Timestamp! @default(expr: "request.time")
}

query ListItems @auth(level: USER) {
  items(orderBy: [{ name: ASC }]) {
    id
    name
    unit
  }
}

The generated interface.

export interface ListItemsData {
  items: ({
    id: UUIDString;
    name: string;
    unit: InventoryUnit;
  } & Item_Key)[];
}

While queries have exported interfaces (types would also be better here) for their result, they are all unique shapes, the Item table definition is never transformed into a TS type. This is not ideal to work with, since they lack a common ancestor - or being a mutation of it. The returned types lose some of their context.

An example based on same schema:

export type Item = {
  createdAt: TimestampString;
  id: UUIDString;
  name: string;
  note: string | null;
  unit: InventoryUnit;
  updatedAt: TimestampString;
}

export type ListItemsData = {
  items: Array<Pick<Item,'id' | 'name' | 'unit' >>;
}

When it comes to combined results from multiple tables, it's even less confusing for work with.

Also, while this is completely valid:

export interface Item_Key {
  id: UUIDString;
  __typename?: 'Item_Key';
}

This is more idiomatic way to do it, and way easier to work with:

export type Item_Key = UUIDString & { __typename: 'Item_Key'};