Admin Generator asyncSelect: derive query name from field name instead of rootQuery

[Copilot]

• Change default queryName derivation from rootQuery to field name in generateAsyncSelect.ts
• Update JSDoc in generate-command.ts to reflect new default behavior
• Regenerate all affected snapshots
• Update tests: add test for new default (field-name-based), update queryName override test
• Update changeset to minor with breaking change note
• Validate queryName against GraphQL operation name rules; throw a clear error with field name when invalid
• Add tests for invalid queryName (empty string and string with invalid characters)
• Regenerate demo/admin generated files so operation names match new field-name-based default

View original Slack conversation

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Copilot]

Pull request overview

Adds a queryName override to admin-generator asyncSelect/asyncSelectFilter so multiple fields sharing the same rootQuery can generate distinct GraphQL operation names, avoiding gql:types conflicts.

Changes:

• Extend FormFieldConfig for asyncSelect and asyncSelectFilter with optional queryName?: string.
• Use config.queryName (when provided) as the generated GraphQL operation name in generateAsyncSelect.
• Add a unit test for custom queryName behavior and a changeset entry.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
packages/admin/admin-generator/src/commands/generate/generateForm/asyncSelect/generateAsyncSelect.ts	Uses queryName override when building operation name / imported generated types.
packages/admin/admin-generator/src/commands/generate/generateForm/tests/asyncSelect.test.ts	Adds test asserting generated code uses custom query names.
packages/admin/admin-generator/src/commands/generate/generate-command.ts	Updates config typing and documents the new queryName option.
.changeset/async-select-query-name.md	Adds patch changeset documenting the new option and motivation.

[nsams]

@copilot wäre es nicht einfacher wenn der query-name abhängig vom field-name wäre? dann müsste man nichts konfigurieren?
Wenns im Code 3 unterschiedliche queries sind müssen es auch 3 unterschiedliche Namen sein. Auch wenn sie exakt gleich sind
Ah, so lösen wir auch mehrere forms für die selbe entity? Weil in dem Fall geht's ja um selbe query für versch. Fields in der selben Form.
Wenn die queries in mehreren files sind können gleiche Namen verwendet werden
ok, hast du schon verstanden was ich meine? In dem fall haben wir die selbe query/datenquelle für unterschiedliche fields in der entity/form. Die drei asyncSelect-Felder für die entity-fields "visit.corporationParticipant", "visit.participants" und "visit.furtherParticipants" werden mit den daten aus dem "people"-resolver befüllt. wenn wir also den field-name in den query-name der asyncSelects bringen, dann brauchen wir nichts konfigurieren. Es würden also dann diese queries generiert: query CorporationParticipantSelect($search: String) { people(search: $search) {...} } --- query ParticipantsSelect($search: String) { people(search: $search) {...} } --- query FurtherParticipantsSelect($search: String) { people(search: $search) {...} }
nein, hab ich nicht verstanden :) (ich hatte das labelField im kopf) ja, das wäre auch eine gute möglichkeit, bin mir aber nicht sicher ob ich in handgeschriebenen code nicht doch eher PeopleSelect verwenden würde
ich hatte schon die sorge ich übersehe mal wieder irgendwas 😅 Bei mir war es handgeschrieben schon immer z.b. CorporationParticipantSelect, weil der query.name operations-name, so wie ich das verstanden habe, einen bezug zur verwendung und nicht unbedingt zum den gefetchten daten haben sollte. über den query-name operations-name dachte ich sollte man auch die stelle finden können, wo die query abgeschickt wird. aber ich schau noch kurz, ob das andere (=KI) auch so sehen, oder ich mir das nur eingebildet hab 🙂
KI Antwort > Kurzantwort: eher kontext-/intent-bezogen, nicht nur daten-bezogen. > • Daten-bezogen (GetArticles) ist ok für sehr generische Basis-Queries. > • In echten Apps ist kontext-bezogen meist besser (GetHomepageArticles, GetTeamDirectoryPeople), weil man in Logs/Tracing sofort sieht, wofür der Call war. > • Besonders bei mehreren ähnlichen Queries auf dieselben Typen hilft Kontext enorm bei Debugging und Performance-Analyse.
Ja hast schon recht, wäre besser. änder das, bin gespannt ob du das jetzt schaffst
änder das, bin gespannt ob du das jetzt schaffst

[Copilot]

@copilot wäre es nicht einfacher wenn der query-name abhängig vom field-name wäre? dann müsste man nichts konfigurieren?
Wenns im Code 3 unterschiedliche queries sind müssen es auch 3 unterschied...

Changed in 6c62dd1. The default query name is now derived from the field name instead of rootQuery. So three fields all using rootQuery: "people" will automatically generate CorporationParticipantSelect, ParticipantsSelect, and FurtherParticipantsSelect — no configuration needed.

The optional queryName override is still available when the auto-generated name isn't suitable.

Breaking change: existing generated files will have different operation names after re-running the generator (e.g. CategorySelect instead of CategoriesSelect).

[johnnyomair]

@copilot rerun the Admin Generator in demo/admin to fix the lint workflow.

[Copilot]

@copilot rerun the Admin Generator in demo/admin to fix the lint workflow.

Done in f27c2a6. Reran the admin-generator in demo/admin — the generated files now use field-name-based operation names (e.g. CategorySelect, TagsSelect, ManufacturerSelect).