feat(store): remove name config option from tables
#818
Conversation
There was a problem hiding this comment.
Agree with name being confusing
I can see it being useful for tables with long prefixes, for example
UnitStatsElementalAttack
UnitStatsElementalDefense
both get cut to UnitStatsElement and conflict with each other,
but it seems fine to expect people to not make such table names
There was a problem hiding this comment.
I'm a little sad these sorts of configurability are going away, but I agree its a little confusing when to use which value (config key vs overridden name). Definitely on board to prioritize simplicity + opinionated and find ways to reintroduce this when it makes sense to do and worth the complexity trade off.
| @@ -163,7 +157,7 @@ export const zTablesConfig = z.record(zTableName, zTableConfig).transform((table | |||
| // default name depends on tableName | |||
| for (const tableName of Object.keys(tables)) { | |||
| const table = tables[tableName]; | |||
| table.name ??= tableName.slice(0, STORE_SELECTOR_MAX_LENGTH); | |||
| table.name = tableName.slice(0, STORE_SELECTOR_MAX_LENGTH); | |||
There was a problem hiding this comment.
is there anything we can do at the type hint level to make folks aware of this limitation? like should a >16 length string fail TS? or warn? does zod provide any helpers for this?
Depends on #815
The
nameconfig option for tables was more confusing than useful. With it we had two ways of setting the "name" of a table: 1. via the table config's key in thetablesconfig, and 2. via thenamefield in the table config. The file name of the autogenerated library always depended on the table config's key in thetablesconfig, while the table metadata and id depended on thenameoption. Using thenameargument also made it much harder to infer client types based on the table's name than using the table config's key in thetablesconfig.This PR removes the
namefield from the user-facing config, so that the config's field is always autofilled with the table config's key in thetablesconfig.